Next.js and Gatsby

Recently I found myself preparing to onboard to a company that heavily leverages Next.js. As I dug through Next.js' source code and docs, I thought over and over how strikingly similar it is to Gatsby, technically and otherwise. It's not uncommon for open source projects to riff off one another, but these two organizations aren't just similar GitHub repos -- they're also businesses with very similar lines of revenue. Maybe, I thought, this is something worth expanding on.

To be clear, this note is not about which framework to use. 😊

Nextby

Next.js and Gatsby have these things in common:

I want to dive deeper into this last point because it's the distinguishing feature of Next.js and Gatsby. This is how Google defines the PRPL pattern:

PRPL is an acronym that describes a pattern used to make web pages load and become interactive, faster:

  • Push (or preload) the most important resources.
  • Render the initial route as soon as possible.
  • Pre-cache remaining assets.
  • Lazy load other routes and non-critical assets.

This is the meat n' taters of what makes these two projects great. It's also what makes it very easy to go down the rabbit hole when you consider how exactly it's achieved. Watch, let me show you -- here are some associated concepts: preload, prefetch, prerender, code-split, lazy load, server-side render, hydrate. Dizzy yet? Yeah, me too.

Each of these topics is complex enough to fill its own note, so we're not going to touch this unruly list here. Instead, let's focus on this: Next.js and Gatsby use the same technologies and patterns. What's different?

Positioning

Here's what I think sets these two projects apart:

Technically, this is complete nonsense. You can build non-trivial web apps with Gatsby and fast static websites with Next.js. Why then the difference in positioning?

The reason is, the business ventures of these two organizations are trying to capture two different segments of the market. Let's dive a little deeper.

Show me the money

First, Gatsby Cloud. Gatsby's roots are as a static site generator. Gatsby takes your source code, builds everything at compile time and spits out HTML documents (it also does a lot of other stuff at run-time but let's ignore that for now). Through the use of webhooks, you can easily have Gatsby rebuild your entire site every time a piece of content is published to reflect the change.

This is magical. But, it also drew attention to a new problem. The smallest change could trigger a rebuild that took anywhere from a few seconds to 10 or 20 minutes if your site was large enough. This is the problem Gatsby Cloud solves with the concept of incremental builds. In other words, rebuild only the part of the site that changed.

If you think about it, this solution is a boon for a particular kind of content-oriented user, like news publishing sites. News publishing sites are, as we think of them, websites, not web apps. Hence, the difference in positioning!

Next, Vercel, the cloud business attached to Next.js. Vercel, like Gatsby Cloud, is also an abstraction layer on top of cloud providers like AWS and GCP, but instead excels at leveraging serverless technology to do things like make efficient database connections and hook into authentication providers. If you take these two problems and you imagine what kind of software would typically need to solve them, there you have it -- web apps. The target user here is completely different from Gatsby Cloud -- think e-commerce platforms, social apps, anything transaction oriented. From this field of view, Vercel would be a natural fit for web app developers.

One more thing

So we took a brief comparative tour of Next.js and Gatsby. Both platforms are popular, robust and without a doubt represent great advancements in the craft of web development. They're both examples of a new startup archetype of companies that emerge from successful open source projects. Most of all, I love that they make the PRPL pattern accessible by doing all the work under the hood. That being said, there's one idea I always find myself circling back to:

You can't use Next.js or Gatsby if you don't want to use React.

I think there's an opportunity here for a PRPL framework to be built on web standards like custom elements rather than on top of another framework or library. It's an idea I tinker with often, and one I think is worth exploring for the future.

Anyhow if you made it this far, thanks for joining me for the ride! 😄

Thanks for reading! Go home for more notes.