DEV Community: Saiful Siam

Motion Mind Is Now Motion Mind X

Saiful Siam — Sun, 11 Oct 2026 12:12:14 +0000

Motion Mind Is Now Motion Mind X

Today, I'm officially announcing a name change for my brand.

Motion Mind is now Motion Mind X.

🌐 Official website: https://motionmindx.com

Why Did I Change the Name?

When I first started programming, I chose the name Motion Mind for my own brand. At that time, I didn't know that the name was already being used elsewhere.

Over time, I introduced my projects under this name and continued building my identity around it. Projects like LeveloJS and Kivex became part of the Motion Mind ecosystem.

So, changing the entire name wasn't something I wanted to do. I wanted a name that felt more unique while keeping the identity I had already built.

That's why I decided to change the name to Motion Mind X.

I haven't come across another brand using this exact name so far, and I believe it gives my brand a more distinctive identity without losing its connection to the original Motion Mind.

What Changes Now?

The official brand name is now Motion Mind X.

However, my nickname, MotionMind2007, which I've used across different platforms, will remain unchanged.

My existing projects and the identity I've built around Motion Mind will continue under the new brand name.

From now on, In-sha-Allah, you'll find my projects under Motion Mind X.

A New Name, The Same Journey

This isn't the beginning of a completely new brand. It's the next step for something I've already been building.

I'm grateful to everyone who has followed my journey so far, and I hope you'll continue being part of it.

Thank you for being here.

Welcome to Motion Mind X.

🌐 https://motionmindx.com

LeveloJS Went Quiet. We Were Rebuilding the Foundation.

Saiful Siam — Fri, 25 Sep 2026 19:39:36 +0000

LeveloJS Went Quiet. We Were Rebuilding the Foundation.

It has been almost a month since we shared a major update about LeveloJS.

If you have been following the project, you may have noticed that we have been unusually quiet.

LeveloJS has not stopped.

Actually, quite the opposite.

For the last month, we have been working on a much bigger change than another framework feature or API improvement.

We are rethinking the architecture of LeveloJS with one long-term goal in mind:

Can LeveloJS become a true multi-platform framework?

And that question has changed a lot of things.

A New Collaboration

This work is now being done by two developers: me and Joseph, a Nigerian developer with more than 10 years of programming experience.

Joseph is not new to building software.

We previously worked together on Kivex, an icon library, where I had the opportunity to review and work with his code. That experience also gave me the opportunity to learn from the way a developer with many years of experience approaches architecture and implementation.

I have been programming for a little over a year.

Joseph has been programming for more than a decade.

That difference in experience is one of the reasons this collaboration has been valuable for me personally as well.

Now we are bringing that collaboration into LeveloJS.

The objective is simple to describe, even though the engineering behind it is not:

We want to take LeveloJS beyond the browser.

But Why Multi-platform?

This is probably the biggest question.

Why not simply keep building LeveloJS as a web framework?

The web already has extremely strong frameworks.

React, Next.js, Vue, Svelte, SolidJS, and many others have already solved many of the problems developers face when building modern web applications.

We looked at that ecosystem and asked ourselves something:

If we build another framework that mainly tries to compete with those frameworks, what new thing are we actually giving to the next generation of developers?

We don't want LeveloJS to exist simply as another React-like, Solid-like, or Svelte-like framework.

Those projects are already doing excellent work.

Instead, we want to explore a different direction.

Build on What Already Exists

Programming history has many examples where progress did not necessarily come from replacing an existing idea with another version of the same thing.

One well-known example is the evolution from C toward C++.

Bjarne Stroustrup did not simply try to create "another C."

C++ extended the ideas of C and introduced a different programming model on top of them.

Another modern example is Next.js.

Next.js did not attempt to replace React with an unrelated rendering model. Instead, it built on React and expanded what developers could build around it.

These examples represent an idea that we find interesting:

Sometimes the next step is not to replace the existing foundation. It is to expand where that foundation can go.

That's the philosophy we want to apply to LeveloJS.

Instead of asking:

"How can we build another web framework?"

we started asking:

"What can we build if LeveloJS is not limited to the web?"

And that question eventually led us to multi-platform development.

Our Goal: Write Once, Run Anywhere

The idea behind our current research is simple:

Write LeveloJS code once and target multiple platforms.

Our long-term target includes:

Android
iOS
Windows
macOS
Linux
Web

We are inspired by the general idea behind "write once, run anywhere" development.

But we are not claiming that LeveloJS has already achieved this.

It hasn't.

We are researching how far it is actually possible to take the idea.

There are many difficult technical problems ahead.

And we don't know yet how many of our current ideas will survive the research.

But we believe the problem is worth exploring.

But Doesn't React Native Already Do This?

Yes.

React Native already provides a way to build applications for platforms such as Android and iOS using React and JavaScript.

So why are we researching another approach?

The answer is that our goals are different.

One thing we find interesting about React Native is that developers work with platform-oriented components such as:

View

Text

TouchableOpacity

For a web developer moving into React Native, this means learning a new set of components and a different UI vocabulary.

We are exploring whether LeveloJS can take a different approach.

Instead of asking a web developer to abandon the familiar JSX elements they already know, we are researching whether the same JSX development model and familiar web-style elements can be used as the input for a multi-platform rendering architecture.

In other words:

We want to explore how far the existing JavaScript + JSX experience can travel.

This is still research.

We are not saying that every browser element can magically become a native component on every operating system.

The challenge is precisely figuring out how such a system could work.

We Are Thinking Beyond Android and iOS

Another reason we are approaching this problem differently is platform coverage.

React Native's core ecosystem primarily targets Android and iOS, while projects such as React Native for Windows provide additional platform support with platform-specific architecture.

That is useful, but it also demonstrates how difficult true multi-platform rendering actually is.

Our research is aimed at a broader question:

Can one LeveloJS architecture be designed to target fundamentally different operating systems without forcing developers to learn a completely separate application architecture for each one?

That means thinking about:

mobile
desktop
web
operating-system differences
rendering
platform APIs
performance
type safety
security
and developer experience

This is much larger than simply adding another renderer.

Rethinking the LeveloJS Architecture

Once we decided that multi-platform was the direction, we realized that the old browser-oriented architecture could not simply remain unchanged.

The original LeveloJS architecture was designed primarily around the web.

That made sense.

But a multi-platform framework needs a foundation that is not tightly coupled to one platform's rendering model.

