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

31–40 of 230 posts

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

#31

Post by huksley »

wouldbecouldbe wrote: post #15

The 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

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

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

#33

Post by cryptonym »

mellosouls wrote: post #2

Reminder, as its not mentioned: Next.js is produced by Vercel, a competitor to Railway.

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

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

#34

Post by crooked-v »

itopaloglu83 wrote: post #30
Hamuko wrote: 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.

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.

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

#35

Post by SilverSlash »

tgdn wrote: post #7

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…

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

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

#36

Post by 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

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

#37

Post by ai_slop_hater »

SilverSlash wrote: post #29

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"

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

#38

Post by norman784 »

abustamam wrote: post #18
mellosouls wrote: post #2

Reminder, as its not mentioned: Next.js is produced by Vercel, a competitor to Railway.

It's not mentioned because it's not relevant.

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

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

#39

Post by selfmodruntime »

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

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.

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

#40

Post by selfmodruntime »

ramon156 wrote: post #9
Hamuko wrote: 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.

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