Forem: Michael Friedman

NextJS vs GatsbyJS - What's the diff?

Michael Friedman — Fri, 16 Aug 2019 18:54:16 +0000

First off, thanks for taking the time! If you're interested in Next.js and the JAMStack in general, I've got a weekly newsletter, where I share the best bits of what I've been learning recently on the topic. I even dive into some other stuff like what I'm reading and things on the horizon. It's totally free for those signing up now, so if you're interested you can sign up at michaels.blog

During my last post, I touched on some of these frameworks' critical features. Today I'd like to make a complete assessment and discuss some of the essential differences and nuances between the two. Let me start by saying that this is not an opinion piece on which React framework is the best. While both of these frameworks could sometimes be used to hit the same target, they excel at very different things and have different costs associated with their implementation. My experience working with NextJS also runs more in-depth, so I'm able to offer a little more insight. I intend to provide some context to make a more informed decision when you are architecting your next stack. I believe that between the two of these frameworks, you can fulfill just about any user story.

NextJS

What is it?

Next.js is a React framework that requires very little boilerplate to configure. Its most significant selling point is the serverside rendering (SSR) that it provides right out of the box. NextJS is developed by Zeit, which is an entire serverless ecosystem built on top of AWS Lambda. NextJS takes advantage of serverless technology to serve your application pages in a swift, reliable, and affordable manner.

Serverside Rendering

Serverside rendering is a topic on its own, but I will say that it's essential for almost any project where being found on the internet is of vital importance. Startups and tech giants alike are often opting for SSR when given a choice. This is because there is a tremendous difference in search engine indexing results for a single page (SPA) vs. SSR apps.

Have you ever used Create React App (CRA)? If you are a React developer, I'm guessing the answer is yes. Have you ever inspected the page source only to see the single div element that your application is rooted too? That's when you usually bust out the React Dev Tools extension to explore your application markup. Unfortunately, Google doesn't know how to crawl your application with React Dev Tools (although hopefully one day).

That only leaves the metadata for the search engines to discern what sort of content is delivered. While convenient, this SPA approach is not nearly as effective for search engine optimization (SEO). A site that loads the page already filled with a mass of relevant content and markup has a significant advantage.

Dynamic Clientside Routing

With Next.js, we render the markup with a Node service and return it to the client. There are many benefits to doing this, the big one we have discussed thus far is SEO, but there are also tremendous performance benefits to properly implemented SSR applications. Allowing a server (or function) to render your project, takes the most cumbersome work off the client, which almost always makes things a lot snappier. Next.js abstracts the process of code splitting, eeking out even more performance wherever possible in your bundle. That's all handled under the hood with some very sensible defaults that allow for easy customization.

Dynamic API Routing

One of the things that I love most about Next.js is how it handles dynamic client-side routing based on your application file structure. Even to those unfamiliar, it's incredibly intuitive. Rolling a proxy for routing an application like this is not an easy task, and Next does a genius job of handling all of this work for us.

The effectiveness of this API benefits significantly from the release of React Hooks. Now NextJS offers us a useRouter hook, which keeps our clientside routing even cleaner by not forcing us to nest our components in a higher-order routing component every time we want to make a clientside route change.

As of this latest major version (Next 9.0), we can use the same approach we do for clientside routing in NextJS on our backend. Just mkdir api in the pages directory of your project, and Next will build your API routes to match the folder and file structure, just like it does on the client. That makes pretty URLs and dynamic page generation easier than it ever has been.

TypeScript Support

NextJS will automatically support TypeScript files in your project. Also, equally important, the framework was just completely rewritten in TypeScript, which is a huge asset to the community. You can now infer a significant amount of safety just by naming your files with a .ts or .tsx extension.

Under the Hood

Already, one of the fastest-growing frameworks in the JavaScript ecosystem, recently, NextJS began receiving boosts of support from very talented members of the Google Chrome team, who are now working actively with Zeit and the NextJS core team to improve performance further. I think this is, in part, a testament to the firm belief that Google has in the future of NextJS, which certainly lends confidence to me when I'm building a project and considering using this framework.

Static vs. Dynamic

Next.js does not dichotomize the choice of dynamic serverside rending or static site generation. Generally, it can be applied to many more use cases than Gatsby.

Clientside Routing

Next.js uses a <Link> higher-order component to wrap anchor elements with additional functionality like the prefetch prop that uses an Intersection Observer to asynchronously fetch your data for linked pages before the client actually requests them. Still, it does so with these requests in a lower priority queue than effects that are executing on the current page, so there is no competition for network resources.

Data

Next.js also pairs very eloquently with AWS Amplify. Amplify will handle authentication for you using AWS Cognito Identity Pools and automatically generate a GraphQL API for your backend and provision it using AWS Lambda, API Gateway, Dynamo DB, and CloudFormation. If all of those things are foreign to you, rest assured, that's the beauty of Amplify; it handles all the infrastructure so that you can focus on your API. That is what serverless and modern development is all about.

Gatsby

It would be unfair to categorize Gatsby as a static site generator and leave it at that. It behaves much more similar to a fully-featured dynamic React app than anything else.

Without additional configuration, Gatsby isn't set up for applications that handle dynamic data. It prebuilds all the HTML for your pages and links a JavaScript file to it, which is your React app. Any dynamic updates would require rebuilding your application. Gatsby's ideal use case is for projects without any changing data. It is perfect for landing pages, marketing pages, and documentation. I'll add simple e-commerce (small e-comm) sites that can effectively run from a cache.