So we started redesigning parts of the architecture.

The JSX tree is now being treated much more deliberately.

We are experimenting with representing individual elements and their relationships in a way that gives the renderer greater control over what each part of the application actually represents.

This is one of the reasons the architecture is becoming more complex—and potentially more capable.

Type Safety Is Becoming More Important

Another major direction of the new architecture is type safety.

We are trying to make the system as type-safe as realistically possible.

For us, this isn't just about getting better autocomplete.

When the same application is expected to target multiple environments, the underlying representation becomes much more important.

We want the architecture to make invalid states harder to create and the relationship between the application structure and rendering system more explicit.

There is still work to do here.

But type safety is now part of the architectural direction rather than something we want to add later.

Security Is Also Part of the Redesign

The new architecture is also being designed with stronger security considerations.

Because we are treating the JSX tree and individual elements more explicitly, we have more control over how those pieces are represented and processed.

This gives us a better foundation for introducing stronger boundaries and safer behavior.

We are still researching and implementing these changes, so we don't want to make exaggerated claims about security.

What we can say is:

Security is being considered as part of the architecture itself, rather than as an afterthought.

Why Rust?

One of the more interesting things we are currently researching is the renderer.

We are experimenting with using Rust in the rendering architecture.

The reason is straightforward.

When you start targeting multiple platforms, performance and low-level control become increasingly important.

A browser framework can rely heavily on browser APIs and the browser's rendering environment.

A multi-platform framework has to think beyond that.

We want a rendering layer that can potentially provide:

high performance
predictable behavior
stronger type guarantees
low-level control
and a foundation suitable for multiple platforms

Rust is one of the technologies we are exploring to help achieve that.

This is still experimental.

We are not announcing a final renderer architecture yet.

There Is One Part We Are Keeping Secret

There is one particularly important part of our multi-platform architecture that we are intentionally not revealing yet.

It concerns how the rendering system will actually work across different platforms.

We already have a direction and ongoing research around it.

But we want to reveal that part together with the relevant LeveloJS feature release.

So for now, we will simply say:

The renderer is being designed around the multi-platform goal from the beginning.

When the implementation is ready, we will explain the architecture publicly.

Why We Chose This Direction

At the end of the day, this isn't about trying to prove that LeveloJS is better than React, Svelte, SolidJS, Vue, or any other framework.

Those frameworks already have strong ecosystems and solve real problems.

We simply don't want to spend our time rebuilding something that already exists in many forms.

We want to explore a problem that is different.

If a developer already knows JavaScript and JSX, could they use that knowledge to build software for multiple platforms?

Could the same development philosophy extend from a website to a desktop application, mobile application, and other environments?

Could we reduce the amount of platform-specific knowledge required to get started?

Those are the questions behind LeveloJS Multi-platform.

What We Want for the Next Generation of Developers

We don't believe developers should stop learning native technologies.

Learning Kotlin, Swift, Flutter, Rust, platform APIs, or other technologies can be extremely valuable.

But we also believe that every platform should not necessarily require a developer to start from zero.

A web developer already knows how to think in JavaScript.

They already understand components, state, events, JSX, and application logic.

If LeveloJS can preserve more of that knowledge while allowing developers to reach other platforms, we think that could make application development more accessible.

That is the opportunity we see.

Not replacing native development.

Not replacing existing frameworks.

But creating another path.

Where We Are Now

At the moment, LeveloJS Multi-platform is still under active research and development.

We are working on:

architectural redesign
multi-platform rendering research
JSX tree representation
type-safety improvements
security considerations
Rust-based rendering experiments
and the overall "write once, run anywhere" direction

We don't know exactly where this research will end.

Some ideas will work.

Some will need to change.

Some may fail completely.

That's part of building something new.

But the work is ongoing.

Help Us Explore This

This is also where the community can help.

If you have experience with:

multi-platform frameworks
rendering engines
compiler architecture
Rust
JavaScript runtimes
native application architecture
cross-platform UI systems
or "write once, run anywhere" technologies

we would genuinely like to hear your ideas.

If you have already researched a similar problem, found an interesting architecture, or simply have an idea that could help us think about LeveloJS differently, share it with us.

Your research may help us avoid mistakes.

It may even help shape the architecture.

We are not trying to pretend that we already know everything.

We are researching.

We are learning.

And we are building.

So, Why Was LeveloJS Quiet for a Month?

Now you know.

For almost a month, we didn't have a major public update because we were working on something that required us to rethink the foundation of LeveloJS.

Joseph and I started this collaboration with a bigger goal:

to explore whether LeveloJS can evolve from a web framework into a multi-platform framework.

That requires architectural changes.

It requires research.

It requires experimentation.

And it requires accepting that we may not have all the answers yet.

But that's okay.

We don't know how far we can take this.

We are putting our trust in Allah and doing the work.

In-sha-Allah, LeveloJS will have a very different story to tell in its next chapter.

This is not the end of LeveloJS as a web framework.

It's an exploration of what LeveloJS could become beyond the web.

The foundation is changing.

The research has started.

And the next chapter is being built.

Why I Built NGCBD: A Dedicated Community for Passionate Bangladeshi Developers

Saiful Siam — Wed, 12 Aug 2026 10:41:05 +0000

NGCBD(Next-Gen CodeCrafters BD): A Dedicated Community for Passionate Bangladeshi Developers

Bangladesh has a growing community of passionate developers, students, researchers, freelancers, and technology enthusiasts. Every day, many of them learn, build, experiment, contribute to open source, and create meaningful digital products.

Yet many of these builders face the same silent problem: they build in isolation.

A project may take months of research, design, debugging, and optimization, but after publishing it online, the creator often receives only a few generic comments such as “Nice project!”. Encouragement is valuable, but it rarely helps a developer grow.

Serious builders need serious feedback:

Is the architecture scalable?
Is the code modular and maintainable?
Are there performance bottlenecks?
Is the UI accessible and production-ready?
Is the repository documented well enough for contributors?

This gap is exactly why NGCBD (Next-Gen CodeCrafters BD) was created.

Official website: https://ngcbd.motionmind.me

The Origin & Vision

Building high-quality engineering tools requires more than technical skill—it requires passion, persistence, and a community that believes in builders.

As the creator and CEO of Motion Mind, I built Levelo.js, a lightweight custom frontend framework, and the Kivex Ecosystem, a family of developer packages featuring 300+ handcrafted icons. These tools were created through countless late nights of experimentation, debugging, and learning.

