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?
Besides, most time is spent running tests anyway.
We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
181–190 of 230 posts
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#182Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#183Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#184Earlier quoted context omitted.
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,…
The parent I responded to was discussing issuing certs, configuring SSH keys, and updating an OS. Those are all in fact trivial and easily automated. 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.
The original claim was "People shouldn't even be in the industry unless they can administer a Linux server, even if that has nothing to do with their role." It is a very significant moving of the goalposts to now suggest this is all about "updating an OS". That's not a good faith claim.
This whole thing is merely cheap online snark masquerading as wisdom. No, not all SWEs know how to maintain Linux servers, and many (most?) SWE roles have all of zero overlap with that kind of work. If businesses could fire all their expensive server admins and replace them with some college kid and a $5 VPS, they would long since have done so.
If this is anything more than poseur snark, put your money where your mouth is and either write a comprehensive resource yourself, or at least compile a list of resources that would suffice for someone to be able to securely run and maintain a live server in production. No, not Hello Worlds, actual prod. Then, when next this comes up, link us to your guide rather than just spraying spittle on the plebs who lack your expertise.
Do something more constructive than low effort snark.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#185Earlier quoted context omitted.
> People are drawn to complexity like moths to a flame. Not to complexity, but to abstraction. The more something is abstracted away, the more fungible "developers" become, to the eventual tune of Claude Code. No one cares that trying to debug a modern application is as hellish as its performance, the KPI that executives go for is employment budget.
I don't know if Next.js, TanStack, etc are more abstract than Rails, Django, etc. They're undoubtedly more complex though. I also find it hard to believe that it's some sort of conspiracy by management to make developers more fungible. I've seen plenty of developers choose complexity with no outside pressure.
Next certainly feels more complex than Laravel or Rails while only providing most of the view layer and a client-server protocol based on React.
You're still left alone with i18n, auth, and pretty much anything to do with the backend, all of which the Rails of this world have you covered.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#186Can we just get back to html/jQuery/handlebars? Those were the good old days :`(
Please no. Those were terrible days. Imperatively poling around the DOM invariably leads to pain. Don't. I openly dislike Next and would take that over those days any day.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#187[deleted]
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#188Earlier 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,…
[deleted]
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#189Earlier quoted context omitted.
Spriting is actually harmful for performance except in specific HTTP-1 scenarios.
Doesn't McMaster Carr still use sprites? Is that like the one optimization they managed to get wrong?
Looks like it, but isn't this site famous for being a "classic" storefront?
Some CMSs would auto-generate sprites. If you are showing most of them, it's still a positive, I'd assume. And, if it ain't broke, don't fix it.