The Modern JavaScript Stack Is Powerful and Painful
I re-entered full-stack development after a decade in enterprise architecture. The modern JS stack can be productive—but its also a house of mirrors held together by duct tape and package churn.
Nino Chavez
Product Architect at commerce.com
I re-entered full-stack development after a decade in enterprise architecture and Java-land. I picked a “modern” tech stack: React, Next.js, Tailwind, Prisma, Supabase, tRPC. It’s what everyone says is the fastest, most productive way to ship full-stack webapps in 2025.
And it can be. But it’s also a house of mirrors held together by duct tape, fanboy energy, and package churn. I’m saying this not as a hater, but as someone who chose it, used it, and felt every sharp edge.
This isn’t a “React is dead” rant. This is me asking: how did we let developer experience get this bad—and pretend it’s progress?
I’m Not Watching This. I’m Living It.
This isn’t recycled rage from a podcast. This isn’t a YouTube rant dressed up as experience.
I’m building a real production-grade tournament app—real users, real deadlines, real backend logic. Not a blog. Not a todo list.
A transactional system with authentication and roles, real-time match syncing, edge function orchestration, and Supabase as the full backend layer.
I’m in the trenches. Shipping production code. Debugging AI-generated TypeScript. Building the actual stack everyone claims is “best-in-class.”
AI Didn’t Break the Stack—It Exposed It
I use AI tools like GPT-4 and Kilo to write, test, and audit code. That should make everything easier.
Instead, it exposed how fragile and misaligned this stack really is.
Case in point: Kilo audited my package.json and flagged a critical misconfiguration—missing dependencies tied to Vite’s manualChunks. Except the project built fine. The config was idiomatic. The logic was intentional. And the packages weren’t even required.
Kilo eventually retracted everything. It admitted it misunderstood how Vite’s manualChunks works, didn’t verify the build, and assumed complexity where simplicity was intentional. Then it claimed it had “learned from this mistake.”
But it hadn’t. It couldn’t. Because most AI tools don’t learn. They simulate correction—they do not operationalize it.
That’s the real story here: not just DX rot, but tooling that pretends to understand while failing silently in the details. Even the AI is confused by the stack we’ve created.
Complexity That Pretends to Be Flexibility
Everyone loves to say: “React gives you the freedom to choose.” But freedom without conventions is just chaos.
You don’t scaffold apps anymore. You negotiate toolchain treaties. Which flavor of routing? App vs Pages? Which state system: Context, Jotai, Redux Toolkit, Zustand? Which data fetching: SWR, React Query, native fetch, tRPC?
You end up building the very framework that older stacks already provided.
I’ve used Spring Boot. I’ve used Rails. They’re not perfect—but they had guardrails, batteries included, and 80% of the app done on day one.
This “assemble your own platform” model? It’s DX hell in a productivity costume.
Enterprises Use It… But With a Muzzle On
Some will say: “But Netflix uses Next.js. GitHub uses React. It’s enterprise-grade.”
Sure—but not like you think.
Enterprises tame the stack with internal forks and vetting, golden path templates, CI/CD and enforced versions, disabled experimental features, and full-time platform teams keeping it glued together.
They’re not chasing React Server Components or bleeding-edge Tailwind configs. They’re freezing the chaos. Stabilizing the churn. So they can survive a 5-year roadmap without rewriting their UI every quarter.
DX Is a Liability Now, Not a Differentiator
What does modern dev actually feel like?
Every blog post is about fixing useEffect. Every issue is about Vercel configs. Every framework update is a breaking change with a Discord server full of workarounds.
React’s promise was “just a view library.” Now it’s a load-bearing empire with enough complexity to rival legacy Java EE.
I shouldn’t need to learn how Webpack’s replacement (Turbopack) streams partial hydration into a React Server Component rendered via suspense on an edge function just to display a list of teams.
There Are Better Ways
This isn’t just a rant. This is a call to look elsewhere.
RedwoodJS gives you a real full-stack JS experience—with structure. Rails still gets you 80% of the way with no glue code. Phoenix + LiveView = real-time, zero-JS madness with clarity. SvelteKit, SolidStart, Astro—lightweight, coherent, joyful.
Modern JS stacks aren’t broken by definition—they’re broken by integration burden. The stack is only “great” if you already know its edges, you accept constant churn, and you build your own conventions.
Otherwise? It’s a Rube Goldberg machine where you write one line of code and it sets off a chain reaction in six files you didn’t touch.
The Real Question
I don’t want another demo video or Hacker News link. I want battle scars. I want receipts.
If you’ve felt the same pain: you’re not crazy. If you think I’m wrong: show me the coherence. The joy. The DX that doesn’t involve choosing 12 libraries and praying they work together in Next.js 15.
Maybe I’m missing something. Maybe there’s a way to use this stack that doesn’t feel like fighting it constantly. But right now, the gap between what’s promised and what I’m experiencing is wider than I expected.
Originally Published on LinkedIn
This article was first published on my LinkedIn profile. Click below to view the original post and join the conversation.
View on LinkedIn