Levelo.js: https://github.com/motionmind2007/Levelo-Js
Kivex Icons: https://github.com/motionmind2007/kivex

But after building production-ready software, I discovered a painful truth:

Great software can still remain invisible when there is no strong engineering community around it.

I realized that this was not only my problem. Across Bangladesh, thousands of talented developers are creating frameworks, libraries, SaaS products, mobile apps, research projects, and open-source tools without receiving meaningful technical feedback or collaboration opportunities.

That realization became the seed of NGCBD.

We built NGCBD so that every Bangladeshi developer can find a peer circle, gain inspiration, receive honest engineering feedback, and build software that truly matters.

Our dream is simple:

No talented Bangladeshi developer should feel isolated while building something meaningful.

Whether you are a student coding on a low-end laptop, a freelancer shipping client products, or a researcher exploring new ideas, this community is built for you.

What Makes NGCBD Different?

Most programming communities eventually become tutorial-sharing groups, job-posting boards, or noisy social feeds.

NGCBD was designed with a different philosophy: high signal, low noise.

We prioritize:

research-level project showcases,
architecture discussions,
performance engineering,
open-source collaboration,
peer code reviews,
and production-quality software practices.

This is not a place for endless forwarded posts or course marketing. It is a place for builders who are actively creating technology.

Learn more: https://ngcbd.motionmind.me/about

A Platform for Research-Level Projects

We encourage submissions that go beyond beginner tutorials. Examples include:

custom frameworks,
compilers and tooling,
developer utilities,
AI/ML experiments,
system design projects,
SaaS platforms,
mobile applications,
and open-source libraries.

The goal is to create a public Proof of Work archive that demonstrates real engineering depth.

Project Showcase: https://ngcbd.motionmind.me/showcase

Expert Code Reviews That Actually Help

Every serious submission is evaluated on multiple dimensions:

architecture and scalability,
code organization,
performance optimization,
UI/UX quality,
accessibility,
documentation,
and maintainability.

A good review should help a project become better, not simply judge it. We want developers to leave with actionable improvements they can implement immediately.

Review guidelines: https://ngcbd.motionmind.me/docs

The Zero Pressure Philosophy

One of the biggest problems in developer communities is unhealthy competition. Weekly sprints, daily streaks, and unrealistic targets often discourage builders instead of motivating them.

NGCBD follows a Zero Pressure Philosophy.

Bi-Monthly League Cycles

Our leagues run in 2-month cycles, giving members enough time to build meaningful projects alongside studies, jobs, or freelance work.

No Forced Participation

If you skip a cycle, nothing happens. You can observe reviews, improve privately, and submit whenever you feel ready.

No Course Upsells

NGCBD is not built to sell courses. Growth is self-paced, research-driven, and based on real engineering effort.

Compete, Learn, and Get Recognized

At the end of each cycle, outstanding projects and contributors receive recognition through:

leaderboard rankings,
featured showcases,
verified badges,
and exclusive community rewards.

Recognition is based on merit and engineering quality, not popularity.

Current leaderboard: https://ngcbd.motionmind.me/leaderboard

The Motion Mind Ecosystem

NGCBD operates under the Motion Mind open-source ecosystem. Developers may also experiment with tools such as:

Levelo.js — a custom high-performance frontend framework,
Kivex — a cross-platform icon ecosystem.

Community members who adopt and provide feedback on these tools help strengthen homegrown Bangladeshi developer infrastructure.

Explore the ecosystem:

Why Peer Review Matters for Your Career

A reviewed repository tells a very different story from an unreviewed one.

When recruiters or collaborators see:

public commits,
documented architecture,
review discussions,
and iteration history,

they can evaluate not only what you built but also how you think as an engineer. In many technical interviews, that is far more valuable than a polished screenshot.

Open Source Is at the Heart of the Community

We encourage members to:

open issues,
submit pull requests,
review peer repositories,
improve documentation,
and contribute beyond their own projects.

A GitHub profile filled with meaningful contributions demonstrates collaboration, problem-solving, and long-term engineering engagement.

GitHub organization: https://github.com/Motion-Mind-Lab/Next-Gen-CodeCrafters-BD

Integrity Above Everything

We welcome inspiration, libraries, and open-source foundations with proper attribution. What we do not accept is plagiarism.

A healthy engineering ecosystem depends on trust, transparency, and respect for original work.

Community rules: https://ngcbd.motionmind.me/rules

Who Should Join?

NGCBD is open to Bangladeshi programmer or aspiring programmer who loves technology and wants to grow through building and learning.

Whether you are:

a school student writing your first lines of code,
a college or university student,
a hobbyist experimenting with programming,
a freelancer working with clients,
a professional software engineer,
an open-source contributor,
or a researcher exploring advanced ideas,

you are welcome here.

Age is not a barrier. A curious 7-year-old beginner and an experienced 45-year-old developer can both learn from the same community.

If you enjoy coding, creating projects, sharing ideas, and growing together with fellow Bangladeshi developers, NGCBD is for you.”

Join the Community

If this vision resonates with you, start exploring the ecosystem today:

Website: https://ngcbd.motionmind.me
Documentation: https://ngcbd.motionmind.me/docs
Showcase: https://ngcbd.motionmind.me/showcase
Leaderboard: https://ngcbd.motionmind.me/leaderboard
About: https://ngcbd.motionmind.me/about
GitHub: https://github.com/Motion-Mind-Lab/Next-Gen-CodeCrafters-BD
Facebook Group: https://facebook.com/groups/916416137573001
WhatsApp Community: https://wa.me/8801804187223?text=Hi%20NGCBD%20Team!%20I%20want%20to%20get%20an%20invite%20for%20the%20developer%20community.

Final Thoughts

I started programming with limited resources and learned largely through experimentation and open-source communities. I know how difficult it can be to grow without a strong technical network.

NGCBD is our attempt to build the community we wish we had when we started.

If you have ever worked on a project and wished someone would truly understand it, review it, improve it, or be inspired by it, then this community was built for people like you.

Let us create a future where Bangladeshi developers are not only consumers of technology, but creators of world-class engineering products together.

Built for builders, by builders.

Building Dynamic Routing for My JavaScript Framework (Levelo JS 2.2.0) — One Last Test Before Bed Changed Everything 🚀

Saiful Siam — Mon, 10 Aug 2026 14:59:37 +0000

