DEV Community

Cover image for πŸ› βœ¨ Demystifying SSR, CSR, universal and static rendering with animations

πŸ› βœ¨ Demystifying SSR, CSR, universal and static rendering with animations

Franck Abgrall on March 04, 2020

πŸ“– Parts 1) Server Side Rendering 2) Client Side Rendering 3) Universal Rendering 4) Static Rendering 5) Comparisons Sometim...
Collapse
 
fluffy profile image
fluffy

This is an okay high-level introduction, but I feel like it's an oversimplification that buys too much into current dogma about web development and which might give folks the wrong idea, especially with the characteristics matrix at the very end.

Not all server side rendering things use a REST API under the hood, for example (WordPress is a common example of this), and I'm not sure what you mean by a "fluid seamless user experience" that is necessarily made impossible by server-side rendering (at least, in a way that is still universally allowed by static rendering).

There are also plenty of middle grounds between server side rendering and universal rendering where you can provide a progressive "web app" feel by having page components rendered server-side but fetched and replacing HTML elements client-side, while also allowing a non-JavaScript experience (which is also better for SEO). And this doesn't even need a heavyweight framework like Angular Universal; for example, in a template-based server-side framework you can have your page template include your component templates, and also provide Javascript functions that access the component templates directly (all rendered server-side) to directly inject that HTML as appropriate. I believe most of the Tumblr "infinite scroll" templates do that, for example.

You can also have static or server-side sites that make use of embedded JavaScript widgets; see a big chunk of the IndieWeb where things like webmentions/reactions and comments are rendered client-side but the vast majority of the page content is static or server-side. My own site is an example of this; all primary page content is rendered server-side, but comments are handled by isso and reactions are handled by webmention.js which is performing client-side rendering of webmention.io API responses.

There is still plenty of room for traditional server-side rendering on the web; not everything has to be "an app."

Collapse
 
kefranabg profile image
Franck Abgrall • Edited

As mentionned in the intro, everything is explained in a "simplified manner" which means that concepts are voluntarily simplified for pedagogy reasons. This article exposes the most important concepts of web rendering.

I think people are smart enough to understand that REST API can be replaced by whatever you want. (btw you're talking about WordPress, but the data you're getting from WordPress is from a REST API) I used REST API as an example because it is the most common way to handle dynamic data.

By "fluid seamless user experience" I mean the time it takes to display a new page during the in-app navigation, which is fast for static, universal and csr, but not for ssr. (I give you this point, I'll update the description as it's not clear).

Web rendering is something really complex. For example, I could have divided static rendering in several subcategories, because each tool works in a different way. However, the overall idea is the same, and this is what I want to show in this article.

Sometimes, simplification is the best way to teach people, and they don't need to know the exact behavior under the hood.

If you're interested in having a more advanced vision of these concepts, I highly recommend you to read this.

Collapse
 
fluffy profile image
fluffy

The fact that WordPress provides a REST API doesn't mean that its rendering stack uses that internally for its actual rendering. Maybe they've changed that in recent years but last I checked, it's pulling the data directly out of the database when it's doing its own rendering frontend.

My issue with the characterization provided in your animation is that it implies that all server-side rendering works in that way, and that the resulting rendering is going to also be slow as an unavoidable result of that, when neither aspect is true. Even if it's going through a REST API, if it's connecting to itself on the same host it'll be quite a lot faster than what's implied by the additional backend connections.

Basically I feel like in your effort to simplify the explanation of these different things you've actually added more complexity to a situation, by implying that things need to be more complex than they actually are.

Maybe I'm just a curmudgeon for disliking the way that websites-as-apps have taken over everyone's way of thinking though. I like to keep things simple, and have never cared for the artificial split between frontend/backend/full-stack for that matter.

Thread Thread
 
kefranabg profile image
Franck Abgrall • Edited

I think that you're misunderstanding here...

  • I never wrote that SSR was the slowest solution
  • a server with the REST API on the same host does not change anything to my explanations...

