Why Every Web Developer Should Build Their Own Framework

source

I know I know - but hear me out!

We all know the meme above or variations thereof. There are too many javascript frameworks. But, we all use the big, well-known established ones like React, Vue, or Svelte at work. And that’s a good thing!You should keep using them for your actual job. They are fast, reliable, and have huge communities.

But here’s the thing: You should totally try building your own framework on the side.

It’s Not About Competing, It’s About Learning

When I say “build your own framework,” I mean you should go ahead and build something complete, from start to finish. Design how state is managed, how components are defined, and how the rendering cycle works from start to finish.

You can decide if you want this to be something you want the world to see, but it can also be just for you, a playground to try stuff and learn.

This works because it forces you to stop being just a user of the framework and start being the architect. You’ll have to solve many fundamental problems yourself (or dig into the source code of existing ones to learn how they did it), from routing to reactivity.

This is where the magic happens. When you’re using a big framework, all the hard parts are hidden behind a nice API. But when you build your own, you won’t be able to avoid having to deal with them.

You’ll learn so much about low-level JavaScript, about DOM, about how browser execute your code and how to use that to make it run fast.

How do you track what has changed in the application’s state? How do you only update the parts of the DOM tree that need it? That’s the whole idea behind the virtual DOM and building a minimal version of it yourself makes the concept totally clear. Of course not every framework uses virtual DOM, so you might want to explore why they chose to do it differently and how you can implement that yourself.

And a huge bonus: you learn about API design. If you’re building a tool for other developers (even if that developer is just future you), you start thinking about what makes a good, simple, and intuitive interface to write components.

A Real Example: My Own Little Project

Here’s what I found when I did this a few years ago. I started a small experiment called enthjs. You can check it out on GitHub here. I never advertised it in a big way and haven’t updated it in forever, but it still works and is there for everybody to check out. Maybe there’s something you can learn from it.

I wasn’t trying to make it famous. I used it as an excuse to play with a few specific web technologies that were becoming more popular at the time.

• My code heavily uses tagged template literals. This lets you write HTML right inside your JavaScript, but in a way that’s easy for the code to parse and update efficiently.
• I also used generator functions for defining components and directives. Generators let you pause and resume function execution, which was a great way to learn about them and see how they could manage the component lifecycle.
• Plus, the whole thing is based on Web Components. That’s the browser’s built-in way of creating reusable elements. Building a framework on top of them gave me a much deeper understanding of the native platform APIs.

Here’s a basic component example from that project. You can see how the framework relied on both generators and tagged template literals to handle rendering and updates:

import { component, html } from 'enthjs';

// The generator function handles the component's state loop.
function* Counter({ start = 0 }) {
  let count = start;

  while (true) {
    // 'yield' outputs the template literal, forcing a re-render.
    yield html`
      <button onclick="${() => count++}">
        Count is: ${count}
      </button>
    `;
  }
}

// This registers the component as a custom Web Component.
component('my-counter', Counter);

All in all, building this little framework was an amazing learning experience and I took away a lot of valuable knowledge that I still use today.

So, Go Build Something Tiny

Look, you don’t need a year. You need a weekend. Or maybe just a few nights.

Don’t worry about bugs (though fixing bugs is a great way to learn by itself) or making it fast enough for production (but trying to squeeze out every last drop of performance is, again, another path to learn more). And the moment it starts to work is magical, I can guarantee it.

And whatever knowledge you gain from the excerise will benefit you in your professional life, it’ll help you write better code, build better products and it will for sure be invaluable when you need to debug some of those very weird bugs that you never encountered before and that might be lurking in the dark corners of your codebase.