Discussion
Moving Railway's Frontend Off Next.js
mlnj: 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.
jspaetzel: Incredible that the builds were ever 10min. How far things have regressed.
mellosouls: Reminder, as its not mentioned:Next.js is produced by Vercel, a competitor to Railway.
debarshri: Moving to vite + tanstack builds faster is also a fact.
maccard: 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..
Hamuko: As a non-frontend developer mainly observing and touching something here and there, a lot of the things that frontend developers do seem vastly over-engineered.
thibran: Isn't the main problem that the building blocks the modern web is based on are not a good fit for what we do with it?CSS is a total mess. HTML is a mess. JS is okay, but is not a high quality language.We would save so much time and money if we would have a modern base to build on. Sadly this will probably never happen, because company interests will try to corrupt the process and therefore destroy it.
UserMark: 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.
ramon156: I'm not insanely deep into frontend, I mostly just pick up React and call it a day, but it seems like this is also over-engineered?I've seen vanilla JS before, and I just know I wouldn't want to do the housekeeping that comes with it. People claim it's less work because it' simpler, but I fully expect myself to rewrite the thing at least twice, only to give up because I have no actual mental model anymore of how it works.
huksley: 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.
Kelteseth: As a cpp developer I had to chuckle there. And I thought our compile times were bad.
samwreww: They don't even mention the Next.js version used - where they using Turbopack or not?
abustamam: I've used the other major meta frameworks (remix and tanstack). I don't think there is a way to improve the speed of building the app in those ecosystems. Happy to be proven wrong.
abustamam: It's not mentioned because it's not relevant.
abustamam: I've been pretty happy with TanStack start for a medium-sized project. I would not know how its build time would compare to Next, but our similarly sized Remix (sorry, React router v7) app takes longer to build.TanStack just has a nicer mental model overall and works great with TanStack query for cache I validation and stuff like that.Remix was promising but there was so much ceremony in registering API routes and stuff. Tanstack just lets you define server functions arbitrarily with no ceremony.Might be worth a spike and some tokens to ask Claude Code to migrate and test the build time and ergonomics.
miyuru: 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
tgdn: 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.
SilverSlash: I hadn't heard of TanStack but a quick look at their website doesn't inspire confidence tbh. I mean, just take "TanStack Pacer".It provides such things as:```import { Debouncer } from '@tanstack/pacer' // classconst debouncer = new Debouncer(fn, options)debouncer.maybeExecute(args) // execute the debounced functiondebouncer.cancel() // cancel the debounced functiondebouncer.flush() // flush the debounced function```Why? Just why do you need to install some "framwork" for implement debouncing? Isn't this sort of absurdism the reason why the node ecosystem is so insecure and vulnerable in the first place? Just write a simple debouncer using vanilla js...
Hendrikto: Two minutes is still way too long. What are we doing? This is ridiculous.
selfmodruntime: We're doing structural type checking for a language that wasn't developed with that in mind.
selfmodruntime: How are CSS and HTML a mess? Combined, they're an incredibly powerful layout engine that works almost the same across all environments and devices while also featuring easy accessibility.
SilverSlash: 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?
GrayShade: We've had shitty bloated websites before LLMs were a thing.
l5870uoo9y: 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/
ai_slop_hater: When you create a Next.js project from Vercel's template, you get an AGENTS.md that literally says "THIS IS NOT THE NEXT.JS YOU KNOW"
mcintyre1994: Is that because LLMs default to the older pages router? Or are they actually providing a different version of the library optimised in some way for agents?
selfmodruntime: I have never in my career encountered a Vanilla JS project of at least medium size that I would have called simple. They all feature brittle selfmade frameworks whose developers have since left the company years ago.
selfmodruntime: C is infinitely less complex to parse and validate than Typescript. C is compiled in a single pass, the `tsc` type checking algorithm has to check structural typing, conditional types and deep generics while also emulating JS' dynamic behaviour.
itopaloglu83: It’s mind blowing when you check the generated code, because it goes over 50 elements deep for a simple looking website.Makes me think that there’s no way this is computationally efficient either.
crooked-v: That particular issue is nothing to do with Next or React and everything to do with how HTML/CSS is a really shitty layout engine.
maccard: Hard disagree. This is JavaScript frameworks building a hierarchy for themselves and ignoring any sort of complexity on the generated DOM. There’s 0 reason for these 8-10 nested divs other than that’s what the framework spits out.
ai_slop_hater: I think they just want LLMs to read the docs instead of using their own knowledge. For example, when I used Next.js a few months ago, models kept using cookies() and headers() without await, because that's how older Next.js versions worked, but modern Next.js requires await. I imagine there are more cases like this.
maccard: I disagree - this is an excuse. Even the post we’re commenting in now shows that it’s a series of poor abstractions and bad tooling that takes way too long to do the basics, combined with a language and ecosystem that encourages this behaviour . They saw a 5x speed up by changing tools while still using a JavaScript framework so it’s clearly possible for it to not be complete nonsense.
christoff12: [delayed]
mememememememo: Wait till you use HTMX!
SilverSlash: As in, htmx is better? I haven't used it but last I looked into it I was extremely confused as to whether it was a meme, an actual framework, or both.
mememememememo: None of the above. It is a utility (I guess framework maybe) for a feature that was cool in ASP.NET back in 2005. But that is it's charm. It is just JS swapping out the dom for you.
fnoef: :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?
yla92: Both can be true at the same time!
pjmlp: Like using SPAs for classical Web development, and then they rediscover PHP.
pjmlp: Zero references to Turbopack, maybe start there?
thibran: When taking a bird eyes view on CSS it will be hard to oversee that CSS is a mixture of different concepts that evolved over time with a lot of inconsistentsies. It possible to make it work, but it's not pretty.Same for HTML. If the web would be reimagined today, there is a very low chance that we would HTML as is.
rk06: the biggest problem with html/css is that they are tightly coupled. you can't meaningfully modify a layout with css alone.second biggest problem is "no stricter mode". so even wrong or useless html/css code goes unflagged and is treated as it is normal.CSS is way too powerful.
rho138: > you can’t meaningfully modify a layout with css alone Wut?
HeavyStorm: That's not the point...
