Grégory D'Angelo for AlterClass

Posted on Dec 12, 2020 • Edited on Jan 4, 2021 • Originally published at alterclass.io

BEST Framework for React JS (Gatsby vs Next.js)

#react #javascript #node #webdev

Table of content

Introduction
Client-Side Rendering
Why using a React framework?
The BEST React framework
Conclusion
BONUS: Become a React Developer

Up until a few months ago, choosing between Next.js and Gatsby was relatively simple.

Need to make a static website, like a blog where the content doesn't change too often? Cool, choose Gatsby.

Need to build a site with server-side rendering, like an e-commerce store with thousands of items? Great, go with Next.js.

But there have been some recent updates that blurred the lines between those 2 frameworks, leaving developers just like you confused about which React framework to choose.

So I'm going to tell you how to make the right decision to build your next React project.

Let's jump into it.

Introduction

So you want to build a React application, but you don't want to deal with routing, configuration, SEO, SSR, image optimization, or all of the hard and cool stuff surrounding React.

These features can be hard or can take a lot of time to implement on your own.

Both Gatsby and Next.js give you those features out of the box. But they both have their own way of doing it.

They are both popular React Frameworks, and each of them has its own strengths and weaknesses.

So in this article, I'm going to give you some tips to help you choose between the two.

But first, let's talk about why you should use a React framework instead of just building a regular React application.

Client-Side Rendering

You are probably familiar with create-react-app, but if you have never heard of it, this is a tool from Facebook you could use to generate a new single-page React application.

It gives you a modern build setup with no configuration.

Thanks to it, you don't have to learn and configure any build tools, and you can dive right into your code.

It's pretty awesome as you just need to run one command line to get up-and-running. Besides that, you even have a basic folder structure to start from.

Under the hood, create-react-app uses tools like webpack, Babel, ESLint, and other amazing projects to power your app, hidden from you behind a single dependency, making it easier to focus on your application itself.

So you may probably wonder, "what's the problem with that"?

Well, with CRA, you get a lot of configuration already in place for you and a folder structure for your application, so you don't have to worry about it.

And in my opinion, it is one of the easiest ways to create a React application very quickly, and if you're new to React, that's probably the way to go.

If you're just learning React, I would recommend starting with CRA or creating your React app by yourself from scratch and then moving into CRA.

But there are some problems with those single-page React applications.

And it is because they use client-side rendering.

With client-side rendering, when you make a URL request, your browser downloads a bare-bones HTML document, and all the content is entirely rendered in the browser with JavaScript.

Basically, all your application is sent down to your browser at the initial request. And then, React handles everything on the browser, like fetching data and rendering the views of your application depending on the route the user is visiting.

For example, with React, you have this HTML file with all your JavaScript dependencies and a single DOM element, which is the root of your application. Nothing else.

And then, when the client requests a page of your website, your browser downloads that single blank HTML page, loads all the JavaScript included and necessary to run your website, and finally, React renders your website's content by filling the HTML file.

So the first problem you can see here with this mechanism is about speed and performance.

Even if this kind of application is great because you don't have to refresh the entire page when having new data to display, the initial loading of your application can be pretty slow.

Your visitors have to wait for the JavaScript bundle to load and for the browser to build the DOM before any content is visible. Your visitors may see a blank page or a loading spinner while JavaScript is loading.

So that's one problem.

The second problem that comes with client-side rendering is about SEO.

With client-side rendering applications, Google has to run all your JavaScript code before it knows what's on your website and how to index it.

So it can take some time and delay your website ranking.

And, you don't even know if the Google web crawler will run your JavaScript the same way your browser is doing it.

Furthermore, your bare-bones HTML document lacks the keyword, description, and social media metadata necessary for search engine optimization and social media sharing.

React doesn't do this for you out-of-the-box. So you need something to help with that as well.

Why using a React framework?

One possible solution is Server-Side Rendering.

In contrast with traditional client-side rendering, in server-side rendering, HTML is generated and populated with all the necessary data on the server.

This process produces static HTML that does not require JavaScript to run on the browser.

In other words, your application will load much faster and will be interactive a lot sooner.

You will also improve your SEO because search engines can more quickly, reliably, and accurately parse your content and meta tags. This is because the page content is immediately available to Googlebot and any other search engine crawlers.

So server-side rendering addresses both concerns we have discussed so far with client-side rendering applications.

But how do you enable SSR?

You can actually implement it on your own, but it's kind of a pain.

Hopefully, both Gatsby and Next.js use Server-Side rendering, so you don't have to implement it yourself from scratch. It's handled out-of-the-box for you by those frameworks.

So, what does differentiate one from the other?

They are both leveraging SSR but the way they do it is quite different.

With Gatsby, all HTML pages are generated in advance, during the build phase, and are then simply sent once to the browser during runtime. Gatsby websites only contain static files that can be hosted on any CDN or hosting service like Netlify, AWS, or anywhere else actually.

