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.
We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
91–100 of 230 posts
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#92I 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
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
#93Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#94Earlier 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.
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
#95Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#96We 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…
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#97I 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.
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
#98Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#99Earlier 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.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#100I 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