A viral thread just asked developers what feels over-engineered in modern web dev. The answers hit like a group therapy session nobody knew they needed.
Thousands of comments. The loudest ones all circled the same absurdity: we're compiling thousands of modules to ship a button that says "Submit." And honestly? Nobody could argue back.
The Space Shuttle Problem
Someone compared modern front-end tooling to building a space shuttle for a marketing site. That metaphor is painfully accurate.
You need a static page with a contact form. By the time you're done, you've got a bundler, a transpiler, a CSS-in-JS library, a state manager, a routing layer, and a deployment pipeline that would make NASA nervous. The button works, though. So that's nice.
The thing is, none of these tools are bad. Webpack solved real problems. React solved real problems. TypeScript solved real problems. But stacking all of them on a five-page site isn't solving a problem — it's performing competence.
Why We Keep Doing This
Here's the part nobody wants to say out loud: simple solutions don't get you promoted.
Nobody writes a blog post about the time they shipped a project with plain HTML and a single CSS file. Nobody gets a senior title for choosing the boring option. The incentive structure in our industry rewards complexity, even when that complexity serves the toolchain more than the user.
→ Complex architectures look impressive in system design interviews
→ "I built it with zero dependencies" doesn't make your résumé pop
→ Conference talks about simple solutions don't fill rooms
→ Pull requests with 47 new packages feel like progress
We cargo-cult complexity because the industry tells us complexity equals skill. Then we wonder why onboarding a junior dev takes three weeks before they can touch a single component.
It Wasn't Always Like This (But Also It Was)
I'm not a fan of making the past seem better than it was. Dealing with jQuery spaghetti code was a nightmare in itself. PHP templating with inline SQL left our applications so vulnerable you could drive a truck through the holes. There were real issues with the old days.
However, somewhere between hand-writing everything and needing 2000 modules to render a button, we overshot. We went from solving user problems to solving developer-experience problems to solving problems that only exist because of the tools we chose to solve the previous problems. It's turtles all the way down. 🐢
The Uncomfortable Fix
The solution doesn't lie in a new tool. It comes down to restraint.
Before you add a dependency, ask yourself one question: who does this serve? If the answer is "it makes the DX nicer for our eight-person team," that might be fine. If the answer is "everyone uses it," that's not a reason — that's peer pressure.
The most effective engineers I've worked with have one thing in common. They're happy being boring. They choose the smallest tool that accomplishes the task at hand, and then they get on with their lives. They don't need the architecture to be interesting. They need the product to ship. 🚀
Start with what solves the user's problem, and work backwards. Not with whatever new hotness the latest blog post introduced to your ecosystem.
So Where Does That Leave Us?
The thread wasn't just people complaining. It was a signal. A lot of developers are quietly exhausted by tooling that exists to justify itself.
We earned this. Every time we npm install'd our way to a 400MB node_modules folder for a freakin' landing page, we earned it. The good news is we can also un-earn it — one boring, right-sized decision at a time.
What's the most over-engineered setup you've ever seen on a project that definitely didn't need it? Give me your horror stories. 👇
Top comments (0)