Earlier quoted context omitted.
Yes, good times! With http2/3 they don't really matter anymore though, you get similar benefits from request pipelining.
Spriting is actually harmful for performance except in specific HTTP-1 scenarios.
We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
171–180 of 230 posts
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#172Earlier quoted context omitted.
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,…
What you have stated requires more knowledge (especially Postgres). You’re not going to get it from a blog post, and will need to read actual source docs and man pages.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#173Earlier quoted context omitted.
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 runnin…
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#174Earlier quoted context omitted.
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
#175Earlier 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.
And this is also bearing in mind that I complicate my setup a bit by running the different sites in docker containers with Caddy acting as a proxy.
With storage volumes for data and a few Bash scripts the whole server becomes throw-away that can be rebuilt in minutes if I really need to go there.
And for sure any difficulty and ops overhead pales in comparison to having to manage tooling and dependencies for a typical simple JS web-app. :)
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#176Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#177It’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..
It's mostly because a lot of the web tooling is written in JavaScript. The build times for the "next generation" tools written in Rust/Go are dramatically faster.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#178Earlier 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.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#179Earlier quoted context omitted.
As in, htmx is better? I haven't used it but last I looked into it I was extremely confused as to whether it was a meme, an actual framework, or both.
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.
What does that mean?
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#180Earlier quoted context omitted.
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