Victor Ramirez didn't set out to rip apart Railway's frontend stack. But when production builds stretched past ten minutes—six of those consumed by Next.js grinding through what logs cryptically labeled "finalizing page optimization"—the calculus became unavoidable. By April 3, Railway had shipped its migration to Vite and TanStack Router. Builds: under two minutes. Downtime: none. The whole thing took two pull requests.
It's the kind of migration story that's been circulating with increasing frequency, a quiet but persistent drumbeat in developer circles. Not because Next.js is broken, exactly. More because, for a certain class of application—think client-heavy dashboards, real-time interfaces, WebSocket-laden experiences—the iteration tax has climbed too high.
The Ten-Minute Problem
Railway wasn't suffering alone. Inngest, the workflow orchestration platform, watched local development page loads balloon to 10 or 12 seconds before they made the jump to TanStack Start in January 2026. After the switch? Two to three seconds. They'd already tried the usual remedies—Turbopack, newer Next.js releases—with middling results. What finally broke them wasn't just the wait times. It was the cognitive overhead: React Server Components, nested caching layers, a server-first architecture applied to what was, fundamentally, a client-side product.
By last September, forum threads on Render and GitHub issues had turned blunt. "Next.js is slow to build," read one title—no hedging, no qualifiers. These weren't outliers. DORA research from 2018 has shown that faster deployment cadence correlates with better team outcomes. When your build pipeline demands ten minutes, you're not just killing time. You're shipping less, iterating slower, and quietly frustrating the people who build your product.
A Satisfaction Cliff
The numbers bear this out, perhaps more starkly than anyone expected. The State of JavaScript survey, published in February 2026, showed Next.js satisfaction dropping from 68% to 55%—a 13-point slide, the steepest among major frameworks. Usage stayed high, around 59%, making it both the most-deployed and most-griped-about library in the survey. That's a telling combination: inertia, not enthusiasm.
Meanwhile, Vite posted 98% retention. Rust-based tooling like Rolldown, now integrated into Vite's pipeline, jumped from 1% to 10% awareness in a single year. TanStack Start—which hit Release Candidate status last September—ranked second in survey write-ins with 235 mentions, despite not even being a listed option. The momentum, in other words, is real.
Architectural Mismatch
Railway's rationale for moving centered on fit, not fashion. Their product—marketing site, dashboard, canvas interface—is overwhelmingly client-side, heavy on WebSockets and real-time state. Next.js's App Router, with its server-first assumptions, wasn't solving problems. It was creating them. The older Pages Router didn't offer enough upside to justify the build cost.
So they switched: Vite for instant hot module replacement and near-zero startup, TanStack Router for type-safe routing and proper layout primitives, Nitro to consolidate routing and caching logic. They replaced next/image with plain `` tags and Fastly Image Optimizer at the edge. Five hundred redirects, more than 200 routes—migrated cleanly. The result wasn't just faster builds. It was a model they could reason about.
Inngest's experience tracked similarly. They stuck with Next.js longer than some, upgrading through multiple versions, hoping the performance gap would close. It didn't. The React Server Components complexity and layered caching kept compounding. A single engineer completed the TanStack Start migration in weeks, leaning on AI tooling where it helped. The 83% improvement in local dev speed wasn't abstract—it changed how the team worked day to day.
Other teams followed comparable paths. T3 Chat and Mastra Cloud both announced exits from Next.js last December, opting for TanStack Start and Vite respectively. Pluslide migrated to Vite and Hono in January, citing both security worries and architectural simplicity. Treon Tech moved to Astro in February and cut JavaScript payload by 45%. The pattern: teams with either client-heavy workflows or content-focused sites found better matches outside the Next.js orbit.
The Alternative Ecosystem Hardens
The tooling landscape has evolved to meet this. Netlify became the official deployment partner for TanStack in March of last year, positioning itself explicitly against the Next.js-Vercel coupling—"anti lock-in," as they put it. React Router v7, which merged Remix features into "framework mode" last November, offers another React-first SSR/SSG route without the RSC dependencies. Astro keeps gaining ground for content sites where minimal JavaScript and islands architecture make more sense than full hydration.
These aren't experimental anymore. TanStack Start's Nitro integration enables deployment across Netlify, Cloudflare Workers, and traditional hosts. Railway, Render, Fly.io all support these stacks natively now. The infrastructure exists; it's not speculative.
What's notable is the decoupling trend. Railway's use of Fastly Image Optimizer replaced next/image with platform-agnostic transforms and caching. Their "Skipped Builds" feature, documented late last March, encourages runtime environment injection rather than build-time inlining—making builds cacheable and skippable across deployments. This mirrors a broader shift: teams extracting capabilities from monolithic frameworks—image optimization, caching, routing—and moving them to edge services or composable layers.
Security Incidents Didn't Help
Late last year didn't do Next.js any favors. On December 3, the React team disclosed a critical RSC vulnerability—CVE-2025-55182, rated CVSS 10—alongside Next.js-specific CVE-2025-66478. Unit 42 and state agencies documented active exploitation, with multiple advisories reporting rapid exploitation in the wild. Patched versions followed quickly, but the incident forced emergency upgrade cycles and prompted some teams to reconsider RSC adoption entirely.
An earlier middleware authorization bypass—CVE-2025-29927, disclosed in March of last year—had already raised eyebrows. For teams weighing framework lock-in against flexibility, security incidents requiring immediate patch cycles don't exactly sweeten the deal.
Next.js Isn't Standing Still
Fair's fair: the Next.js team has been working the problem. Version 16, released last October, and 16.2 in March both emphasized Turbopack and dev/start performance gains. Some community reports claim "up to 4× faster dev server" in certain configurations, though results vary wildly by codebase. The framework continues investing heavily in Rust-based tooling to close the gap with Vite.
ThoughtWorks' Technology Radar from last April endorsed Vite's developer experience while acknowledging Next.js's ongoing investment and platform synergy with Vercel. Some teams that tried migrating away ended up returning—for SEO, platform-specific features, reasons that made sense in their context. Framework fit remains, as ever, context-dependent.
The Realignment
What's happening isn't the death of Next.js. Usage numbers are too high for that narrative. It's a realignment, maybe. For content sites and marketing pages, Astro and similar tools offer minimal JavaScript and faster builds. For client-heavy React applications—dashboards, real-time UIs, authenticated experiences—Vite with TanStack Router or React Router v7 increasingly makes more sense than forcing everything through a server-first architecture.
The gap may narrow as Rust-based bundlers mature across both ecosystems. But right now, the developer experience delta is measurable. Railway and Inngest didn't migrate on ideology. They migrated because ten-minute builds and ten-second local reloads were destroying velocity. When one engineer can complete a framework migration in weeks and immediately see iteration speed double, triple even, the math becomes straightforward.
The broader lesson is perhaps about architectural honesty—not the sexiest topic, admittedly, but the one that matters. Next.js optimizes for server-rendered, streaming applications with tight Vercel integration. That's legitimate. Powerful, even. But when your product is fundamentally client-side—when you're managing WebSocket connections, real-time state, interactive canvas UIs—pretending otherwise creates friction everywhere. The migration wave isn't rejection, not really. It's teams finally admitting the mismatch and choosing tools that fit the problem they're actually trying to solve.
