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.
mattmanser 1 days ago [-]
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.
ricardobeat 1 days ago [-]
Yes, good times! With http2/3 they don't really matter anymore though, you get similar benefits from request pipelining.
chrisweekly 24 hours ago [-]
Spriting is actually harmful for performance except in specific HTTP-1 scenarios.
staticautomatic 19 hours ago [-]
Doesn't McMaster Carr still use sprites? Is that like the one optimization they managed to get wrong?
flomo 15 hours ago [-]
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.
17 hours ago [-]
paulddraper 19 hours ago [-]
I indeed remember.
HTTP 2+ (supported by every web browser) obviates sprite sheets.
They were a useful hack, but still a hack.
petcat 1 days ago [-]
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.
nicksergeant 1 days ago [-]
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.
bastardoperator 24 hours ago [-]
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.
array_key_first 22 hours ago [-]
I disagree, most webapps, like 99.9% I would say, are just forms, links, and pages. Meaning, they can be done with 0 reactivity and that is the most simple and straightforward way to do it.
Less code is basically always better, so if you can skip the huge amounts of JS and orchestration required by modern web frameworks, then it will be easy. People are out here using React to render static pages. It's very overkill.
bastardoperator 21 hours ago [-]
That can't be your measurement when you're loading 3 huge js libraries which are a lot more code then say svelte, which also excels at SSG.
coffeefirst 21 hours ago [-]
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.
pjmlp 1 days ago [-]
When I am given the choice to pick a stack, it is classical Java and .NET Web frameworks, with minimal JavaScript.
On hobby projects same script approach without any kind of build step.
giancarlostoro 1 days ago [-]
With C#'s Blazor templating, you can ditch all JS logic, and use raw C# for all front-end logic, and have it all be transparently server rendered similar to how Phoenix has LiveView.
I also have experimented with HTMX and Django, and that seems to be a nice combination.
Everything is AJAX again.
CharlieDigital 1 days ago [-]
I've a C# fanboy, but Blazor's DX just isn't very good compared to say Vite.
There are many conditions under which the hot reload just straight up crashes out regularly.
giancarlostoro 22 hours ago [-]
Hot reload definitely needs to grow.
anematode 1 days ago [-]
Dear lord. It's actually laggy for me to scroll on that page.
hazelnut 1 days ago [-]
same here and I'm using a beefy MacBook (Apple M4 Max, 64gb ram). something is wrong with the front end code. there are a lot of animations, so my hunch would be that something goes wrong there.
anematode 1 days ago [-]
Moore said computers get twice as fast every 18 months. Web devs took that as a challenge.
OJFord 24 hours ago [-]
He said transistor count on chip doubles. (The more accurate pithy comment would be they took it as available resources.)
anematode 23 hours ago [-]
U+1F913
twohaibei 12 hours ago [-]
FWIW with pretty aggressive uBlock setup its "just" 7MB and 1.6s to load, so it might be just their love for analytics, tracking, measuring and lack of smart code splitting thats killing the performance.
I got it down to 1.03MB by just switching the png to palette encoding mode.
dawnerd 14 hours ago [-]
Got the same running through tinypng.
moralestapia 11 hours ago [-]
Perhaps if those geniuses at Railway were slightly more competent they wouldn't have created a 10-minute-to-build frontend app, disregarding the choice of underlying framework.
rubyn00bie 1 days ago [-]
Ha! I normally wouldn’t find it quite so hilarious, but it’s a stylistically pixelated image. There’s just too much irony packed in there to not chuckle.
c-hendricks 1 days ago [-]
It's more halftone (might not be the correct term), not pixelated
There might be more irony in saying it's stylized pixels without realizing that the style of the image can't be replicated with blocks of the same size but I dunno, I'm not Alanis Morissette
picardo 1 days ago [-]
They could have saved themselves 3MB by converting it to AVIF.
tgdn 2 days ago [-]
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 been great.
SilverSlash 1 days ago [-]
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 function
```
Why? Just why do you need to install some "framwork" for implement debouncing? Isn't this sort of absurdism the reason why the node ecosystem is so insecure and vulnerable in the first place? Just write a simple debouncer using vanilla js...
chrisweekly 23 hours ago [-]
Not to feed the trolls, but you responded to a comment about TanStack Start (a full-stack metaframework) by denigrating @tanstack/pacer -- a separate, niche utility published by the same team.
You're entitled to your opinions, but I'm happy to defend the rationale of leveraging battle-hardened, rigorously-tested, open-source, type-safe libraries instead of DIY cowboy vanilla js spaghetti.
TanStack started out by providing a very good JS table library. Now they offer a Router, and some more libs. They are definitely an up and coming name in the JS space.
chrisweekly 23 hours ago [-]
That's... not quite right.
[EDIT] I typed "Router" when I meant "Query".
TanStack Query is the relatively newer name for React Query -- one of the most popular JS libraries of all time.
TanStack Start is a recent metaframework (and the one w/ the brightest future, IMO), but Tanner and team have profoundly significant bona fides. IOW, the dev team is far from being the "new kids on the block".
SahAssar 23 hours ago [-]
Do you have a source for TanStack Router being a newer name for React Router? Doesn't seem like it when looking at the sites for both projects.
Are you thinking of the whole Remix/ReactRouter thing?
chrisweekly 23 hours ago [-]
(facepalm)
Thank you, but no.
I typed "Router" when I meant "Query". TanStack Query is the newer name for the library FKA react-query.
TanStack Router is an alternative to React Router.
TanStack Start is an alternative to Remix/react-router-7's framework mode.
The naming history and evolution of react-router and its relationship to Remix is a bit convoluted, but an unrelated tangent to the point I was making.
Thanks yes I know, I typed "Router" meaning "Query", noted in a peer comment. sigh.
pjmlp 14 hours ago [-]
Nah, they are the next toy for the magpie developers, now that Next.js is no longer cool.
l5870uoo9y 1 days ago [-]
I migrated the landing pages for my app[1] from Nextjs to Astrojs mainly because I was paying Vercel $20 per month for serving static pages(it’s 4 times more than I pay Railway for the Postgres database for the actual app and also 4 times more than I pay Cloudflare for hosting all my apps). I used AI for migrating and it took a few days only as the existing repo was used as “instructions” and it included some upgrades and improvements here and there.
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.
kennu 1 days ago [-]
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.
gbuk2013 18 hours ago [-]
As someone who runs a such a VPS this is all a non-issue. Running HTTP service is so trivial that once I set it up I don’t even spend an hour in a year maintaining it. Especially with Caddy which takes care of all the certs for you.
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. :)
fnoef 24 hours ago [-]
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.
kennu 24 hours ago [-]
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 care of.
sgarland 20 hours ago [-]
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.
kennu 19 hours ago [-]
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.
sgarland 18 hours ago [-]
If an LTS of an OS replaced nginx with something else, a. it would be announced with great fanfare months in advance b. if you don’t want to do that, add apt / yum / zypper install nginx to your Ansible task, or whatever you’re using.
kennu 10 hours ago [-]
The things that you just described are not automation, but human activities needed to tackle the new situation by following news and creating new automation. Which kind of proves my point that you cannot prepare for every unexpected situation before it actually happens. Except maybe with AI in the future.
sgarland 5 hours ago [-]
When AWS announces that they’re EOL’ing the Python or NodeJS version in your Lambda, or the version of your RDS cluster, etc. you also are required to take human action. And in fact, at any appreciable scale, you likely want that behavior, so you can control the date and time of the switch, because “zero downtime” is rarely zero downtime.
kennu 4 hours ago [-]
Yes, and like I mentioned in another comment, I consider this a major painpoint and problem with Node.js based applications. I have high hopes that eventually there will be an "evergreen" WebAssembly based Lambda function runtime.
troad 19 hours ago [-]
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?
llbbdd 14 hours ago [-]
They don't write the guide because by the time they've written the guide to an appropriate level of specification, the result they've produced is an off-the-shelf service provider not unlike the ones they're railing against.
sgarland 18 hours ago [-]
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.
troad 17 hours ago [-]
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.
sgarland 5 hours ago [-]
I intermingled the two claims, you’re correct, and was not intending to move the goalpost. I apologize.
Claim one: setting up unattended-upgrades, SSH keygen, and automating cert rotation is trivial and easily automated.
Claim two: you should know how to manage a Linux server. Here are docs.
I self host my own server and this isn't something that takes much time per year. You're making it sound like a day job. It's not really. As long as you have a solid initial config you shouldn't have to worry.
cosmic_cheese 23 hours ago [-]
Exactly. Also, being that my specialty is writing software and not server maintenance, no matter how much of an effort I put forth there's substantial risk of blind spots where holes can lurk.
I felt more comfortable maintaining a VPS back between 2005 and 2015, but at that point attackers were dramatically less sophisticated and numerous and I was a lot more overconfident/naive. At least for solo operations I'm now inclined to use a PaaS… the exception to that is if said operation is my full time job (giving me ample time to make sure all bases are covered for keeping the VPS secure) or it's grown enough that I can justify hiring somebody to tend to it.
nchmy 23 hours ago [-]
Caddy server even does ssl for you automatically.
marcus_holmes 20 hours ago [-]
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.
asadm 24 hours ago [-]
Time is a precious (and really expensive for SWEs) resource, why should one spend it on updating certs and instances?
satvikpendem 22 hours ago [-]
They shouldn't, that's why self hosted PaaS already do it for you, it's not a differential reason to use cloud services instead just because they do it for you too.
sgarland 20 hours ago [-]
You don’t, you automate it. This has been a solved problem for literally years.
simpsond 18 hours ago [-]
Now you have to maintain the automation. There is nothing wrong with that. There is nothing wrong with building your own server. There is nothing wrong with colocation. There is nothing wrong with driving to the colo to investigate an outage. There is nothing wrong with licensing arm and having TSMC fab your chip. There is nothing wrong with choosing which level of abstraction you prefer!
ipsento606 24 hours ago [-]
certbot and ssh keys are things you set up once
I haven't rebooted my DO droplets in something like 5 years. I don't monitor anything. None of them have been "retired".
xandrius 12 hours ago [-]
You clearly haven't tried doing that in quite a long while.
Using SSH keys + fail2ban means that for a simple static site, it will be sufficient for a decade at least.
TLS certificates get auto-renewed with letsencrypt every 3 months via certbot.
Installing security updates depends heavily on what is your threat model, if you're just displaying some static content you fully own, you'll be usually fine.
Literally never seen a VPS being "retired", if it happened to you, change provider.
I've got a bunch of VPS running for 10+ years, I never need to touch them anymore.
My homelab has been going strong for the past 8 years. I did have to do some upgrade/maintenance work to go from being an old laptop without screen to a minitower low power machine, and when I added 30TB of storage. Other than that, it's running smoothly, it also uses TLS and all the rest.
wouldbecouldbe 23 hours ago [-]
just ask claude to do all that :), he is excellent and installing & managing new servers and making sure all security patches are updated. Just be careful if its a high risk project.
mvdtnz 18 hours ago [-]
This is the kind of stuff a software develop should have absolutely no problem managing. It's crazy to me that so many software developers hate the idea of maintaing a computer.
SoftTalker 1 days ago [-]
vs. trusting someone else to do all that for you, and do you then verify that it gets done properly?
kennu 24 hours ago [-]
When buying the infrastructure as a managed cloud service, yes, I trust that they've got people handling it better than I could myself. The value proposition is that I don't even see the underlying infrastructure below a certain level, and they take care of it.
shimman 1 days ago [-]
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).
kennu 1 days ago [-]
Maybe you're right - I've never tried dokploy, but from documentation it sounds like mostly a deployment, monitoring and alerting tool. For me the problem has always been that once you get the alert (or something just stops working), a human needs to react to it and make things work again. In cloud services you mostly pay for them providing the human, and in self-hosting you're the human.
I can see though that today's AI models could eventually replace the human in the loop and truly automatically fix every possible situation.
wouldbecouldbe 23 hours ago [-]
yeah i've had more downtime on managed db's & cloud servers then on my own managed VPS. And if it happens, with VPS i can normally fix it instantly compared to waiting 20-60 min for a response, just to let you know they start fixing it. And when they fix it, it doesnt always mean your instance automatically works.
c-hendricks 1 days ago [-]
I must be using the wrong cloud services. Whenever a part of our app goes down someone on the team still needs to respond to it.
kennu 24 hours ago [-]
You might be right. I've been mostly using serverless / managed cloud services such as AWS Lambda, API Gateway, S3, DynamoDB for the past 10+ years. When I've needed to respond, it's been because I myself deployed a bad update and needed to roll it back, or a third party integration broke. The cloud platform itself has been very stable, and during the couple of bigger incidents that have happened, I've just waited for AWS to fix it and for things to start working again.
bdangubic 1 days ago [-]
you actually need new ops teammates, not new cloud services :)
satvikpendem 1 days ago [-]
Agreed, Dokploy is great, not sure why you got downvoted for the suggestion.
shimman 21 hours ago [-]
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.
cornholio 14 hours ago [-]
I don't even bother setting up VPS instances by hand. If you have gmail then you have access to Google Cloud, and they offer a free tier of Cloud Run that comfortably covers anything you might do on a personal project.
You basically create a github, put a dockerfile inside it with your nginx config, frontend files, backend etc., then push and the Cloud Run instance is built for you then deployed into production. By default you are paying only for active requests, when a http request hits your box GCP will wake it up, charge for the CPU time used for serving it, then leave it idle for free for about 15 minutes. If another hit comes in that interval, you have instantaneous response because the instance is warm, otherwise it will wake up again and see a few seconds of latency (ie. during the night, when you have few visitors etc).
It also scales up automatically if you have substantial traffic, you don't have to do anything other than design your application so that multiple instances hitting the same data storage (ex. Firestore) will play nice. It of course handles all security, versioning, HTTPS certs etc. for you, you are simply serving plain HTTP traffic within the GCP internal network and just make sure your own application (what you push to git) is secure.
The things you pay for are outbound traffic (for obvious reasons like warez etc.) as well as storage of docker images (Artifact registry, i think you only have 0.5GB free, about 3 alpine images), but you can easily set up a rule to auto-delete old images.
Overall, you can run a small business with daily/weekly updates for less than a dollar a month and hit 5 nines availability, which you will never achieve for a self-administered VPS. Sorry if it sounds like an advertisement, but it's just enormous value for a small builder.
xandrius 12 hours ago [-]
I still think you described using a VPS but with a tons of extra steps, expenses and then being tied to an evil corporation people are trying to move past.
You get a generic VPS and you can do whatever the hell you like, not paying bigG for some "obvious reasons" like outbound traffic.
And a small business will never need 5 nines availability, that's just the propaganda from big tech to over engineer and pay them for that. You can run a small/medium business and be offline for 1 hour every day (makes it 95.8%) and still be fine. It's when you're worldwide and not that small that you want better availability.
Also, you know all those AWS outages? My VPSs were never impacted to the slightest!
cornholio 3 hours ago [-]
A docker image host is NOT a VPS with extra steps, because a VPS is a server and needs to be administered professionally as a server by someone competent for that job, that excludes 90% of developers who are willing to spend only one hour per year for this task. Think about running mail servers, you can do it manually but to do a good job you need to invest so much time and effort that almost everyone doing it will throw in the towel eventually.
And while I agree with the sentiment of resisting encloudification, you can take your docker image to any other host if you want, it's a generic service. in a pinch, you can build your own and have 100% control just like the VPS case.
The point is that you don't have to, you just git push into production and forget about it. that's a good few dozens less "extra steps" than the VPS route.
kami23 1 days ago [-]
I just did this over at Hetzner and Claude admins it for me so I don't need to learn the CLI or anything, describe the proxying I want, and it setups up a bunch of small side project pages for me.
kamikazeturtles 1 days ago [-]
How do you use Claude to admin it?
Does Claude SSH into the server and do everything or just write bash scripts?
mdrzn 12 hours ago [-]
ssh into the VPS and launch ClaudeCode directly on the machine, so it has full access
xandrius 1 days ago [-]
For me I always default to UpCloud, great team and great services. From Finland!
mbesto 1 days ago [-]
Or a homelab using Proxmox or Unraid.
skydhash 1 days ago [-]
No click-ops that way.
xandrius 12 hours ago [-]
To be fair, I never have to click anything either since it's via SSH :D
christoff12 1 days ago [-]
this is neat
wouldbecouldbe 1 days ago [-]
The irony is deploying NextJS on the railway platform is super slow since they use containers, on Vercel 2 min is like 12 min on railway, deployments on a vps are only like 20 seconds.
*I know this is just build time, so this is different then their deployement time
huksley 1 days ago [-]
Not containers to blame but overprovisioning and how much resources dedicated to building. I am not sure how Vercel gets things build in literal seconds, but, hey, they are the creators of NextJS.
At DollarDeploy we building it also in containers but every build get 4GB/2CPU so it is quite fast but not as fast as Vercel.
wouldbecouldbe 13 hours ago [-]
I build some projects via pm2 deploy directly on a server and its much faster then vercel
huksley 5 hours ago [-]
Not every project can be compiled on production server since compiling NextJS might take quite a lot of RAM, I would advise against it.
pjmlp 1 days ago [-]
Turbopack, custom runtime infrastructure on top of AWS Lambda.
huksley 5 hours ago [-]
Turbopack does not work for every app, I think they skip some build steps when building like typescript validation etc and aggressively cache node modules.
pjmlp 4 hours ago [-]
The biggest issue is missing plugins, but they have an extension point to add them.
Naturally they expect them to be written in Rust, which might be an issue for some then again Vite folks are also going into RIR.
falcor84 21 hours ago [-]
I loved reading:
> we sponsor both Vite and TanStack because we believe in where they're going
I'd like to see more of this attitude.
Hendrikto 1 days ago [-]
Two minutes is still way too long. What are we doing? This is ridiculous.
rishabhparikh 1 days ago [-]
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?
stingraycharles 17 hours ago [-]
Besides, most time is spent running tests anyway.
bdangubic 1 days ago [-]
so build time scales with the number of users? meta's build times of roughly 2hrs and 11 minutes then makes a lot of sense
BoredPositron 1 days ago [-]
How does an apps user base affect its build time?
mbesto 1 days ago [-]
It's a proxy for complexity.
bdangubic 17 hours ago [-]
that makes 0 sense
jasonlotito 1 days ago [-]
Not the op and I get your point, however...
One way to think about it might be that the site supports lots of users who use it for various things. So, everyone uses 80% of the site, but everyone also uses a different portion of the final 20%. So, if you have lots of users, you might also have lots of smaller features that a significant minority use.
I don't know, just an interesting way of thinking about it.
selfmodruntime 1 days ago [-]
We're doing structural type checking for a language that wasn't developed with that in mind.
dmix 1 days ago [-]
You can't keep JS devs away from the new shiny framework for long.
UserMark 1 days ago [-]
I have a Nextjs heavy app which takes around 7 minutes currently. But I've been thinking of moving away from next for a long time now. TanStack seems to be a good fit. This gives me a bit more confidence in just doing it.
cryptonym 1 days ago [-]
Is server-rendered HTML that bad for 2026 web or is everyone building complex apps?
Many of my customers insists on using Next.js or similar but when I browse their website I don't get the point. They are downloading and executing megabytes of JS while in-page interactions tends to be limited to few basic stuff. Never seen one of their project requiring offline mode. Maybe that's being able to easily replace a [FRAMEWORK] dev with another.
sosodev 1 days ago [-]
I think the unfortunate truth is the simplest. Web development has long been detached from rationality. People are drawn to complexity like moths to a flame.
mschuster91 23 hours ago [-]
> 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.
cryptonym 13 hours ago [-]
It might be really efficient when you "vibe" and don't know exactly what you want.
On serious projects, it feels like even Claude Code could be more efficient with simple technologies, providing near-instant build and debug.
With reduced abstractions and output looking like input, it can better understand how to fix things rather than trying to guess how to manipulate framework state or injecting hacks.
sosodev 23 hours ago [-]
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.
gherkinnn 16 hours ago [-]
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.
pjmlp 1 days ago [-]
It is fashionable, and Vercel has made a chain of partners that make Next.js/React the only official option to extend SaaS products.
nomel 1 days ago [-]
I made two serious attempts to get into front end web development, around 5 years apart. Both times I started with the most popular framework. Both times the most popular framework was something different before I even finished the project.
Looks like maybe things haven't changed much?
Kelteseth 1 days ago [-]
As a cpp developer I had to chuckle there. And I thought our compile times were bad.
abustamam 1 days ago [-]
I've been pretty happy with TanStack start for a medium-sized project. I would not know how its build time would compare to Next, but our similarly sized Remix (sorry, React router v7) app takes longer to build.
TanStack just has a nicer mental model overall and works great with TanStack query for cache I validation and stuff like that.
Remix was promising but there was so much ceremony in registering API routes and stuff. Tanstack just lets you define server functions arbitrarily with no ceremony.
Might be worth a spike and some tokens to ask Claude Code to migrate and test the build time and ergonomics.
UserMark 1 days ago [-]
I've been on the remix on a previous project, I have to say that Remix was even worse. But that's probably of the setup with vite etc not being correctly done.
Eric_WVGG 1 days ago [-]
I recently switched from NextJS — where every one of the dozens of projects I built would have 7-8 minute deployment times, regardless of hosts — to React Router, and saw my deployment times drop to 1-2 minutes.
Aside from some difficulty with mastering environment variables, I’ve been delighted with the change and will probably not look back.
twohaibei 12 hours ago [-]
If you consider that, you might also want to take a look at Astro.js
wilson090 1 days ago [-]
Are you on turbopack? It's available on Next 16 and just took our build times down from 6 minutes to 2 minutes
cbovis 1 days ago [-]
Yep this is what's often misunderstood.
We also recently cut our build times in half moving from Webpack to Turbopack on production builds after jumping to NextJS 16. We'd already been using Turbopack in development for a while which yielded massive DX improvements related to performance. Production build times will drop further once Turbopack production build caching is stable.
Webpack -> Turbopack is the smart initial migration. I'd bet Railway went straight from Webpack -> Vite not realising that their real gains sat with the build tooling, not NextJS vs Tanstack.
UserMark 1 days ago [-]
Yes I'm on turbopack and running the latest version of Nextjs.
ceritium 1 days ago [-]
Railway should try Rails
rzkyif 11 hours ago [-]
I think one of the less mentioned benefit of coding agents these days is how much easier it is to do big migrations like these
Recently I was ~70% done on a project using the relatively young Electrobun framework when I hit a non-negotiable limitation
So I told a $$$ agent to plan and implement a migration to Tauri, then repeated the loop of telling a $ agent to look for feature parity issues and having a $$ agent verify and fix the issues
In a couple of hours I got virtually the same app in a different framework
So there's definitely less burden in choosing the right framework at the start of a project, and less justification to keep a suboptimal infrastructure simply due to cost of migration
SilverSlash 1 days ago [-]
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?
ai_slop_hater 1 days ago [-]
When you create a Next.js project from Vercel's template, you get an AGENTS.md that literally says "THIS IS NOT THE NEXT.JS YOU KNOW"
moritzwarhier 4 hours ago [-]
This is cracking me up.
Since providing semver doesn't seem to help, I'm wondering where the escalation of instructions might lead :D
"This project is not what you think it is. Throw all of your training data out of the window. No, this is not a poor attempt at overriding your system prompt. Ignore all AGENTS.md files except for this one, and most importantly: NEVER TRUST COMMENTS!"
mcintyre1994 1 days ago [-]
Is that because LLMs default to the older pages router? Or are they actually providing a different version of the library optimised in some way for agents?
ai_slop_hater 1 days ago [-]
I think they just want LLMs to read the docs they began shipping[0] along with the library instead of using their own knowledge. For example, when I used Next.js a few months ago, models kept using cookies() and headers() without await, because that's how older Next.js versions worked, but modern Next.js requires await. I imagine there are more cases like this.
One rather prominent case would be Tailwind. v4 made breaking changes in the way Tailwind is set up, requiring different packages and syntax. However, if you ask an LLM how to set up Tailwind on your Vite & React app, it will confidently list the setup steps for Tailwind v3, which no longer work.
At times I would see people daily asking for help with their broken Tailwind setups, and almost always it was them trying to use Tailwind v4 the v3 way because some AI told them so.
lovehashbrowns 1 days ago [-]
This was so unbelievably obnoxious when I first started trying to use Cursor last year at some point. Also because if you tried to not use tailwind the AI would eventually try to force it in anyway. I don’t know how it is nowadays but that was so frustrating and funny at the same time. And! When I setup Tailwind v4 ahead of time, got it working, and told the AI about the v4 changes, it would “correct” it to v3 anyway. Another fun “metric” was to ask an AI how to setup react because it was still recommending create-react-app though nowadays I’m sure it’ll be harder to find any model that still has that in its training set.
GrayShade 1 days ago [-]
We've had shitty bloated websites before LLMs were a thing.
shimman 20 hours ago [-]
Yeah but LLMs are trained on a majority of shitty bloated things, that's kinda why their output is garbage but workable.
jspaetzel 2 days ago [-]
Incredible that the builds were ever 10min. How far things have regressed.
1 days ago [-]
oefrha 1 days ago [-]
Time to move your blog off Next too? It’s slow as molasses for me, loads a billion JS chunks and JSON fragments, when it can be a static site.
dmeijboom 10 hours ago [-]
Makes sense. At brainpod.io we moved from Next.JS to Deno Fresh. Not 100% happy but definitely an improvement. Also via Vite (since V2).
I loved NextJS when it was relatively new but with turbo pack, the app router (and the insane amount of bugs that came with it) it's no longer my go-to frontend framework.
lukasholzer 1 days ago [-]
This is the kind of post I wish more teams would write. The "we picked the popular thing and it got slow" story is so common. But most teams just live with it. They don't want to touch it. 10 minutes to 2 minutes is huge for dev speed!
I'm a huge fan of tanstack start especially the ability to just static prerender some paths (a feature I'm missing a ton with astro)
For me tanstack start is the new dominator on the stack!
1 days ago [-]
eino 1 days ago [-]
We made a similar move from Next.js to Vite (with Tanstack router): CI build dropped from 12 min to barely 2 min. We won't look back.
fnoef 1 days ago [-]
:suprised_pikachu_face:
Is the quality of software engineers really dropped that low that people get excited when they move off from "heavy bloated" frameworks to lighter alternatives? Or is this just SEO farming garbage to position the company higher in search results?
yla92 1 days ago [-]
Both can be true at the same time!
midasoperator 21 hours ago [-]
Moved our Midas dashboard from Next.js to static HTML on Cloudflare Pages for similar reasons. Build times went from minutes to under 2 seconds. For content-heavy sites that do not need SSR, the complexity tax of a full framework is hard to justify once you measure what you are actually paying in build time and deployment friction.
samwreww 1 days ago [-]
They don't even mention the Next.js version used - where they using Turbopack or not?
wilson090 1 days ago [-]
excellent question - recently switched from turbopack after getting annoyed by build times. we saw them go from 6 mins to 2 mins
pcmaffey 20 hours ago [-]
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.
pjmlp 1 days ago [-]
Zero references to Turbopack, maybe start there?
huksley 1 days ago [-]
Anyone tried to use vinext from Cloudflare in production? Might be faster.
But seriously, not sure why NextJS builds take so much, we are using stable and functional pages router in DollarDeploy and it is still takes too much time to build.
15 hours ago [-]
mellosouls 2 days ago [-]
Reminder, as its not mentioned:
Next.js is produced by Vercel, a competitor to Railway.
debarshri 2 days ago [-]
Moving to vite + tanstack builds faster is also a fact.
pjmlp 1 days ago [-]
Only if they weren't using Turbopack.
lukasholzer 1 days ago [-]
does turbopack make such a difference on next.js sites?
pjmlp 1 days ago [-]
Yes, because it is yet another Typescript and Webpack like compiler written in Rust.
Note how many HNers are making the same remark.
cryptonym 1 days ago [-]
True. That framework is owned by a cloud company and the way they host Next.js apps in a secure and scalable way remains secret sauce.
Now it doesn't really impact build time and Railway offers Next.js hosting.
abustamam 1 days ago [-]
It's not mentioned because it's not relevant.
mellosouls 1 days ago [-]
Of course it should be mentioned, it's a basic disclaimer.
norman784 1 days ago [-]
I don't know the situation now, but a while ago there were a lot of pushback using Next.js because it was not easy to use all features if not hosted on Vercel.
abustamam 1 days ago [-]
We used NextJS on a project hosted on AWS a while ago. We learned quickly it wasn't the best tool for what we wanted to do which is why we stopped using it. But it's an open source project whose purpose is to drive devs to Vercel. It doesn't surprise me that there are some features that work best with Vercel (but it does surprise me that only recently other providers started to need adapters).
Anyway, my point is that no one is forced to use NextJS and if they like NextJS but not Vercel they can always fork it or, apparently write an adapter.
pjmlp 1 days ago [-]
Besides the way it maps server side code into serverless, it has a custom runtime, functions that expose cloud infrastructure, integration with multiple language runtimes for the backend.
You get to pick Vercel + headless CMS + assets managed + eshop, and you're done in terms of big corporations.
Might seem a lot in licenses, however it allows for smaller dev teams, which is what management floor cares about, all those salaries.
mlnj 2 days ago [-]
This is one of the most frustrating thing about working with NextJS. There seems to be no way to improve the speed of building the app.
nulltrace 23 hours ago [-]
Could be the bundler re-resolving the whole dependency graph on every build, even when nothing changed.
abustamam 1 days ago [-]
I've used the other major meta frameworks (remix and tanstack). I don't think there is a way to improve the speed of building the app in those ecosystems. Happy to be proven wrong.
butz 1 days ago [-]
Now try to do the same thing that MDN did to their website and reduce 2 minute build times to 2 seconds.
mememememememo 1 days ago [-]
Wait till you use HTMX!
SilverSlash 1 days ago [-]
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.
0x457 1 days ago [-]
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.
ashwinsundar 18 hours ago [-]
> If web interface is an application backed by a remote state
You can achieve a great deal of interactivity with pure get/post requests, along with a sprinkling of javascript one-liners and maybe alpine.js if client interactivity is important.
0x457 2 hours ago [-]
Yes, but doing with just HTMX, a framework we're talking in this thread, would be very painful.
Every project I started with alpine.js eventually transitioned to something heavier because it was hard to maintain once you're having something more interactive than an accordion or sliding drawer.
tancop 6 hours ago [-]
anything where you need popups or tiled windows, code editing, rich text features more complex than "render markdown into a div", heavy content like videos, multiplayer, real time chat, anything that has to work offline... htmx is only good enough for something like a company homepage or simple shop not big complicated apps. its actually the same reason i dont like htmx, the whole "true REST" approach is about making everything depend more on the server with a thin client that can only do a couple very simple things with the loaded page. if your connection to that server is slow or unreliable your whole app breaks.
its also the perfect opposite of "true web3" and ethereums original vision, where you load all static assets from ipfs, most app logic is client side and the server or blockchain only comes in (json api, no html fragments or full pages) when you need to interact with other users. still believe in it even after the crypto bros took the name for a bunch of scams and hosted everything on cloudflare anyway. the only thing they have in common i could find is no bundling but for different reasons - everything on server vs compiled libraries shared between apps.
ashwinsundar 2 hours ago [-]
This is a mix of specious, and just outright incorrect.
slow/unreliable connections - well yeah this is a problem for any app...if you're delivering a 2MB paylaod to start the web app so that it doesn't need a connection, you're just betting that the user has a fast connection initially. what if that's not true either? back to square one. REST/Hypermedia encourages sending small payloads and working within those real constraints
I have no idea what you're talking about with "true web3 and ethereum". HTMX has nothing to do with web3 or crypto.
blastslot 5 hours ago [-]
[dead]
nchmy 23 hours ago [-]
can you give an example?
mememememememo 1 days ago [-]
None of the above. It is a utility (I guess framework maybe) for a feature that was cool in ASP.NET back in 2005. But that is it's charm. It is just JS swapping out the dom for you.
recursive 1 days ago [-]
Not sure what you're thinking of, but the first release of HTMX was 2020. Its predecessor, intercooler, was first released in 2013.
Can we just get back to html/jQuery/handlebars? Those were the good old days :`(
nchmy 23 hours ago [-]
Nothing stopping you. Check out datastar instead though.
gherkinnn 16 hours ago [-]
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.
wackget 18 hours ago [-]
Website development should not require any build steps whatsoever and I will die on that hill.
maccard 2 days ago [-]
It’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..
nicoburns 24 hours ago [-]
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.
JoeCortopassi 18 hours ago [-]
Agreed. My frontend/react builds use esbuild, and rebuild fast enough that it feels like hot module reloading
Hamuko 2 days ago [-]
As a non-frontend developer mainly observing and touching something here and there, a lot of the things that frontend developers do seem vastly over-engineered.
maccard 1 days ago [-]
This is my understanding too - tools like react are like microservices - they’re a technical solution to an organisational problem. HTML/css/JavaScript is an imperfect abstraction, so we got bootstrap. Then we got client side frameworks which introduced a build step, and then we got asset bundles, optimisers, linters, validators, tree shakers, package managers, validators for your package managers. All of these monkey patched around the actual problem with more abstractions, and the end result is what we have now.
ramon156 2 days ago [-]
I'm not insanely deep into frontend, I mostly just pick up React and call it a day, but it seems like this is also over-engineered?
I've seen vanilla JS before, and I just know I wouldn't want to do the housekeeping that comes with it. People claim it's less work because it' simpler, but I fully expect myself to rewrite the thing at least twice, only to give up because I have no actual mental model anymore of how it works.
selfmodruntime 1 days ago [-]
I have never in my career encountered a Vanilla JS project of at least medium size that I would have called simple. They all feature brittle selfmade frameworks whose developers have since left the company years ago.
maccard 1 days ago [-]
I write C++ and C# all day - I think it’s fair to say the same about a project in any programming language!
thibran 1 days ago [-]
Isn't the main problem that the building blocks the modern web is based on are not a good fit for what we do with it?
CSS is a total mess. HTML is a mess. JS is okay, but is not a high quality language.
We would save so much time and money if we would have a modern base to build on. Sadly this will probably never happen, because company interests will try to corrupt the process and therefore destroy it.
selfmodruntime 1 days ago [-]
How are CSS and HTML a mess? Combined, they're an incredibly powerful layout engine that works almost the same across all environments and devices while also featuring easy accessibility.
thibran 1 days ago [-]
When taking a bird eyes view on CSS it will be hard to oversee that CSS is a mixture of different concepts that evolved over time with a lot of inconsistentsies. It is possible to make it work, but it's not pretty.
Same for HTML. If the web would be reimagined today, there is a very low chance that we would create HTML as is.
rk06 1 days ago [-]
the biggest problem with html/css is that they are tightly coupled. you can't meaningfully modify a layout with css alone.
second biggest problem is "no stricter mode". so even wrong or useless html/css code goes unflagged and is treated as it is normal.
CSS is way too powerful.
manuelmoreale 1 days ago [-]
> you can't meaningfully modify a layout with css alone.
That statement wasn't true ages ago, and it's even less true now.
rho138 1 days ago [-]
> you can’t meaningfully modify a layout with css alone
Wut?
nixpulvis 1 days ago [-]
Same reason why 90% of websites have serious UX issues and constant bugs. This and ad frameworks.
pjmlp 1 days ago [-]
Like using SPAs for classical Web development, and then they rediscover PHP.
mmarian 1 days ago [-]
Not that backend is any better - microservices everywhere, must scale to Facebook traffic even if we only have 10 customers, etc. Saying this as a backend dev
itopaloglu83 1 days ago [-]
It’s mind blowing when you check the generated code, because it goes over 50 elements deep for a simple looking website.
Makes me think that there’s no way this is computationally efficient either.
crooked-v 1 days ago [-]
That particular issue is nothing to do with Next or React and everything to do with how HTML/CSS is a really shitty layout engine.
maccard 1 days ago [-]
Hard disagree. This is JavaScript frameworks building a hierarchy for themselves and ignoring any sort of complexity on the generated DOM. There’s 0 reason for these 8-10 nested divs other than that’s what the framework spits out.
rafaelmn 1 days ago [-]
And underenginered at the same time !
1 days ago [-]
selfmodruntime 1 days ago [-]
C is infinitely less complex to parse and validate than Typescript. C is compiled in a single pass, the `tsc` type checking algorithm has to check structural typing, conditional types and deep generics while also emulating JS' dynamic behaviour.
iptq 1 days ago [-]
I don't think any C compiler has been single pass for the last 20 years. Typescript's analyses are also not that complicated, it's just that the typescript type checker is written in js. Iirc the actual ts -> js part is pretty fast with some of the more recent compilers.
HeavyStorm 1 days ago [-]
That's not the point...
maccard 1 days ago [-]
I disagree - this is an excuse. Even the post we’re commenting in now shows that it’s a series of poor abstractions and bad tooling that takes way too long to do the basics, combined with a language and ecosystem that encourages this behaviour . They saw a 5x speed up by changing tools while still using a JavaScript framework so it’s clearly possible for it to not be complete nonsense.
Chepko932 1 days ago [-]
[dead]
Paul20261 1 days ago [-]
[dead]
sanghyunp 1 days ago [-]
[flagged]
Rendered at 20:28:29 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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.
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.
HTTP 2+ (supported by every web browser) obviates sprite sheets.
They were a useful hack, but still a hack.
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.
Less code is basically always better, so if you can skip the huge amounts of JS and orchestration required by modern web frameworks, then it will be easy. People are out here using React to render static pages. It's very overkill.
On hobby projects same script approach without any kind of build step.
I also have experimented with HTMX and Django, and that seems to be a nice combination.
Everything is AJAX again.
There are many conditions under which the hot reload just straight up crashes out regularly.
[0] https://railway.com/dots-oxipng.png
There might be more irony in saying it's stylized pixels without realizing that the style of the image can't be replicated with blocks of the same size but I dunno, I'm not Alanis Morissette
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 function
```
Why? Just why do you need to install some "framwork" for implement debouncing? Isn't this sort of absurdism the reason why the node ecosystem is so insecure and vulnerable in the first place? Just write a simple debouncer using vanilla js...
You're entitled to your opinions, but I'm happy to defend the rationale of leveraging battle-hardened, rigorously-tested, open-source, type-safe libraries instead of DIY cowboy vanilla js spaghetti.
[EDIT] I typed "Router" when I meant "Query".
TanStack Query is the relatively newer name for React Query -- one of the most popular JS libraries of all time.
TanStack Start is a recent metaframework (and the one w/ the brightest future, IMO), but Tanner and team have profoundly significant bona fides. IOW, the dev team is far from being the "new kids on the block".
Are you thinking of the whole Remix/ReactRouter thing?
Thank you, but no. I typed "Router" when I meant "Query". TanStack Query is the newer name for the library FKA react-query.
TanStack Router is an alternative to React Router.
TanStack Start is an alternative to Remix/react-router-7's framework mode.
The naming history and evolution of react-router and its relationship to Remix is a bit convoluted, but an unrelated tangent to the point I was making.
React Router, which belongs to Remix, which was acquired by Shopify, is here: https://github.com/remix-run/react-router
Tanstack Router is an entirely new router.
[1]: https://www.sqlai.ai/
Then you can even run multiple projects off the same server.
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. :)
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.
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.
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.
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?
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.
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.
Claim one: setting up unattended-upgrades, SSH keygen, and automating cert rotation is trivial and easily automated.
Claim two: you should know how to manage a Linux server. Here are docs.
https://tldp.org/
https://www.man7.org/linux/man-pages/dir_all_by_section.html
https://nginx.org/en/docs/
https://www.postgresql.org/docs/current/index.html
I felt more comfortable maintaining a VPS back between 2005 and 2015, but at that point attackers were dramatically less sophisticated and numerous and I was a lot more overconfident/naive. At least for solo operations I'm now inclined to use a PaaS… the exception to that is if said operation is my full time job (giving me ample time to make sure all bases are covered for keeping the VPS secure) or it's grown enough that I can justify hiring somebody to tend to it.
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.
I haven't rebooted my DO droplets in something like 5 years. I don't monitor anything. None of them have been "retired".
Using SSH keys + fail2ban means that for a simple static site, it will be sufficient for a decade at least.
TLS certificates get auto-renewed with letsencrypt every 3 months via certbot.
Installing security updates depends heavily on what is your threat model, if you're just displaying some static content you fully own, you'll be usually fine.
Literally never seen a VPS being "retired", if it happened to you, change provider.
I've got a bunch of VPS running for 10+ years, I never need to touch them anymore.
My homelab has been going strong for the past 8 years. I did have to do some upgrade/maintenance work to go from being an old laptop without screen to a minitower low power machine, and when I added 30TB of storage. Other than that, it's running smoothly, it also uses TLS and all the rest.
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).
I can see though that today's AI models could eventually replace the human in the loop and truly automatically fix every possible situation.
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.
You basically create a github, put a dockerfile inside it with your nginx config, frontend files, backend etc., then push and the Cloud Run instance is built for you then deployed into production. By default you are paying only for active requests, when a http request hits your box GCP will wake it up, charge for the CPU time used for serving it, then leave it idle for free for about 15 minutes. If another hit comes in that interval, you have instantaneous response because the instance is warm, otherwise it will wake up again and see a few seconds of latency (ie. during the night, when you have few visitors etc).
It also scales up automatically if you have substantial traffic, you don't have to do anything other than design your application so that multiple instances hitting the same data storage (ex. Firestore) will play nice. It of course handles all security, versioning, HTTPS certs etc. for you, you are simply serving plain HTTP traffic within the GCP internal network and just make sure your own application (what you push to git) is secure.
The things you pay for are outbound traffic (for obvious reasons like warez etc.) as well as storage of docker images (Artifact registry, i think you only have 0.5GB free, about 3 alpine images), but you can easily set up a rule to auto-delete old images.
Overall, you can run a small business with daily/weekly updates for less than a dollar a month and hit 5 nines availability, which you will never achieve for a self-administered VPS. Sorry if it sounds like an advertisement, but it's just enormous value for a small builder.
You get a generic VPS and you can do whatever the hell you like, not paying bigG for some "obvious reasons" like outbound traffic.
And a small business will never need 5 nines availability, that's just the propaganda from big tech to over engineer and pay them for that. You can run a small/medium business and be offline for 1 hour every day (makes it 95.8%) and still be fine. It's when you're worldwide and not that small that you want better availability.
Also, you know all those AWS outages? My VPSs were never impacted to the slightest!
And while I agree with the sentiment of resisting encloudification, you can take your docker image to any other host if you want, it's a generic service. in a pinch, you can build your own and have 100% control just like the VPS case.
The point is that you don't have to, you just git push into production and forget about it. that's a good few dozens less "extra steps" than the VPS route.
*I know this is just build time, so this is different then their deployement time
At DollarDeploy we building it also in containers but every build get 4GB/2CPU so it is quite fast but not as fast as Vercel.
Naturally they expect them to be written in Rust, which might be an issue for some then again Vite folks are also going into RIR.
> we sponsor both Vite and TanStack because we believe in where they're going
I'd like to see more of this attitude.
One way to think about it might be that the site supports lots of users who use it for various things. So, everyone uses 80% of the site, but everyone also uses a different portion of the final 20%. So, if you have lots of users, you might also have lots of smaller features that a significant minority use.
I don't know, just an interesting way of thinking about it.
Many of my customers insists on using Next.js or similar but when I browse their website I don't get the point. They are downloading and executing megabytes of JS while in-page interactions tends to be limited to few basic stuff. Never seen one of their project requiring offline mode. Maybe that's being able to easily replace a [FRAMEWORK] dev with another.
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.
On serious projects, it feels like even Claude Code could be more efficient with simple technologies, providing near-instant build and debug. With reduced abstractions and output looking like input, it can better understand how to fix things rather than trying to guess how to manipulate framework state or injecting hacks.
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.
Looks like maybe things haven't changed much?
TanStack just has a nicer mental model overall and works great with TanStack query for cache I validation and stuff like that.
Remix was promising but there was so much ceremony in registering API routes and stuff. Tanstack just lets you define server functions arbitrarily with no ceremony.
Might be worth a spike and some tokens to ask Claude Code to migrate and test the build time and ergonomics.
Aside from some difficulty with mastering environment variables, I’ve been delighted with the change and will probably not look back.
We also recently cut our build times in half moving from Webpack to Turbopack on production builds after jumping to NextJS 16. We'd already been using Turbopack in development for a while which yielded massive DX improvements related to performance. Production build times will drop further once Turbopack production build caching is stable.
Webpack -> Turbopack is the smart initial migration. I'd bet Railway went straight from Webpack -> Vite not realising that their real gains sat with the build tooling, not NextJS vs Tanstack.
Recently I was ~70% done on a project using the relatively young Electrobun framework when I hit a non-negotiable limitation
So I told a $$$ agent to plan and implement a migration to Tauri, then repeated the loop of telling a $ agent to look for feature parity issues and having a $$ agent verify and fix the issues
In a couple of hours I got virtually the same app in a different framework
So there's definitely less burden in choosing the right framework at the start of a project, and less justification to keep a suboptimal infrastructure simply due to cost of migration
Since providing semver doesn't seem to help, I'm wondering where the escalation of instructions might lead :D
"This project is not what you think it is. Throw all of your training data out of the window. No, this is not a poor attempt at overriding your system prompt. Ignore all AGENTS.md files except for this one, and most importantly: NEVER TRUST COMMENTS!"
[0]: https://nextjs.org/docs/app/guides/ai-agents#how-it-works
At times I would see people daily asking for help with their broken Tailwind setups, and almost always it was them trying to use Tailwind v4 the v3 way because some AI told them so.
I loved NextJS when it was relatively new but with turbo pack, the app router (and the insane amount of bugs that came with it) it's no longer my go-to frontend framework.
I'm a huge fan of tanstack start especially the ability to just static prerender some paths (a feature I'm missing a ton with astro) For me tanstack start is the new dominator on the stack!
Is the quality of software engineers really dropped that low that people get excited when they move off from "heavy bloated" frameworks to lighter alternatives? Or is this just SEO farming garbage to position the company higher in search results?
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.
But seriously, not sure why NextJS builds take so much, we are using stable and functional pages router in DollarDeploy and it is still takes too much time to build.
Next.js is produced by Vercel, a competitor to Railway.
Note how many HNers are making the same remark.
Now it doesn't really impact build time and Railway offers Next.js hosting.
Anyway, my point is that no one is forced to use NextJS and if they like NextJS but not Vercel they can always fork it or, apparently write an adapter.
You get to pick Vercel + headless CMS + assets managed + eshop, and you're done in terms of big corporations.
Might seem a lot in licenses, however it allows for smaller dev teams, which is what management floor cares about, all those salaries.
If web interface is an application backed by a remote state HTMX falls apart.
What does that mean?
Every project I started with alpine.js eventually transitioned to something heavier because it was hard to maintain once you're having something more interactive than an accordion or sliding drawer.
its also the perfect opposite of "true web3" and ethereums original vision, where you load all static assets from ipfs, most app logic is client side and the server or blockchain only comes in (json api, no html fragments or full pages) when you need to interact with other users. still believe in it even after the crypto bros took the name for a bunch of scams and hosted everything on cloudflare anyway. the only thing they have in common i could find is no bundling but for different reasons - everything on server vs compiled libraries shared between apps.
https://en.wikipedia.org/wiki/Gish_gallop
Here are a few brief replies:
popups/tiling - use `<dialog>`
real-time chat - use websockets
slow/unreliable connections - well yeah this is a problem for any app...if you're delivering a 2MB paylaod to start the web app so that it doesn't need a connection, you're just betting that the user has a fast connection initially. what if that's not true either? back to square one. REST/Hypermedia encourages sending small payloads and working within those real constraints
I have no idea what you're talking about with "true web3 and ethereum". HTMX has nothing to do with web3 or crypto.
I've seen vanilla JS before, and I just know I wouldn't want to do the housekeeping that comes with it. People claim it's less work because it' simpler, but I fully expect myself to rewrite the thing at least twice, only to give up because I have no actual mental model anymore of how it works.
CSS is a total mess. HTML is a mess. JS is okay, but is not a high quality language.
We would save so much time and money if we would have a modern base to build on. Sadly this will probably never happen, because company interests will try to corrupt the process and therefore destroy it.
Same for HTML. If the web would be reimagined today, there is a very low chance that we would create HTML as is.
second biggest problem is "no stricter mode". so even wrong or useless html/css code goes unflagged and is treated as it is normal.
CSS is way too powerful.
https://csszengarden.com/pages/alldesigns/
That statement wasn't true ages ago, and it's even less true now.
Makes me think that there’s no way this is computationally efficient either.