Building Dynamic Routing for My JavaScript Framework (Levelo JS 2.2.0) — One Last Test Before Bed Changed Everything 🚀

I'm a student who enjoys building things from scratch.

For the past few months, I've been researching and building my own JavaScript framework called Levelo JS. Every feature I add teaches me something new about how modern frameworks work internally.

Today I'm releasing Levelo JS v2.2.0, a feature-focused update that introduces dynamic routing, a new params API, ref support, and several improvements to the routing system.

It Worked... Until I Tested It 😅

After hours of work, I finally finished implementing dynamic routing.

I added route pattern parsing.

I added parameter extraction.

I connected everything together.

Everything looked correct.

It was already late at night, and before going to sleep I thought,

"Let me test it one last time."

That one decision completely changed my evening.

The router simply refused to work.

No dynamic routes.

No page switching.

Nothing.

The Bug I Couldn't Stop Thinking About

Since Levelo JS is a Single Page Application framework, page navigation happens without reloading the browser.

When I tested the new router, something felt completely wrong.

At first, I thought the bug was somewhere inside my route matching logic.

So I checked the regular expressions.

I checked parameter parsing.

I checked the navigation flow.

Everything looked fine.

But the router still wasn't working.

It was already late, so I decided to stop for the night and get some sleep.

Even then, the bug stayed in the back of my mind.

The Next Morning

The next morning, I opened my editor almost immediately.

Instead of writing new code, I started reading my existing implementation.

Then I suddenly remembered something.

I had actually faced a very similar problem before...

...and somehow completely forgot about it. 😂

Sometimes your own old code becomes the best documentation.

The Real Problem

The router wasn't the problem.

The route matching wasn't the problem.

The History API wasn't the problem.

The real issue was how I was updating the DOM.

Instead of trying to reuse the existing rendered page, I discovered that removing the old page node completely and creating a fresh one worked much better for Levelo JS.

The change itself was surprisingly small:

container.removeChild(currentRenderedNode);

After removing the previous page, the framework creates a new component instance and mounts it again.

That simple architectural change fixed the routing issue.

Looking back, solving it the next morning taught me an important lesson about how my framework should manage DOM updates.

Dynamic Routing is Finally Here 🎉

With that solved, Levelo JS now supports routes like this:

<Page path="/user/:id" component={UserPage} />

You can access route parameters directly:

import { params } from "levelojs";

console.log(params.id);

Internally, Levelo JS now:

Parses route patterns into optimized regular expressions.
Extracts dynamic parameters automatically.
Updates pages without refreshing the browser.
Integrates with the History API for SPA navigation.

A Cleaner Router Architecture

While implementing dynamic routing, I also decided to reorganize the routing system.

Previously, most of the routing logic lived inside a single runtime file.

Now it's separated into dedicated modules:

src/router/
├── Page.ts
├── Pages.ts
└── params.ts

This structure is much easier to maintain and gives me a better foundation for future routing features.

A New `params` API

Since dynamic routes are now supported, I wanted accessing route parameters to feel simple.

That's why Levelo JS now officially exports a params API, making it easy to read URL parameters anywhere they're needed.

`ref` Support

After finishing the routing system, I thought,

"Why not add ref support as well?"

Fortunately, this feature was much smoother to implement.

Levelo JS now supports:

Object refs
Callback refs

along with proper TypeScript typings for native DOM elements.

Better SPA Title Handling

This update also fixes a small but important SPA issue.

Previously, if a page didn't define its own head() configuration, the previous page title could remain visible.

Now Levelo JS automatically restores the default document title whenever necessary, making navigation behave much more naturally.

What I Learned

Building a framework isn't only about adding features.

It's also about questioning your own assumptions.

This time, I was convinced the router itself was broken.

In reality, the routing algorithm was working.

The regular expressions were working.

The parameter extraction was working.

The actual problem was the DOM update strategy.

Sometimes the hardest bugs aren't caused by complicated code—they're caused by a small architectural decision hiding in plain sight.

Still Learning

One thing I'd like to mention is that I'm still a student.

Levelo JS isn't a commercial framework—it's a research project that I build to understand how modern JavaScript frameworks work internally.

Every new feature, every bug, and every refactor teaches me something new.

Version 2.2.0 is another step in that learning journey, and I'm excited to keep improving it.

If you're interested in framework development or enjoy seeing how things work under the hood, I'd love to hear your feedback.

Thanks for reading! ❤️

Kivex Just Crossed 300+ Icons — 107 New Icons and Package Fixes

Saiful Siam — Thu, 06 Aug 2026 15:02:01 +0000

Kivex Just Crossed 300+ Icons — 107 New Icons and Package Fixes

Kivex just got a pretty big update. 🚀

With the latest update, 107 new icons have been added to the Kivex ecosystem, bringing the total collection to 309 icons.

That means Kivex has officially crossed the 300+ icon milestone.

And while the icon collection is the main highlight of this update, there were also a few small but important improvements under the hood.

🎨 107 New Icons

The biggest part of this update is, of course, the icons.

107 new icons have been added to Kivex, expanding the collection from its previous size to 309 icons in total.

This gives developers a much broader set of icons to work with while keeping Kivex focused on a consistent and reusable icon system.

Whether you're building a web application, developer tool, dashboard, mobile application, or something completely different, having a larger icon set makes it easier to stay within the same visual language instead of mixing icons from multiple libraries.

📦 Kivex Is Now a 300+ Icon Ecosystem

Kivex isn't just a single icon package.

It's an ecosystem designed to make the same icon collection available across different platforms and frameworks.

With 309 icons now available, the ecosystem is continuing to grow while keeping the goal simple:

One icon collection. Multiple platforms. Consistent design.

The goal isn't simply to keep increasing the number of icons.

It's to build a collection that developers can actually use across their projects without having to constantly search for another icon library whenever they need something new.

🛠️ Small Package Fixes

Along with the new icons, a few small bugs were also fixed in the package ecosystem.

Packages including Kivex React and Kivex Solid, along with some other Kivex packages, received fixes to their package.json files.

These weren't major API changes or flashy new features, but they were important cleanup fixes to make the packages more reliable and consistent for developers using them.

Sometimes the small fixes matter just as much as the big features.

🚀 What's Next for Kivex?

Crossing 300 icons is a nice milestone, but this isn't the finish line.

