Together with my co-founder, Sam Bhagwat, I’m thrilled to announce the formation of Gatsby Inc. Based on the open source project Gatsby I founded, Gatsby the company will make feature-rich and blazing-fast websites easier to build and run.

First of all, if you haven’t used Gatsby yet, what is it? Gatsby:

is a blazing fast static site generator for React.js

is a powerful and flexible modern website framework that simplifies every step of starting, developing and running websites

helps you leverage open source innovations in the React, NPM, and Gatsby communities for your web projects

lets you pull data into pages from WordPress, Drupal, Contentful, markdown—and any other data source you can imagine

compiles and optimizes your site’s code to make your sites lightning fast—even on mobile

Gatsby is used by tens of thousands of developers and organizations and is downloaded nearly ½ million times per month.

Follow our getting started instructions to try out Gatsby in less than 5 minutes!

I’ll get to the new company in a bit, but first, let me tell the story of how Gatsby came to be.

Origins of Gatsby

Drupal and the LAMP stack

I first tried web development 12 years ago during my sophomore year of college. I spent hours setting up PHP and MySQL on my laptop and was ecstatic when the iconic blue of Drupal finally appeared in my browser. Drupal v5 had just been released and I was proud to be learning the latest version of the top open source CMS. I clicked around the admin screens with awe and anticipation.

I spent 1000s of hours building websites with Drupal—I even attempted to build a startup based around Drupal after college. I spoke at several DrupalCons and participated heavily within the Drupal open source ecosystem.

The emerging world of JavaScript applications

But after years of building Drupal sites, I started feeling the pull of the emerging world of JavaScript web applications.

Like most people, I was blown away when I first tried Gmail. How was an application running in my browser faster to load and use than my desktop email app?

During my years building Drupal sites, I’d occasionally cast envious eyes at apps like Gmail, wishing I could work on something like that. But I could never quite figure out how they worked. JavaScript was a second-class citizen in Drupal those days, and I spent 99% of my time writing PHP.

Backbone.js/Node.js/NPM

Then, in late 2010, the initial version of Backbone.js was released. I started playing with it and got super excited because things finally clicked for me: this was how to build rich, real-time JavaScript apps. The next year, I started my first full-time software development job at Pantheon.io and had a fantastic time building the Pantheon dashboard with Backbone.js to support Drupal & WordPress developers. I attended Backbone.js meetups and the first few Backbone.js conferences. Developer excitement online and at meetups was palpable. We could all feel that the world of web applications was starting to change dramatically.

Node.js, then only a couple of years old, was gaining traction fast. For the first time, NPM enabled the easy sharing of JavaScript libraries. Consequently, the number of libraries exploded. With a server runtime and ecosystem developing around JS, more and more web development tools started being written in JavaScript.

The fast paced world of the web was reinventing itself again.

First exposure to cloud-native software engineering

Working at Pantheon was my first exposure to modern software engineering techniques like microservices, stateless services, 12-factor applications, Chef, Docker, Heroku, cheap development environments that mirrored production, continuous integration and deployment, atomic deploys and easy rollbacks with dreams of canary deploys and feature flagging. Product Development Flow became my bible.

I was hooked on being able to ship production code so quickly. Life was good.

React.js

Then in 2013, React.js was released.

I first heard about React from David Nolen’s blog post introducing his ClojureScript wrapper of React Om. I was completely fascinated by his analysis; his identification of DOM manipulation code as a major contributor to application complexity and slowdowns resonated with me. I started reading everything I could find on React and soon became a huge fan.

Early in 2014, I left Pantheon to explore new opportunities. I dove deeper into React and built a number of sample applications and was astounded at how productive I was. Problems that used to take me weeks to solve in Backbone.js took me hours in React.js. Not only was I productive; my code felt remarkably simple. With Backbone.js, I always felt I was one or two slip-ups from the whole application spiraling out of control. With React, elegant and simple solutions seemed to come naturally from using the library. Again, I could feel things in web land were changing in a very big way.

Distributed computing & event sourcing

A friend and I decided to work on a startup idea using React to build data-driven landing pages for sales reps.

During this time, I read two articles that had an enormous impact on me—“The Log: What every software engineer should know about real-time data's unifying abstraction” and “Turning the database inside-out with Apache Samza.” Databases and distributed systems finally clicked for me, and I obsessed over how to implement event sourcing for my startup. The latter article’s elegant critique of caching as an inevitable source of bugs and complexity and its suggestion to use materialized views generated through event sourcing sunk deep.

The traditional batch processing mode of computing—which reached its pinnacle with Hadoop—was taking heavy criticism as more and more applications demanded real-time data processing. The era of Big Data had arrived as the volume of data rolling through systems reached stratospheric levels at large numbers of companies. Kafka and stream processing frameworks like Spark were getting lots of attention.

Designing and launching the initial version of Gatsby

Meanwhile, I was having lots of fun in my startup optimizing my landing pages. I added server side rendering and a number of other really fun performance tweaks while poring over reports from webpagetest.org. Universal JavaScript had arrived and was amazing.

We reached the point where we needed a website for the startup and after having focused on web apps for so long, all of the solutions in the content website world felt out of date.

Spinning up a local DB & server felt like a return to 2006, while template-based site generation felt far inferior to React’s elegant component model.

After some exploration with React server rendering for our app, I realized that React could actually be used as the basis for a static site generator. I got really excited about the potential and started scribbling notes in my notebook from time to time. Eventually, I took a week to build this out and launched Gatsby in late May 2015. To my surprise and delight, people started using Gatsby almost immediately after I open sourced it. I spoke about Gatsby at the React conference in January of 2016 and was surprised at how many people knew about it and were using it.

Growing momentum—can Gatsby be much much more?

Like most open source projects under heavy use, it started getting feature requests. One of the most common requests was how to scale Gatsby to larger sites as well as how to integrate Gatsby with CMSs like WordPress, Contentful, Drupal, and others. I had assumed people just used static sites for markdown or JSON driven sites, but as it turned out, there was a large group of developers interested in pushing the boundaries of what static sites can do.

These developers realized that the scaling and performance challenges faced by traditional CMS-driven sites was difficult to resolve without a new way to build websites. They had watched database-driven sites fail under heavy loads, and had seen slow, unoptimized websites drive away potential visitors.

They also like static sites generators because they easily leverage modern engineering ideas like Git, cheap development environments, continuous integration and deployment, open source innovations, modern JavaScript tooling and frameworks that dramatically improve productivity and developer happiness.

Static sites let you focus on what’s unique to your site—components, data structures, and design.

Limitations of static site generators

But static sites, despite how much developers love them, have never gained widespread usage. They have real limitations in real-world use cases—they can’t handle frequent content updates and can’t scale to large and complex sites.

Rebuild Gatsby on a stream processing architecture to eliminate the build step

As I thought deeply about this problem, it occurred to me that there were strong parallels between this problem and everything I’d learned about event sourcing and building cloud-native applications.