10 Rendering Patterns:

# 10 Rendering Patterns: Source: https://www.youtube.com/watch?v=Dkx5ydvtpCA&ab_channel=BeyondFireship ## I. What is a rendering pattern ? - Rendering is a process of turning data and code into a HTML file that can be seen by the users - This can be done on the server or in the browser. It can be done all at once or partially ## II. Different rendering patterns: **1. Static Website:** - In this rendering paradigm, you put together all of your html webpages in advance then upload them as static files to a storage bucket somewhere in the cloud and point your domain name to them - The draw back of this pattern is it's only suitable for website that isn't dynamic where information doesn't change all the time **2. Multipage application:** - The HTML and data is put together dynamically on the server whenever a request comes in from a browser. This means the html response changes all the time - Many of the web app today still use this approach such as: amazon, etc. - Frame works that are used to build multipage apps: PHP, Laravel, Wordpress, Ruby on Rail - This approach works great until the iphone came out. People starting to realize that loading the full page on every changes is not very smooth **3. Single Page Application:** - All the rendering happens in the browser. The server serve a skeleton HTML page then execute the javascript file to render the UI and fetch new required data. - Even though it's a single page app it can have multiple route. Routes don't point to the server, they're just updated by javascript in the browser, allowing fast route transition - However, big disadvantages of this approach is it require a large JS bundle, which can make the initial load pretty slow. Search engine have a hard time understanding the content on the web page since the content is rendered on the browser, not the server, very bad for SEO. - Framework: React.js, Angular, Vue.js **4. Server-Side Rendering with Hydration:** - This approach render inital HTML page on the server, then hydrate to client side javascript afterward to render all other page on client. - We call this SSR today, but the general idea is that the initial load is rendered on the server and other pages is rendered on the client to provide the SPA experience - Framework (Meta Framework): Next.js, Nuxt.js, Svelte Kit - Some draw back of this approach: - You need a server for this approach. Server is costly **5. Static Site Generation with Hydration:** - This is a slight variation of SSR - This approach renders all of HTML page in advance then upload it to a static host like a storage bucket. But like SSR, it will hydrate to JavaScript after the initial page load - Website like this are often called JAMstack site. This has a simple hosting and provide the experience of SPA when changing route - Framework: Next.js, Nuxt.js, Svelte Kit - Drawback: you will need to redeploy your site whenever the data changes **6. Incremental Static Regeneration:** - Same idea as Static Generation. However, the static html files are re-render every (for example 10 second) on the server when the cache is invalidated - Normally for a static site, you can cache everything permanently on a CDN. With ISR, the cache can be invalidated based on a specific amount of time that you can set. When that happens, the pages can be rebuild - This allow you to handle dynamic data without the need for an actual server deployment like you would with SSR. - Drawback: complex to self-host, you will need to find a host like vercel that support this type of rendering. **PROBLEMS WITH HYDRATION:** On the initial page load, the app might feel like frozen, while the javascript is executing to take over the rendering **7. Partial Hydration:** - On a website, javascript may have to process the thing that not visible to the end user yet. It might be visible to the user later on when they scroll down - With partial hydration, you can lazy load the component and serve the component only until the user need to see it - Many tools today support code splitting to break the app into smaller chunks to facilitate lazy loading pattern like this Example: ![](https://i.imgur.com/ztVQpyy.png) **8. Island:** - With hydration, javascrip takes the entire rendering of a page. However, many components are just static and non interactive - With island, you start with a file that rendered static HTML on server then only use JavaScript to render interactive components. This gives you island of interactivities - You might have a page that is fully static, in which case, no javascript bundle needed to be served - Framework: Astro ![](https://i.imgur.com/MOUOgzi.png) **9. Streaming SSR:** - Another way to address inefficient hydration is a paradigm called Streaming SSR. - This allow your app to render server side content concurrently in multiple chunk instead of all at once - Framework: Next.js 13 ![](https://i.imgur.com/T8D5VUS.png) **10. Resumability:** - Getting rid of Hydration. This is a new rendering paradigm - A website and all its data even things like javascript event listener are serialized into HTML, then the actual javasript code is broken into tons of tiny chunk - That means the initial page load is always static HTML, no hydration needed. Any javascript required is lazy loaded in the background - Framework: qwik