Live data from Hacker News

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

blog.railway.com

41–50 of 230 posts

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

#41

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?

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?

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

#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 upgrades and improvements here and there.

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

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

#43

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?

We've had shitty bloated websites before LLMs were a thing.

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

#44
post #11
post #8

Earlier quoted context omitted.

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.

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.

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

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

I don't think any C compiler has been single pass for the last 20 years. Typescript's analyses are also not that complicated, it's just that the typescript type checker is written in js. Iirc the actual ts -> js part is pretty fast with some of the more recent compilers.

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

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

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.

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

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

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.
Post reply on HN