We Badly Need Frameworks

With all their pros and cons.

The Experiment

I asked some AI to give me a todo list app. First in React, then in plain JavaScript.

React Todo App

Vanilla JavaScript Todo App

The Results

The React version came back more or less as you would expect. Some JSX, some state, a render function. Familiar. I could hand that snippet to almost any React developer and they would skim it and nod along. No drama, no surprises.

The vanilla JavaScript version was a different story. It worked, sure, but it took me considerably longer to understand. DOM manipulation here, event listeners there, a custom renderer. Honestly, I could think of a hundred ways to build it, and each would spark a debate. None feel like the obvious baseline. And that is the problem.

The Cost of Freedom

Without a framework, you are inventing your own rules. The next person on the team has to learn them. Subtle bugs are likely to creep in because the solution is novel, not battle tested. These are the kind of bugs nobody wants to debug. They are not about features, they are about the scaffolding holding the project together. And if the team is skilled and committed enough to actually build something sensible, well, congratulations. You just invented a new framework. Not that anyone will call it that.

Why Frameworks Help

Frameworks give us something better than freedom. They provide conventions most people already understand, which saves a huge amount of time and mental overhead. Patterns for state management, project structure, component hierarchy, and even file organization are mostly solved problems. Linting rules, best practices, and common gotchas are baked in or widely documented. You do not need to reinvent solutions for problems that thousands of developers have already tackled. On top of that, you can largely delegate framework related bugs and edge cases to the open source team maintaining it, which means less responsibility on your team and more focus on building features that actually matter.

It’s Not All Shiny

“It’s just JavaScript” is a common refrain, but once you commit to React, Vue, or Svelte, you are not just picking a library. You are picking a whole ecosystem. Swapping frameworks later is not trivial, and in practice, once you go in, you are committed for good. Framework independent libraries cannot always be ported easily, and that is often why developers stick with a framework. Better support, tooling, and packages are usually part of the equation. I have built some open source libraries myself, and I feel the pain for library authors. To reach a wider audience, they often have to maintain multiple versions across frameworks. That is why I personally pick React and build for that. I do not have the energy to port my code across the most used frameworks. Not a heroic choice, just realistic.

The Clojure Example

Some ecosystems, like Clojure, work differently. A handful of battle tested libraries everyone trusts. You can mix and match them to make something tailored while still benefiting from a standard toolset.

Even here, there are trade offs. Picking a number of modules to get started can be a blocker for more junior developers who do not yet understand the patterns and best practices, making the community less welcoming to newcomers. Nothing is perfect, but at least the baseline is shared.

Conclusion

As much as frameworks can seem limiting and come with their own quirks, they are still the best way to keep projects maintainable and understandable. The alternative is worse. Every team reinventing its own mini framework will inevitably degrade over time due to lack of resources or simply poor decisions.