We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

Original Article ↗ Hacker News Discussion ↗

Next.js vs Vite/TanStack and Build Times

  • Many commenters relate similar migrations from Next.js to Vite + TanStack (or Astro/static HTML) cutting CI builds from ~7–12 minutes to ~1–2 minutes or even seconds.
  • Some argue the real win is swapping Webpack for modern Rust/Go-based tooling; they suggest trying Turbopack first, reporting 6→2 minute improvements.
  • Others say even with Turbopack, builds remain frustratingly slow and hard to optimize, especially for client-heavy apps that don’t benefit from Next.js’s server-first features.
  • Several note that for mostly-static or marketing sites, Next.js’s complexity and build cost feel unjustified vs static or simpler setups.

Vendor Lock-In and Vercel vs Railway

  • Multiple comments remind that Next.js is built by Vercel, a Railway competitor, and argue this should be disclosed as context.
  • Some report friction using Next.js off Vercel historically, though adapters and other hosts now exist.
  • Others insist the competitive relationship is irrelevant to the technical build-time critique.

Frontend Complexity, Overengineering, and the Web Stack

  • There is broad frustration that modern frontend builds can exceed Linux kernel compile times.
  • Many see the React/Next/tooling ecosystem as over-engineered layers on top of flawed or awkward primitives (HTML/CSS/JS).
  • Counterarguments highlight HTML+CSS as a powerful, accessible layout system; issues are blamed on frameworks generating deep, unnecessary DOM trees.
  • Debates arise over whether complexity is driven by genuine needs, organizational scaling, or fashion/abstraction for its own sake.

Alternatives: Simpler Stacks, HTMX, and Server-Rendered Apps

  • Several advocate returning to server-rendered HTML with minimal JS (Django, Rails, .NET, jQuery, HTMX, Blazor-like approaches), emphasizing no build steps and fewer dependencies.
  • Others respond that such setups become hard to manage for larger teams or more interactive apps, though some disagree and say most apps are just forms and pages.

Performance of Railway’s Own Site

  • Commenters test Railway’s domains page and report heavy payloads (~10 MB+), long load times, layout shifts, and laggy scrolling.
  • A single ~3.5 MB PNG background is called out as a major, non-framework-related optimization miss.

DevOps vs PaaS Debate

  • A long subthread debates self-hosted VPS (nginx/Caddy, Docker, automation tools) vs managed platforms.
  • One side stresses the hidden long-term maintenance burden; the other claims modern tooling and automation make VPS management trivial for competent developers.