DEV Community: Saiful Siam

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.

What Nobody Told Me About Maintaining an Open Source Project

Saiful Siam — Sat, 13 Jun 2026 06:37:20 +0000

I am a solo learner. I started coding last year with the help of AI and sometimes without any tutorials or courses.

At first, I thought this journey would be easier. But soon I realized something important — no AI or tool can fully solve the real problems I was facing as a developer.

I used AI a lot. It explained things with confidence and even provided code.

But when I ran that code in my terminal, many times it didn’t work.

That’s when I understood something important: AI can guide, but it cannot replace understanding.

After facing these issues, I changed my way of learning.

Instead of blindly trusting AI, I started:

Finding real open-source projects
Studying how they were built
Listing important topics from those projects
Reading documentation carefully
Asking AI to explain specific lines of code

This helped me understand real-world code better.

From this learning journey, I realized something:

I should also build my own open-source projects.

At first, I believed that creating a powerful project could automatically bring attention and users.

But I was wrong.

I made a mistake — I was not active on any platform.

I was just coding inside VS Code, without communication or sharing my work anywhere.

Then I realized:

Being a developer is not only about coding. Visibility and communication are also important.

After that realization, I started being active on platforms like Dev.to, LinkedIn, and other developer communities.

I started posting my work and sharing my progress.

Even though I didn’t get many comments, I started getting reactions and engagement. That small feedback gave me motivation.

From this journey, I learned something important:

Open source is not only about code. It is about helping other developers, sharing knowledge, and being consistent and visible.

A developer should not only code silently but also participate in the community.

Now I understand that coding is only one part of being a developer. Community, communication, and consistency are equally important.

And I will continue building open source projects while staying active in developer platforms.

What I Learned Building a JavaScript Framework from Scratch at 18!

Saiful Siam — Fri, 12 Jun 2026 06:23:27 +0000

Whenever I used JavaScript frameworks like React, Next.js, or SvelteKit to build e-commerce sites and web applications, one question always stuck in my mind: "How does it actually work under the hood?"

During my recent Eid vacation, I decided to stop just using them and try building one myself. Here is the story of how Levelo JS was born.

The Spark of Curiosity

I started by asking Gemini to explain the core mechanics of modern JavaScript frameworks. That is when I learned about how compilers work—specifically, how they transform JSX-like syntax into pure, optimized vanilla JavaScript DOM operations.

To dig deeper, I spent days reading through the open-source compiler code of SolidJS and React. The fine-grained reactivity architecture of SolidJS fascinated me the most.

Armed with this knowledge, I teamed up with Gemini to brainstorm and research the architecture. After intense experimentation, we successfully built Levelo JS — a lightweight, zero-runtime, Virtual-DOM-free JavaScript framework built entirely from scratch.

Coding on a Mobile Phone 📱

The journey was extra challenging and interesting because I was at my village for the holidays and didn't have access to my laptop or PC.

Driven by pure passion, I coded the entire core framework (up to v1.0.4) on my Android phone using Termux and the Acode editor. Because I had already thoroughly studied the documentation of React, SolidJS, and Svelte, I managed to build the initial core architecture in just 15 days.

The Hardest Challenge: Building a Client-Side Router

Since Levelo JS is designed for Single Page Applications (SPA), it absolutely needed a client-side routing mechanism.

Building this routing system from scratch was the hardest part of the project. It took me 2 entire days of continuous debugging just to get the basic routing features stable. While there might still be minor edge-case bugs, I am actively identifying and fixing them as the framework evolves.

My Biggest Takeaway

Building Levelo JS taught me that as developers, we shouldn't just blindly memorize how to use tools like Next.js or React. We need to look deeper and understand how they work under the hood.

Understanding the internals makes you a better software engineer and helps you write significantly faster, more optimized code for production.

I would love to get your feedback on the architecture!

🔗 GitHub: MotionMind2007/Levelo-Js
🔗 Documentation: levelojs.motionmind.me

