You know that sinking feeling when you open a new JavaScript project and see a config file jungle, a build pipeline that requires a PhD in Webpack, and a package.json that’s longer than the actual code? That’s not progress. That’s a failure of the web’s most fundamental promise: that anyone can learn to build for it.
I’ve been there. You’ve been there. And Lea Verou, a veteran web standards researcher, laid it bare in a 2020 post that still stings. She walked into the modern JavaScript ecosystem as an outsider—someone who had written JS since the ’90s—and found herself lost. Not because she couldn’t code, but because the tooling had become a foreign language. The JavaScript ecosystem has become a high-stakes game of ‘who can abstract the most,’ and the web is losing.
Think about it. The original pitch of JavaScript was simple: a scripting language for the browser, no compilation, no ceremony. You could write a script tag, hit refresh, and see your work. Today, you need a build tool, a bundler, a transpiler, a linter, a formatter, and a package manager just to say “Hello, World.” We’ve built a system where the barrier to entry isn’t learning to code—it’s learning to configure.
And the worst part? We’ve convinced ourselves this is engineering maturity. “Modern tooling is necessary for scale,” they say. “You can’t write vanilla JS in production.” Bullshit. We’re not building Mars rockets; we’re building websites. The web’s greatest strength was always its low barrier to entry. A kid in a library could open Notepad and make a page. Now that kid needs a dev environment, a terminal, and a 12-step setup guide. If the web was once a playground for curious minds, today it’s a fortress guarded by a million npm packages.
But here’s the twist—the part that makes this uncomfortable. We did this to ourselves. Developers, myself included, chased “ergonomics” and “scalability” without asking who we were leaving behind. We optimized for the experienced engineer’s convenience and forgot the beginner’s struggle. And now we’re shocked that the next generation of developers is choosing Python, Rust, or even no-code tools instead. We optimized our own comfort and called it progress. The web paid the price.
This isn’t a Luddite rant against progress. It’s a call to remember what the web was supposed to be. The W3C built HTML and CSS to be forgiving. JavaScript was designed to be approachable. We’ve layered on so much complexity that the original philosophy is nearly unrecognizable. Lea Verou’s article isn’t an outlier—it’s a mirror. If a world-class web standards expert feels alienated, imagine how a newbie feels.
So what do we do? Start by admitting the problem. Stop treating config files as a badge of honor. Stop gatekeeping the web behind a wall of tooling. If your project requires more than a text editor and a browser to get started, you’ve already lost the web’s soul. The next time you set up a new project, ask yourself: is this tooling actually helping the user, or just impressing your peers? Because the web doesn’t need more impressive build pipelines. It needs more creators.
FAQ
Q: Isn't modern tooling necessary for large-scale applications?
A: Not for the majority of projects. Most websites don't need Webpack, Babel, or a 50-package ecosystem. Vanilla JavaScript with modern ES6+ is perfectly capable for the vast majority of use cases. We've over-engineered the trivial into the complex.
Q: What's the practical implication for a team lead?
A: Audit your stack. Every tool you add is a barrier to onboarding new developers and a maintenance burden. Ask: 'Does this tool directly improve the user experience or the developer experience for the *longest tail* of my team?' If the answer is 'it makes me feel pro,' cut it.
Q: Aren't you just romanticizing the 'good old days' of spaghetti code?
A: There's a middle ground between spaghetti and a nuclear reactor. The goal isn't to abandon all tooling, but to demand that tooling actually serves the human—not the other way around. The web's original promise wasn't perfection; it was participation. We've let 'best practices' become a barrier to entry.