A case for minimalist, low-dependencies web development

We all take things for granted. Like initializing a new web project with a whole stack of tools we are comfortable with.

But even open-source tools we think we can rely on, can come to an end. For example, in August 2025, Google announced that it "will no longer be possible to develop apps for the Android platform without first registering centrally with Google," putting open-source Android apps at risk.

So what if, let’s say React or Angular meet the same fate? What if the license change and you either have to rewrite your whole web app or hope that someone will fork the project and fix that critical vulnerability so you can patch your production app?

Every now and then I have a moment where I try to challenge my practices and habits, you know, just for the sake of it. A bit like genetics algorithms introduce randomness just to avoid being stuck on a local optimum forever.

And in the light of the recent global geopolitical events, maybe it’s time to think more about resilience. Europe is thinking about it a lot by trying to promote open-source projects and sovereignty.

So maybe, given all this, it’s a good idea in 2026 to start considering alternatives to all frameworks. Web standards have progressed. Things are now possible natively on the browsers, that would before require third party tooling. This is not perfect but maybe a slightly less elegant abstraction is a small price to pay for a resilient, less dependent codebase that could resist big changes in the ecosystem. It’s not for all projects but there are some that can surely benefit from it.

One of the side benefit of removing tools and framework is that, it can reduce accidental complexity on your project. It means a better maintainability (if done right) and less time fixing error related issues (I’m looking at your, hydration errors). But the cost of choosing the right abstraction and structuring your code is now yours, so it might not be the best decision in the context of your team!

HTTP2, ESMs, and the need for bundling

HTTP2 introduced a thing called multiplexing, allowing the load of multiple files in parallel. It doesn’t make bundling obsolete, but it makes the use of ECMAScript Modules (ESM) very efficient.

It has been around since 2015. So it’s possible to start a web project using only ESM and imports and have a well organized code that loads efficiently, without having a bundler involved. It means that the deployment is also instant. The development code is your production code!

Dependencies with importmap

A follow-up of this is that there is no tree shaking. It might be a good thing as it forces you to be more mindful of your dependencies.

With the abundance of supply chain attacks, typosquatting, and more recently slopsquatting (using LLMs hallucinations for non-existant packages as an attack vector), it’s a good thing to think very hard before adding a dependency to your project.

A way to handle dependencies is importmap. It allows you to declare a module from a CDN or a folder (if you prefer vendoring for your dependencies) and use it as a regular import in your code.

To make up for the lack of tree shaking, there are a lot of dependencies that are available as ESM modules and that can be imported granularly on your project.

Type safety can be achieved with JSDocs

With import, you don’t have access to things like Intellisense (I didn’t manage to make it work anyway, though it might be achieved by a local npm install -D of the module).

Which makes a good transition toward type safety! One of the main reasons people have a build step in their projects: the use of TypeScript.

Types annotation (so a subset of TypeScript) being included in ECMAScript is still being discussed so we won’t see it in browsers anytime soon. In the meantime, there is JSDocs.

JSDocs is a great way to type your code. I know, the syntax is not as elegant as TypeScript, but it has many benefits: no need for a build step, and you don’t depend on a big company (here Microsoft) for your production code (so a huge improvement for resilience).

You might think I am crazy, but some projects like Svelte have already ditched TypeScript (which does not mean ditching support for type safety).

You can always write your types in type declaration files (.d.ts) and use them in your ECMAScript code, allowing your IDE to tell you when you pass the wrong parameter and having some completion on your objects.

Web Components

Web Components are controversial. Some people hate them. They are not perfect by any means and more verbose to use than other frameworks, but hear me out: they. are. forever.

Frameworks come and go. Standards are here to stay. So if you don’t want to rewrite your frontend every 10 months, maybe you should consider Web Components.

I wouldn’t use the shadow DOM in most cases though. If you want a unified styling anyway.

It doesn’t replace a full framework. It’s just the view layer. But it can greatly improve the reusability of code.

I haven’t used templates yet, I don’t know about them…

Frameworks converge toward reactivity achieved by signals

Most majors framework achieve reactivity using signals. You can also use them without a framework. They are great for state management.

There are multiple implementations which are very lightweight, and a standard implementation is currently being discussed by TC39.

Signals work great with the native fetch API and the Web Components. So it might be a great way to write some modern UIs with very little dependency and maybe one day, no dependency at all.

Conclusion

My conviction is that in 2026 you can develop things from scratch and still have a modern web development experience. Most of the heavy lifting can be done either natively or by lightweight libraries.

I think this year I want to explore doing web development past the framework hopping phase. And go back to basics to deliver value in a codebase that’s maintainable and future-proof.

Low-dependencies, no-build web development has its use-cases where it can shine, especially when resilience to third parties is needed. And I’ll continue to focus on learning standards, which is useful whether I go with a framework or not.