Web Rendering Patterns

13 Jan 2023

We find ourselves in an era where a new JavaScript framework was born, bringing exciting possibilities to the web development landscape.

However, its complexity can be overwhelming, especially for those new to the field.

In order to ease this challenge, this blog post simplifies 10 Web Rendering Patterns for your convenience.

1. Static

(MPA) is a type of web application where each web page corresponds to a different url
Whenever a user navigates to different parts of the application, the browser sends a request to the server for a new html, which is then rendered in the browser
Each page has its own html file
😔 Whenever user navigates new page, browser have to request new html, css, js from the server
😔 Less seamless UX

Unlike MPA, SPA loads single html page and all UI changes are made using JavaScript
😔 Since all UI updates requires JavaScript, initial page loads can be very slow
😔 Not search engine friendly (yes, still 🤦🏼‍♂️)

Render html on the server and then after initial page load hydrate client side javascript to make web page intractive
SSR is like MPA + SPA
😔 Server cost

Allows us to send components down to the client as soon as they’ve been generated
With regular SSR, the user has to wait for the entire HTML to be generated on the server before it gets sent down to the client. However, with streaming SSR, components get streamed down as soon as they’re ready, making the UI become interactive faster
😔 May result in more network traffic compared to traditional server rendering, as the browser receives html in chunks instead of a single response

Pre-build your HTML, CSS, and JavaScript files and serve them as static files
Similar to SSR, hydration occurs after the initial page load
This is a great choice when the majority of the website is static. For instance, consider an e-commerce website: while the product page is dynamic, you can pre-render the rest of the static pages on the server and use an external API for the product page to load dynamic data
😔 Have to deploy whenever your static data changes

Allows you to create or update content without redeploying your site
It’s like an improved version of SSG because you have to redeploy an SSG app even for small changes
With ISR (Incremental Static Regeneration), the SSG will only regenerate specific pages or sections of the site that have been updated, rather than regenerating the entire site. For example, if revalidation is set to 10 seconds, the page will be regenerated after the first request at most once every 10 seconds
😔 However, there is no guarantee that the user will see the latest version

Hydrate selected parts of the website instead of all using code splitting
For example, you can keep the footer static until the user scrolls to the bottom, and then hydrate it
😔 However, this approach can make testing harder and cause content shifting

The general idea of an islands architecture is to render HTML pages on the server and inject placeholders or slots around highly dynamic regions
There are independent “islands” to load and hydrate components in isolation, rather than loading the entire application.
This approach appears to be an improved version of code-splitting and may resemble micro-frontends
Astro generates every website with zero client-side JavaScript by default. If your component/page has no JavaScript interactivity, Astro won’t ship JavaScript to the client, even if you build your app with a JavaScript library like React
😔 Relies on each island being independent, which can make it harder to share functionality between islands

Qwik believes hydration can be expensive because a large amount of JavaScript has to execute before the page is actually interactive
Resumability aims to deliver HTML and have the application become interactive immediately after delivering the HTML, basically skipping all the work involved with hydration
All website content is serialized into HTML (data, event listeners, etc.). JavaScript code is broken into tiny chunks, and the initial page load is always static HTML. There is no hydration
Everything is lazy-loaded
JavaScript is not shipped until the user interacts with it. Take a React Counter button as an example. JavaScript for the button is not loaded until the user clicks it
So, how do these multiple chunks of JavaScript files determine when to execute? They know it because of serialization