🔥 New blog post: Web dependencies are broken. Can we fix them?
“Dear JS ecosystem, I love you, but you have a dependency management problem when it comes to the Web, and the time has come for an intervention.”
Read more: https://lea.verou.me/blog/2026/web-deps/
Jan 7, 2026, 7:05 PMthis problem was solved by userland until standard bodies made a power grab and re-introduced problems we didnt have anymore.
not only was the ecosystem split and gazillions of developer hours burned to manage the fallout and chaos between cjs ans esm, but also marketing pushes esm on all of us and with it apl the problems we didnt have anymore.
its a disaster and most ppl habitually following authorities instead of making up their mind, we're not getting out of this mess sadly
@serapath Please go find a blackboard and write "I will not reply to articles I haven’t read" 50 times.
I’ll wait.
Jan 7, 2026, 7:32 PMi mean i did read it and all your ideas undee "Where to go from here" are reasonable if you believe in standard bodies and beg them and hope they will liste and one day adopt those.
the holier than thouh spec makers to deliver us the goodies.
..all of what you say is already possible in userland. you have fetch. you have eval. thats it.
progress was fast when nodejs started because in a short time userland could fix all the crap spec makers werent able to fix.
🤷♀️
Jan 7, 2026, 7:34 PMi know, not a popular opinion, and less popular the more famous devs are - so i assume you dont agree at all with my takes, but i still need to voice them.
watching this back and forth for 3 decades now just makes me sad. ...there was a small window between ~2012 to ~2017 or so ...where spec makers mostly didnt matter and userland just made up stuff and adopted what they liked most... creating best practices rather than standards... all of which avoids bloating the core of the web
@serapath 1. As a member of several standards bodies since 2012, you’re just …wrong.
Spec makers are not holier than thou, but we do have the weight of responsibility that ANYTHING we define can never change, the Web will carry it forever. And it needs to work for everyone, and every little edge case. It’s very different concerns than userland.
2. If you read it, you didn’t understand it, because the core point it's making is that this is not functionality that should be solved in userland.
Jan 7, 2026, 8:51 PM@leaverou
this is your opinion that it shouldnt be solved in userland, but in reality... this is what happened successfully before.
there were dozens and dozens of competing import mechanisms in the early days of nodejs and eventually commonjs emerged victorious.
and for many reasons.
esm - standard by self proclaimed authority - is flawed and ppl figure out more&more why.
esm work started a decade ago and was released 7-8 years ago and today we still discuss issues solved by cjs back then
Jan 7, 2026, 8:54 PMthe core of the web always adds more.
...if the web is around forver and this doesnt stop it will become unmaintainable and large in size so ppl eventually have to abandon it
if you want to design a system for eternity, the only reasonable approach is to follow the core mantra of SEL4 kernel
https://en.wikipedia.org/wiki/L4_microkernel_family
check under **design paradigm**
...if you dont its o ly a matter of time until it all will fail eventually.
Jan 7, 2026, 8:56 PMthere are an estimated 30 million web developers and only the tiniest most privileged fraction of them has ever been able to participate in spec making process regardless of all the opaque processes that are documented but need studying & privilege to learn & follow.
in the core are devs supported/selected by the biggeat funders and most user participation is anyway not binding and a mere sugfestion.
maybe you are blinded by group think or your social bubble. 30mio is a huge number
@leaverou What we do is we install with npm, then create symlink to somewhere in repo like /externals/foo, then we usually create our own entry to that dependency somewhere else convenient like foo.js that imports-exports exact the stuff we need and finally we specify that /externals/foo to our build system that uses custom built imports rewriter plugin that fixes the imports to proper. Because the world is full with assholes who omit .js from import just because they can force us for build step.
We have also static deps, that is when it is in bloody TS, then we just add JavaScriptified files directly into repo. Then the same dance as above.
This of course works best with deps that have no deps. But we have done this for years and it works for us.
@atirip Fascinating! Do I have your permission to quote this in the article?
@leaverou Yes, you have my permission.
@atirip What URL should I link your name to?
@leaverou oh thats is hard one. I guess this mastodon is these days the only place i talk about my work.
@Razemix @leaverou not really, our “build” is just copy file from repo to webserver root. Plus we have few plugins to minify, etc for production run and we need to do some other direct file manipulation on few and we have this gulp pipeline for 10 years. To clarify - we do not transpile and build, we run actual es6 modules as is.
@atirip @Razemix I do think there is a need for a lightweight dependency manager that only handles rewriting specifiers to URLs and copying the right files out of node_modules and **nothing else**. Once external import maps are a thing, it could handle generating that too. To my knowledge, this does not exist. If only I had the time to write it…
@leaverou @atirip Would a generated js file that just `document.write`s the importmap be really such a crime against humanity? 😄 I know, it still doesn't fully solve dependencies of dependencies (when different versions are needed), but if you basically have a flat package-lock.json, this could work.
@Razemix @atirip import maps can have different versions per dependency, through scopes.
As for whether it's a crime, there are some pretty real drawbacks, see https://developer.mozilla.org/en-US/docs/Web/API/Document/write . Plus, I don't even know if it would actually work, I haven't tried it.
@Razemix @leaverou i tried import maps at the beginning, but the deps we have all have various craziness backed in and i needed tens and tens of cryptic and brittle (for example sentry changes often) lines that were pain to debug. Simple forced rewrite with some javascript ifelses was way way easier.
@leaverou remind me in few weeks, i may have something for you you can work on. In in the process of rewriting our ”build system” and i can share the import rewriter i think.
@Razemix @leaverou also many steps are just for sanity. Symlinking stuff from node_modules to repo creates nice ”real” files you access in repo. Having special accesspointtodep.js is to only allow one way and it helps when changing deps. We changed for example our date library and even rendering library by changing imports and stuff in that accesspoint.js file
@leaverou really appreciated the article, thank you for writing it.
was this cover image generated by some text-to-image machine learning model by any chance? it looks very much like it.
@moonfaced yes, Gemini! Though it took a lot of iteration
@leaverou I'm very disappointed to learn this. I'm of the opinion that your usage of large-scale machine learning models for image generation is highly incompatible with your work on improving efficiency and empowering marginalized people on the Internet.
It's particularly striking to me when in the same article, you profess not wanting people in California to decide for the rest of the world: I'm sure you've heard of the training, tuning, and usage of these models is a significant toll on resources such as water and electricity, and makes use of underpaid and traumatic labor from people in the global south.
I'm sad seeing you do this and hope you understand why. Thank you for your work on web standards and your blogging over the years :)
@leaverou
The technical approach by which dependencies are downloaded is irrelevant (to the problem that needs solving most). The real reason the npm ecosystem is in such a bad state is not the npm tool or the npm registry, it is misplaced trust in and lack of control over transitive dependencies. If we switch to directly importing urls but keep the same ecosystem of transitive dependencies then the problem will only grow worse.
"Injecting import maps via DOM methods now works in all browsers! In fact, JSPM 4.0 uses it! 🎉 This is a gamechanger." Well, sweet! This made my day.
I definitely can't imagine going bundler-free in any large scale project, due to all the reasons you highlight in this fantastic article. For side projects I've been working bundler-free, just to see if I could. It's not ideal. Essentially, I have as few dependencies as possible, and I target dependencies I know have single ESM bundles (so, kind of offloading the bundling to the dependency to some extent). For example, my current side-project has
"@preact/signals-core" and "valibot" as the only dependencies. Then I have a small dev server that serves out of "node_modules" locally. For deploying, I have a script that copies over the dependencies as needed. It works, but it's very janky.
@ectopod it made my day too. In fact, I’m working on a solution based on jspm that mitigates these issues. Hopefully I can release a proof of concept very soon! Do you want to test drive it before I release it?
@leaverou Yes please!
@leaverou Thank you for this fascinating article. Great to see some try to find a solution to this pain we share.
I then visited some of the pages of your site and found some dead GitHub links here https://lea.verou.me/credits/ I thought you'd like to know.