If you're writing a SPA, server side rendering is probably the most important optimization you can make to speed up your application. No other optimization will come close to the benefits of server rendering. SPAs are both slow and perceived as slow. True SPAs are only appropriate for a subset of the web where you have very specific user constraints.
"That is not only slower but it also feels slower to the user"
Not always the case and in many cases, server side rendering is totally fine and has been for decades. We need to stop suggesting that only 1 solution is correct. SPAs have a place but plenty of use cases can do fine with old school server side renders.
I think SPA were cool and with all the frameworks, it became even cooler to just do more client side work BUT don't forget that there are plenty of studies now that have shown that SPAs are not always the correct and magical answer and in many cases they are actually slower.
SPA doesn't imply initial client side render. The first render should of course be done by the server, ideally cached and reused. After that, you can leverage caching and preloading to significantly improve the user experience, page loads can be near-instant.
There’s no arguing against server rendering being simpler - it objectively consists of fewer components. But to say that it is more performant by nature? You can’t actually argue that. There are plenty of performance downsides to rendering a full page in response to every user action. Don’t forget, an SPA can fetch a very small amount of data and re-render a very small part of the page in response to a user action. There is a noticeably performance benefit to doing that.
Performance doesn’t only boil down to the first page load. Hopefully your application sessions are long, and the longer page load time gets amortized across the session if interactions are performant after that.
Note, I primarily work on enterprise apps where the sessions are long, and the workflows are complicated. Of course page load time matters much more for a static site or a blog / content site.
But to claim that SPAs are all cost with no benefit is just disingenuous. Of course they have their own set of trade offs. But there is a reason people use them, and it’s not some conspiracy fueled by uneducated people. Server rendering isn’t some objective moral higher ground.
With server side rendering you have to reload the whole page everytime there's an update on some data or if you want to submit data. That is not only slower but it also feels slower to the user. With SPAs you only reload the part of the page that has some data changing which loads asynchronously in the background, so it's not only faster, it also feels faster. If your new implementation is worse maybe the company you hired didn't do a great job...
It's a powerful argument. Defending client-side rendering here (or SPAs) is almost no-true-Scotsmanish. It is technically possible to do a good job, but it's almost never done. Yours and sangnoir's teams may care about performance and do actual software engineering - but it doesn't help me much when my bank doesn't do it, the places I shop don't do this, big sites like Reddit don't do this, and seemingly none of the SPAs I've visited in the past 5 years do it.
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.
That's not going to happen. It's much easier to open a model or sidesheet than use server side rendering. I imagine in future generations of frameworks and browsers, we will be able to do SPAs without the issues we currently see.
He also doesn't cover the high interaction problems of server-side rendering. If you have a website that isn't a SPA but has a really complex form (for let's say a good reason). Making that server side can be incredibly complex for only fractions of a second in gains.
>which alone can easily be in the hundreds of milliseconds
This actual paint time is surely not any different than if you rendered the exact same application from pre-hydrated HTML though.
Plus, if your application is so complex that paints are on the order of magnitude of network latency, it's probably very important to have a framework to handle interactivity, else everything will end up as some kind of a mess if you try to re-load the whole HTML page to change some small DOM subtree.
Overall, I don't really see the situation where an SPA is performing worse than a server-rendered application, given that some in-browser interactivity is required.
I think this depends on the application. For a complex spa, sure. But for something like a news site or social media the extra load time feels horrible. It's preferable to use server side rendering as much as possible. That also means you gotta speed up your database queries, which is where techniques like in the OP come into play.
I think that is a bit of confirmation bias. Client-side rendering has definitely garnered a lot of attention lately, but that doesn't mean that everyone has simultaneously stopped doing server-side rendering
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.
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.
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.
reply