Watch the YouTube video here
What is the benefit of using NEXT.JS over React? What does it offer? Before diving into what and why NEXT.JS, first, let’s understand how React JS works.
How React JS works?
Let’s see how react works on a production website. For serving react files to the client, you particularly don’t need a server. You can serve the react website using a CDN (Content Delivery Network) as well. Well, CDN is like a dumb server. It can’t do much computation but can serve the static files to the client. So CDN’s are optimized for file delivery, not for computing.
So on the TCP handshake, the CDN server sends the index.html file to the client. Inside the index.html, it contains a bundle.js script. This file could have been named anything but react names it bundle.js.
This bundle.js contains a lot of code related to the react runtime, JSX & components, router and Page Layout. So the index.html file is almost blank. It is bootstrapped with the help of bundle.js as react is fundamentally a JavaScript library, and now the client should execute the JavaScript to understand how the page should look.
So while using react, the server has a very minimal role in speeding up the delivery of your application. The server can only increase/decrease the Time to First Byte (TTFB), and we are maximizing it by using a CDN. So here, instead of using an EC2 instance or Digital Ocean droplet, it is better to use CDN to maximize the TTFB of your static react application using CDN.
How Next JS works?
It gets pretty interesting when it comes to how Next.js works here. For Next.js to work perfectly in the backend, we use the Node.js process to run in the server, but if you are using Vercel, you can also deploy a CDN as a middle man to maximize the delivery. You can also use the middle man CDN using the AWS serverless Next.js.
But compared to AWS, Vercel is amazingly simple and yet very effective for hosting while working with Next.js.
So what happens when you use Next.js over react here. So as said earlier in the react section, the client has to process the bundle.js to build the initial paint, but with Next.js, the initial document will be rendered to you and then served to the client as an HTML Document.
Server-Side Rendering with React
At first thought, you may think that it might be a good idea to generate the document in the server itself, but here is a problem. The HTML document may also need a revalidation on the client to have the event listeners access the window and other stuff. So it is too expensive to run this in a headless browser on the server and send it to the client.
So what the developers have done is they have developed a react-dom/server so that you can natively export the react-dom into a static HTML to serve to the client, which you can rehydrate.
Rehydrating means that you magically attach all the event listeners to the HTML Blob, which can be rendered in the client.
What Next JS Does?
Server-Side Rendering and Rehydration complexes the part of developing a clean and elegant application faster. This is where Next.js comes in as it abstracts the SSR and Rehydration from you, and on top of it, it can give you additional superpowers as it is running on a server.
So first, Next.js renders the same react application on the server.
So once the rendering is finished the Next.js creates an HTML Blob out of the rendered document. Now you can serve the HTML page, then the JavaScript because HTML runs faster in orders of magnitude when compared to JavaScript in the browsers, as browsers are very optimized to run HTML, and JavaScript is a programming language, it is comparatively slow for the browser to bootstrap the document with HTML. So this is a great way to reduce the delivery time. This method might sound similar to JavaScript bootstrapping for smaller applications, but as applications grow larger and their latency increases, say 200–300 ms, then because of Next.js, you can reduce your time.
The next best thing that Next.js does is, it stores the HTML blob that we have generated in the CDN, so now you can deliver it even faster.
What is CDN and how it works?
As discussed earlier, CDN doesn’t execute much code. Its primary objective is to server the files to the clients.
Now the CDN’s across the earth will have a copy of your HTML blob. It can now deliver it faster to you as it is nearest to you. So that now you don’t need to render the script over and over again to get the HTML blob because when it comes to Node.js, it is a slow language for CPU bound tasks, that means when you are trying to SSR it every time, it may slow you down, so this will intern affect your time to first byte.
Server-Side Generation + Validation
So the most appropriate mix to get the best of both would be to do server-side generation using the Node.js server and then validating it in a specific interval of time in the CDN and then fetch a new HTML blob from the server.
So by using server-side generation, the client gets their application loaded much faster, but what if you want real-time data? Then also, it won’t be a problem. After the page is painted, you can connect to a web socket to get real-time data from AWS or any other provider. So now you have performant, SEO friendly and an application that loads faster.
Why Vercel needs a server?
So remember that we discussed that the HTML blob needs to be revalidated. To manage that revalidation, we need a server. But, if you are using Vercel for serving your application, Vercel internally manages this process. And, if you are hosting this on any other provider, you have to handle this by yourself so that the page can be revalidated at a particular interval of time.
Conclusion
So now you got the idea of how Next.js has the upper hand in managing the server-side stuff over React and why you should prefer to use it over React. This is just an abstract way of how Next.js works in the background to provide the client with the application as fast as possible. If you are new to React.js or Next.js, you might have understood how Next.js works under the hood.
Top comments (0)