Kivex is still evolving, and the focus remains on expanding the icon collection while improving the ecosystem around it.

For now:

107 new icons.
309 icons total.
A few package fixes.
And Kivex keeps moving forward. ❤️

If you've been using Kivex already, thank you for being part of the journey.

And if you haven't tried it yet, now might be a pretty good time to take a look.

❤️ Like Kivex?

If you find the Kivex ecosystem useful or simply like what we're building, consider giving the project a ⭐ Star on GitHub. It helps the project get more visibility and motivates us to keep improving and expanding the ecosystem.

⭐ Star Kivex on GitHub

And if you'd like to become a contributor to the Kivex ecosystem, you're more than welcome!

One of the best ways to contribute is by creating new icons and helping expand the Kivex icon collection. If you have ideas for useful icons that you'd like to see in Kivex, we'd love to have you contribute them.

Your icons could become part of Kivex. 🎨

Kivex is still growing, and we'd love to build that growth together with the community.

309 icons today. More to come, In-sha-Allah. 🚀

LeveloJS v2.1.2 — A Cleaner JSX Runtime Architecture

Saiful Siam — Thu, 23 Jul 2026 12:35:06 +0000

LeveloJS v2.1.2 — A Cleaner JSX Runtime Architecture

After releasing LeveloJS v2.1.1, I started writing the documentation for the new JSX type support. While reviewing the implementation, I realized that although everything worked correctly, there was a flaw in the internal architecture.

The JSX runtime and its type definitions were connected in a way that wasn't as clean or maintainable as I wanted. Instead of leaving it that way, I paused the documentation work and decided to refactor the entire JSX module before moving forward.

The result is LeveloJS v2.1.2.

Why another update so soon?

Sometimes a feature is functionally correct, but the implementation behind it isn't ideal.

As I prepared to write the documentation, I noticed that the JSX module structure could become difficult to maintain as the framework grows. Rather than building more features on top of that design, I chose to improve the foundation first.

This release is mostly about internal architecture, TypeScript integration, and developer experience.

What's Changed

Reorganized the JSX Runtime

Previously, the JSX runtime and its type declarations lived in different locations.

They have now been reorganized into a dedicated module:

src/runtime/jsx/
├── jsx-runtime.ts
└── jsx.d.ts

Keeping the runtime implementation and its type definitions together makes the project structure much easier to understand and maintain.

Removed Unnecessary Coupling

Previously, jsx.d.ts relied on the package entry (index.ts) to expose JSX types.

In v2.1.2, the type definitions are linked directly with jsx-runtime.ts, allowing the runtime to manage its own typings without depending on the root entry point.

This creates a cleaner separation of responsibilities and simplifies the internal architecture.

Improved DTS Bundling

While restructuring the JSX module, I also fixed declaration build issues that appeared during tsup builds.

This resolves errors such as:

Module has no exported member 'h'

The runtime and declaration files are now synchronized correctly, resulting in more reliable declaration generation.

Better Ambient JSX Typings

This release also improves the overall TypeScript experience.

It fixes issues including:

This JSX tag requires 'h' to be in scope

and CSS side-effect import errors by integrating the ambient JSX types directly into the new runtime pipeline.

As a result, JSX works more naturally with fewer manual configuration steps.

Why This Matters

Framework development isn't only about introducing new APIs.

A clean internal architecture makes future development easier, reduces maintenance, and helps prevent issues before they appear.

Although most users won't notice these improvements immediately, they provide a much stronger foundation for upcoming features in LeveloJS.

Changelog

Fixed & Refactored

Reorganized the JSX runtime into a dedicated src/runtime/jsx/ module.
Moved jsx.d.ts and jsx-runtime.ts into the same directory.
Removed the dependency between jsx.d.ts and the package entry point.
Linked JSX type definitions directly with the runtime module.
Fixed DTS bundling issues during tsup builds.
Resolved Module has no exported member 'h' build errors.
Fixed ambient JSX typing issues.
Resolved This JSX tag requires 'h' to be in scope.
Improved CSS side-effect import support.
Simplified the internal JSX architecture for future development.

Looking Ahead

With the JSX runtime architecture now cleaned up, I can continue working on documentation and future framework features with a much stronger foundation.

More improvements are already on the way.

If you're interested in modern JavaScript frameworks or TypeScript tooling, feel free to check out the project and share your feedback.

GitHub: https://github.com/MotionMind2007/Levelo-JS

Documentation: https://levelojs.motionmind.me

Splitting the Compiler from the Runtime in Levelo JS

Saiful Siam — Sat, 18 Jul 2026 05:24:53 +0000

Splitting the Compiler from the Runtime in Levelo JS

Yesterday was focused on improving the architecture of Levelo JS rather than adding flashy features.

One of the biggest changes was separating the Vite compiler from the core framework.

Previously, the compiler lived inside the main levelojs package. Now it has been extracted into its own package:

Installation:

npm install levelojs vite-plugin-levelojs

pnpm add levelojs vite-plugin-levelojs

This makes the runtime cleaner, easier to maintain, and allows the compiler to evolve independently.

What's New

Batch Updates

Levelo JS now includes a new batch() API.

batch(() => {
  setCount(v => v + 1);
  setUser("MotionMind");
  setCount(v => v + 1);
});

Multiple state updates are grouped together, reducing unnecessary reactive executions and improving performance.

Reactive Input Tracking

Reactive value binding for form elements has been improved.

Previously, updating a signal didn't automatically synchronize the value of inputs in every case.

Now developers can simply write:

const [message, setMessage] = state("");

<input
  value={message()}
  onInput={(e) => setMessage(e.target.value)}
/>

The input stays synchronized with the reactive state automatically.

Dedicated Vite Plugin

The compiler is now available as an official package:

vite-plugin-levelojs

It compiles JSX into optimized h() calls at build time, eliminating the need for a Virtual DOM.

Runtime Refactoring

The internal JSX runtime has also been reorganized.

The h() factory has been extracted into its own runtime module for better code organization and maintainability.

Verified in a Real Project

After publishing the new packages, everything was tested inside a real Vite application.

The compiler, runtime, JSX transformation, and reactivity all worked as expected.

This update isn't about adding new UI features.

It's about making the foundation stronger before building bigger things on top of it.

More improvements are coming soon.

GitHub: https://github.com/motionmind2007/levelojs

Documentation: https://levelojs.motionmind.me

Introducing Kivex: A Production-Ready Multi-Platform Icon Ecosystem

