I just tried their domains page it took 10.8MB of data and took 2s for the DOM to be ready.

page actually took 17s to fully render with multiple shift changes.

all to render a domain search bar similar to google home page.

https://railway.com/domains

I migrated the landing pages for my app[1] from Nextjs to Astrojs mainly because I was paying Vercel $20 per month for serving static pages(it’s 4 times more than I pay Railway for the Postgres database for the actual app and also 4 times more than I pay Cloudflare for hosting all my apps). I used AI for migrating and it took a few days only as the existing repo was used as “instructions” and it included some upgrades and improvements here and there.

[1]: https://www.sqlai.ai/

Railway should try Rails

We went through a very similar migration. Had a Next.js landing page and a separate TanStack Router SPA - consolidated both into a single Vite + TanStack Start app. Same experience with build times and the architecture mismatch: our app is heavily client-side with real-time state, and fighting Next.js's server-first assumptions wasn't worth it. TanStack Router's type-safe routing and file-based route generation have been great.

You can't keep JS devs away from the new shiny framework for long.

Two minutes is still way too long. What are we doing? This is ridiculous.

I have a Nextjs heavy app which takes around 7 minutes currently. But I've been thinking of moving away from next for a long time now. TanStack seems to be a good fit. This gives me a bit more confidence in just doing it.

Now try to do the same thing that MDN did to their website and reduce 2 minute build times to 2 seconds.

A lot of the LLMs are very familiar with next.js and vercel is also aggressively building an ecosystem around their tooling for LLMs. So I wonder if this problem will only be exacerbated when everyone using LLMs is strongly nudged (forced) to use next?

Incredible that the builds were ever 10min. How far things have regressed.

The irony is deploying NextJS on the railway platform is super slow since they use containers, on Vercel 2 min is like 12 min on railway, deployments on a vps are only like 20 seconds.

*I know this is just build time, so this is different then their deployement time

Time to move your blog off Next too? It’s slow as molasses for me, loads a billion JS chunks and JSON fragments, when it can be a static site.

This is the kind of post I wish more teams would write. The "we picked the popular thing and it got slow" story is so common. But most teams just live with it. They don't want to touch it. 10 minutes to 2 minutes is huge for dev speed!

I'm a huge fan of tanstack start especially the ability to just static prerender some paths (a feature I'm missing a ton with astro) For me tanstack start is the new dominator on the stack!

We made a similar move from Next.js to Vite (with Tanstack router): CI build dropped from 12 min to barely 2 min. We won't look back.

They don't even mention the Next.js version used - where they using Turbopack or not?

:suprised_pikachu_face:

Is the quality of software engineers really dropped that low that people get excited when they move off from "heavy bloated" frameworks to lighter alternatives? Or is this just SEO farming garbage to position the company higher in search results?

Zero references to Turbopack, maybe start there?

Can we just get back to html/jQuery/handlebars? Those were the good old days :`(

This is one of the most frustrating thing about working with NextJS. There seems to be no way to improve the speed of building the app.

Anyone tried to use vinext from Cloudflare in production? Might be faster.

But seriously, not sure why NextJS builds take so much, we are using stable and functional pages router in DollarDeploy and it is still takes too much time to build.

Reminder, as its not mentioned:

Next.js is produced by Vercel, a competitor to Railway.

Wait till you use HTMX!

It’s absolutely mind boggling to me that we have gotten to a point that building a web frontend takes longer than compiling the Linux kernel..

[dead]

[dead]

The two-PR strategy is smart — decouple from the framework first, then swap it. That's the kind of migration discipline most teams skip, and it's why they end up running two systems in parallel for months.

I run a Next.js App Router site in production (marketing + blog). Build times aren't painful yet, but I've noticed the same pattern: most of the build time is Next.js doing things I didn't ask for. For a mostly-static marketing site it's tolerable, but I can see how it becomes a dealbreaker for a rich client-side app like Railway's dashboard.

Curious — after the migration, did you see any measurable difference in runtime performance (TTFB, hydration) or was the win purely on the build/DX side?