Server side rendering has significant upsides but I feel one of the biggest downsides is consistently ignored when discussing it, namely that when you render (parts of) pages you burn expensive server side CPU cycles rather than the free client side cycles which in most cases noticeably affects hosting/scaling cost.
Not to mention that server side rendering increases cpu load on your servers. Of course that may be a feature if you're a customer who's tired of slowly loading webapps.
Oh, interesting! Thanks for sharing. But there still is a little bit of server load, whereas front-end has 0.
Honestly, unless you're serving billions of pageviews on a very tight budget, I'm not really sure how much of a savings we're talking about here (server side vs. client side rendering).
I'm really curious why you say that? Certainly it seems to me there's enough downsides to client side rendering still that I can't see how it's that clear cut.
It's pretty obvious that server side rendering has more potential bottlenecks and IO overhead. But with that said, nothing says it must be slower. It just has more potential to be slower.
The scaling characteristics of a client side and server side rendered app is different. Client side apps have up front costs which are amortized as the view can be incrementally updated. Whether this is more performant depends on the metric and the problem domain.
Particularly static pages with minimal interactivity can be prerendered and cached at the CDN, but that’s not necessarily the same as an on demand server side rendered page, either.
And, heck, there's a solid argument that server-side rendering is more environmentally efficient, since the work is done in a data-center, which can (1) utilize caching to avoid re-doing work and (2) be built in an optimal location for electricity generation.
Server side rendering has one big advantage - it's fast. Client side rendering frameworks may be easier and sexier, but serving html is always going to be faster.
It feels so much faster tho, to not have websites slow down when my browser slows down. Server side rendering should be considered a better experience for the end user, especially if it can prefretch the next pages.
Those free client-side cycles have a hidden cost - slow rendering times, especially on mobile. If you've done your work right, server-side is scalable.
It's not so much a scalability issue as a cost-per-user issue. Obviously client rendering performance (or lack thereof) is a concern and if server side rendering solves that for a manageable increase in cost that's perfectly fine but that cost has to be part of the conversation.
This was my thought, too. In reality, client side rendering today is “cheap” because you typically put a CDN in front of your application to serve static resources and scripts, and your backend only serves the API requests (if needed). Rendering everything on the backend means by contrast that you’re limited to the capacity of your server and the latency based on where it’s located.
Yeah, the operating assuptions of client side rendering seem to be that server-side CPU is expensive while network bandwidth and latency are cheap and the client has a fast CPU which it isn't using. I do wonder how it ever took off.
It's just intuition on my part, but I think the environmentally friendly option is probably actually sending a couple extra packets (server-side rendering) vs cooking the CPUs of however many clients you have with JS (client-side rendering)
The difference isn't between sending a couple of extra packets versus rendering on the client. It's between rendering on the server PLUS sending a couple of extra packets versus rendering on the client. You have to do the rendering somewhere. Assuming the code that does the rendering is essentially the same whether it's server-side or client-side, the only difference is sending the extra structural layout data when you render on the server. For most sites it'll make no real difference but if you're at Facebook scale I'd guess a couple of extra packets really adds up, especially considering you could cache the client-side templates between sessions.
Sure, but the advantage is that if you can write your rendering logic once and have it run both server-side and client-side, you've saved a ton of work.
Reading the docs, it says the Forms run on the client, so most rendering should run too. Client-side rendering - while it has its disadvantages - shouldn't be worse for the CPU time than server-side, though. What's your concern?
reply