Saiful Siam — Fri, 17 Jul 2026 06:47:12 +0000

Introducing Kivex: A Production-Ready Multi-Platform Icon Ecosystem

Every developer has faced this situation.

You start a new project, search for an icon library, install it, and begin building.

A few weeks later, another project comes along—this time with a different framework. Suddenly you're searching for another icon package, learning a different API, and trying to keep the design consistent across platforms.

I wanted a better solution.

That's why I built Kivex.

What is Kivex?

Kivex (Kinetic Vector Exchange) is an open-source, production-ready icon ecosystem designed for modern applications.

Instead of maintaining different icon libraries for different frameworks, Kivex provides a single collection of 200+ lightweight, pixel-perfect SVG icons that can be used across multiple platforms while keeping the same visual identity.

The goal is simple:

One icon library. Multiple platforms. Consistent design.

Why Kivex?

When building applications across different technologies, consistency matters.

Kivex focuses on providing the same icons, the same names, and the same design language everywhere.

Highlights

200+ pixel-perfect SVG icons
Multi-platform ecosystem
Lightweight and optimized
TypeScript support
MIT Licensed
Completely open source

Current Packages

The Kivex ecosystem currently includes:

kivex-icons — Core JavaScript package
kivex-react
kivex-levelo
kivex-solid
kivex-svelte
kivex-vue
kivex-react-native
kivex_flutter

Every package shares the same icon collection, making it easy to switch between frameworks without changing icon names or redesigning your UI.

Designed for Modern Development

Whether you're building:

🌐 Web Applications
📱 Mobile Apps
🖥️ Desktop Applications

Kivex aims to provide a familiar and consistent developer experience.

Instead of treating every framework as a separate project, Kivex treats them as part of the same ecosystem.

The Vision

Kivex isn't just another icon package.

The vision is to build a complete icon ecosystem that developers can rely on regardless of the framework they're using.

Future plans include:

More icons
More platform integrations
Official documentation website
Icon search experience
Better developer tools
Community-driven contributions

This is only the beginning.

Open Source First

Kivex is developed as an open-source project because great developer tools grow through community collaboration.

Bug reports, feature requests, pull requests, and discussions are always welcome.

If you'd like to contribute, feel free to join the project.

GitHub

⭐ Repository

https://github.com/MotionMind2007/Kivex

If you find the project interesting, consider giving it a ⭐.

Feedback and contributions are always appreciated.

Thanks for reading!

This is the first public introduction to Kivex, and I'm excited to continue building it with the open-source community.

Levelo-Js v2: The TypeScript Rebirth

Saiful Siam — Sat, 11 Jul 2026 06:33:45 +0000

If you have ever built a custom JavaScript framework from scratch, you know that the line between a smooth, memory-clean engine and a total memory-leak disaster is incredibly thin.

With version 1, Levelo-Js proved that lightweight reactive UIs could be fast and intuitive. But as codebases grow, raw JavaScript starts to feel like writing code blindfolded. The dreaded undefined is not a function is always lurking around the corner.

Today, we are taking a massive leap forward. Meet Levelo-Js v2—a complete ground-up architectural rewrite, fully re-born in TypeScript, with enterprise-grade build tooling and absolute bulletproof memory management.

Let’s dive into what makes v2 an absolute game-changer.

The Pillars of the TypeScript Rebirth

1. Full TypeScript Migration & Modern Bundling

We didn't just add types; we transformed the entire runtime engine core and internal modules from .js to .ts. Every piece of code is now strictly type-safe, offering self-documenting APIs and flawless IDE autocompletion (IntelliSense) right out of the box.

We also waved goodbye to publishing raw, uncompiled source files. Levelo-Js v2 now ships with production bundles powered by tsup. The engine is now pre-bundled into highly optimized, tree-shakable ES Modules (compiler/index.js), making your production build lighter than ever.

2. Hierarchical Tracking Context (`owner.ts`)

Handling nested reactive scopes and side-effects can easily lead to chaotic state bugs if not tracked properly. v2 introduces a robust Reactive Ownership Architecture. This creates a clean parent-child tracking hierarchy, ensuring that nested state updates always know exactly where they belong in the application tree.

3. Ownership-Driven Effects & Zero Memory Leaks

Memory leaks are the silent killers of Single Page Applications (SPAs). In v2, our core effect() engine has been deeply integrated with the new ownership layer.

The breakthrough? It now auto-disposes stale tracking dependencies automatically. We ran heap snapshots before and after intense button-press and state transitions—the memory profile stays completely flat (stabilizing perfectly around 2.5MB). Zero bloat. Absolute mitigation against memory leaks.

4. Advanced Lifecycle Mechanisms

To give you pixel-perfect control over your components, we introduced two advanced lifecycle hooks:

mount(): Safely schedules tasks precisely after the browser finishes synchronous layout painting. Perfect for clean DOM manipulations and secure API fetches.
cleanup(): Automatically captures and wipes out active intervals, event listeners, and pending asynchronous tasks during state or route transitions.

Bulletproofing the Developer Experience (DX)

A great framework isn't just about core reactive algorithms; it's about how it handles real-world ecosystem edge cases. Along with the core v2 rewrite, we've polished major real-world behaviors:

Standardized SPA Routing & High-Fidelity 404

In modern Single Page Applications, client-side routing must be bulletproof. We redesigned the core SPA fallback viewport (Page Not Found) with a high-fidelity native CSS layout. If a user wanders off to an unregistered route (like /asdf), the framework gracefully catches it, preventing server crashes and serving a gorgeous, responsive, center-aligned 404 screen.

Smart SVG Compiler Fixes

Compilers can sometimes be over-aggressive. We caught and squashed an tricky compiler bug where camelCase SVG attributes like viewBox were accidentally being converted to kebab-case (view-box), causing rendering glitches. v2 introduces strict exception mapping for core SVG properties—your icons and vectors will now render flawlessly.

🚀 Experience Levelo-Js v2 Today

Levelo-Js v2 behaves exactly how you expect a modern, high-performance framework to behave—lightning fast, type-safe, and incredibly respectful of your user's system memory.

Whether you are looking for zero-config autocomplete, strict compile-time safety, or zero memory leaks, v2 is ready for your next project.

# Create a fresh, fully optimized Levelo-Js v2 template instantly
npx create-levelo-app my-app

🔗 Links & Resources