Websites built with Gatsby are very fast by nature since they are already rendered during compilation. This technique is actually called Static Site Generation (SSG).

Whereas, with Next.js, HTML is generated at runtime each time a client sends a request to the server.

The way it actually works is quite different from Gatsby. Next.js is running on a Node.js server. And when it receives a request, it matches it with a specific page (or React component), requests the data from an API, a database, or a CMS, waits for this data, and then generates the HTML based on the received data and the React components and finally sends it to the browser.

But with Next.js, you can also choose if you'd like a specific page to be rendered to static HTML at build time or use regular server-side rendering and generate HTML at runtime on each request.

This is pretty powerful because you can use the best of both worlds, SSG and SSR, inside the same framework. So you could build a website where you have, for example, the blog pages rendered at build time using SSG and render more dynamic pages of your website at runtime using regular SSR.

So that's a considerable advantage for Next.js over Gatsby.

I'd also like to mention the difference in how you fetch data with both frameworks.

With Next.js, you can use any asynchronous or even synchronous data fetching technique, including fetch, REST, GraphQL, or even directly accessing a database. Next.js really does not care about how you do it. It's up to you!

While Gatsby is much more opinionated about how you should do it. It is not required, but Gatsby recommends you and encourages you to use GraphQL as a best practice for structuring and writing your Gatsby applications.

So when building your app with Gatsby, you should access your data through GraphQL. But like Next.js, Gatsby can load data from anywhere, a CMS, a database, through an API, or from the filesystem.

So that's something you should consider when choosing between those 2 frameworks. If you'd like to use something other than GraphQL to fetch your data, you better use Next.js.

But keep in mind that's GraphQL has become a popular alternative to REST for modern web applications. So, you are probably already using it in your projects, but if you are not, working with Gatsby is an excellent opportunity to learn about this powerful technology.

Question of the day: have you already used GraphQL to fetch your data before? If yes, I'd like to hear from you what application you have built with it. Let me know in the comments section below.

Alright! Let's keep going.

Something important you should also consider between those 2 frameworks is the way you will host your applications.

As we've seen, Gatsby only generates static files during compilation. So you could actually host your Gatsby website anywhere you want.

On the other side, with Next.js, you get a Node.js server. So you have to host this node server for your app to run. I believe the easiest way to do it is by using Vercel, which has been made by the creators of Next.js. So, it could be the fastest and easiest way to do it.

Let me know in the comments section below if you have used it before.

But, you can actually deploy your Next.js application to any hosting provider that supports Node.js, like Heroku or Netlify, which I love, by the way!

So that's important. Remember that with Gatsby, you just get static content, which is actually cheaper to deploy than the Node server you get with Next.js. And it may be a bit easier even if today, you won't have any problem to host a Node server thanks to all these great hosting providers.

The BEST React framework

So now, maybe that's why you've been waiting for, let's talk about when to use which.

We have seen so far that both are leveraging pre-rendering.

Gatsby uses SSG, where the HTML is generated at build time and is reused on each request.

Next.js lets you choose which pre-rendering technique you'd like to use for each page. You can create a "hybrid" Next.js app using Static Generation for most pages and using Server-side Rendering for others.

But Gatsby gives you a nice and unified data layer out-of-the-box. In Gatsby, you use plugins to pull in data from any number of sources like API or CMS, and you can query all that data with GraphQL throughout your app. This data layer simplifies the process of pulling data from different sources and providing them in your pages and components.

On top of that, both frameworks add a ton of great features to your applications. But Next.js is probably winning the game over Gatsby with its recent release.

Now, with Next.js, you get automatic image optimization, built-in internationalization, continuous analytics from real measurements, and you even have an all-in-one starter kit for e-commerce that you can use and fully customize.

Even if Gatsby is also providing some of these features (but not all of them) through its plugin system, we can clearly see that Next.js is becoming the best React framework to actually build anything you want.

So, in conclusion, I'll still probably use Gatsby for a purely static website like a blog as it's an excellent framework, and it has been designed from the very beginning to build this kind of website.

And, you have a vast community of people used to build static websites with Gatsby. So it may help sometimes.

But, if I have to build a web app that contains dynamic data, or even a hybrid web app where I need both — static site generation and server-side rendering, I'll choose Next.JS for sure.

More and more of my applications are built with Next.js, but I still keep using Gatsby for static websites as I don't need to deal with Node. And I can use any CDN to create superfast websites.

And what about create-react-app? I don't really use it very often now, but I keep using it for teaching purposes and building prototypes and small applications.

Conclusion

Alright! That's it, guys. I hope you enjoyed this video and get a ton of value out of it. Please let me know in the comments section below which framework you will use for your next React project. I'd be happy to hear from you.

Thank you so much for reading.