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, i simplified 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 (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 send down to the client.
However, with streaming SSR, components get streamed down as soon as they’re ready. So UI became 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-built your html, css and javascript files and serve them as static files
Like SSR, hydration occur after initial page load
Great choice for where majority of website is static.
Imagine an e-commerce website: while the product page is dynamic, we can pre-render rest of the static pages on server and use external api for 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 improved version of SSG because we have to deploy SSG app even we have small change in the app
With ISR, the SSG will only regenerate the specific pages or sections of the site that have been updated, rather than regenerating the entire site. E.g. If revalidation is set 10 seconds, the page will be regenerated after the first request at most once every 10 seconds
😔 There is no guarantee that user sees the latest version

Hydrate selected part of the website instead of all using code splitting
E.g. we can leave footer static until user scrolls to bottom and when user reaches, we can hydrate it
😔 Can make testing harder and cause content shifting

General idea of an islands architecture is: render html pages on the server, and inject placeholders or slots around highly dynamic regions
There are independent “islands” to load and hydrate the component in isolation rather than whole application
Looks like better version of code-splitting and may seem similar to micro-frontends
Astro generates every website with zero client-side javascript by default. If your component/page has no javascript interactivity, Astro don’t ship javascript to the client at all even 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 large amount of javascript have to execute before the page is actually interactive
Resumability aims to deliver html, and have the application interactive immediately after delivering the html, basically skipping all the work involved with hydration
All website serialized into html (data, event listeners etc.) Javascript code broken into tiny chunks and 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