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.
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.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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.
I think that you're misunderstanding here...
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.
Reacting on something fluffy said:
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.