Live data from Hacker News

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

blog.railway.com

91–100 of 230 posts

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

#91
post #78
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

web dev is a sewer All my projects are server rendered with jinja/minijinja, bootstrap, jQuery, and htmx when I need a little bit of SPA behavior on forms. No builds, just static <script src= tags. Very fast and easy. I'll never recommend anything else.

I'm coming back to Django after a decade of experience with it post-0.96 and having moved to Next.js a few years ago. Going from 1,700 dependencies to 65 total with Django + Wagtail + HTMX.

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

#92
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

There are some easy optimizations wins for this page but none of the top ones are framework related. Maybe with the faster build times they can easily optimize images and 3rd party dependencies. As someone else pointed out, nearly half that data is unoptimized images.

For the curious, google's current homepage is a 200kb payload all in, or about 50 times smaller.

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

#93

Two minutes is still way too long. What are we doing? This is ridiculous.

2 mins for a production deploy of an app with millions of users? Seems fine to me! How fast would you expect it to be?

How does an apps user base affect its build time?

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

#94
post #89

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.

It means you take responsibility of maintaining the server forever, i.e. dealing with TLS certificates, SSH keys, security updates, OS/package updates, monitoring, reboots when stuck, redeploy when VPS retired, etc. Usually things work fine for a year or two and then stuff starts to get old and need attention and eat your time.

This is extremely easy with tools like dokploy tho... I use dokploy locally to manage all my VPSs + home server. Truly good stuff and I don't believe your quip at the end, it feels like poisoning the open source waters for consolidated anti democratic cloud platforms.

It's way way way way easier managing a basic VPS that can be highly performant for your needs. If this was 2010, I'd agree with you but tooling and practices have gotten so much better over the last decade (especially the last 5 years).

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

#96
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 funct…

Obviously it's more than just debouncing. https://tanstack.com/pacer/latest/docs/overview

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

#97
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

There are some easy optimizations wins for this page but none of the top ones are framework related. Maybe with the faster build times they can easily optimize images and 3rd party dependencies. As someone else pointed out, nearly half that data is unoptimized images. For the curious, google's current homepage is a 200kb payload all in, or about 50 times smaller.

Who remembers sprite sheets? Does that give my age away?

I did an optimization pass for a client once where I got rid of a ton of the sprites but didn't have the energy to redo it all, so it just had huge sections that were blank.

Super snappy loading afterwards though.

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

#99

Earlier quoted context omitted.

There are some easy optimizations wins for this page but none of the top ones are framework related. Maybe with the faster build times they can easily optimize images and 3rd party dependencies. As someone else pointed out, nearly half that data is unoptimized images. For the curious, google's current homepage is a 200kb payload all in, or about 50 times smaller.

Who remembers sprite sheets? Does that give my age away? I did an optimization pass for a client once where I got rid of a ton of the sprites but didn't have the energy to redo it all, so it just had huge sections that were blank. Super snappy loading afterwards though.

Yes, good times! With http2/3 they don't really matter anymore though, you get similar benefits from request pipelining.

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

#100
post #80
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

The 3.57MB background PNG is hilarious [0] [0] https://railway.com/dots-oxipng.png

They could have saved themselves 3MB by converting it to AVIF.
Post reply on HN