The Analogy
When I think of rendering a webpage I liken it to creating a piece of art. By happenstance, many of the metrics used to analyze the optimization of various websites happen to fit in nicely with this analogy. Metrics like, First Paint, First Contentful Paint, First Meaningful Paint - all of those are measuring in various ways the speed at which your site and content load onto the page.
In this analogy, we have two key components: the server, the client, and the DOM. In this analogy, the DOM represents the canvas of paint, the client represents the painter, and the server represents the commission request for painting.
Server Side Rendering (SSR)
When the internet was first getting started, just about everything was rendered on the server side. For the most part, this was done because of limitations around computer speed. In these early days of computing, shipping large quantities of information over the web was highly taxing; communication, browsers, everything at that time (as you would expect) was significantly less sophisticated and slower than it is today.
In line with the analogy, all paintings requested from the server were prints and occasionally they were paint by numbers. The server could adjust the painting, but for the most part the painting was already created in templates which are immediately shipped and sent out to the canvas of the DOM for the browser to render.
Some languages, like Pearl and PHP, would create templating libraries where you would inject variables into HTML templates. The template would then render the final HTML with the variables you are using.
There are two key problem with this: You have to wait for the server to render the page (fill in those variables) The greater the burden on the server means you will have a greater challenge to scale and have information update dynamically.
Client Side Rendering (CSR)
As computers and browsers became faster and more adaptable, there was a shift towards client side rendering. Frameworks like React and Angular capitalize on this pretty heavily.
In client side rendering, the burden of dynamic rendering can happen on the front end. Rather than creating a template which the server renders, you make API calls to the backend server which collects specific data and renders them inside your components (I like to think of components as the much more able and modular siblings of those old PHP templates).
This significantly improved the responsiveness of websites, enhancing the overall user experience as they navigate through organisms of modularized components.
In line with the analogy, commission requests were sent to the server and the server responded with a set of instructions (written in Javascript) for the painter to paint upon the DOM. The painter then executes all of the instructions and dynamically paints the DOM with all of the components necessary to fully construct your website.
The downside to this is on the search engine side. Search engines will look at your HTML file and derive the content of your side from that html - with client side rendering, you often will have an HTML file with only one div in in - entrusting the browser to dynamically inject the content off of that single div. Search engines have been improving on this front - which we will discuss in another article.
The Value of Next.JS
Next.js is an isomorphic combination of each of these rendering methods. Next will enable engineers to partition out their sites so they can have all three rendering methods. This allows engineers to optimize their websites for speed, responsiveness, and search engine querying without a tremendous deal of effort.
Using Next, an engineer can render static components which are optimal for search engine optimization, parts which are dynamic are server side rendered, and that everything else on the page is client side rendered. Capturing the key value adds of each rendering method, while minimizing their potential downsides.
In this instance, we have a nice hybridized workflow between the commission requests, the painter, and the canvas. Those aspects of the canvas which require quick viewing and which need to be read by machines (like search engines) will be sent directly from the server. Meanwhile, those aspects of the canvas which are a bit more dynamic will be painted on the fly by the Javascript code executing.