The JavaScript Framework Identity Crisis

I asked my junior dev to build a new feature in Next. He spent two weeks building a Nest service. At least he was only off by one vowel and the entire application layer

P1 alert: “Nxt latency > 300 ms”  -  now Next, Nuxt, and Nest teams are all on the bridge, and the real bottleneck is grep-ing three monorepos to learn what the alert even meant

After 15 years in the industry, I've learned that the hardest distributed systems problem isn't consensus algorithms or CAP theorem - it's explaining to a CTO why we need three different frameworks that sound identical but solve completely different problems, and why renaming them would break half the internet's build pipelines

When your tech stack meeting devolves into explaining that Next.js renders React on the server, Nuxt.js does the same for Vue, and Nest.js is actually a backend framework with decorators - and the PM still asks if they're interchangeable. The real villain here isn't the frameworks, it's whoever decided that appending '.js' to similar-sounding names was peak developer experience. At least they all agree on one thing: they're definitely not the same Spider-Man, even if your junior dev's resume lists proficiency in 'Next/Nuxt/Nest' as a single skill

I told the team to ship it in Next; we ended up with React SSR, a Nuxt pipeline, and a Nest module - plus three tsconfigs arguing over the same path alias

Next.js spawned the name, Nuxt Vue'd the clone, Nest decorator'd the backend - eternal framework finger-pointing ensues

Architectural note said “adopt N?xt.js”; the React team shipped Next, the Vue team shipped Nuxt, the backend rewrote in Nest - and now three routers are arguing over /auth