I'll repeat myself: I used this architecture as an example as it is the most common architecture nowadays and it was easier to explain the concepts this way.

"I feel like in your effort to simplify the explanation of these different things you've actually added more complexity" : That's your point of view.

Thread Thread
 
jaxxeh profile image
Jaxxeh

Reacting on something fluffy said:

I like to keep things simple, and have never cared for the artificial split between frontend/backend/full-stack for that matter.

I don't agree that the split is artificial at all. It's actually eminently practical to decorrelate presentation from data.

While you're perfectly accurate when you point out that 'old-style' SSR (i.e. Rails, etc.) doesn't necessarily follow the API pattern and pulls data straight from data sources (esp. databases), it's not a pattern I would recommend nowadays, where you might have multiple frontend data 'consumers' (website(s), phone apps, desktop apps, other APIs) for a single data 'provider' (your API, which is really a data aggregator, as you might be pulling data from a variety of sources).

With a monolithic design pattern, you would have to replicate the backend side for each consumer frontend. Admittedly, you could engineer your monolithic design to return, say, JSON as well as HTML and thus turn it into an API in addition to being a website, but that muddles up the whole idea of separation of concerns between data and presentation, which is the opposite of "keeping things simple" as you put it.

Collapse
 
pixelfixer_ profile image
Nooa L.

These animations are way too good. Thank you for this!

Collapse
 
kefranabg profile image
Franck Abgrall

Thanks! ☺️

Collapse
 
leastbad profile image
leastbad • Edited

Also, while Turbolinks ships standard with Rails, any SSR framework developer can use it to achieve lightning fast page navigation without server round-trips.

Collapse
 
donghoon759 profile image
Donghoon Song

Hello! What a nice article! It helped me a lot to understand diverse rendering processes. Would you mind if I translate this in Korean with link to original source and post on my blog? I will leave the link after posting. I will wait for your response :)

Collapse
 
kefranabg profile image
Franck Abgrall

Sure !

Collapse
 
ahmadawais profile image
Ahmad Awais ⚑️

Animations are top-notch πŸ’―

Collapse
 
mynameisgenesis profile image
Genesis

I love the animations and the chart at the bottom. It's crazy because all of this happens within seconds (most of the time lol) but there is still always something faster.

Collapse
 
hoer profile image
hoer

MagnΓ­fico!

Collapse
 
hafidzamr profile image
hafidzamr

wow, thanks sir.

Collapse
 
kefranabg profile image
Franck Abgrall

A pleasure!

Collapse
 
harrypham profile image
Harry Pham

Nice animations and explanation, how do you make these ?

Collapse
 
kefranabg profile image
Franck Abgrall

Thanks ! I used keynote πŸ™‚

Collapse
 
aizkhaj profile image
Aizaz Khaja

This came in just in time of me starting the process of picking a frontend stack. Thanks for a simpler explanation, think I may actually use universal rendering now πŸ˜‰

Collapse
 
kefranabg profile image
Franck Abgrall

Happy that it helped you made your decisions !

Collapse
 
nanouchkaya profile image
Claudine

This is a huge help for my understanding of all these types of rendering. Thank you πŸ™ I do appreciate the final comparisons table.

Collapse
 
kefranabg profile image
Franck Abgrall

I'm really happy that it helped you 😊

Collapse
 
leastbad profile image
leastbad

What about solutions like StimulusReflex and Phoenix LiveView that can deliver highly performant reactive UIs faster than an SPA?

It seems like the existence of StimulusReflex raises the valid question of whether we need these heavy JS frameworks at all.

Collapse
 
sirjoe profile image
Ibrahim Joseph

simple animation with lots of information. Thank you

Collapse
 
raknjarasoa profile image
Njarasoa Rakotozafy

Thanks. Animation is perfect

Collapse
 
kefranabg profile image
Franck Abgrall

You're welcome !

Collapse
 
rcsm profile image
Rafael Cascalho

I enjoyed very much! The article simply clarified some points I've already known, but with clear explanations. Thanks Franck ;)