Frontend
Post #7176 · source on Telegram
Server-Side vs Client-Side Rendering: A Love Story by Dax
Description
Screenshot of two tweets from dax (@thdxr) on X/Twitter dated Jan 11. First tweet reads: 'you want me to render it on MY server??? why would i do that when i can render it on your client? what am i a charity?' with 46 replies, 103 retweets, 3K likes, and 107K views. Second tweet below is a reply: 'bitch you asked for this file and you don't wanna do any of the work?' The tweets humorously personify the server-side vs client-side rendering debate, with the server refusing to do rendering work and pushing it to the client, a common sentiment in the SSR vs CSR architecture debate
More like this
More like this in Frontend →
Use J and K for navigation
Comments
36Comment deleted
The server has adopted a strict 'your browser, your problem' policy. Next up: the client files a grievance with the HTTP standards committee for hostile working conditions
Client-side rendering is the ultimate architectural sleight of hand: convincing the user's browser to pay your AWS bill one CPU cycle at a time
Sure, I can render it server-side - right after finance approves upgrading the EC2 micro to something with an actual core
After 20 years in tech, I've realized the SSR vs CSR debate is just a sophisticated way of asking 'whose electricity bill should this JavaScript execution appear on?' - and honestly, making the user's laptop fan sound like a jet engine is just distributed computing with extra steps
The eternal SSR vs CSR debate distilled to its economic essence: 'Why should my AWS bill subsidize your user's potato laptop?' This perfectly captures the architectural tension between server costs, client capabilities, and the philosophical question of who should bear the computational burden - especially when you're the one serving millions of requests at $0.09 per GB transfer
Client-side rendering: turning your users’ laptops into your free compute cluster and calling it “edge.”
Backend creed: Ship raw assets, let client GPUs spin - because your AWS bill isn't my charity case
CSR is the CFO’s favorite autoscaling strategy: replace servers with 100k unpaid laptops - until SEO and accessibility demand you actually render something
Electron behavior Comment deleted
For fucking real Comment deleted
😂 Comment deleted
ngl this is the philosophy i've been using for most things if i can use your computer for free, why would I make the server do it for money Comment deleted
You gotta weigh what will cost you little to nothing to improve user experience and what will cost way too much user inconvenience. If you are the government website you take the worst of both Comment deleted
What user inconvenience of client side rendering? Comment deleted
Loading times, battery drain, heat, possibly not even supported Comment deleted
Ah you must own a pixel Comment deleted
Thankfully no Comment deleted
Any old hardware gets old. Also 99% of your clients will run your websites and apps on a toaster or potato Comment deleted
Flutter runs well on potato hardware :3 Comment deleted
Server side rendering can also mean better security where that's relevant too. As it means the client never gets direct access to the data, only the rendered data. Comment deleted
Yea Comment deleted
what's the problem in not including the sensitive data in the API response? Comment deleted
Devs make mistakes. Comment deleted
You have testers. And at the end of the day, you have f-ing responsibility. Comment deleted
This is like saying you can use raw pointers in C++ instead of smart pointers because you won't make a mistake. It's just not reflective of reality. Mistakes will happen if you're at it for long enough. Comment deleted
Why would you, say, put your users' SSN / VAT / password hash / etc. in the user list API enpoint in the first place? Comment deleted
Average firebase app Comment deleted
If you're just directly serializing an object from a database call, that might be fine until you or some other dev later adds another value to that object in the database. Changes unrelated to the API endpoint could easily result in changed API output. Comment deleted
how? any browser can render a website Comment deleted
Yeah browser api is knows to be stabile Comment deleted
"Just don't make mistakes" is a really stupid design philosophy. It just doesn't work that way. Comment deleted
Every C dev when rust Comment deleted
Literally tho. Comment deleted
Have you tried using a browser thats not updated since 1y? Comment deleted
Have I need to mention some people use browsers that havent been updated in 6 years? Comment deleted
And thats why you never should work for government website development Comment deleted