Introduction and Controversy
Hi there. The title of this video is not clickbait. Next.js is not the same as React. So why am I saying this? Well, a few days ago, I sent out an email and a small part of it was taken out of context. It quickly stirred up a big controversy on the official Next.js subreddit and Josh made a video saying that React has been cancelled. This was the part that was posted on Reddit: "Next.js isn't React and you won't get better performance if you use it the way you use React." Let me explain. Those useState, useEffect, and other hooks we're used to are client stuff. We must get rid of that way of thinking completely to build a Next.js application. Now, the controversy was mostly stirred up by the part of the email being taken out of context and some unclear wording on my part, but I'm kind of surprised at how many people reacted to it. Saying "Next is React" is the same as saying a house is the same as bricks. Bricks are essential for building a house, but a house consists of many more elements such as windows, doors, and furniture, just as Next.js extends React with additional features and capabilities. So, in this video, you'll get a no-nonsense straightforward explanation of why Next.js is the future of the web and why if you're not using it correctly, you must start doing so right now. In full transparency, the ultimate Next.js course, which I've been working on for the last nine months, will be released on September 22nd. So without further ado, let's get started.
Why Knowing React Matters — But Next Is More
To be a Next.js developer, you need to know React. React is the base for Next. It's similar to React and JavaScript: you need to know JavaScript to become a React developer. We really can't say React is the same as JavaScript though. It's just built on top of it. Going down that path, we can also say that Next is no different than JavaScript, which is no different than binary code as it all turns into ones and zeros in the end. Now, there were many comments expressing frustration. Comments like this one saying, "Next isn't React. Stupidest thing I've seen all day." And we also had this comment, "But Next.js is React. Looks like someone needs to learn the difference between client and server side React." These comments are not correct, but don't take my word for it. Let's look at some blog posts and GitHub pages from the official React and Next.js documentations. React isn't designed for SSR, at least not right now. They have only shipped the React Server Components in the Next.js app router. And the React team even said that they recommend using an existing framework. Unless I'm missing something, the only way you can use React Server Components right now is with Next 13.4's app router or through a lot of tinkering and other third-party solutions.
Server Components and Framework Support
React team says that server components are still experimental, but you can expect that they release an initial version really soon, but in the meantime, we're working with frameworks like Next and others to prepare for broad adoption. Yet another article says that server components are experimental and are not yet ready for adoption. So use them in your projects at your own risk. So with that in mind, Next.js can handle SSR right now at this moment reliably as a full-stack framework. It's these extra abilities that make Next.js different from React and good for writing server-side code. All of the features added in v13, other than silly naming conventions, were all introduced by the React team. Well, yes. At the end of the day, it's just plain JavaScript. The Facebook team worked for many years to create this library called React that does the same thing as JavaScript with a couple of extra features like creating components, which we can still technically do using vanilla JavaScript. Everything was there when Brendan Eich created JavaScript. Still, React has its unique role. We chose React for a boost in performance thanks to features like the virtual DOM and its improved development workflow. Now, when we talk about Next.js, it's like React on steroids. It kicks up performance several notches and speeds up development even more. The moral of the story is Next 13 isn't React, especially not the React we're used to. So, fully utilizing Next.js means using its server components.
Shifting the Mental Model: Client vs Server
I mentioned that we must change our way of thinking and approach building Next.js applications differently than we approach building React applications, especially the server-side aspects. To which some people immediately said, "Good luck creating a navigation menu without useState or without client components. How can we implement onClick, onChange, or all of that functionality in server components?" Well, if you watched our Next.js crash course, seen our project videos, read our Next.js ebook, or paid attention to this email, you'd understand that the goal is not to eliminate hooks. We still want to use them when managing state, effects, and browser events. Client-side means executing the code on the user's browser. This means that the server sends the HTML, CSS, and JavaScript code to the client. Then the browser executes the JavaScript code and the page is displayed. Server-side means executing the code on the server before it is sent to the user. The server executes the JS code, pre-renders the content, and sends the pre-rendered HTML file. That doesn't mean it doesn't send JavaScript files at all. It still sends some, but a lot less than before. This leads to the page loading faster because the user's browser doesn't have to download a bunch of JavaScript code and execute it to render the page. So, how do you know what to render on the client side and when to render things on the server side? Next.js has made a nice chart to show us where to put our code depending on what it does. If your code fetches data, does backend stuff, or can work on the server, it's better to put it on the server. The only situation where you should use client is if your code uses things like buttons, input fields, and other things that need events, states, and effects, or needs the web browser to run them, then put them on the client side. But there's more to it. Trust me, even if you think it's impossible to render something on the server, there might be a way. I think the best way to explain this is on a real-world example.
So, let's implement a form with Next.js. We all know forms, right? They need to be interactive, handle events, and send data. So, there's no way they can be rendered on the server side, right? Or as one commenter would put it, "server components are useless anyway because practically everything requires a use client." Well, that is not true. As you get better with writing server-side Next.js code, you will get better with transforming things that maybe don't need to use client to use the server. You might have seen it on the masterclass admission modal or the ultimate Next 13 course waitlist form. Here's how it works. Instead of making the whole masterclass page on the client side with "use client," we're only rendering the form or the modal on the client side. The rest of the page can be static and can be rendered on the server side leading to better performance. That's the beauty of Next.js 13 architecture. You can choose where to render even the tiniest element. Now, let's look at our example to understand it better. Let's say you're developing an edit form in plain React. Here's what it would look like. We import the necessary components and functions from our project files and React. We create a functional component called Page. Set up state variables using the useState hook such as message and item. Use the useEffect hook to fetch the data. We then fetch an item using the fetchItem function and update our state and pass an empty dependency array to run this effect only once. Then we have an onEdit function that handles form submission and updates the item. Finally, we have JSX for our component where we create an input to edit the item's name. Looks just fine, right? Well, not exactly. All of this is happening on the client side. And imagine if this was a part of a much larger page. What if we pre-render a part of the code on the server side? That way, we reduce the load of JavaScript code that has to be executed on the user's browser. So, here's the server-side approach and the thinking shift I mentioned before. First, separate the client and server components. Think what has to go on the client versus what can go on the server. In React, this means breaking up the page into components. The result: we have one server page where we import the necessary components, use an async functional component called Page which is a server component where we just at the top fetch an item using the fetchItem function and then render the JSX. Finally, we render the edit form component and pass it the fetched item as a prop. Pretty simple, clean, and easily readable, right? And then this is our client component. It has a "use client" directive, so it's rendered on the client. And then here we do the rest of things as they are: all the states and needed interactions, the state and the onEdit function as well as the form. So what did we do here? We're telling Next.js to render the edit page with the prefilled input fields on the server and send that rendered content to the user. The rest of the content such as the interactivity of the edit form will be handled by the browser.
But why should we do that? Why not just use plain React and do it on the client side? Well, there are many benefits of doing it the Next.js way. Let's cover them one by one. The first one is faster initial page load. Take the example I just mentioned. We already generated the HTML page on the server and sent it to the client. Now the user's browser won't have to make any API calls or execute that whole client-side chunk of code. The browser only has one job which includes those event listeners and hooks. Doing everything else on the server has reduced the time it takes for the client to render or display that initial page. Therefore, the page loads faster. And by the way, if you want me to show you how we built our new jsmastery.pro website with Next, mostly on the server side and our thinking process while building it, let me know in the comments. If many of you request it, the video is coming really soon. Now, the second reason is reduced client-side load. With React, we're doing everything on the client's device. And we're making a big assumption here. We're assuming that the user's device is capable of doing this. Some older phones or PCs with lower processing power will struggle. With server-side rendering, we can lift that burden off the user and do some of the things on the server side. This is amazing for devices with limited processing power. Again, I'm not saying that we do everything on the server side, but I recommend that you render on the server side when you can. The argument against SSR is that devices and the internet are getting faster every day and that is true, but still there are hundreds of millions of people in the developing world and areas with slower devices and internet. Of course, it depends on where your users are. If you have a website for a local sushi restaurant in New York, you don't really need to take into account international users. It all depends on the context. So with server-side rendering, because the server takes the load of executing the JavaScript code, users with slower internet and slower devices can start seeing content more quickly, which is never a bad thing. The third reason to use proper Next.js is SEO. Better SEO means that search engines like Google can understand your website better and recommend it to more users. Think about how often you look things up on a search engine. SEO can make a big impact on businesses and it's one of the reasons I recommend using Next when working on projects for most clients. Client-side rendering has worse SEO because it sends minimal HTML content along with heavy JavaScript files. Search engine crawlers can't understand JavaScript that well. Server rendering is different. The server will send the complete HTML file and minimal JavaScript, meaning that the crawlers read the bigger HTML file, resulting in better SEO. Also, faster initial load speed matters. Google values it as the top ranking factor when deciding whether to display your website or not. There is a reason why so many famous companies including Netflix, TikTok, Twitch, Hulu, Notion, Target, and many more use Next.js. And finally, the fourth reason for using Next is improved user experience. You probably know the annoying feeling of a site taking too much to load, getting frustrated, and leaving the website. This is a bad user experience. Faster page load leads to less waiting time and ultimately a better experience. All of these so far are great, but there's also a slightly more complicated benefit that has caught my attention and that is resource proximity. Let me break it into parts. First, it means reduced network latency. And if you're a gamer, you know what ping or latency is. It's the time it takes for information to go from one computer to another. And when the server makes API calls, these calls are typically made within the same data center. This reduces the network latency when compared to making API calls from the client side. Extending this to something related to databases, we have improved data locality. Simply put, this means keeping the data you need close to where you need it. Server-side resources and databases are often physically located near the server, aiming for faster access to the data. So if we make calls from the server, well, they're closer. And finally, enhanced security. You may have heard that ENVs are exposed on the client side. And a good solution for that is to keep sensitive data and API keys on the server side. And these were just the benefits of server-side rendering in general. Next.js has a ton to offer other than SSR. File-based routing is amazing compared to React Router DOM and we can't forget better loading and error state management. So I truly believe that saying "Next is React" is false and I hope this video helped clarify the differences. Next is the best way to use React in 2023. It's the first recommended framework in React Docs and Docs also recommend not even creating plain React apps anymore. So what allows me to speak about this topic with knowledge and certainty about what I'm saying? I've used Next for every single personal and commercial project ever since Next 13 came out. My team and I wrote a 100-page ebook on Next 13 and we're now extending it to twice its size with new information. And most importantly, I've been working on the ultimate Next 13 course for the whole of 2023. And I'll launch it on September 22nd. It's my best course yet, a project-based course, but a lot more in-depth and much more interactive than my YouTube videos. It will also explain how web dev truly works under the hood and help you get a deep understanding of the web now that AI can output basic code. Next 13 is amazing and there's so much more to learn to truly use its full potential and get incredible performance. So if you don't want to miss the launch, exclusive bonuses, and the launch discount, join the wait list by going to jsmastery.pro/next13 or by clicking the first link in the description. That's all for today. I hope to see you inside the course. And in the meantime, to get you fired up, you can watch the Next.js 13 crash course or build the Threads app. Have a wonderful day.