Building a Frontend Framework from Scratch: Introducing Levelo JS

Saiful Siam — Thu, 11 Jun 2026 12:27:54 +0000

As developers, we often use frameworks every day without thinking much about how they work internally.

A while ago, I started exploring frontend architecture more deeply. I wanted to understand what happens behind components, state management, reactivity, and rendering systems.

That curiosity eventually led me to build my own frontend framework.

Today, I'm excited to share Levelo JS.

What is Levelo JS?

Levelo JS is a frontend framework built completely from scratch in JavaScript under the Motion Mind brand.

The framework is designed around a few core ideas:

No Virtual DOM
Signal-based reactivity
Small bundle size
SPA-focused architecture
Simple developer experience

Current core package version: levelojs v1.2.0

The ecosystem also includes a CLI tool:

npx create-levelo-app my-app

Why Build Another Framework?

The goal was never to create "the next React" or replace existing frameworks.

The real goal was to learn by building.

I wanted to understand:

How reactivity systems work
How rendering pipelines are designed
How state updates affect the UI
How framework architecture evolves from simple ideas

Building everything from scratch taught me far more than simply reading documentation ever could.

Signal-Based State Management

One of the core concepts in Levelo JS is signal-based reactivity.

A simple counter looks like this:

import { state } from 'levelojs';

function Counter() { 
  const [count, setCount] = state(0); 
  return ( 
    <div> 
      <h2>{count()}</h2> 
      <button onclick={() => setCount(count() + 1)}> Level Up ➔ </button>              
    </div> 
  ); 
} 
export default Counter;

The framework updates only what needs to change, without relying on a Virtual DOM.

Built Under Motion Mind

Levelo JS is being developed under Motion Mind, an initiative focused on next-generation software and AI solutions.

The vision behind Motion Mind is simple:

Build useful software.
Explore new ideas.
Share the journey through open source.

A Personal Milestone

One detail that makes this project special to me is how it started.

Up to version 1.0.4, Levelo JS was built entirely on an Android phone using Termux and acode.

What started as experimentation on a mobile device eventually grew into a complete open-source framework with its own CLI, documentation site, and ecosystem.

Explore Levelo JS

Documentation:
https://levelojs.motionmind.me/

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

Open for Collaboration

Levelo JS is open source and actively evolving.

If you're interested in frontend architecture, framework design, JavaScript internals, or open-source development, I'd love to hear your thoughts and feedback.

Every suggestion, discussion, and contribution helps move the project forward.

Thanks for reading.

DEV Community: Saiful Siam

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

Dedicated Vite Plugin

Runtime Refactoring

Verified in a Real Project

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

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

What is Kivex?

Why Kivex?

Highlights

Current Packages

Designed for Modern Development

The Vision

Open Source First

GitHub

Levelo-Js v2: The TypeScript Rebirth

The Pillars of the TypeScript Rebirth

1. Full TypeScript Migration & Modern Bundling

2. Hierarchical Tracking Context (owner.ts)

3. Ownership-Driven Effects & Zero Memory Leaks

4. Advanced Lifecycle Mechanisms

Bulletproofing the Developer Experience (DX)

Standardized SPA Routing & High-Fidelity 404

Smart SVG Compiler Fixes

🚀 Experience Levelo-Js v2 Today

🔗 Links & Resources

⭐ Support the Project!

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

Intent-Based Discovery and Global Search Architecture

Continuous Context AI and Interactive Onboarding

Granular Real-Time Package Telemetry

Built for Engineering Velocity

Why Most Developers Never Finish Their Projects

The Difference Between Starting and Building

Tutorial Knowledge Does Not Automatically Become Real Experience

The Trap of Perfectionism

Shiny Object Syndrome

Motivation Starts Projects, Discipline Finishes Them

Small Projects Create Big Skills

The Goal Is Not Just Writing Code

Final Thoughts

How I Built a Reactive State System in Pure JavaScript

The First Idea

A New `params` API

`ref` Support

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