At some point, frontend devs became build engineers without realizing it.
What started as a webpack.config.js turned into a devops theater production: Vite for dev, esbuild for speed, tsc for types, SWC for transforms, Babel for legacy, Turborepo for caching, Prettier for vibes.
Half your time isn’t spent building apps — it’s spent building the build.
You’re debugging sourcemaps. Resolving plugin conflicts. Reading RFCs for bundlers that are “blazingly fast” but break on Tuesdays.
This is not productivity.
This is paranoid overengineering masquerading as modern development.
The Toolchain Tax
Every tool you add comes with:
- Mental overhead — You now need to understand how it works and how it breaks.
- Integration pain — Tools don’t compose cleanly. They compose chaotically.
- Version fragility — Upgrades become diff hell. Dependencies fall out of sync.
- Opaque performance issues — Is it Vite?
ts-node? A rogue plugin? Flip a coin.
Most teams aren’t speeding up delivery.
They’re spending sprints fixing their own infrastructure.
When Tools Become a Cult
The web dev ecosystem loves “best practices” that are suspiciously complex.
We optimize before we validate.
We scaffold before we sketch.
We argue about whether tsx should go in src/pages or app/routes instead of asking, “Do we need this at all?”
The result is yak-shaving disguised as progress.
Shiny tools justify their own complexity by promising escape from older complexity.
You chase simplicity through abstraction — and end up with neither.
The Paradox: Simpler Is Harder
The most robust stacks look boring:
- Vanilla HTML/CSS with sprinkles of JS
- Minimal build steps (or none at all)
- Clear, predictable deployment paths
But boring doesn’t tweet well.
It doesn’t have a Discord server.
It doesn’t spawn a startup.
So we overbuild to look modern.
We mistake complexity for capability.
Sanity Check: Productive vs. Paranoid
| Signal | Productive | Paranoid |
|---|---|---|
| Builds | One tool, minimal config | Multiple layers, redundant transforms |
| DX focus | Real developer needs | Edge-case fetishism |
| Stack changes | Based on app needs | Based on Twitter threads |
| Debugging | Rare and obvious | Frequent and mysterious |
| Tool upgrades | Safe and boring | Stressful and breaking |
Audit Your Stack. Then Burn It Down.
Ask yourself:
- Do we need this tool, or are we compensating for another tool’s failure?
- Is our build pipeline solving real problems — or creating new ones?
- Could we replace three layers with one sane default?
Your toolchain should be a scaffold — not a second job.
Build less.
Ship more.
And stop confusing clever with useful.