8 ms·
We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
- mellosouls 6mo agoReminder, as its not mentioned: Next.js is produced by Vercel, a competitor to Railway.
- debarshri 6mo agoMoving to vite + tanstack builds faster is also a fact.
- pjmlp 6mo agoOnly if they weren't using Turbopack.
- lukasholzer 6mo agodoes turbopack make such a difference on next.js sites?
- pjmlp 6mo agoYes, because it is yet another Typescript and Webpack like compiler written in Rust. Note how many HNers are making the same remark.
- abustamam 6mo agoIt's not mentioned because it's not relevant.
- mellosouls 6mo agoOf course it should be mentioned, it's a basic disclaimer.
- norman784 6mo agoI don't know the situation now, but a while ago there were a lot of pushback using Next.js because it was not easy to use all features if not hosted on Vercel.
- abustamam 6mo agoWe used NextJS on a project hosted on AWS a while ago. We learned quickly it wasn't the best tool for what we wanted to do which is why we stopped using it. But it's an open source project whose purpose is to drive devs to Vercel. It doesn't surprise me that there are some features that work best with Vercel (but it does surprise me that only recently other providers started to need adapters). Anyway, my point is that no one is forced to use NextJS and if they like NextJS but not Vercel they can always fork it or, apparently write an adapter.
- pjmlp 6mo agoBesides the way it maps server side code into serverless, it has a custom runtime, functions that expose cloud infrastructure, integration with multiple language runtimes for the backend. You get to pick Vercel + headless CMS + assets managed + eshop, and you're done in terms of big corporations. Might seem a lot in licenses, however it allows for smaller dev teams, which is what management floor cares about, all those salaries.
- cryptonym 6mo agoTrue. That framework is owned by a cloud company and the way they host Next.js apps in a secure and scalable way remains secret sauce. Now it doesn't really impact build time and Railway offers Next.js hosting.
- maccard 6mo agoIt’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 6mo agoAs 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.
- ramon156 6mo agoI'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.
- selfmodruntime 6mo agoI 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.
- maccard 6mo agoI write C++ and C# all day - I think it’s fair to say the same about a project in any programming language!
- thibran 6mo agoIsn'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.
- jspaetzel 6mo agoIncredible that the builds were ever 10min. How far things have regressed.
- deleted 6mo ago[deleted]
- mlnj 6mo agoThis 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.
- abustamam 6mo agoI'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.
- nulltrace 6mo agoCould be the bundler re-resolving the whole dependency graph on every build, even when nothing changed.
- tgdn 6mo agoWe 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 6mo agoI 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' // class const debouncer = new Debouncer(fn, options) debouncer.maybeExecute(args) // execute the debounced function debouncer.cancel() // cancel the debounced function debouncer.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...
- MajimasEyepatch 6mo agoObviously it's more than just debouncing. https://tanstack.com/pacer/latest/docs/overview https://tanstack.com/pacer/latest/docs/overview
- chrisweekly 6mo agoThat's putting it mildly!
- tacker2000 6mo agoTanStack started out by providing a very good JS table library. Now they offer a Router, and some more libs. They are definitely an up and coming name in the JS space.
- 6mo ago
- UserMark 6mo agoI 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.
- Kelteseth 6mo agoAs a cpp developer I had to chuckle there. And I thought our compile times were bad.
- abustamam 6mo agoI'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.
- UserMark 6mo agoI've been on the remix on a previous project, I have to say that Remix was even worse. But that's probably of the setup with vite etc not being correctly done.
- cryptonym 6mo agoIs server-rendered HTML that bad for 2026 web or is everyone building complex apps? Many of my customers insists on using Next.js or similar but when I browse their website I don't get the point. They are downloading and executing megabytes of JS while in-page interactions tends to be limited to few basic stuff. Never seen one of their project requiring offline mode. Maybe that's being able to easily replace a [FRAMEWORK] dev with another.
- sosodev 6mo ago
- samwreww 6mo agoThey don't even mention the Next.js version used - where they using Turbopack or not?
- wilson090 6mo agoexcellent question - recently switched from turbopack after getting annoyed by build times. we saw them go from 6 mins to 2 mins
- huksley 6mo agoAnyone 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.
- wouldbecouldbe 6mo agoThe 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
- huksley 6mo agoNot containers to blame but overprovisioning and how much resources dedicated to building. I am not sure how Vercel gets things build in literal seconds, but, hey, they are the creators of NextJS. At DollarDeploy we building it also in containers but every build get 4GB/2CPU so it is quite fast but not as fast as Vercel.
- pjmlp 6mo agoTurbopack, custom runtime infrastructure on top of AWS Lambda.
- huksley 6mo agoTurbopack does not work for every app, I think they skip some build steps when building like typescript validation etc and aggressively cache node modules.
- pjmlp 6mo agoThe biggest issue is missing plugins, but they have an extension point to add them. Naturally they expect them to be written in Rust, which might be an issue for some then again Vite folks are also going into RIR.
- bgwhn 6mo ago> skip some build steps There was a change in Next 16, not Turbopack, that removed `ESLint` during `next build`: https://nextjs.org/blog/next-16#breaking-changes-and-other-updates https://nextjs.org/blog/next-16#breaking-changes-and-other-u... This behavior is the same whether you use Turbopack or webpack. It doesn't make sense for us to couple ourselves with ESLint when there are many viable alternatives. No other popular frameworks run ESLint automatically during builds. This change in Next 16 brought up closer to parity with other frameworks and bundlers. > typescript validation There's no change here with Turbopack. We do still run `tsc` automatically to check your types. That's part of `next build` and not Turbopack. However, we may remove this in the future for similar reasons. There's no good reason for the bundler to call the typechecker. Bundlers strip types. Historically this was done with Babel in webpack. Modern versions of Next.js use SWC for type stripping in both webpack and Turbopack. > aggressively cache node modules We aggressively cache everything. We don't have special-casing for `node_modules`. See our blog post about our caching system: https://nextjs.org/blog/turbopack-incremental-computation https://nextjs.org/blog/turbopack-incremental-computation Interestingly vite does actually special-case and cache `node_modules`: https://vite.dev/guide/dep-pre-bundling https://vite.dev/guide/dep-pre-bundling There are tradeoffs to both approaches, and I think Vite's choice makes sense in the context of their broader minimal-bundling-in-dev design, but it makes less sense for Turbopack (as well as webpack and Rspack) where we produce bundles in dev.
- Paul20261 6mo ago[dead]
- mememememememo 6mo agoWait till you use HTMX!
- SilverSlash 6mo agoAs 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 6mo agoNone 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.
- recursive 6mo agoNot sure what you're thinking of, but the first release of HTMX was 2020. Its predecessor, intercooler, was first released in 2013.
- mememememememo 6mo agoYep but the idea goes back further. Memory is vague but this may have been it. https://www.ajaxtoolkit.net/DynamicPopulate/DynamicPopulate.aspx https://www.ajaxtoolkit.net/DynamicPopulate/DynamicPopulate....
- 0x457 6mo agoHTMX is great when your web interface is just a representation of a server state. If web interface is an application backed by a remote state HTMX falls apart.
- nchmy 6mo agocan you give an example?
- Hendrikto 6mo agoTwo minutes is still way too long. What are we doing? This is ridiculous.
- selfmodruntime 6mo agoWe're doing structural type checking for a language that wasn't developed with that in mind.
- rishabhparikh 6mo ago2 mins for a production deploy of an app with millions of users? Seems fine to me! How fast would you expect it to be?
- BoredPositron 6mo agoHow does an apps user base affect its build time?
- jasonlotito 6mo agoNot the op and I get your point, however... One way to think about it might be that the site supports lots of users who use it for various things. So, everyone uses 80% of the site, but everyone also uses a different portion of the final 20%. So, if you have lots of users, you might also have lots of smaller features that a significant minority use. I don't know, just an interesting way of thinking about it.
- mbesto 6mo agoIt's a proxy for complexity.
- bdangubic 6mo agothat makes 0 sense
- bdangubic 6mo agoso build time scales with the number of users? meta's build times of roughly 2hrs and 11 minutes then makes a lot of sense
- fnoef 6mo ago: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 6mo agoBoth can be true at the same time!
- SilverSlash 6mo agoA 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?
- ai_slop_hater 6mo agoWhen 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 6mo agoIs 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?
- ai_slop_hater 6mo agoI think they just want LLMs to read the docs they began shipping[0] along with the library 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. [0]: https://nextjs.org/docs/app/guides/ai-agents#how-it-works https://nextjs.org/docs/app/guides/ai-agents#how-it-works
- HKayn 6mo agoOne rather prominent case would be Tailwind. v4 made breaking changes in the way Tailwind is set up, requiring different packages and syntax. However, if you ask an LLM how to set up Tailwind on your Vite & React app, it will confidently list the setup steps for Tailwind v3, which no longer work. At times I would see people daily asking for help with their broken Tailwind setups, and almost always it was them trying to use Tailwind v4 the v3 way because some AI told them so.
- miyuru 6mo agoI 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 https://railway.com/domains
- anematode 6mo agoDear lord. It's actually laggy for me to scroll on that page.
- hazelnut 6mo agosame here and I'm using a beefy MacBook (Apple M4 Max, 64gb ram). something is wrong with the front end code. there are a lot of animations, so my hunch would be that something goes wrong there.
- petcat 6mo agoweb dev is a sewer All my projects are server rendered with jinja/minijinja, bootstrap, jQuery, and htmx when I need a little bit of SPA behavior on forms. No builds, just static <script src= tags. Very fast and easy. I'll never recommend anything else.
- l5870uoo9y 6mo agoI 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/ https://www.sqlai.ai/
- christoff12 6mo agothis is neat
- xandrius 6mo agoWhy is everyone so afraid to get a $5/mo Ubuntu/Debian VPS, install nginx and call it a day? Then you can even run multiple projects off the same server.
- kami23 6mo agoI just did this over at Hetzner and Claude admins it for me so I don't need to learn the CLI or anything, describe the proxying I want, and it setups up a bunch of small side project pages for me.
- xandrius 6mo agoFor me I always default to UpCloud, great team and great services. From Finland!
- kamikazeturtles 6mo agoHow do you use Claude to admin it? Does Claude SSH into the server and do everything or just write bash scripts?
- mdrzn 6mo agossh into the VPS and launch ClaudeCode directly on the machine, so it has full access
- sanghyunp 6mo ago[flagged]
- oefrha 6mo agoTime 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.
- eino 6mo agoWe 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.
- Chepko932 6mo ago[dead]
- pjmlp 6mo agoZero references to Turbopack, maybe start there?
- lukasholzer 6mo agoThis 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!
- sakopov 6mo agoCan we just get back to html/jQuery/handlebars? Those were the good old days :`(
- deleted 6mo ago[deleted]
- ceritium 6mo agoRailway should try Rails
- dmix 6mo agoYou can't keep JS devs away from the new shiny framework for long.
- butz 6mo agoNow try to do the same thing that MDN did to their website and reduce 2 minute build times to 2 seconds.
- wackget 6mo agoWebsite development should not require any build steps whatsoever and I will die on that hill.
- midasoperator 6mo ago[flagged]
- falcor84 6mo agoI loved reading: > we sponsor both Vite and TanStack because we believe in where they're going I'd like to see more of this attitude.
- pcmaffey 6mo agoFunny, I just today merged our migration from Next (with turbopack, page router, ~200 pages) to Vite + Tanstack Router. Builds went from 2.5m to 25s. But even bigger was the improvement to dev mode compile times. With Vite it’s near instant. With Next running our e2e tests in development was utter pain. So happy to leave next & vercel behind.
- deleted 6mo ago[deleted]
- rzkyif 6mo agoI think one of the less mentioned benefit of coding agents these days is how much easier it is to do big migrations like these Recently I was ~70% done on a project using the relatively young Electrobun framework when I hit a non-negotiable limitation So I told a $$$ agent to plan and implement a migration to Tauri, then repeated the loop of telling a $ agent to look for feature parity issues and having a $$ agent verify and fix the issues In a couple of hours I got virtually the same app in a different framework So there's definitely less burden in choosing the right framework at the start of a project, and less justification to keep a suboptimal infrastructure simply due to cost of migration
- dmeijboom 6mo agoMakes sense. At brainpod.io we moved from Next.JS to Deno Fresh. Not 100% happy but definitely an improvement. Also via Vite (since V2). I loved NextJS when it was relatively new but with turbo pack, the app router (and the insane amount of bugs that came with it) it's no longer my go-to frontend framework.
- plasticeagle 6mo agoAI;DR
- nextlsj 6mo ago[flagged]