We moved Railway's frontend off Next.js. Builds went from 10+ mins to under two
Railway made headlines by successfully migrating their entire production frontend from Next.js to a Vite + TanStack Start stack. This ambitious technical overhaul dramatically slashed build times from over ten minutes to under two, significantly boosting developer experience for their client-heavy application. The move ignited spirited debate among developers regarding Next.js's architectural choices and the broader landscape of modern frontend development.
The Lowdown
Railway, a platform provider, recently detailed their significant migration of their primary frontend – encompassing their dashboard, canvas, and main website – off Next.js. They successfully transitioned to a new stack built on Vite and TanStack Start, executing the entire change in just two pull requests with zero downtime. This post lays out the 'why' and 'how' of their architectural pivot.
- The Next.js Quandary: Railway initially found Next.js beneficial, but its build times ballooned to over 10 minutes, with a substantial portion dedicated to 'finalizing page optimization.' The framework's server-first philosophy, especially with the Pages Router, clashed with Railway's overwhelmingly client-side, stateful application, necessitating complex workarounds for basic layout and routing needs.
- The TanStack + Vite Solution: The new stack was chosen for its alignment with Railway's explicit, client-first development style. Key benefits include type-safe routing, first-class layout support, instant Hot Module Replacement (HMR), near-zero startup times, and the flexibility for selective server-side rendering (SSR) only where truly needed.
- Two-PR Migration Mastery: The migration was meticulously planned and executed in two distinct phases. The first PR focused on decoupling, replacing all Next.js-specific APIs (
next/image,next/head,next/router) with native browser APIs or framework-agnostic alternatives. The second PR then cleanly swapped the framework, migrating over 200 routes and integrating Nitro as the new server layer, centralizing configurations like redirects and security headers. - Navigating Trade-offs: While gaining speed and explicit control, Railway acknowledged trading built-in Next.js features like image optimization (now handled by Fastly at the edge) and certain ecosystem tools (replaced by small in-house solutions). They embraced TanStack Start's relative newness, confident in its direction and the responsiveness of its maintainers.
- 'Railway Runs on Railway': The migration also served as a testament to Railway's own platform capabilities. Their production frontend is deployed using the same tools users have access to, showcasing the platform's support for fast builds, immutable assets, and zero-downtime rollouts without infrastructure changes.
- Embracing Iteration Speed: The core motivation was to minimize the bottleneck between writing code and deploying it. The new stack, combined with edge caching and an efficient asset model, positions Railway for near-instant frontend changes.
This case study effectively demonstrates how a strategic framework change, driven by specific application needs and developer experience considerations, can yield substantial improvements in performance and iteration velocity, even for a large-scale production application.
The Gossip
Next.js's Nagging Negatives
Many commenters echoed Railway's frustrations with Next.js, particularly its increasingly slow build times (often 7-10+ minutes) and its server-first orientation feeling mismatched for client-heavy applications. Some highlighted how Next.js's complexity and 'magic' led to unexpected build overhead, even for simple static sites, with several users expressing relief or renewed confidence in moving away. However, some pointed out potential solutions like using Turbopack in newer Next.js versions for significant build time reductions, while others noted the disparity between Vercel's build speeds and self-hosted Next.js deployments.
Frontend Framework Follies
The discussion quickly broadened to the general state of modern frontend development, with many users expressing exasperation over perceived over-engineering, bloat, and the rapid churn of frameworks. Critics questioned the necessity of complex frameworks for seemingly simple websites, lamenting the large bundle sizes and slow rendering experienced by end-users (one commenter noted Railway's own domains page was 10.8MB and took 17s to fully render). The continuous cycle of adopting and abandoning 'popular' frameworks was a common sentiment, prompting questions about the underlying quality of web building blocks like HTML and CSS.
TanStack's Terrific Transition (and Trade-offs)
The community generally praised Railway's two-PR migration strategy as disciplined and effective. Many users shared positive experiences with TanStack Start, citing its type-safe routing, explicit mental model, and improved build times as key advantages, especially for client-side applications. Some even reported similar successful migrations from Next.js to Vite + TanStack. However, some expressed skepticism about TanStack's componentization, questioning the need for framework-level utilities for basic functions like debouncing, and highlighting the overall complexity of the modern Node.js ecosystem.
Corporate Cross-Currents (Vercel vs. Railway)
A notable undercurrent in the comments revolved around the competitive relationship between Railway and Vercel, the creator of Next.js. Some commenters explicitly pointed out that Next.js is produced by Vercel, a direct competitor to Railway, implying this context is relevant to the article's narrative. Others dismissed this as irrelevant, advocating for a purely technical focus. The discussion also touched on how Next.js's tight integration with Vercel's hosting environment might lead to performance disparities or feature limitations when deployed on other platforms, like Railway itself.