GitHub Repository: github.com/motionmind2007/levelo-js — Check out the source code, open issues, or contribute!
Official Documentation: levelojs.motionmind.me — Dive deep into the reactive APIs, lifecycle hooks, and routing guides.

⭐ Support the Project!

Building a framework from scratch and moving it to a complete TypeScript ecosystem takes a massive amount of love, caffeine, and code iterations.

If you find Levelo-Js v2 interesting, or if you love open-source developer tooling, please consider giving the repository a Star (⭐) on GitHub. It helps the project gain more visibility and motivates us to keep shiping awesome features!

Drop a ❤️ and a 🦄 if you liked this post, and let me know your thoughts in the comments below. Happy coding! 🚀

The New Standard for NPM Package Discovery: Deep Dive into LibPilot

Saiful Siam — Wed, 24 Jun 2026 15:51:59 +0000

As web developers, engineering workflows are heavily dependent on the NPM registry. However, the traditional process of searching, auditing, and integrating packages remains highly fragmented. Developers are routinely forced to hop between npmjs.com, GitHub source repositories, and external documentation tabs simply to verify bundle sizes, check dependency trees, or generate setup boilerplate.

Following a strong reception on LinkedIn, X, and Facebook, the Motion Mind Team has introduced LibPilot to the dev.to community. LibPilot is not a traditional registry interface; it is an AI-powered search engine and discovery hub engineered to index, track, and analyze over 4,000,000 NPM packages in real time.

Here is an architectural breakdown of how LibPilot restructures package exploration for modern developers and autonomous AI code agents.

Intent-Based Discovery and Global Search Architecture

Traditional search engines require users to input the exact name or strict keyword of a library. LibPilot introduces a dual-input architecture on its home page to eliminate this constraint:

Direct Registry Querying: Users can input full or partial package names into the global search bar to instantly surface clean, structured, and typed suggestions directly from the live NPM ecosystem database.
Contextual AI Recommendations: For scenarios where the ideal package is unknown, developers can type out a complete description of their project architecture or system constraints (for example: "a lightweight, typed state management engine that handles server-side rendering natively"). LibPilot's internal AI agent processes the functional requirements and suggests production-ready libraries suited for that stack.

Continuous Context AI and Interactive Onboarding

A core goal of the platform is reducing developer friction and maintaining deployment momentum. LibPilot transitions static package documentation into an interactive environment:

Unlimited AI Chat Architecture: Once a library is selected, users can initiate a continuous, context-aware AI chat directly inside the hub. This allows for immediate questions regarding framework compatibility, performance trade-offs, and custom edge cases without changing tabs.
AI-Generated Implementation Guides: The integrated AI engine evaluates the target package to instantly compile environmental setup guidelines, configuration boilerplate, and exact terminal commands tailored to specific execution workflows.

Granular Real-Time Package Telemetry

When auditing a specific library, LibPilot maps complete technical data points across a unified, minimalist panel. Rather than cross-referencing multiple platform registries, developers gain instant access to structural package metrics:

Identity Verification: Displays the official Package Name, Package Description, current active Version, and categorized Package Tags.
Ecosystem Metrics: Tracks the absolute operational footprint via Unpacked Package Size, Total Files bundled in the archive, and verified License compliance headers.
Source Endpoints: Fast-tracks source access with direct triggers to the official Package Home Page, active Git Repository, and standalone Documentation manuals.
Clean Dependency and Dev Dependency Lists: Shows two clear, dedicated containers displaying the exact list of Dependencies and Dev Dependencies required by the package, complete with their semantic version codes and total package counts.
Maintainer Attribution: Verifies code provenance by surfacing official Contributors/Maintainers alongside their verified contact endpoints, alongside the exact Last Update timestamp to easily spot unmaintained code.
Terminal Installation Triggers: Out-of-the-box support for copying ready-to-run terminal installation strings optimized for npm, yarn, pnpm, and bun.

Built for Engineering Velocity

LibPilot acts as a powerful web-based bridge between the massive registry registry and your local setup. It replaces cluttered configuration workflows with real-time operational metrics and deep-context automation.

Explore the live engine and leverage AI insights for your next development environment directly at the official platform: https://libpilot.motionmind.me

Why Most Developers Never Finish Their Projects

Saiful Siam — Tue, 16 Jun 2026 14:42:15 +0000

Starting a new project feels exciting.

A new idea appears, the first few lines of code are written, the design starts coming together, and everything feels possible.

But after some time, many projects slowly disappear.

The repository stays untouched.
The last commit becomes weeks or months old.
The idea that once felt amazing becomes another unfinished folder.

This happens to many developers.

The problem is usually not a lack of intelligence or creativity.

The problem is finishing.

The Difference Between Starting and Building

Starting a project is easy.

Almost every developer has experienced the excitement of:

Creating a new repository
Choosing a tech stack
Designing the UI
Writing the first components

The first 10% of a project is often the most enjoyable part.

But real building starts when the excitement disappears.

When you need to:

Fix unexpected bugs
Refactor messy code
Make difficult decisions
Handle boring tasks
Continue without motivation

That is where many projects stop.

Tutorial Knowledge Does Not Automatically Become Real Experience

One of the biggest reasons developers don't finish projects is staying in learning mode forever.

Learning is important.

But there is a difference between:

"I know how to build this"

and

"I actually built this."

You can watch dozens of tutorials about authentication, databases, APIs, or frameworks.

But the real lessons appear when you try to combine everything into a real product.

A finished imperfect project teaches more than a perfect tutorial.

The Trap of Perfectionism

Many developers delay releasing because they want everything to be perfect.

The UI must be perfect.
The code must be perfect.
The architecture must be perfect.

But the truth is:

The first version of almost anything is not perfect.

Great software is usually created through improvement.

A small working version gives you:

Real feedback
Real problems to solve
Real users
Real learning

A project that exists can improve.

A project that is only an idea cannot.

Shiny Object Syndrome

Technology changes quickly.

A developer starts building something with one stack.

Then a new framework appears.

A new library looks interesting.

A new trend starts.

Suddenly the old project feels boring.

So they restart.

Again and again.

The result?

Many beginnings.
Few endings.

Learning new technology is good, but constantly switching prevents growth.

Motivation Starts Projects, Discipline Finishes Them

Motivation is powerful at the beginning.

It helps you start.

But motivation is temporary.

Some days you will not feel inspired.
Some days coding will feel difficult.

That is normal.

