What are Pre-Rendering and Hydration in Web Development? A Deep Dive for Devs
Have you ever wondered how Frameworks like Next.js, Gatsby.js, and Remix work? These frameworks use the concepts of Pre-rendering and Hydration, which represent significant advancements in the history of web development. These frameworks leverage the...
These frameworks use the concepts of Pre-rendering and Hydration, which represent significant advancements in the history of web development.
These frameworks leverage these concepts to create toolchains that build efficient web applications. In this article, we’ll discuss Pre-rendering and Hydration and why they are important features to use when building single-page applications.
To understand these concepts, we need to explore why they were created and what problem they are trying to solve. Let's take a look at the beginning of web applications.
Back in the days of traditional server-side rendering, rendering and interactivity were separated. We used server-side languages like Node.js, PHP, Java, and Ruby on Rails.
Within our servers, we created views using templating languages like JSP and EJS. Views are HTML pages, and you could inject JavaScript or Java inside them to add functionality, dynamic data retrieved from database queries, and interactive segments with languages like JQuery.
Global Reach: A Dynamic CDN was needed to cache your dynamic files. CDNs are better suited for static content, but companies like Cloudflare created Cloudflare-Workers to help with the process.
Upscaling Servers: If more users started using the application, there would be an increase in demand on the server. You might have needed to invest more in resources such as scaling up by adding more servers.
You may have duplicate code. For example, if you were trying to validate form fields, you'd have to validate in both the EJS file and your API endpoint.
Let's look at the code snippet below to see an example of this duplicate Logic:
Code in EJS
<form action='/submit-form' method='POST' id="myForm"><label for="email">Email:</label><input type="email" id="email" name="email"/><button type="submit">Submit</button></form><script> document.getElementById('myForm').addEventListener('submit',function(event){const email = document.getElementById('email').value;if(!email.includes('@')){alert('Please enter a valid email.'); event.preventDefault();}});</script>
Code in Express.js
import express from"express";const app =express();const path =require("path");const port =3000;// To received form dataapp.use( express.urlencoded({extended:true,}),);// view engine setup. Need a folder called viewsapp.set("views", path.join(__dirname,"views"));app.set("view engine","ejs");app.get("/",(req, res)=>{// To render the view res.render("index",{errors:null});});app.post("/submit-form",(req, res)=>{const email = req.body.email;if(!email.includes("@")){ res.status(400).send("Invalid email.");return;}// Proceed with form processing});app.listen(port,()=>{ console.log(`Sandbox listening on port ${port}`);});
Traditional Server-Side Rendering had significant downsides, but the introduction of single-page applications marked a new era in web development.
A Single-page application (SPA) is a web app implementation that loads only a single web document and then updates the body content of that single document via JavaScript APIs such as Fetch when different content is to be shown. Allows users to use websites without loading whole new pages from the server.
A popular way to implement SPA is by using React. React lets you create fast applications and simplifies updating the UI more easily than DOM manipulation methods.
It offers several advantages:
Improved User Experience
An SPA loads a single HTML file and dynamically updates the content as the user interacts with it. All of this is done without a full page reload.
An SPA can update the state of the UI easily and provide instant feedback to users based on actions taken on the app.
Reduced Server Load
Most of the work is done by the browser. This reduces the load on the server!
Better Scalability
The browser is now doing most of the work. We can now deploy dedicated servers focused on serving data via APIs. We can easily scale horizontally. We have the option of using servers or serverless functions like AWS lambda.
An SPA can be hosted on a static CDN like Netlify.
With the addition of toolchains like Vite and Create React App to automate the setup of a modern JavaScript application, engineers no longer had to worry about configuring Webpack manually.
There are some downsides to implementing SPAs. The big one is that it relies on the browser to load all the JavaScript and HTML for us. This means that on mobile devices and for people with slow internet, users may experience delays in seeing the page. Let’s examine the flow to explain this:
Several steps are needed for the users to finally see the HTML page.
First, the browser fetches the HTML. This initial HTML will be blank and incorrect. Why? Because the content comes from JavaScript. This means that it takes time for the browser to fetch JavaScript, load it, and execute it. Since the initial HTML is wrong, web crawlers and search engines will not find relevant content on the website and skip it.
Take a look at the below GIF. Here JavaScript is disabled on the Chrome Developer Tools. The website fails to load without JavaScript. If JavaScript is enabled but the internet connection is slow, users may see a blank page for an extended period.
Single Page Application JavaScript Disabled Test.
This was a big problem. This led to Web Development evolving into the Pre-Rendering era.
React components are rendered on the server, and the resulting HTML is sent to the browser. This can improve SEO and initial load times. The rendering process occurs on each page request.
Static HTML pages are generated at build time. These pages can be served quickly without requiring a server to render them on the fly.
Either method is beneficial! Now the HTML that the user receives will be correct. They will see a page with content instead of a blank page as seen using Vite or Create React App.
But there is a problem: the HTML the user receives is not interactive. They cannot click on it or submit a form. How can we add interactivity to our app? By Hydrating properly🚰 🌊!
Hydration is what adds interactivity to our app. It loads the JavaScript that makes our app interactive.
Info
In React, "hydration" is how React "attaches" to existing HTML that was already rendered by React in a server environment. During hydration, React will attempt to attach event listeners to the existing markup and take over rendering the app on the client.
Reconciliation is when React figures out how to update the UI in response to changes in data or components hierarchy.
When components are rendered, a Virtual DOM is created. If there are changes in state or props, then a new Virtual DOM is created. React then uses its diff algorithm to compare the new Virtual DOM with the previous Virtual DOM to check for changes. This is reconciliation.
Based on the changes found, React is not going to update the entire UI. Instead, it will select which elements need to be updated. This article helped me understand Reconciliation.
During the Pre-rendering and Hydration flow, first, the user will see HTML with the correct content.
Then Hydration kicks in and loads JavaScript to give interactivity to the application.
Let's simulate the process of what happens if the Hydration process takes a long time (due to a slow internet connection) or if the user has JavaScript disabled.
Here is a gif where I disable JavaScript on my Portfolio. I created my portfolio using Gatsby a static-site-generation framework (it also has server-side rendering capabilities):
Portfolio JavaScript Disabled Test.
Even though there is no JavaScript, I can still see content on my portfolio. That’s because the user received pre-render HTML! You can see that I cannot click on the dropdown menu items or the buttons that say About Me, Projects, and Experience. That’s because the JavaScript did not load so the user cannot interact with it.
Josh Comeau created a cool mental model for Hydration. Josh calls it the “Two Pass Rendering.”
Info
***The first pass, at compile-time, produces all of the static non-personal content and leaves holes where the dynamic content will go. Then, after the React app has mounted on the user's device, a second pass stamps in all the dynamic bits that depend on the client state.
functionHydrationErrors(){return(<><h1>Hydration Errors</h1><div><p>Today date in milliseconds is {newDate().getTime()}</p></div></>);}
Here, the server will generate HTML with a timestamp in milliseconds. For example: 1724869161034. The Hydration process begins, and then the client loads the HTML. Time has passed and the timestamp is different, it is now 172486193750! This scenario causes the following error:
Mismatch text content from server and client hydration error.
This happens because the getTime() function will generate a different timestamp.
This means that the server and client generate different HTML. The Network Tab shows us the server's response. It is a different HTML from what the client loads.
The server's response below:
Different server html generated.
The client's response below:
Different client html generated.
To Fix the Error:
functionHydrationErrors(){const[date, setDate]= useState<number>(); useEffect(() => {setDate(newDate().getTime());}, []); return (<><h1>Hydration Errors</h1><div><p>Today date in milliseconds is {date}</p></div></> );}
You can use the useEffect hook. Why would this work? Because the HTML that the server and client render will contain an empty date state variable.
Once the component mounts, the useEffect activates and adds the dynamic data from the state variable or you can use the suppressHydrationWarning flag and set it to true.
<psuppressHydrationWarning={true}>Today date in milliseconds is {date}</p>
Everything we have discussed is what all these frameworks focus on.
Static-Site Generation and Server-Side Rendering can be implemented using Gatsby.js, Next.js, and Remix. They focus on creating a pre-render HTML ready for the user to see, then initiate Hydration to add interactivity to the app.
Gatsby.js, Next.js, and Remix do not replace the concept of single-page applications – they add to the process. Take a look at this flow:
Pre-rendering and Single Page Application combined flow. (Source: How NextJS REALLY Works)
It is adding to the current SPA flow! If you did not have Pre-rendering, the process starts where the pink box begins, with an incomplete HTML.
This article is meant as an introduction to pre-rendering and hydration.
Next.js first implemented these concepts with the Pages Router. Pages Router was great and introduced the world to functions like getServerSideProps, getStaticPaths, and getStaticProps to implement Static-Site Generation and Server-Side Rendering.
Info
These implementations had their pros and cons. For example, Josh W Comeau mentioned that with getServerSideProps:
This strategy only works at the route level, for components at the very top of the tree. We can't do this in any component.
Each meta-framework came up with its own approach. Next.js has one approach, Gatsby has another, Remix has yet another. It hasn't been standardized.
All of our React components will always hydrate on the client, even when there's no need for them to do so.
The React team saw this too and created a new paradigm called React Server Components (RSC). To implement RSC, the Vercel team created the App Router. App Router still uses the concepts of pre-rendering and hydration, but it no longer uses getStaticProps, getStaticPaths, and getServerSideProps. It uses RSC and other great App Router features to implement better web applications. I recommend taking a look at App Router when you get a chance.
I learned a lot from writing this article. I started this research because I used Gatsby to create my portfolio version 4 and Next.js in my job, but I did not understand the concepts behind these frameworks and why they were created.
I made a web application to demonstrate the topics covered in the article.
