Web Rendering Patterns
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
- Upload your static files like html on server and itβs done
- π Not good for websites that frequently update their content
2. MPA (Multi Page Application)
- (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
3. SPA (Single Page Application)
- 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 π€¦πΌββοΈ)
4. SSR (Server Side Rendering)
- 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
5. Streaming SSR
- 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
6. SSG (Static Site Generation)
- 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
7. ISR (Incremental Static Regeneration)
- 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
8. Partial Hydration
- 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
9. Islands
- 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
10. Resumability
- 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