Updates using server-side rendering without page refresh - api

Question

I was reading an interesting blog. Here the author said:
Updates using server-side rendering is where a lot of developers start
going off the deep end. They actually think page refresh. Instead,
what I thought we've all been doing for the last half decade, is some
form of:
$('#loadTweets').on('click', function(e) {
$.get('/tweets/person', {last_id: 239393939}, function(r) {
$('#tweets').prepend(r);
});
e.preventDefaults();
});
In other words, we are still only doing a partial update, but letting
the server do the rendering and inserting that finalized output into
our DOM.
I did not understand what he meant by "is some form of:...we are still only doing a partial update".
I mean, if I understood correctly, server sending the html and css on every request is Server-Side Rendering (SSR). Server sending json on every request except first is Client-Side Rendering (CSR).
As far I understand, in the code bellow, if r is json then it is CSR and if r is html then it is SSR:
$.get('/tweets/person', {last_id: 239393939}, function(r) {
$('#tweets').prepend(r);
});
What am I getting wrong here?

Answer 1

Bassed on your definition of SSR vs CSR
Server sending [HTML] on every request is Server-Side Rendering (SSR)
Server sending [JSON] on every request except first is Client-Side Rendering (CSR).
let's try to apply that to the example logically:
$.get('/tweets/person', {last_id: 239393939}, function(r) {
// do stuff with `r`
});
For that I made your statements into this decision table. (I'll get to the undefined cases right away, keep reading.)
First Response?
JSON
HTML
Yes
undefined
SSR
No
CSR
undefined
First, we check whether it's the first request. We can say without problems that it is not, wouldn't the client have gotten the JavaScript earlier it couldn't be running it.
Now let's introduce what type of data is send:
if [response] is json then it is CSR
if [response] is html then it is SSR
The first statement is valid, it would definitely be CSR. But the second one would lead an undefined case. We're deeply confused now!
To address that, let's read how the author defines as CSR and SSR:
With client-side rendering, your initial request loads the page layout, CSS and JavaScript. It's all common except that some or all of the content isn't included. Instead, the JavaScript makes another request, gets a response (likely in JSON), and generates the appropriate HTML (likely using a templating library).
With server-side rendering, your initial request loads the page, layout, CSS, JavaScript and content.
For now, this leads to a similar table than yours, but note how the format/type headers are slightly different!
First Response?
Data as JSON
Data as HTML
Yes
undefined
SSR
No
CSR
undefined
S/He continues:
For subsequent updates to the page, the client-side rendering approach repeats the steps it used to get the initial content. Namely, JavaScript is used to get some JSON data and templating is used to create the HTML.
So s/he's now at the second row of his table, i.e. not the first response.
Then your quote starts (emphasis mine):
Updates using server-side rendering is where a lot of developers start going off the deep end. They actually think page refresh. Instead, what I thought we've all been doing for the last half decade, is some form of [...] doing a partial update, [...] letting the server do the rendering [of the HTML] and inserting that finalized output into our DOM.
With this we can fix the undefined case in the not-first-request-row we have been confused about!
First Response?
JSON
HTML
Yes
undefined
SSR
No
CSR
Partial Update
There is still the first-response-JSON-case, but as the browser cannot generate further requests from this on it's own we can ignore it here.
Hope this helps!