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

161–170 of 230 posts

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

#161

Post by coffeefirst »

bastardoperator wrote: post #134
petcat wrote: post #78

Earlier quoted context omitted.

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.

Sounds more difficult then modern web frameworks. We've all done this for little projects, but anything with users or development teams, your method is DOA.

Eh, there’s tradeoffs. They’re real. But I’ve done plenty of this on teams back in the day before all these frameworks and it can absolutely work. It may even be easier now with JS modules.

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

#162

Post by shimman »

satvikpendem wrote: post #124
shimman wrote: post #94

Earlier quoted context omitted.

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 pra…

Agreed, Dokploy is great, not sure why you got downvoted for the suggestion.

IDK, I only found out about Dokploy six months ago. The tools nowadays for managing small hosted solutions is absolutely amazing. You can do a lot with a single VPS if you avoid bloated software choices.

People often forget there is a massive economy out there for niche solutions and if you're a small team you don't exactly need a large slice to make a nice life for yourself.

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

#163

Post by marcus_holmes »

nchmy wrote: post #148
fnoef wrote: post #130

Earlier quoted context omitted.

Oh no! Issuing SSL certificates! The horror! I really doubt that people who can’t install an ssh key should be able to practice software engineering. Sometimes, I think that software engineering should be a protected profession like other types of engineering. At least it will filter out the people who can’t keep their OS up to date.

Caddy server even does ssl for you automatically.

Caddy runs on top of Go's excellent acme library that handles all of the cert acquisition and renewal process automatically.

I get that if you get a problem then it'll take a bit of work to fix, but all of this seems like a lot less work than dealing with support for a platform you don't control.

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

#164

Post by shimman »

GrayShade wrote: post #43
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?

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

Yeah but LLMs are trained on a majority of shitty bloated things, that's kinda why their output is garbage but workable.

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

#165

Post by sgarland »

kennu wrote: post #136
fnoef wrote: post #130

Earlier quoted context omitted.

Oh no! Issuing SSL certificates! The horror! I really doubt that people who can’t install an ssh key should be able to practice software engineering. Sometimes, I think that software engineering should be a protected profession like other types of engineering. At least it will filter out the people who can’t keep their OS up to date.

This is not about how easy or difficult it is to issue TLS certificates, to configure SSH keys or to update the OS. It's about having to actively maintain them yourself in every possible situation until eternity, like when TLS versions are deprecated, SSH key algorithms are quantum-hacked, backward-incompatible new OS LTS versions are released, and so on. You will always have new stuff come up that you need to take c…

This is all trivial, and can and should be automated. Furthermore, all of your arguments can easily be applied to NodeJS version deprecations, React realizing they shipped a massive CVE, etc.

I will die on this hill: parent is correct - the ability to manage a Linux server should be a requirement to work in the industry, even if it has fuck-all to do with your job. It proves some basic level of competence and knowledge about the thing that is running your code.

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

#166

Post by sgarland »

asadm wrote: post #132
fnoef wrote: post #130

Earlier quoted context omitted.

Oh no! Issuing SSL certificates! The horror! I really doubt that people who can’t install an ssh key should be able to practice software engineering. Sometimes, I think that software engineering should be a protected profession like other types of engineering. At least it will filter out the people who can’t keep their OS up to date.

Time is a precious (and really expensive for SWEs) resource, why should one spend it on updating certs and instances?

You don’t, you automate it. This has been a solved problem for literally years.

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

#167

Post by pcmaffey »

Funny, I just today merged our migration from Next (with turbopack, page router, ~200 pages) to Vite + Tanstack Router. Builds went from 2.5m to 25s.

But even bigger was the improvement to dev mode compile times. With Vite it’s near instant. With Next running our e2e tests in development was utter pain.

So happy to leave next & vercel behind.

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

#168

Post by troad »

sgarland wrote: post #165
kennu wrote: post #136

Earlier quoted context omitted.

This is not about how easy or difficult it is to issue TLS certificates, to configure SSH keys or to update the OS. It's about having to actively maintain them yourself in every possible situation until eternity, like when TLS versions are deprecated, SSH key algorithms are quantum-hacked, backward-incompatible new OS LTS versions are released, and so on. You will always have new stuff come up that you need to take c…

This is all trivial, and can and should be automated. Furthermore, all of your arguments can easily be applied to NodeJS version deprecations, React realizing they shipped a massive CVE, etc. I will die on this hill: parent is correct - the ability to manage a Linux server should be a requirement to work in the industry, even if it has fuck-all to do with your job. It proves some basic level of competence and knowled…

I keep reading posts like this, but the people who say this never actually seem to enlighten the rest of us troglodytes by, say, writing a comprehensive, all inclusive, guide to doing this.

If it's so easy, surely it's no big undertaking to explain how one self hosts a fully secured server. No shortcuts, no "just use the usual setup" (we don't know what it is!), no skipped or missed bits. Debian to Caddy to Postgres, performant and fully secure, self upgrading and automated, from zero to hero, documenting every command used and the rationale for it (so that we may learn).

Or is it perhaps not as simple as you say?

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

#169

Post by kennu »

sgarland wrote: post #165
kennu wrote: post #136

Earlier quoted context omitted.

This is not about how easy or difficult it is to issue TLS certificates, to configure SSH keys or to update the OS. It's about having to actively maintain them yourself in every possible situation until eternity, like when TLS versions are deprecated, SSH key algorithms are quantum-hacked, backward-incompatible new OS LTS versions are released, and so on. You will always have new stuff come up that you need to take c…

This is all trivial, and can and should be automated. Furthermore, all of your arguments can easily be applied to NodeJS version deprecations, React realizing they shipped a massive CVE, etc. I will die on this hill: parent is correct - the ability to manage a Linux server should be a requirement to work in the industry, even if it has fuck-all to do with your job. It proves some basic level of competence and knowled…

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 running apps. Apps should run forever even if the underlying platform completely changes, and only require updating if the app itself contains something that needs updating.

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

#170

Post by paulddraper »

mattmanser wrote: post #97
toddmorey wrote: post #92

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.

I indeed remember.

HTTP 2+ (supported by every web browser) obviates sprite sheets.

They were a useful hack, but still a hack.

Post reply on HN