The developers who finish projects are not always the most motivated ones.

They are the ones who continue even when the excitement is gone.

Consistency beats intensity.

Small Projects Create Big Skills

Many developers think every project needs to be a huge startup idea.

It doesn't.

A small completed project teaches:

How to structure code
How to debug
How to handle mistakes
How to deploy
How to maintain software

Finishing small things builds the ability to finish bigger things.

The Goal Is Not Just Writing Code

A developer is not only someone who writes code.

A developer solves problems.

And solving problems requires:

Patience
Decision making
Communication
Persistence

The hardest part of software development is often not syntax.

It is staying with a problem long enough to solve it.

Final Thoughts

The world is not lacking ideas.

Developers have thousands of ideas every day.

The difference is made by the people who keep working after the excitement disappears.

Start small.
Build consistently.
Finish what you start.

Because a completed project, even an imperfect one, will always teach you more than an unfinished perfect idea.

How I Built a Reactive State System in Pure JavaScript

Saiful Siam — Sun, 14 Jun 2026 05:58:58 +0000

When I started building Levelo JS, one of the most interesting challenges was creating a reactive state system.

At first, I wanted something that felt similar to React. My goal was to make state access simple and intuitive, where developers could work with state values directly without extra function calls.

But once I started implementing it, I quickly realized that building a reactive system is much harder than it looks.

The First Idea

My original plan was to create a getter/setter system where state values could be accessed directly, similar to how developers usually work with variables.

On paper, it sounded simple.

In reality, it introduced many challenges.

The framework needs to know exactly when a value is being read, when it changes, and which parts of the UI depend on that value. Handling all of that correctly without adding unnecessary complexity turned out to be much more difficult than I expected.

Rethinking the API

Instead of spending weeks trying to perfect the original idea, I decided to focus on building a working MVP first.

That's when I started experimenting with a function-based approach.

The API eventually became:

import { state } from 'levelojs';

function Counter() {
  const [count, setCount] = state(0);

  return (
    // UI
  );
}

This approach felt much simpler to implement while still providing the reactive behavior I wanted.

Interestingly, this design ended up being closer to SolidJS than React.

Building It

I wasn't working completely alone.

Part of the implementation was something I explored together with AI while experimenting with different ideas and approaches.

The goal wasn't to copy another framework.

The goal was to understand how reactivity actually works behind the scenes and then build a system that fits the design philosophy of Levelo JS.

Once the function-based API was in place, many parts of the system became easier to reason about.

The implementation became cleaner, debugging became simpler, and progress became much faster.

What I Learned

This project taught me something important:

The first idea is not always the best idea.

Sometimes developers spend too much time chasing the "perfect" solution when a simpler solution can move the project forward much faster.

I still find the direct getter/setter approach interesting, and I may revisit it in the future.

But for an MVP, the function-based API was the right decision.

Final Thoughts

Building a reactive state system taught me that reactivity is not magic.

Behind every simple API, there is a lot of design, experimentation, and problem-solving.

Levelo JS is still evolving, and there are many things I want to improve.

But creating the state system was one of the moments where I learned the most about framework development and how modern JavaScript libraries work under the hood.

If you're building your own library or framework, don't be afraid to choose the simpler solution first.

You can always improve it later.

DEV Community: Saiful Siam

Motion Mind Is Now Motion Mind X

Motion Mind Is Now Motion Mind X

Why Did I Change the Name?

What Changes Now?

A New Name, The Same Journey

LeveloJS Went Quiet. We Were Rebuilding the Foundation.

LeveloJS Went Quiet. We Were Rebuilding the Foundation.

A New Collaboration

But Why Multi-platform?

Build on What Already Exists

Our Goal: Write Once, Run Anywhere

But Doesn't React Native Already Do This?

We Are Thinking Beyond Android and iOS

Rethinking the LeveloJS Architecture

Type Safety Is Becoming More Important

Security Is Also Part of the Redesign

Why Rust?

There Is One Part We Are Keeping Secret

Why We Chose This Direction

What We Want for the Next Generation of Developers

Where We Are Now

Help Us Explore This

So, Why Was LeveloJS Quiet for a Month?

Why I Built NGCBD: A Dedicated Community for Passionate Bangladeshi Developers

NGCBD(Next-Gen CodeCrafters BD): A Dedicated Community for Passionate Bangladeshi Developers

The Origin & Vision

What Makes NGCBD Different?

A Platform for Research-Level Projects

Expert Code Reviews That Actually Help

The Zero Pressure Philosophy

Bi-Monthly League Cycles

No Forced Participation

No Course Upsells

Compete, Learn, and Get Recognized

The Motion Mind Ecosystem

Why Peer Review Matters for Your Career

Open Source Is at the Heart of the Community

Integrity Above Everything

Who Should Join?

Join the Community

Final Thoughts

Building Dynamic Routing for My JavaScript Framework (Levelo JS 2.2.0) — One Last Test Before Bed Changed Everything 🚀

Building Dynamic Routing for My JavaScript Framework (Levelo JS 2.2.0) — One Last Test Before Bed Changed Everything 🚀

It Worked... Until I Tested It 😅

The Bug I Couldn't Stop Thinking About

The Next Morning

The Real Problem

Dynamic Routing is Finally Here 🎉

A Cleaner Router Architecture

A New params API

ref Support

Better SPA Title Handling

What I Learned

Still Learning

Kivex Just Crossed 300+ Icons — 107 New Icons and Package Fixes

Kivex Just Crossed 300+ Icons — 107 New Icons and Package Fixes

🎨 107 New Icons

📦 Kivex Is Now a 300+ Icon Ecosystem

🛠️ Small Package Fixes

🚀 What's Next for Kivex?

❤️ Like Kivex?

LeveloJS v2.1.2 — A Cleaner JSX Runtime Architecture

LeveloJS v2.1.2 — A Cleaner JSX Runtime Architecture

Why another update so soon?

What's Changed

Reorganized the JSX Runtime

Removed Unnecessary Coupling

Improved DTS Bundling

Better Ambient JSX Typings

Why This Matters

Changelog

Fixed & Refactored

Looking Ahead

Splitting the Compiler from the Runtime in Levelo JS

Splitting the Compiler from the Runtime in Levelo JS

Installation:

What's New

Batch Updates

Reactive Input Tracking

A New `params` API

`ref` Support

2. Hierarchical Tracking Context (`owner.ts`)