Despite each scrum team being unique and every project different, we still seem to face the same old problems when it comes to the development cycle. Among the most common is the plannin...
Gatsby.js and Next.js – which one to use?
What is Gatsby.js?
As per their homepage: "Gatsby is a free and open-source framework based on React that helps developers build blazing-fast websites and apps."
Its primary focus is to enable high performance by generating static HTML pages. If we combine this with built-in PWA support, getting only the critical assets on a first load and prefetching assets for subsequent pages, we get almost instant loading times. It also has an entire ecosystem of plugins and ready-to-use themes.
Gatsby is somewhat opinionated on how you should provide data for your application or website. Despite being able to handle different data sources like headless CMS, SaaS services, API, or even markdown files, you still need to use GraphQL to put this data into your React app. For a more in-depth feature list, please refer to Gatsby.js documentation. For more insights, you can also check out a great Gatsby.js use case by our React Developer, Mateusz Wójcik.
What is Next.js?
In contrast to Gatsby, performance (though it's still great) isn't the main focus of the Next.js framework. Its goal is to provide an opinionated toolset with which developers can create Server Side Rendered applications or websites with close to no configuration. You can read about all the functionalities in more detail in their documentation.
Next.js gives you routing, CSS-in-JS styling, folder structure, code splitting, data fetching of the box. The best thing is that you can easily customize or even wholly replace each of these elements without a hassle. You can find a multitude of examples of how to integrate Next.js with other tools.
Who is using Gatsby and Next?
You might be wondering which big companies are using those frameworks. It is an excellent question, and the answer is... a lot of them! Here are some examples:
Gatsby and Next: The similarities
Before we talk about the differences, let's see what these frameworks have in common. First of all, no matter which one you choose, you will get a performant website or application, although this outcome is achieved by different means. Additionally, Next.js and Gatsby.js provide good SEO out of the box, since both deliver already rendered HTML (at least on the initial render).
As mentioned in previous paragraphs, we can expect exceptional Developer Experience from either of these toolsets. Additionally, both support hot reloading out of the box. Depending on your needs, this can be a huge advantage over just using Create React App in which you need to handle most of the configuration and architectural decisions by yourself. Because both frameworks aren't that complex, the learning curve is quite small, and besides, they have excellent documentation and tutorials.
Other handy features that Gatsby.js and Next.js handle similarly are:
Gatsby and Next: the differences
OK, so if both frameworks are so similar, then what are the differences between them? There are a few, but the most important ones are how the pages are rendered and how they handle data.
As mentioned before, Next.js renders pages via the usage of Server Side Rendering. Because of that, to run applications made in that tool, we need to use a Node.js server, which will handle the dynamic rendering of HTML upon each request. It all happens in the runtime. After the initial HTML is loaded, Next.js handles hydration so that the application can become interactive.
Gatsby.js, on the other hand, generates HTML during the build time, which is why it is widely considered as a static site generator. It is not entirely correct since it can be used as PWA and handle API calls easily. The main benefit of this approach is that we don't need any Node server to handle rendering.
After the build, we already have HTML/CSS/JS files, which we can host wherever we want. Although it sounds good, this approach also comes with some drawbacks, especially if our website has a lot of subpages. After each data update, a rebuild should be triggered, which will re-generate all the HTML files, and if we have hundreds of them, this process can take quite some time.
Both frameworks have taken a very different approach to this topic. Gatsby.js tells you exactly how you should handle data fetching (GraphQL), while Next.js leaves that aspect entirely to the developer's decision. Because of Gatsby's approach, we will focus on explaining it, since this is what you need to use.
GraphQL enables you to fetch only the data that you need for each page. On the other hand, it ties you to the technology that you might not want to use. Gatsby.js also provides a variety of plugins via which you can connect to a set of different data sources. During the build process, data is fetched and stored in JSON files for later usage. It can also be updated when needed. More extensive docs on that process can be found on the Gatsby.js page.
Gatsby or Next: Which one to use?
For small and mid-sized projects, you can't go wrong with either of those. You have to take the differences into account, especially in terms of the data fetching approach and figure out which one suits your taste more. We recommend using Gatsby if you're building a website based on a JAM stack, personal blog, or just a simple static website. If you don't want to use GraphQL and you're building a more dynamic website or a hybrid app (like Twitter or Reddit), Next.js might be a better choice, mainly because of the runtime SSR.
Things get more complicated if we talk about a large website with hundreds and thousands of subpages and content being added by multiple users. In that case, the clear winner is Next.js because of its approach to SSR. As mentioned before, Gatsby.js generates every page on each rebuild. It can get up to even 20 minutes for a large collection of content. Since users would like to see their added content in real-time and not have to wait minutes or even hours in extreme situations, static site rendering is not a good tool for this job.
As you can see, the answer to our main question is not that simple, unless you're building a big application or website with 500+ pages. As usual, you should always try to pick the right tool for the job, based on its features and your personal preferences. We hope that our guide will help you make this decision and provide you with enough knowledge of the pros and cons of both frameworks, so you'll be happy with whatever you end up using. Would you like to know more? Get in touch at email@example.com