Do you REALLY need SSR?

S/O Ph4seOne for the awesome edit 🙏

[serge]

excellent, this certainly is one of your best breakdowns so far
. I've been following for nearly a year now, just wanted to let you know that this kind of content is what makes you stand out (for me)

[PsychoGod]

I think there are a lot of valid use cases where SSR totally makes sense. And I am happy that we have Next and React SSC. But also in practice: a lot of React applications are behind a login mask, should never be crawled and have a lot of interaction. For this kind of app, I still prefer a fully client side rendered approach as it is much simpler to code, maintain and host. If the performance of the users devices is of no concern, I don't see any downsides. And I also prefer having a slightly longer loading time but seeing some loading spinners that tell the users what is happening instead of just having a blank page

[frostmichael]

Even for devs who experiment NextJs/SPA/SSR since many years, the level of understanding and the level of pedagogy is so worthfull !! Thank you very much \o/

[abrudner]

This is awesome. I’ve seen all of these models on various websites but seeing how they work out in these block diagrams makes it super easy to understand. You’re a great teacher Theo! Knowing how to break down a complicated topic into easy to understand chunks is an art and a skill and you have both.

[zangetsu]

I think is worth mentioning that in the SSR model, after hydratation, your page can do API calls and update the UI using the returned JSON, no need of a page refresh. Something similar to what we used to do in the old days using ajax and jquery.

[SeanMcQuaidCode]

Man, you are putting out some BANGERS more recently. Keep up the great work, appreciate what you do Theo!

[dennis_benjamin]

So to summarize: The benefits of SSR are:
- we can cache the rendered page, which only works for not personalized pages, which unfortunately doesn't apply for most pages.
- we can't show loading animations even if we would like to
- if we have 100 users on the page with iPhones at the same time, if our servers have more performance than their 100 iPhones the rendering would be slightly faster
- instead of js files and JSON we push huge html pages to the client. Wasn't the big preformance benefit of Angular and React that after the bundles where in the browser cache the only thing we had to push to the client was some JSON data instead of the whole html?
- we can deliver a small part of the page statically generated then load more data and render the rest of the page on client side anyways

I have been working for 2.5 years now with SSR in my current project and researched it on the internet a lot but I have not found a reason that's worth adding the complexity yet. And for me it sounds crazy that the servers should now have more power than all of the users devices compared to actually have faster rendering. And all of this runs on node.js which scales really bad and doing actual work on node.js servers just defeats the one benefit they have of being unblocking. If I'm missing something please tell me.

[jjrise]

ugh I love these excalidraw videos... thanks for the effort on these, unbelievably helpful!

[YoannMaingon]

The explanation about Single Page App, is not fair. For Business Web Apps (not public facing websites), users will access the website everyday, if it takes 2, 5, 10 secs to load on the first access it is not a problem at all. Js is cached and the website is fast to load every other time. I have got webapps for which users actually never reload the page for a full day of work.

[adaliszk]

I find it funny how we got a full circle where we started server-side rendered templates that were updated through Ajax, moved to entirely client-side rendering, and now we are returning to rendering on the server side again. I am unsure why you are saying that we re-rendered everything on a page with Ajax. While there were certainly ones who did, a significant revolution with Ajax was that you could render portions of your page and replace the result within containers.

EDIT: The old solution was not ideal, but the concept worked overall. The new tools are definitely better, especially when we look at possibly the next steps with things like Qwik/Yew and similar, combining the server and client to deliver an experience.

[nezukovlogs]

My Cold Take - What happened IMO was that Fully client side app's where a huge blow to the cloud/hosting providers as now all the rendering process is done on client side and no server is used, expected for just apis. So, what they do? They started creating Meta frameworks which uses Server side rendering also so that, server is also used in generating pages, and that increases their revenue.

[HHJoshHH]

Ty so much for helping me learn and grow, Theo! Love your content. Definitely subbed with notifications set to all.
When I get a job I’ll be able to be a greater value to your channel but….im working hard to stay organized and on task.

[ashishpandeyone]

A very detailed video and totally on point explanation.

Yes, SSR looks great and definitely improves SEO and UX. The problem now though is you totally give up all chances of page caching when under any decent load. Most apps that are behind a paywall or require mandatory user authentication and authorisation do not need to be SSR. And while nobody is considering this but when you're serving DOM from a server, you're serving a lot of redundant data, using a lot of TCP connections and burning a lot of compute and IO to read files and serve them. SSR IS EXPENSIVE AND COSTLY and unfortunately no one is saying that.

For blogs, public content, etc. SSG is still the best option and in case the page requires some dynamic data to be included, make it ISR and let the client request the dynamic data that it needs. Our mobile devices aren't weak, our networks aren't unreliable but our cloud costs are always increasing. SSR, when unnecessary, just adds to this cost. Caching is your friend and caching JSON will be easier / simpler and much more scalable than SSR DOM.

Even for the most data intensive applications out there, ISR + HTTP Polling / GraphQL subscriptions is still the best way to have a great UX today. SSR is a great piece of tech and React's concurrent mode along with suspense makes it very scalable too but unless you've 10k dynamic layouts with lot's of decision making and need realtime sync renders, don't use it!

[kn-heik]

As much as there was a trend of spa, it seems that the current trend of SSR is in progress.
I think the time it takes for spa to actually load is overstated.
With technologies like module federation, speed is not an issue.
SEO is definitely an advantage of ssr.

Don't burden the server too much.
The client's energy consumption is entirely up to the user, but
Server usage is money. $

[ricktar]

Amazing video Theo. Your videos are tidbits into tech topics that are so ideal in giving brief overviews of new trends. I really like how you took the time to graph and visualize how the flow of package load has changed over these past times. Keep up the great work

[christian-schubert]

This is legitimately one of the best explanations of the differences between traditional PHP vs. clientside rendered vs. SSR content serving. REALLY. WELL. DONE. 👍

[jdevstudio]

Your explanations (in tandem with Excalidraw illustrations) are the best I've ever seen. Thank you.

[bbubbu]

Describing the traditional SSR and next.js's SSR model separately was so helpful for me getting where I was stuck at! It was so helpful. Thanks.

[maxwilsonpereira]

Amazing content very well explained! Thanks a lot Theo! 😀

[mngages]

Great video. As someone who is gonna start playing with next soon, i really needed the high level overview.
Would help if you can make another video on how it is implemented too.