While you can realistically build just about anything with Gatsby, it does not mean that you should. It's all about picking the right tool for the job, and it's my firm belief that you should use Gatsby for what it's best at which is static websites like the blog I'm publishing this post on, or documentation for OSS and other use cases that can primarily rely on cached content. Don't try to turn it into something it's not; static sites were never intended to deliver dynamic content.

One of the greatest things Gatsby has going is the community of talented developers that have built a copious amount of ingenious plugins, themes, and starters to aid in rapid iteration. However, the Gatsby docs do some comparing and contrasting of these two frameworks, and I think their chart is misleading and more marketing-driven rather than fact-based- so hopefully, this helps shed some light on the subject.

What has my attention in 2019?

Michael Friedman — Mon, 05 Aug 2019 15:46:25 +0000

I mentor a few React developers and often get asked where people should focus their attention while studying to gain the most relevance in today's job market.

This blog post is a rundown where I'm focusing my programming attention, a little explanation as to why, and some useful resources for you to get started with these technologies. If you're not familiar with the modern JavaScript ecosystem and want to get on the fast track now, pay close attention to the following.

React JS (NextJS, Gatsby)
GraphQL / Apollo
Amazon Web Services (Lambda)
TDD
Redux

React

A deep understanding of React is an essential building block for nearly all modern web developers. I won't spend much time here, I'm just going to assume that if you're a web developer or want to become one, you already understand that you need to know React like the back of your hand.

When I was starting, this wasn't a given. The boot camp curriculums often struggle to keep up with the industry trends. I was taught both Angular and React when I was attending Galvanize. For me, the writing was already on the wall when it came to the Angular (that was 2016-2017). Today, I'm comfortable recommending React as the only frontend library/framework you will need in your toolbelt to be relevant in the current market. You're better off knowing React intimately than you would be splitting your time between learning multiple frontend frameworks.

React@16.8 brought us some powerful new API's, that should change the way you create React applications. Gone are the days of classes and lifecycles. Now, we can design genuinely composable interfaces using functional components that allow us to derive our UI directly from the state of the application in a much more flexible and extendible way than ever before.

Next JS

Next is a React framework that gives you serverside rendering for free. Serverside rendering allows the DOM to be fully hydrated on page load, meaning that the code is much more crawlable and SEO friendly than your typical Create-React-App (CRA) application. SSR applications are ranked substantially higher in the search engine indexes because it is much easier for the search engines to glean the type and quality of information that the site is disseminating.

NextJS abstracts a substantial amount of the complexity involved in configuring a serverside rendered application. As if this wasn't reason enough, NextJS has added lots of performant features that prove incredibly useful when developing React apps. The latest version of NextJS now supports TypeScript out of the box, without any additional configuration. Just name your files with a .ts or .tsx and you're off and running with TypeScript.

Gatsby

Gatsby is another React Framework, but Gatsby's specialty is static websites. The JavaScript / React community has rallied around Gatsby and the JAM Stack to grow its plugin library to over 1200 packages. Properly developed Gatsby sites are speedy and remain highly available when network connectivity is interrupted. Gatsby relies on GraphQL to query its API, which has been so quickly and widely adopted.

React Resources

GraphQL

GraphQL is the most exciting advancement in backend development that I've seen innovated during my career as a software developer. It rewrote the book on how modern backends should be architected. It allows our clients to eloquently describe the data that they require to operate, which is a problem that has never been really solved until now. Being able to get all our data from a single endpoint, totally changes how we can think about organizing our data. It also allows for incremental adoption, so it's not an all or nothing buy-in, again contributing to its rapid adoption.

GraphQL Resources

Lambda

We're now in the era of serverless computing. Serving millions of customers for a fraction of what it used to cost means businesses that have not already moved to this model definitely will over the next five to ten years. That includes industries like banking that haven't had an infrastructure overhaul in 20+ years. Monolithic backends are becoming incrementally antiquated. The financial benefits of running a serverless architecture are causing technology giants to rewrite their entire APIs in what seems like rapid succession. AWS Lambda and API Gateway are the core of modern serverless computing technology.

The AWS Cloud Practitioner Certification is an excellent place to start with AWS. I only mention AWS because of its market share. If you have a reason to be on another provider, by all means, learn Google or Azure instead.

One approach is to rely on our colleagues to build fantastic developer tooling so that you never have to see the inside of the AWS Admin Panel. Perhaps a better one is understanding that you should have at least a good familiarity with the cloud.

AWS Lambda Resources

TDD

If you are practicing agile development in the React ecosystem, that probably means you'll likely be using Jest, React Testing Library, and/or React Storybook. Most React shops will expect juniors to have extensive experience with at least one or two of them. Unit testing is something you should have a deep understanding of, this is often overlooked by boot camps.

TDD Resources

Jest
Storybook
React Testing Library
5 Questions Every Unit Test Must Answer

Redux

Wait, but I thought Hooks meant we didn't need Redux Anymore? Not quite. Local state management has indeed improved by leaps and bounds with the release of Hooks in React v16.8. There are far fewer use cases that require Redux; however, many complex applications at scale still need the reliability of a deterministic UI. Familiarity with these technologies will be a pivotal asset to potential employers. It will be one of the things that set you apart as more mid-level or senior in your proficiency.

Redux Resources

Dan Abramov's Egghead Course