The React wayThis is where React comes in. It improved the development lifecycle byintroducing components, virtual DOM concepts, and the client-servermechanism.When you access a React website, the client's browser sends a requestto the server for the webpage content. In response, the server sends aminimal HTML file, which serves as the entry point for the entireapplication, along with a bundled JavaScript file.React initiates client-side rendering using this JavaScript file,manipulating the virtual DOM. Instead of directly modifying the actualDOM, React updates the virtual DOM and then applies only thenecessary changes to the real DOM, resulting in the desired pagedisplay.React utilizes its client-side routing library, React Router, to navigate todifferent pages within the React application. This library enableschanging the route without a full server request, preventing pagerefreshes.React Router re-renders the relevant components based on the newURL when a new route is triggered. If the new page requires fetchingdata from the server, the corresponding components initiate requests to retrieve the necessary data.What’s the catch?<b>Complexity</b>Building a React application can present greater complexity thantraditional HTML, CSS, and JavaScript websites. It involves thinking incomponents, managing state and props, and working with the virtualDOM, which may require a learning curve for developers new to React.js.<b>Processing</b>Similar to the traditional approach, react primarily performs client-siderendering. It heavily relies on JavaScript for initial rendering andsubsequent requests to update the user interface, which are all handled on the client’s browser.However, this reliance on client-side rendering can delay rendering andinteractivity, particularly on devices with slower processors and limitedresources.<b>SEO</b><b>Yes</b> , if you recall, we previously touched upon a notable drawback ofReact compared to NextJs in the Introduction chapter.The issue is that search engine crawlers might need help fullyaccessing the website's content since everything is handled throughJavaScript and only rendered on the client side. As a result, it impactsthe website’s visibility in search engine results

Knowing the benefits and limitations of both techniques, Verceldevelopers allowed us to choose where to render the content, on theclient or server.Typically, when a user visits a Next.js site, the client sends the request tothe server, which starts executing the React Components, generatesHTML, CSS, and JavaScript files, and sends back the fully rendered HTMLto the client as a response. This file includes initial content, fetcheddata, and React component markup, making the client render itimmediately without waiting for JavaScript to download and execute.But it doesn’t mean we don’t receive any JavaScript files. The server willstill send the JavaScript code as needed for the user interaction. Fromhere, Next.js takes over and performs client-side hydrationHave you ever encountered the issue of a hydration error where theuser interface doesn't match what was originally rendered on theserver?Well, this is what it is about. Hydration is attaching JavaScript eventhandlers and interactivity to the pre-rendered HTML. And when theplaceholders of React components i.e., div, form, span, don’t matchwhat’s being rendered on the client side, you see that error.This is what it is — The hot topic of web development i.e Server Side Rendering!(SSR) For subsequent requests, you have full control over where to renderyour page content i.e., either on the server side (SSR) or the client side (CSR).

You might be itching to start with Next.js code, right?Although writing code is important, we must first build our foundations.It’ll not just help you in clearing interviews but will also help in makingsound decisions in your application.If your why isn’t clear, you’ll have no idea what you’re doing, and you’llblame it on Next.js by saying that it’s an overrated piece of technology.That will only showcase your lack of knowledge. It's a foolproof recipe toamaze everyone with your impressive ignorance.So, perfect your why and your how will come naturally.Let’s time-travel a bit to see how things were used to work withdifferent technologies.

Websites built using the web's fundamental elements, namely HTML,CSS, and JavaScript, function differently compared to the latesttechnologies.When a user visits such a website, their browser (the client) sends arequest to the server (another computer where the site is hosted)asking for the content to be displayed.Traditionally, for each of these requests, the server responds by sendingthree files i.e., the HTML, CSS, and JavaScript (only if any JavaScript codeis involved). The client's browser receives these files and begins byanalyzing the HTML file. Then, it applies the styles from the CSS file andimplements any user interaction, such as event handlers or dynamicbehavior, specified in the JavaScript file on the webpage.The client will send additional requests to the server if the website hasmultiple pages. In response, the server will send the three filescontaining the respective content needed to render each page.<h3>What’s the catch?</h3><b>Processing</b>Most processing occurs on the client side, meaning the user's webbrowser is responsible for rendering the HTML page and executing anyJavaScript code present.However, if the website is complex and the user's device needs morecapabilities, it can strain the browser and create a burden for it tohandle.<b>Bandwidth</b>As the server sends complete files to the client for each page request, itincreases bandwidth usage. This becomes particularly significant whendealing with complex websites containing numerous pages and videoand audio clips scattered throughout the site.<b>Load Time</b>The initial page load time may be longer when compared to the latesttechnologies. This is due to the complete transfer of files for eachrequest. Only after the server has sent all the necessary files and thebrowser has finished parsing everything will we be able to view thewebsite's content.