Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.railway.com

Post reply on HN
Print view View original

51–60 of 230 posts

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

#51

Post by ai_slop_hater »

mcintyre1994 wrote: post #41
ai_slop_hater wrote: post #37

Earlier quoted context omitted.

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"

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?

I 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

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

#52

Post by maccard »

crooked-v wrote: post #34
itopaloglu83 wrote: post #30

Earlier quoted context omitted.

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.

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.

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.

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

#54

Post by christoff12 »

l5870uoo9y wrote: post #42

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 upgrade…

this is neat

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

#55

Post by cbovis »

wilson090 wrote: post #25
UserMark wrote: post #10

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.

Are you on turbopack? It's available on Next 16 and just took our build times down from 6 minutes to 2 minutes

Yep this is what's often misunderstood.

We also recently cut our build times in half moving from Webpack to Turbopack on production builds after jumping to NextJS 16. We'd already been using Turbopack in development for a while which yielded massive DX improvements related to performance. Production build times will drop further once Turbopack production build caching is stable.

Webpack -> Turbopack is the smart initial migration. I'd bet Railway went straight from Webpack -> Vite not realising that their real gains sat with the build tooling, not NextJS vs Tanstack.

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

#56

Post by maccard »

Hamuko wrote: post #8
maccard wrote: post #3

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..

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.

This is my understanding too - tools like react are like microservices - they’re a technical solution to an organisational problem. HTML/css/JavaScript is an imperfect abstraction, so we got bootstrap. Then we got client side frameworks which introduced a build step, and then we got asset bundles, optimisers, linters, validators, tree shakers, package managers, validators for your package managers. All of these monkey patched around the actual problem with more abstractions, and the end result is what we have now.

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

#57

Post by maccard »

selfmodruntime wrote: post #40
ramon156 wrote: post #9

Earlier quoted context omitted.

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…

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.

I write C++ and C# all day - I think it’s fair to say the same about a project in any programming language!

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

#58

Post by mememememememo »

SilverSlash wrote: post #32
mememememememo wrote: post #22

Wait till you use HTMX!

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.

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.

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

#59

Post by yla92 »

fnoef wrote: post #26

: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?

Both can be true at the same time!
Post reply on HN