Live data from Hacker News

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

blog.railway.com

201–210 of 230 posts

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

#201

Earlier quoted context omitted.

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

No click-ops that way.

To be fair, I never have to click anything either since it's via SSH :D

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

#202
post #36

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

FWIW with pretty aggressive uBlock setup its "just" 7MB and 1.6s to load, so it might be just their love for analytics, tracking, measuring and lack of smart code splitting thats killing the performance.

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

#203

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.

If you consider that, you might also want to take a look at Astro.js

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

#204

Earlier quoted context omitted.

I got it down to 1.03MB by just switching the png to palette encoding mode.

Got the same running through tinypng.

Perhaps if those geniuses at Railway were slightly more competent they wouldn't have created a 10-minute-to-build frontend app, disregarding the choice of underlying framework.

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

#205
I 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

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

#206
Makes 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.

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

#207
post #169

Earlier quoted context omitted.

I'm curious about this trivial automation. Let's say the new OS LTS version no longer includes nginx, because it was replaced by a new product with different config. How does the automation figure out what the new server package is and migrate your old Nginx config to the new format? I agree with Node.js version deprecations being a huge problem and personally advocate for an evergreen WebAssembly platform for runnin…

If an LTS of an OS replaced nginx with something else, a. it would be announced with great fanfare months in advance b. if you don’t want to do that, add apt / yum / zypper install nginx to your Ansible task, or whatever you’re using.

The things that you just described are not automation, but human activities needed to tackle the new situation by following news and creating new automation. Which kind of proves my point that you cannot prepare for every unexpected situation before it actually happens. Except maybe with AI in the future.

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

#208
post #106

Earlier quoted context omitted.

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

> If web interface is an application backed by a remote state What does that mean?

anything where you need popups or tiled windows, code editing, rich text features more complex than "render markdown into a div", heavy content like videos, multiplayer, real time chat, anything that has to work offline... htmx is only good enough for something like a company homepage or simple shop not big complicated apps. its actually the same reason i dont like htmx, the whole "true REST" approach is about making everything depend more on the server with a thin client that can only do a couple very simple things with the loaded page. if your connection to that server is slow or unreliable your whole app breaks.

its also the perfect opposite of "true web3" and ethereums original vision, where you load all static assets from ipfs, most app logic is client side and the server or blockchain only comes in (json api, no html fragments or full pages) when you need to interact with other users. still believe in it even after the crypto bros took the name for a bunch of scams and hosted everything on cloudflare anyway. the only thing they have in common i could find is no bundling but for different reasons - everything on server vs compiled libraries shared between apps.

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

#209
post #31

Earlier quoted context omitted.

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.

I build some projects via pm2 deploy directly on a server and its much faster then vercel

Not every project can be compiled on production server since compiling NextJS might take quite a lot of RAM, I would advise against it.

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

#210
post #104
post #31

Earlier quoted context omitted.

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.

Turbopack, custom runtime infrastructure on top of AWS Lambda.

Turbopack does not work for every app, I think they skip some build steps when building like typescript validation etc and aggressively cache node modules.
Post reply on HN