Andrés Bedoya
Software Engineer
The code that I am going to show you is only code for theoretical purposes, I am not sure that it will work.
# PRESENTING CODE
Web rendering patterns emerged in response to the challenges of building more interactive and dynamic web applications. As web applications became more complex, there was a need for a more efficient and scalable way of handling the rendering and updating of the user interface in the browser.
The first web rendering approach was Server-Side Rendering (SSR), in which the server constructs the entire web page on the server side and sends it to the user's browser.
However, with the growing popularity of Single-Page Applications (SPAs), a new rendering approach called Client-Side Rendering (CSR) was developed.
Static HTML files that were generated on the server and sent directly to the user's browser (SSR)
With JavaScript, it was possible to generate and manipulate content on the client-side, without having to send requests to the server for every user action (CSR)
SSR + CSR = UR.
The goal of Universal Rendering was to offer the best of both worlds: a fast initial load with the ability to dynamically interact with the user
- Static Rendering (SR)
- Incremental Static Generation (ISG)
JAMStack (?)
AJAX emerged as a popular technique for creating more interactive web pages. With AJAX, it became possible to update parts of a web page without reloading the entire page
- React Server Components (RSC)
- Resumability
- Selective Hydration
- Islands Architecture
# PRESENTING CODE
# PRESENTING CODE
# PRESENTING CODE
# PRESENTING CODE
Pros:
Cons:
# PRESENTING CODE
Pros:
Cons:
# PRESENTING CODE
Universal Rendering is a technique in which the same application code runs on both the server and client, which allows for the generation of complete HTML content on the server to be sent to the client. This way, the content is immediately visible to the user and improves the page loading experience.
Server-Side Rendering with Client-Side Hydration involves generating HTML on the server and transferring it to the client, but instead of having all the application code on the server and client, only a reduced version of HTML and JavaScript is sent to the client.
# PRESENTING CODE
Pros (UR):
Cons (UR):
Pros (Server-Side Rendering with Client-Side Hydration):
Cons (Server-Side Rendering with Client-Side Hydration):
# PRESENTING CODE
Pros:
Cons:
# PRESENTING CODE
The Incremental Static Generation (iSSG) pattern was introduced as an upgrade to SSG, to help solve the dynamic data problem and help static sites scale for large amounts of frequently changing data. iSSG allows you to update existing pages and add new ones by pre-rendering a subset of pages in the background even while fresh requests for pages are coming in.
Incremental Static Regeneration (ISR)
Pros:
# PRESENTING CODE
React Server Components allows the server and the client (browser) to collaborate in rendering your React application. Consider the typical React element tree that is rendered for your page, which is usually composed of different React components rendering more React components. RSC makes it possible for some components in this tree to be rendered by the server, and some components to be rendered by the browser 🤯
# PRESENTING CODE
There are certain advantages that rendering on the server has over the browser:
# PRESENTING CODE
The islands architecture encourages small, focused chunks of interactivity within server-rendered web pages. The output of islands is progressively enhanced HTML, with more specificity around how the enhancement occurs. Rather than a single application being in control of full-page rendering, there are multiple entry points. The script for these "islands" of interactivity can be delivered and hydrated independently, allowing the rest of the page to be just static HTML.
Pros:
# PRESENTING CODE
Resumability is a way for a framework to recover its state without re-executing the application components on the client. This is done by serializing not just the application state but also the framework state during HTML pre-rendering. By serializing the component boundaries, event listeners, and reactivity graph, a resumable framework can continue executing where the server left off. The client can resume the execution where the server left off and therefore save itself the cost of re-executing the component tree (Hydration) in order to become interactive. Combine this with fine-grain-reactivity, and the framework, most of the time, does not have to download the components
# PRESENTING CODE