Live data from Hacker News

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

blog.railway.com

61–70 of 230 posts

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

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

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.

That's not the point...

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

#62
post #49

Earlier quoted context omitted.

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.

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.

> you can’t meaningfully modify a layout with css alone Wut?

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

#63
post #11

Earlier quoted context omitted.

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.

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.

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 is 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 create HTML as is.

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

#65
post #8
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.

Like using SPAs for classical Web development, and then they rediscover PHP.

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

#67

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

Yes I'm on turbopack and running the latest version of Nextjs.

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

#68

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.

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…

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

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

#69
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!

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

#70

Earlier quoted context omitted.

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…

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

Post reply on HN