Since its inception in the 1990s, the World Wide Web (WWW) has never ceased to evolve and amaze us all.

At the beginning, websites were completely static. You would insert content into your web pages and these would be served as-is, without any modifications. Then, over the years, the web has become more and more dynamic.

For a long period of time, server-side rendering (SSR) was all the rage. Many languages and frameworks allowed developers to inject data into pages before returning the generated HTML to clients.

Frameworks such as Apache Struts (Java), JavaServer Faces (Java), ASP.NET (.NET), Zend (PHP), Django (Python), Flask (Python), Ruby on Rails (Ruby), and many more fall into this category.

At that time, web browsers were considered as dumb Terminals, merely capable of rendering HTML pages. There were multiple reasons for this state of affairs:

• Desktop usage was still predominant.
• Desktop computers were many times slower than our current smartphones.
• The JavaScript engines inside web browsers were much slower than those we have today.
• The web as a platform was far less capable than it is nowadays.

But SSR was not perfect. For instance, it wasn't network- or mobile-friendly. Server responses mixed data and presentation (HTML/CSS/images), which resulted in an enormous waste of bandwidth.

Applications relying on SSR usually maintained user sessions on the backend, which required more resources and more complex setups for high availability. For example, the JavaServer Faces (JSF) framework maintained the state of the user interface in memory for all connected users.

From a user's perspective, the main drawback of SSR was that most actions and page transitions required full round-trips to the backend and full page refreshes. This was wasteful and far from ideal for good user experiences.

However, as we'll see, SSR has its merits and is still relevant today. But, it has evolved to complement the experience provided by SPA, which we'll introduce next.