Road to Server-Side Rendering for a Frontend Engineer in 2023

Jayanga Jayathilake
Aeturnum
Published in
4 min readMay 29, 2023

This All started with Sir Tim Berners-Lee’s invention of the World Wide Web (www) in 1989. Which transferred content from server to client as a simple static HTML page. This amazed the public with the technology that prevailed at the time: telegraph, telephone communication, and of course the Postal system. Yet still, it was not that much accessible.

Then in 1995, JavaScript(JS) came into the world with Netscape. But it was not meant to do much work in the process of how presenting content on the web. Because it was just a sidekick by adding more interactivity, and creating animations thus not doing any dynamic DOM manipulation stuff.

After that, we came along with MySpace days, which took more power and raw features to the users thus creating more engagement on the internet with more content. Behind the scene, it was ColdFusion that did the dynamic content rendering. It was a Server-Side scripting language built on top of C and C++ in the initial stages.

From 2004 onwards there was Facebook, which is based on PHP which is another server-side scripting language. With its simple intuitive User Interface and features which can easily be personalizable, it took over the Web and gradually engulf the user base that existed around MySpace.

During the above time period, it was mainly around Server-Side rendering and required a full page rendering to display the page with dynamic content.

In 2005, Jesse James Garrett wrote an article called “Ajax: A New Approach to Web Application” which included the use cases around the new API which loads the dynamic content differently: without full page loads. With this new API, JS got its missing piece to pave the road to the next era of page rendering.

The conventional model for a Web Application versus an application using Ajax by DanielSHaischt, via Wikimedia Commons

After 2006, Google announced their new set of APIs including Google Maps, an update built using AJAX (Asynchronous Javascript And XML). It was in the spotlight as to how that is possible on the web. Showing user search queries along with a map showing the related point of interest for that search result was a great achievement at that time.

Google Developer Day 2007 (Back in the day Google I/O) showing casing their new AJAX APIs for Search, Images, Maps, and Youtube.

Meanwhile, there was the new library that sets new standards in the JS world. Welcome jQuery, the most loved and the go-to library at that period. We can also name that “the React” by that time.

That was quite a ride. From the early days, we had to deal with XMLHtppRequest APIand DOM Selector APIs: document.getElementById,document.getElementsByTagName, and DOM Manipulation APIs, etc…
But with jQuery, it got a more concise and more developer-friendly API, which is $(<css selector>) which ability to do DOM manipulations, Browser Event bindings, etc…, but it also included its own wrapper which is created easier access to AJAX API using $.ajax().
Along with this jQuery have a greater ecosystem and a community.

Then the emergence of more frameworks and libraries came into action, BackboneJS, KnockoutJS, EmberJS, AngularJS, and ReactJS are very few of them. Initially, It all focused on the application structuring for maintainability, DOM rendering optimizations, state management, etc…

With all of that coined the new SPA: Single Page Application along with several component architectural patterns,

  1. Stateful container components and Stateless presentational components
  2. Atomic Design components

are some of the patterns introduced.

Initially, there was no client-side routing that was said to be handled, but with time developers found their way to manage routings based on URL HashChange (as of 2023, you can still find it on Gmail).

Most of them had to bundle up to be served over the internet to the end-user. with that Webpack, Babel, Rollup, and a few others came up.

On SPA, mostly the data was not pre-fetched, so the browser had to wait until the JS scripts were also loaded completely to fetch the data and render with the dynamic data.

This seems to be a bottleneck in several use cases including Web Indexing, Search Engine Optimization(SEO) because it required client-side rendering, Which was not a problem in serving dynamic content using server-side scripts. So developers had to think of ways of merging both eras together to form the ideal solution.

This made frameworks such as NextJS, Nuxt which were known as meta-frameworks also emerge as they provide more efficiency in managing both server-side generation and client-side rendering along with client-side routing. This was made possible using a stage called “hydrate” which does the server-side and client-side binding.

That was quite a ride when we think of the evolution. But there will be more to uncover in the process.

Thank you all of you for bearing with me. Please do comment if you have any suggestions or if I have missed anything in the process.

--

--