The Great GatsbyJS

Jason, in May some news announced Gatsby.js raised a 3.8 million dollar seed round and is now a startup. Gatsby.js is a static site generator, so the question that leaps out of my tongue is how is a static site generator raising almost four million dollars and gonna be a big business? Just amazing… Can you tell us how that went down?

Yeah, so I don’t have the specifics, because I wasn’t in on the fundraising, but what I think the difference is – this is something we’re struggling with at Gatsby right now… Static site generator - the word “static” is kind of ingrained in everybody’s mind that it just takes something and it spits out HTML, and that’s it. And the reason that I think Gatsby was able to grow into a company that got venture funding is that most static site generators - you take some data, you process it, you spit out some files. What Gatsby is doing is a little bit beyond that, on a couple fronts.

The biggest one is we’re very performance-focused. When you build a site through Gatsby, we’re going to automatically handle your code splitting, your minification, all of the optimizations that need to happen - pre-loading in the background, image processing, so on and so forth, so that the site that you build, without any type of manual performance tuning, is already gonna perform better than most, as soon as you ship it. That’s even more important – I don’t know if you saw here a couple weeks ago, I guess it was not that long ago, there was an announcement from Google that they’re gonna start using mobile page performance as an indicator in your search engine rankings… That’s gonna be a big deal, so that’s something that Gatsby is very well suited to handle.

[04:14] The other thing that we do that I think is one of the reasons people are very excited about it - Gatsby is able to act as a universal data consumer. We can take data from pretty much anything that can expose a JSON object. We can take a database, we can take markdown files, we can take any REST API endpoint, we can even take an Excel sheet, like Google Sheets, and we can consume that and we put it into a central data endpoint, like a GraphQL endpoint. That means that developers, when they’re working on a Gatsby site, they always have a really uniform surface to work on; they’re working in React and they’re grabbing data from GraphQL.

But what that means for content editors - this is where we think the big change is - the content team is working in WordPress, the sales team is working in Salesforce, the developers are writing docs in markdown, and nobody has to change their workflow because Gatsby can consume all of that and make it so that the front-end team is just able to build this amazing site that’s very uniform and a completely cohesive experience, despite the fact that data is coming from all over the place.

I think those are our two key competitive advantages, and I think the reason that people are interested. And the other reason is just I think our long-term vision, which is maybe a bit bigger of a discussion… But just the ecosystem that we want to build around Gatsby as an open source project.

So about a year ago we had the Netlify team on the show, talking about JAMstack, and they’re trying to get this term into the Zeitgeist in order to have people move past the idea of static site generators, which I agree has kind of stuck in my mind at least as like a very specific thing… That being said, GatsbyJs.org does show a blazing fast static site generator. Is JAMstack something that you all are trying to align yourself with?

It absolutely is. Kurt Kemple is one of our developers, and he is famous for making silly stickers; at one point he made socks with Ken Wheeler from FormidableLabs, his face on the socks… Just silly things like that. But he’s currently working on a sticker that is just a jar of jam and it just says “Gatsby is my JAM.” [laughter] That led us to having this conversation about “Can we make actual fruit preserves and make that a part of our swag?” [laughter] Because it just seems like such a fun thing to do, especially because there’s so many pun opportunities. We absolutely need to make the jam stack, so a box of like three jars stacked on top of each other, and then one of them is 100% gonna be called The Grape Gatsby. Come on… [laughter] All of my dad jokes can be funneled through swag at this point, which is about the best thing that I could have hoped for in a career, I think.

That’s interesting.

Now you’re stealing my episode name ideas, so I’m gonna have to come up with something else for this episode…

[laughs]

The Grape Gatsby… Certainly it’s helpful considering all that, which may be where it stems from, but the color purple was your brand color, so… It’s the perfect brand.

It’s so on brand.

Yeah, I mean…

Actually, that had nothing to do with our decision-making. We actually chose that particular shade of purple – that’s Rebecca Purple, which was named after Eric Meyer’s daughter… So it’s kind of a little homage to the stuff that he’s done for the web. We were playing with brand colors, and somebody came up with purple and we were like, “Well, we should use Rebecca Purple”, and we’ve kind of adopted that as like the core of our pallet.

[08:02] So you have big ambitions - static site generators, open source projects… Things like these don’t usually start with the big ambitions. Some people start with a huge ambition. Adam, who’s the fella who’s doing Redox OS? Someone who’s like “I’m gonna write an operating system in Rust.” That is a huge ambition. But somebody who’s going to take some things and process them and spit them out in an HTML - many of us have kind of done that; we’ve ran our own little site generators, so there’s lots of these things… And maybe you weren’t there for the genesis of Gatsby, but do you know – what was the initial ambition…? I’m assuming it was because React was cool, but what got Gatsby started and got it down this path to where now it’s able to have this big ambition of more than just an open source project?

Sure, yeah. Gatsby was created by Kyle Mathews; I think it’s three years old now, and it was right when React and GraphQL were starting to be recognized. I think this pre-dated Apollo. It was on the Relay/GraphQL approach… So we’ve got all the Graph terminology, the jargon, like edges and nodes and things like that. And then it was also because React created this really easy development experience… And Kyle at the time was working at another startup and was just trying to find something that let him have the good React development workflow that he liked without giving up all the control that a CMS would give him.

So he started just kind of scratching his own itch, and over time it expanded and expanded, and there suddenly there was a plugin ecosystem, and people were getting excited… And I think he was very fortunate to have just backed two technologies at the right time to have a good influx of early adopters to help push the project forward, and we had amazing input from people all over… The Facebook team has contributed, the GraphQL core team has been involved in discussions… It was a really good intersection of – like, Kyle is a very good developer, the timing was great for the technologies that he chose, and the community was ready for something that could move beyond the limitations of something like Wordpress.

This was about the same time - I think; I might have my timelines mixed up here, but this was about the same time that headless CMS started to become something that people were really interested in. So it was just a lot of good timing, mixed with a solution that was flexible enough to adapt as people were coming up with newer and better ideas. Now it’s grown into – I think about the time v1 hit, there was just this amazing core group. We had hundreds of developers at that point contributing to the Gatsby core… And that’s about the same time that Kyle started thinking “Hey, maybe this is like a business.”

I can’t remember when v1 was released, but in 2017 was when Kyle and Sam Bhagwat, who is the co-founder, they started really talking about this in earnest and chopping it around and talking to people about their broader vision to get Gatsby funded into a company.

When you think about that - sure, okay, it’s got great uses… But then you’ve gotta think about who’s gonna buy it. So a business is something that actually earns money from sales of some sort, so what is the sales for Gatsby, the dot-com version, the business version?

[11:38] Yeah, so what we’re trying to do with Gatsby – Gatsby as an open source product is not really gonna change; it’s gonna stay open source. Where the limitations of static site generators come in though is that you’re moving from this model where the user requests a page from a server, and that server builds a page and sends it back… And you’re changing to this model where now you have to pre-compile everything ahead of time. And when you’re dealing with a small site, that’s not a big deal, but when you start dealing with tens of thousands of pages or hundreds of thousands of pages, suddenly you’re looking at these build times of five minutes, ten minutes… In extreme cases we’ve seen like an hour to build a static site.

That’s totally fine if you’re pushing to master and then you get to walk away and the changes go live when CI completes, but if you’re somebody who’s editing content, like if you’re not a developer and you’re editing this content and you need to push an article live, waiting an hour for your article to go live, to realize that you made a typo and then wait another hour for that change to go live - that’s not really a feasible workflow.

So what we’re trying to do is we’re bringing in some back-end ecosystems, things that require server resources and things like that, to make sure that people have a ready-made system to build static sites extremely quickly, and that’s the part that we’re selling. We’ve got standard things like enterprise support contracts, so if you’re building a Gatsby site, you can hire us; we’ll come in and consult on architecture etc.

In the future, we’re getting ready to launch an alpha… We are doing cloud-based preview, where effectively somebody who’s non-technical will be able to edit a Gatsby site that’s in develop mode. So when they make a change, they’ll be able to see those changes live, as they make them, rather than having to install it locally and build the site. Then we also want to build an infrastructure that would allow for extremely fast rebuilds, so that an enterprise client, somebody who’s got a Wikipedia size page, will be able to make a change and see that change go live near instantly. We’re trying to create the infrastructure that works around the limitations of statically building sites.

So that puts you in competition with a Netlify then, or not?

I don’t think so, because Netlify is solving a different use case. Netlify is an excellent platform for the vast majority of people who use Gatsby. We’re going kind of further along to very specialized use cases where you’ve got a huge team, and you’ve got a lot of people on the team who are non-technical, who need to be able to edit content and see that content live… So that’s moving outside of what Netlify even does. Now you’re running a server to the side of Netlify, and when they publish, you could still publish to Netlify using this system.

Then if your site grows to where you need extremely fast turnaround – one of the problems that you run into with Netlify is with a big site they have a timeout, and memory caps. So if you’ve got a huge site, you’ll hit their memory limit or you’ll hit the timeout, which I think is around 15 minutes, where Netlify is like “Hey, this exceeds what we’re willing to deal with” and they just kill the container. Then your build fails, and now you have to start it again, you have to eliminate things and figure out what went wrong, and that just makes it a little more hostile to a large team development workflow, where you don’t necessarily want to have somebody who has to just babysit the build all day.

So we’re kind of looking to provide a way to step beyond – like, Netlify is an excellent base use case, and then if you push it too far to one end, we want to have the “enterprise-grade build a Gatsby site” solution. It’s gonna be highly tailored to us, highly tailored to using Gatsby. It’s not something that we think Netlify is really gonna be interested in doing, because it’s extraordinarily coupled to our particular platform.

That makes sense. There’s a lot of these generators out there, as I’ve mentioned before, and then many of us cut our teeth on Jekyll; plenty of people are still using Jekyll today. If you’re publishing to GitHub Pages or even to your own site… I know for myself personally, my blog is still on Jekyll, which is why I don’t write for it anymore. [laughs] Because over time as I got enough markdown files in my repo - it just took too long to compile, so the writing process became painful, and that’s my excuse for not writing quite so often.

[16:12] But when it came to speed, Hugo came around - I’m not sure exactly when Hugo came out - which is a Go-based static site generator, which is blazing fast as well. I’m just trying to think of comparisons, and what makes Gatsby stand out… So there are other blazing fast static site generators, so to me it seems like the big differentiator beyond that is the React and the GraphQL as kind of these core components that are burgeoning and people are excited about.

The blazing fast is nice to have, and is definitely a feature, but do you think people are coming for blazing fast or are they coming for React and GraphQL?

The answer to both is yes, but I think there’s a distinction that should be drawn. Hugo is an extremely fast build, but Gatsby is a blazing fast product. The build process for Gatsby is actually slow. That’s something that we’re actively working on, but compared to competition like React Static, Hugo, we’re actually one of the slower build processes. The blazing fast in Gatsby’s case is that we’ve got such a finely-tuned build pipeline… The stuff that we’re doing with Webpack, and code-splitting and pre-loading and all these things - the site that comes out the other end is basically gonna ace that Lighthouse audit right out of the box… Whereas a Hugo site absolutely can; I used Hugo before I switched to Gatsby a while ago, and my Hugo site did pass the Lighthouse audits, but I had to manually do that.

My Gatsby site - I didn’t have to do any of that manual tuning; it just did the stuff right away, because that’s what Gatsby is optimized to do.

What’s the stuff?

There are a few things that you’re gonna be expected to do to pass the Lighthouse audit. The first one is you don’t want any blocking scripts. You wanna make sure that you’re only sending rendered critical stuff down to the viewport, so basically not rendering anything off-screen. You’re lazy-loading your images, you’ve got the proper code-splitting so that you’re not loading CSS that’s not being rendered on the page, you’re not loading JS that’s not being rendered right now… And all of this is possible to do with Webpack and various JavaScript modules.

What Gatsby is doing is it’s pre-configuring these things. We look at your routes based on your individual pages, and then we can tell (because it’s React) when we do the static rendering, we know what’s on the page, what’s actually visible, and we can split the code accordingly so that you only receive – like, even if your full page bundle would be 2 or 3 megabytes, we can send down 300 kb total of HTML, CSS and JavaScript that gets that initial page rendered, and then in the background we’ll load everything for your About page, or your footer that’s not visible right now, the images that are off-screen… All of that stuff happens after you get to your initial paint, which means that on 3G – the guideline that is put forward by Google is that if your site doesn’t load in three seconds, you’re gonna lose 50% of your visitors.

On 3G I think the last average that I saw was that sites were taking between 12 and 15 seconds on 3G on average. A Gatsby site, on the other end, is gonna take like 1 to 5 seconds, depending on how much stuff you’re putting on the page. That’s just what we’ve baked into the core. Obviously, you can make decisions that will make your site slow. We’ve seen some Gatsby sites that are scoring like 0 on the Lighthouse audit and we’ve reached out to the authors to try to help them figure out what went wrong, but by default, if you follow our recommendations and use the tooling that we’ve built - our image handling and that sort of stuff - your site is going to probably score in the high 90s on Lighthouse by default.

[20:08] That’s a nice bonus.

Yeah, so that’s the differentiation with–

That’s a heck of a distinction, because when I see a blazing fast generator, I think the generation is fast, I don’t think the end product is fast.

When we took the funding, we realized that our messaging – like, our messaging was written for an open source project. We’ve put no time or effort into it. We’re trying to figure out how to explain this in a way that doesn’t – we don’t wanna get hypey, but we also wanna make sure that we’re being clear about what we’re saying… And “blazing fast” is true, but we wanna make sure that people know how it’s true.

There’s a very common misconception that when Hugo is fast and Gatsby is fast, it’s fast the same way, and that’s actually a very different way of being fast.

I’m just looking through some of the things you’re saying here; you’re saying future-proof, at least on the .org… So you’ve got dot-org and dot-com. For listeners, you can see both gatsbyjs.org and gatsbyjs.com. Dot-com is the business, dot-org is the open source. You’ve got future-proof, progressive… I’m just looking at some of the adjectives you’re using here. “Scale to the entire internet”, talking about scaling your servers… Speeding past competition…

Well, not scaling servers; it’s actually removing the need for servers. One of the things that we really wanna do is – because of the way that static sites work, you don’t need a server. You can actually take an enterprise-level application that’s run through Gatsby, put it into an S3 bucket and use CloudFront, or put it on Netlify, or put it on whatever, any kind of CDN, and host the whole thing with no servers.

We just ran a case study on a company called (I think) Escalade Sports; they were paying $5,000/month in hosting. They reconfigured to use Gatsby with (I believe) Contentful as their back-end and some Lambda functions to handle any back-end processing that needed to be done async, and they went to $5/month hosting bill.

$5,000 to $5? That’s crazy.

It was big enough that it surprised me, too. I was like “Come on, that sounds made up.” It turns out that was – they were paying for these big, bare metal servers to handle the server loads for like sale day launches, and when you go to a CDN, the CDN is paying for those big, bare metal servers to handle traffic surges. So you’re basically already paying in your CDN fees for that kind of traffic, and typically, most of us never use it. So basically, we’re all amortizing the cost of big sale day launches for other people on the same CDN… So yeah, it was extraordinarily cheap for them once they cut out the need for those traffic resistant servers.

Jason, let’s talk about some of these moving pieces… I did go through the tutorial today and I npm-installed Gatsby CLI. 211 packages from 105 contributors, so good old-fashioned JavaScript open source; staying on the shoulders of many giants… The three I would name would be React, GraphQL and Webpack. Are there any other huge moving parts that I don’t know about that are dependencies?

I feel like that’s a better question to ask Kyle or Mike Allanson, or Michał I’m going to murder his last name Piechowiak I think it is. They’re the three core OSS maintainers. But yeah, React, GraphQL and Webpack I would say are the three that are most notable.

Yeah, and it’s a huge thing to make it standalone, in many regards, to some of the other offerings out there… So let’s zoom in on the GraphQL a bit, because as I went through some of the tutorials I think this is the thing that stuck out the most to me as being like “Oh, this is novel and different.” And you mentioned it earlier in the call, kind of in passing, where it’s kind of this normalization of data access from disparate sources in the file system; a CMS with a JSON endpoint… All these different places, but inside Gatsby, when you’re actually building your stuff out, it’s like this uniform GraphQL thing. Can you tell us, a) is that a correct assessment, and b) can you tell us more about it?

That’s absolutely a correct assessment, and I think if I had to take a guess on what gets people most excited about Gatsby and why they stay, it’s this. Prior to coming to Gatsby, I was a front-end architect at IBM, and I guess the big project that I did there was I rolled out a GraphQL layer to one of IBM’s products, and it was amazing to watch the shift in velocity for teams that went from using traditional multiple REST endpoints to load data for UI’s, to using a centralized GraphQL service as the way to get data. It just fundamentally shifts the way that you build front-ends, because there’s this context switch when you go from writing a bunch of async calls to load data, and then you’re doing data munging, and then you’re getting it somewhere where you can actually access it. That’s a whole different set of critical thinking that breaks your flow when you’re just trying to get data onto the screen.

So when we rolled out GraphQL as a service on these teams in IBM, we saw things that were taking six months or more than six months to build - suddenly, these timelines compressed to like six weeks, and a lot of it was because the developers were no longer switching context. They were looking at GraphQL, they would define the – I mean, GraphQL… The way that it’s easy to describe, but it isn’t technically accurate… But you basically write an empty JSON object, and what comes back is just that JSON object with values attached. There’s more to it than that, there’s a little more nuance in there, but fundamentally, as a conceptual model, that’s how you’re working.

The developers who are working on the front-end, they just say “Oh, okay, so I’m building this UI. I need this data.” They describe that data in a GraphQL query, and then it’s available. They can test this in a user interface - it’s called GraphiQL - or they can use… The Prisma team has something called GraphQL Explorer, I believe, which is a great tool. You do this right in the browser, and then you drop that into your code and it just works.

[28:00] You’re no longer writing async requests, you’re not dealing with any of the AJAX stuff that usually trips people up… It’s a really, really powerful thing to do. Gatsby takes that and kind of moves it to the next level, which is now instead of having to do all of that work of building a GraphQL layer in-house, you’re able to do that through your build tool.

I think the Gatsby ecosystem is now over 300 plugins. Many of those are source plugins, so you can get – I think there’s a Contentful plugin, and a GraphCMS plugin, and a Wordpress plugin, and a Drupal plugin… So that you can, at build time, pull in those endpoints and say “Hey, I want all my Wordpress data” or “I want all my Drupal data.” That comes in and then shows up in a GraphQL endpoint, and as a developer, you didn’t have to do anything. You just went and found your API token for whatever service and dropped that into our plugin, and now you’ve got it.

The documentation on how to create source plugins is pretty straightforward. I’ve just had to create one for Shopify’s Buy SDK that was compatible with version 2. I think it took me like a couple hours, because the documentation is like “Okay, get an object, drop in the object, and alright, you’re done.” There’s nuance to that as well, but overall, it just eliminates this whole category of what effectively feels like busy work when you’re trying to build the UI.

I think once you’ve worked that way – recently, after using Gatsby for a while, I went back and maintained one of the other sites that I’ve built just for fun, and it’s got this kind of like async fetching layer that’s pulling data from all these different places, and I was like “Oh, this is a nightmare. I should just convert this whole thing to Gatsby so that I don’t have to do this anymore.” I feel like it really spoils you once you get in and just see how much nicer it is to work with.

So in the case of something like Shopify or something like that, you’re saying that Wordpress - or pick your CMS or source of data - you can build a Gatsby site on your own, but use Shopify data and essentially build your own storefront with Gatsby?

Yes, we actually just did this. One of my most recent projects was to build a swag store. I just got the boxes today, got some T-shirts and everything… We got custom T-shirts, custom socks, and we needed a way to get these out to contributors. So one of the things that we’re trying to do is whenever somebody contributes to Gatsby - we’re now a funded company; we want to make sure that people know we really appreciate that, and the open source part of Gatsby is still super dependent on the open source community… Because we’re never gonna keep up with demand for open source.

We wanted to come up with a way to give back, so I built a store using Auth0, Shopify, GitHub, MailChimp (I think that was it), and we made it so that anybody who contributes to Gatsby gets automatically invited to be a maintainer on the org, so you can review and merge pull requests and stuff, because we wanna give the power to the community. Then we also automatically qualify you to get a discount code to claim for a T-shirt or socks.

Through the Shopify store - we built the store with Shopify, but then we pulled in that data to Gatsby, and then I built just kind of like a really, really simple API that creates a Shopify customer to whitelist you. So you log in with Auth0… Once you get into the authenticated part, it’s just a React app. Gatsby doesn’t do anything there. It’s basically identifying “Oh, once you get to /account, it’s a React app. Let it be just a React app.”

[32:06] Then on the front-end we’re loading in the Shopify products, displaying those, and you can add them to your cart, checkout all the same way that you would through a Shopify store, but it’s all being done through a Gatsby/React-based website.

That’s exactly our intention - to make it so that literally anything that exposes an API where we can get at the data, we can then consume and put into Gatsby so that you can build a static site out of that data.

What happens at product modification time? Say you have this exact setup, and maybe each product, each T-shirt has its own page on your site… So at build time, Gatsby would basically do the GraphQL query or whatever that middle layer is in order for you to write your GraphQL query, and get the product information looper over those and generate a page. What happens when somebody goes into the CMS, into the Shopify side and says “This is no longer for sale.” Doesn’t Gatsby have to rebuild in order to reflect that in the static site?

It does, and Shopify has webhooks… So the Gatsby store right now is built on Netlify. So I went into Shopify and hooked up webhooks so that whenever somebody edits the Shopify store it triggers a rebuild for Netlify. So at the speed of rebuilding the Gatsby site - that one takes a couple minutes because it’s pretty small - then the interface will update with whatever changes.

If it’s incremental builds though and it’s just content, you could probably skip over a lot of the other stuff that’s like minification, munging, things that typically take CI processes, which you mentioned earlier, a long time if you have larger content sites… Like, why rebuild the whole thing when you can just rebuild that fragment or that portion?

That is exactly what we’re working on right now. It’s something that we’ve wanted to do for a long time, but we didn’t have the space to do it. Funding gives us the ability to dedicate people full-time to it, and we have a great team of open source people who are working – we basically have a combination of open source contributors, full-time people at Gatsby and a couple contractors to solve specific problems.

We hired Tobias from Webpack to help us solve some key Webpack problems, and we’re trying to use the funding from Gatsby to give back to the open source community… Like, we have a problem? Cool, hire the person from that project and pay them to solve a problem that makes their product better and helps us solve an issue that we’re overcoming.

To answer your question in a single sentence, incremental building is ideal and we’re working toward it, but we’re not there yet.

Who’s competition for you? For one thing, it’s a business now, right? You graduated from open source to funded, proving out a business model. You’re a business, but from what I can tell, you’re not quite selling yet, so you’re sort of proving the model of what to sell, so you’re still in that “Will we survive” stage, potentially… And you can answer yes or no to that, but… Once you get past that, do you have competition? Who competes with you? Are you in a blue ocean?

I mean, I guess it depends on what we ultimately end up offering for sale. It feels very blue ocean in a sense, because Gatsby has some maturity that a lot of other projects in the ecosystem – they just haven’t been around this long. That being said though, there’s some really exciting stuff happening in the Vue space; we’re seeing things come up there where we’re like “Oh man, we should build that.”

[35:47] So I think that we’re gonna see some stuff… I think VuePress is one of them, there’s a – I can’t remember the name of it right now, but there’s like an e-commerce Vue platform that’s offering a really similar kind of solution to what Gatsby does… We were like, “Oh man, that’s also a really good idea.”

I think there’s not a ton of competition now, but we’re seeing things coming out. React Static is an excellent tool. We’re seeing just some really, really fast builds; the stuff that Tanner is working on is really exciting… So there’s competition, but there’s no formal competition. I don’t think there are businesses that are specifically pursuing like “Can we auto-generate massively performant sites and do this at scale?” I think that that is a very, very limited window though, because I think it’s coming.

Jerod, maybe this is more of a question for you than it is for Jason, but have you seen anything out there like Gatsby where it’s like “Hey, we’ll be the one way to build front-ends and one way to build websites and you can get your data from anywhere”? Is there anything else out there like this?

I don’t know…

Everybody seems to be like “Come into our camp”, whereas Gatsby is like “Play in whatever sandbox you want to, we’ll just be your front-end and the way you build your site, and we’ll be partners with anybody pretty much out there, rather than competition.

Yeah, it might be unique, it might be things that we don’t know about.

There’s some companies that I think are doing similar things, but… So Apollo or Prisma are interesting models in the same way, where they’re like “Yeah, we don’t care where your data comes from. We just wanna make it easy to use.” What I think is unique about Gatsby is that Gatsby is kind of spanning all the way in the back, like “How do we get data?”, all the way to the front, like “Here’s how you display data”, and I think most people are either doing one or the other.

We’re not unique, I think we just are in kind of a very niche space. We do the same thing as some companies and the same thing as other companies, but I don’t think there are any companies that do everything that we do.

Same, but different. Let’s go back to this idea of the webhooks and retriggering builds. Of course, when you get your incremental builds out there, then everything will be faster and maybe you can even just have your site rebuilt once every five minutes, come what may… But what about when you’re trying to integrate with a CMS that doesn’t have the hooks that Shopify has, or GitHub has? I don’t know if Google Sheets has the ability to trigger a thing when you update spreadsheet data… Are there situations where you’re kind of hamstrung because you can’t ping Gatsby and say “Hey, rebuild”?

Yeah, and we tend to just solve that problem with a hammer… You know, we just set up cron jobs. We’re finding it’s not as common as we had feared to have sites that just don’t play well with webhooks.

The thing that’s really nice about the modern web - I feel like companies are much more open to the idea of being part of an ecosystem, instead of being the ecosystem. Back in the day, before Wordpress made the decision to become a headless CMS in addition to being just a CMS, it was kind of like “Hey, if you’re gonna use Wordpress, you’ve gotta go all Wordpress.” And Magento was kind of like that; if you’re gonna use Magento, your data is in Magento, your front-end is in Magento, and I don’t even think they – they might have plans, but I haven’t seen a Magento API, so that you can get data out.

Let’s face it, if you’re on Magento, you’re probably never gonna get off Magento… [laughter] That’s where you are, and that’s where you’ll live for the rest of your days.

But then in contrast, you’ve got companies like Shopify… Shopify is like “We don’t care. We’re gonna handle your products and inventory and we’ll process orders for you. If you wanna display it through Shopify - great, here’s some tools. If you don’t - great, here’s an API.” Contentful, GraphCMS - they’re all doing the same thing, these open CMS’s.

[40:04] And then on the back-end you’ve got things like Netlify, where Netlify is like “Yeah, we wanna host your stuff, but we don’t care where it comes from, as long as it’s like files.” And I think that’s really exciting, that companies are starting to realize that specialization and collaboration is really the trick, because then we can all deliver one piece of a fantastic experience without having to also deliver every other piece of that experience… Because you know, we’ve seen it happen over and over again - you’ve got a thing that does one thing really well, and then you try to make it do all of the things so that you can be competitive in the market, and inevitably, all of these others things suck. Or your main thing starts to suffer, because you’re diverting too many resources to the other things. I’m really happy that that’s no longer like a default business model.

It seems like the ultimate “sample it wherever you want” mentality, where like if this is the way you build your site but you can get your data and things from anywhere else, when Shopify tanks - which it never will, of course, because it’s awesome and it’s ran by a phenomenal team… But let’s say it changes its business model to something you don’t agree with and you wanna move to something else, well you could probably do that so long as you’re willing to do all the product movement, stuff like that, but just point your site to a different place for your data and you can easily move to something new, or sample the most modern way to do things. It seems really logical, but it took a long time for somebody to come up with this idea of Gatsby.

Yeah, I think it’s one of those things - it fit a need at the time when that need was capable of being met… But it opened such exciting possibilities. For example, if you had a Wordpress site and you just had years and years and years of Wordpress content but you wanted to migrate over to a new CMS, traditionally you would have to find a way to do that migration. You’d have to get a dump of your Wordpress database and shape it to whatever the new CMS’s thing was… And of course, a lot of CMS’s are gonna offer that Wordpress import, but with Gatsby you don’t even have to do that. You could just import the Wordpress stuff and build it into your blog, and then import the new CMS stuff, and like New Post from that blog get built in the exact same place, and time goes on, and that’s it.

So it just opens these amazing possibilities where you don’t have to throw away parts of your tech stack to do other things. You can have a consistent web experience and completely change the underlying pieces, without the introduction of tremendous tech debt. I mean, obviously, there are ways you could create tremendous tech debt, but if well considered, you can shave off a lot of migration paths in huge projects to move old content that’s not really important (but is too important to throw away) to a new stack just so that it can be archived there.

You’ve got some examples on your site… Are there any outliers or anybody that’s maybe known to our audience (a very developer audience) that is already using Gatsby to do some really cool stuff? Like you’d mentioned, the $5,000 hosting bill to $5 - anything that’s similar to that, where they’ve been able to prove a lot of what you’re saying?

Yeah, a couple cool example… One that I love is the React Docs are using Gatsby. They’re doing things like using different Netlify branches or deploy previews as a way to show different versions of the content. So rather than having to build like a full separate instance of the site, they just grab a commit, and that commit becomes the frozen in time version of like the React version 15 docs.

[43:50] Another really cool example is - I hope I’m getting the name right - Escalade Sports. They built a site called CajunBowfishing.com, which uses – I don’t know if it’s Salesify or Salsify, but it’s like a product coordination thing… It sounded very powerful, and it was clearly something that I didn’t quite grasp how they did it, but it coordinates product data from all over the place… So they’re pulling this archive of data from all over the place and updating their site without having to rewrite a bunch of their back-end.

Or even like kind of a silly example… Ryan Florence of React Router fame has recently started this business called Workshop.me. He didn’t really want to deal with a CMS, so he has people submit workshops to him through a Google Form. That Google Form puts the workshop data into Google Sheets; he does minor edits and then rebuilds his Gatsby site using Google Sheets as the data source. So he doesn’t actually ever have to transfer data anywhere. People write down what they wanna do, he makes sure that he’s cool with that being on the website, and he hits a button and it goes live for him.

It’s kind of like, you know, use data the way that it fits into your workflow. You don’t have to jump through hoops, you’re not doing copy-paste anything; you just keep it where it lives and put it on the internet the way that it suits you.

So Jason, with all things surely it’s not all rainbows and unicorns… I know we’ve been talking about the stuff that gets us excited, and I’m excited about Gatsby - it seems like there’s tons of potential here - but being so close to it, I’m sure you know some of the warts, some of the drawbacks, some of the cons… I’m gonna provide a little bit of a balanced perspective here, because we’ve been getting hyped up, or at least I am personally listening to all this stuff that you can do - especially the GraphQL layer is really awesome - but what are some of the places where Gatsby lacks, or there’s holes or headaches in using this technology?

Sure. I think the places where we’ve been seeing the most struggles are what we were talking about with build times… That’s probably the biggest, most obvious pain. As your site grows, and as you see more and more content coming into it, you just see the build times start to grow, and sometimes we’ve been seeing them grow non-linearly, which we’re trying to figure out why.

We’ve got a PR open right now where Kyle – he’s calling it his Hulk Smash PR, and he’s just been working on a ton of different build time optimizations… A lot of improvement is coming, but for the time being, builds are still not as fast as we want them to be.

[48:01] It can be difficult to use Gatsby on a mixed team. So if not everybody on the team is a developer, it can be challenging to work through some of the initial setup, so that people who are doing content are able to see what’s happening when they edit that content. That’s something that we’re aiming to fix in the future, and that’s gonna be one of the Gatsby Inc. commercial products - you get an account to preview things live, without having to use any code.

Another one that we’re struggling with is some of the more advanced use cases… We don’t have a good internationalization story. You can do it, but basically you’re rolling your own solution when you start doing internationalization in Gatsby. So we’re trying to figure out, is that something that Gatsby itself should have an opinion on? Should we have an official Gatsby internationalization plugin that solves that problem for you? And then, you know, when you get in the depths of our really low-level things, the documentation just isn’t quite finished… But that’s a big focus of ours, and we’ve got multiple people who are working really hard on docs. Shannon Soper is managing an information architecture overhaul of our documentation, she’s finding the gaps in it and making sure that it’s actually meeting the needs of the people who show up on the site. But in the meantime, you’ll find some gaps, and if you get down into the low-level APIs, you’re gonna be like “I have literally no idea how this works”, and you’re gonna find yourself reading source code to figure it out.

A lot of it is edges that we haven’t run into yet… You cross that edge of the map and now you’re building it yourself, you’re back on your own. That’s pretty standard for any sufficiently advanced use case, but some of them feel like they shouldn’t be advanced use cases. Internationalization should not be an advanced use case.

We don’t have a great accessibility story. We do the basics. We run the JSX Accessibility plugin in our ESLint config, and we’re trying to do things like that, but we’re also trying to figure out – like, we were in talks with Leonie Watson about how can we make it so that when you navigate between pages, screen readers will actually announce a page change. That’s a pretty classic problem with single-page apps - when you navigate between pages using React Router, there’s no indication to the person who’s using a screen reader that the navigation is complete; they just have to guess, and that’s a problem. We haven’t solved that problem either, but it’s something that we’re working toward, and it looks like Ryan Florence, I believe, is working on something called Reach Router, which I believe solves that problem, so we’re gonna try to migrate over to that to have a better accessibility story inside of Gatsby as well.

Standard use cases - you’ll probably be fine. When you start getting to the edges, you’ll start to see where we just haven’t had the time to work through a standard approach, or we just haven’t had a chance to document things yet.

I think the accessibility bit would be huge, to bake that kind of stuff in, especially now that we have the Firefox DevTools added an inspector, we’ll have better auditing for these things… And accessibility is really hard to get – I mean, performance is accessibility in certain ways, but it’s a hard thing to do well and often, so the more tools gives us the ability to be winners and not losers, you’re gonna empower a lot more people to have much better experiences… So that would be something that I think would definitely differentiate it.

[51:58] Yeah, and I think we need to make that part of like the core technical offerings that we have, because we have amazing people out there… you know like Leonie Watson that I’ve mentioned before, we’ve got Marcy Sutton… There’s this whole group of people doing amazing work in evangelizing accessibility, but the vast majority of us have probably not seen their talks. Those of us who have seen their talks, the vast majority of us probably don’t have time to implement all of those solutions. So if we can bake that right into the technology that we’re shipping – it’s not hard to do, it’s just time-consuming, so we should make sure that we’re making it as easy as possible for people to do this. That’s our entire goal with Gatsby - we wanna make the right thing the easy thing, and we’ve started by doing that with performance, and we wanna kind of expand that to cover additional stories, like internationalization and accessibility.

Well, now you’ve got some runway, now you have some money to spend on these particular things… Tell us about that, ever since the raise happened and the team has been expanding. What’s the money being spent on, how are you expanding the team…? Tell us about that side of things.

Sure. We raised – I think we officially closed the funding in late 2017. I joined up in March, or maybe February, and we’ve only scaled so far to ten people. We’ve got a few contractors that we’ve hired to help us solve very specific problems… So we’re trying to overcome a few different things. There’s the initial challenge of “How do you take an open source project and inject funding into it without alienating the open source community?” That’s one of the reasons why I’m putting such a big focus on – like, I want to make sure that the people who are part of the Gatsby community and the open source community in general are just taken really good care of. The swag store is one of the ways we’re doing that.

We’ve just started a program where me, Kyle Matthews, Mike Allanson, Michał Piechowiak, Kurt Kemple - we’re all gonna do community pairing hours, where anybody in the community can just basically say “Hey, I’d like to pair up with you for an hour.” We’ll get on a video call with you, and ostensibly, we’re gonna work on something Gatsby-related, but honestly, we just wanna help people in the community… So what can we help with? Let’s debug something, let’s get started on your first Gatsby project, let’s build something together… So just try to pay it forward into the community and give back, because open source is the reason that we’re able to do what we’re currently doing, and we wanna make sure that that goes back into the community and that we are spreading as much of that love and appreciation as we can back into the community, as opposed to becoming a place where it’s soaked up. We want the value to stay distributed.

Then we’re also trying to figure out how do we scale properly. We started out by hiring people directly from the open source community, but that has advantages; we’ve got people who are extremely familiar with how Gatsby works technologically, but it has disadvantages - people who work on GitHub are predominantly white males, so we have a disproportionately white male team right now… So now we’re trying to figure out, okay, how do we work with under-represented communities, how do we make sure that we’re reaching out to the right people…

We’ve been in talks with a lot of developers in Nigeria to try to figure out how to get into that community; can we get contractors out of the Nigerian community? We’re in talks with a group in Portland, where I live, called Women Who Code, and we’re attempting to put together some workshops to try to train – so I’m gonna run one workshop, but I’m gonna have somebody from this group work with me as like a TA, and then the next time they’ll lead the workshop and I’ll work as a TA, and the third time I’m not gonna be there at all; they’ll be able to just run that workshop.

[56:08] So we’re trying to train up people in the community to be able to take value out of Gatsby on their own, and hopefully, we’ll be able to hire those people and grow our team in that way. And how do we do that in a way that is sustainable, that’s gonna help us grow and make sure that we’re not tripping over our own feet?

There are a lot of really, really interesting and really not related to code questions that we’re trying to figure out as we scale, which is like both extremely fun, because we get to look at – like, okay, we’ve always worked at companies, and I don’t know if you’ve had this experience, but every company I’ve ever worked at (except the one that I owned), I sit down and I look at the company and I go “Oh, I could run this better. Here are all the reasons my boss is an idiot.” [laughter] And now we’re in this situation where we are that idiot boss, so we get to put up or shut up, like “How are we gonna make the company that we always wanted to work at, and what are we gonna do to make sure that this is a company that not just I wanna work at, but that everybody wants to work at?”

How can we make sure that when we open a job opening, we get flooded with resumes from literally everyone? Every corner of the internet, every different group… We want to be that company, so we’re trying to solve that puzzle. How do we make amazing technology that people are really excited to use? What do we do to incentivize the internet at large to use Gatsby as their technology of choice? And beyond that, how do we make Gatsby into a company that is a model company for the tech world, for companies in general, that is a place that people are excited to work at, that if you say “Hey, I work at Gatsby”, people say “Oh man, I’m so jealous that you get to work there. That sounds so awesome.”

This is the most terrifying and most exciting challenge that I’ve ever had, and I think that everybody in Gatsby right now shares that excitement and terror, that we really wanna get this right on all fronts. I’ve been just ravenously reading books on team culture, how do you make communities welcoming, how do you make people feel safe… I was on Twitter like “Hey, send me books so that I can be less of a jerk to my team and make people comfortable giving me feedback.” I don’t know man, I’m terrified, but I’m also having a lot of fun.

Where does community live at for you? Is there a central place where you do community? Is it in Slack? Is it in issues, is it spread around? Where does it typically happen and how do you get that feedback from the community to know if you’re doing right or not?

It’s largely happening in GitHub issues or Twitter right now. We haven’t really had the chance to think through how to centralize that, because we wanna have a way for people to do this well, and maybe that’s GitHub issues, but then GitHub issues can be a problem because not everybody who can contribute is necessarily gonna be a GitHub user.

We could potentially use something like Discourse… You know, one of those types of community services, but we’re not sure. If you’ve got ideas, I’m all ears, because we aren’t quite sure how to scale properly.

Well, the one idea I’d give - and Jerod, you’ve heard me give this advice every single time when we ask this kind of question, when we have this conversation on community… It’s like, you’ve gotta put a community link in your main navigation. If people gotta find it, search it or ask the question like me, “Where is it at?”, then your first step is shooting yourself in the foot… Because if there’s no community button that says “Hey, here’s where you come to find out where it begins.” Really, that’s your first step there, identifying that.

[01:00:11.07] Don’t mind me, I’m just taking notes in the background… [laughter]

I mean, I do see Discourse as an icon over to the right in the dot-org’s main navigation, but to me, I feel like when you put a community link in your navigation, it’s like an invitation. Then you say “Everyone’s welcome here.” We get this right because I thought through this, and we do have community in our main navigation and we do say “Hey, everyone’s welcome here.” This is where you can hang your hat, this is where you can hang out with fellow developers, ask questions, whatever. You’re welcome here. I feel like that’s a core step to getting it right. If that’s so important to you, that could be a first step for you.

I love that.

But getting it right though, I don’t think there’s any sort of perfect recipe to say “Hey, here’s how we get community focus right” or “Here’s how we welcome people” or “Here’s how we build a company that people are jealous of and they wanna work at when they hear that you work there”, but the pair programming thing is pretty interesting; it gets people on board faster. You kind of knocked your docs a little bit; maybe your docs are not as fully featured as you’d want them to be, but they’re so easy to navigate. I think you’ve done a really great job on that front there.

And in terms of scaling your team - jeez, that’s every startup’s hardest part… It’s scaling, right?

Yeah, I definitely agree with you. I think when I hear this from probably any other startup, I’m like “Yeah, that sounds hard”, and now that it’s me, I’m like “Oh my god, we’re gonna get this so wrong…” [laughter]

I like how you said that’s the most exciting and most terrifying, because that lets you know you’re in the right place. I feel like that’s the perfect combination of doing what you do, what you love, because you’re a little terrified of your day, you’re a little excited about your day, and you’re like “I can get it wrong, and I can get it right.” That’s the fun part.

Yeah, I think that’s where I wanna live in the Venn diagram. The overlap between excitement and terror is probably the best place to be in a startup… And it certainly suits my personality best. One of the reasons I left IBM was because it felt like all the decisions had been made… So being in a startup where almost none of the decisions have been made is significantly more stressful, but if feels like good stress. I don’t wake up dreading my life, I don’t wake up in cold sweats or anything, but I am absolutely every day thinking, okay, well, we get to make decisions today that will echo through the rest of our company, because we’re small enough now and we’re making decisions now that if we don’t get this right, if we build bad habits and hire people while we still have bad habits, this culture is going to implode in the future…

So we need to be thinking, “How do we make sure that everybody in the company is thinking about the company in a way that helps us grow together? How do we become a culture, rather than a collection of people who work at the same place?” And then once we’ve become a culture, how do we make sure that we’re a culture that is headed in the right direction and has the right values?

I feel like there’s a long philosophical discussion about how to define a company’s values and what those values should be, so I probably won’t get into that… But it’s a really interesting and fascinating place to be, and it gives me an excuse to read a lot of books that I’ve been putting off for a long time… So if nothing else, I at least get to do some great reading.

That’s always fun too, whenever you step into a job… Not that you haven’t done this before, but you step into a job to have the feelings that we’ve just talked about, but then also be like “I’ve gotta read…” Because I’ve been in positions like that, where I’m like clamoring for new books to read and consume to do my job day-to-day better, or the future job I’m trying to grow into as whatever I’m doing.

[01:04:07.28] That’s an interesting place to be at too, whenever you’re just like “What book can I read to learn the next thing I need to know to do the next leapfrog, or the next lily pad to get to in my journey of what I’m doing?” That’s interesting.

There was a recent blog post that you all had… We kind of covered a little bit of the learning process, but I thought it was kind of interesting that you had this teacher who kind of covered learning Gatsby in a really interesting way for people who were kind of like from a graphical background. I guess the question, maybe to tie off on for the end of the show, may be how to get started…? For these people it was really easy, because it was very intuitive in a lot of ways; it was speed, a lot of fun stuff in terms of the commands and whatnot… The hot reloading was, you know, let them do something and then automatically see some feedback… When you say “Hey, go learn Gatsby”, what do you point people to and what do you link them up to? What gets people to that first step to say “A-ha!”?

So our tutorial gets a lot of props for getting people to that a-ha moment. I think what we’re trying to do is we wanna get you up and running with something that’s actually a website… And I feel like where I really struggled with computer science and where I’ve seen a lot of people struggle with it is that the beginning stages don’t feel like doing anything; it feels like memorizing stuff… You’re back in high school doing math, and you’re just kind of wondering “When am I ever gonna use this?” So Gatsby – we have really tried to focus on making it so that you immediately start building real things, and the stuff that you’re building is designed to be visual.

We took away a lot of the initial boilerplate in the configuration, so you can just install a starter and run Gatsby Develop and you’re just looking at a real website; if you go in and change one of the files, you see that website update in real time. So it’s a little easier to start to feel the repercussions of what happens when you change code, as opposed to in a JavaScript exercise where maybe you’re just trying to edit an array and get a value out of that array. That’s very useful information, and it’s something that you will eventually need to know as a developer, but it’s not particularly exciting and it doesn’t feel like you’re doing anything until later, when you understand why it’s important. We’re trying to flip that on its head.

We want you to be able to create something now, and when you get to the point where you need to know why something’s important, then you get pointed to the relevant computer science that will help you do that. Did that actually answer your question? I feel like I went on a little bit of a tangent.

It was a good answer… [laughter] I mean, what URL do you start to? Is there a /getstarted?

Yeah, yeah… At gatsbyjs.org/tutorial - it starts from absolute zero. We’ll link you out to what is the command line, if you need that… And if you don’t, then you just kind of skip ahead to the part where you feel comfortable, and we’ll walk you through the process of building a site, loading in data, doing styles, doing everything that you would need to build a functional, production-ready website with Gatsby.

We’ll make sure we link that up. It looks like it’s about seven different steps, or seven different sections with lots of different sections to dive into, everything from components in CSS to building a page with GraphQL queries, transferring your plugins, all that good stuff.

Yeah, and there’s a really cool pull request in progress right now with Shannon Soper and Florian Kissling. Shannon is doing our UX and information architecture research, and then Florian is our lead designer… And they are kind of overhauling the way that the docs are set up. So if you’re interested in seeing such things, there’s a pull request on the Gatsby repo that has the new – there’s a preview to see the Netlify branch that has the new docs information architecture. It’s pretty cool, and there are some design updates and that makes it look really nice.

[01:08:06.27] Nice. Well, since you mentioned “up next”, what else is upcoming that we’re not aware of, that could be like – you know, whoever’s listening to this like “I’ve really gotta try this now”, you hear this and it’s like “I’ve REALLY gotta try it!” What’s coming up?

We are trying to get version 2 to stable. Version 2 is in beta right now; you can use it, it’s significantly faster than version one. We added some things that make it less – there’s no more magic in Gatsby; we’re using the standard React way of doing things now, so there’s a changelog that you can look at to see that…

But I think the things that I’m really most excited about - we have someone working on putting schema stitching into our GraphQL schema, so that you don’t have to build a plugin if you already have a GraphQL endpoint. For example, GitHub already has a GraphQL API, so you can just stitch that right into Gatsby and use it right away. There’s no need to put together a source plugin for it anymore. That’s super exciting.

We’re working on some new stuff with images where you can lazy-load your images but generate SVG low-poly versions, which basically means it starts to look like impressionist art… It turns your photo into 12 triangles and rectangles that roughly resemble the image, and then your high-res image fades on top of it. It looks amazing.

The store is probably the other thing that I’m most excited about. We’re rolling out a lot of automations inside of the Gatsby Organization on GitHub, so that we can give people – anybody who contributes to the repo, we’re gonna have swag available for you as a thank you… And anybody who contributes a merge PR is gonna automatically be invited to become a maintainer, which means you’ll have the ability to review pull requests and merge pull requests.

We wanna really make sure that Gatsby is in control of the open source community. We always wanna emphasize that it is an open source community-driven project; it’s not a commercial project that uses predatory open source practice, and that’s a big thing for us.

Jason, thanks for coming on the show. It’s been a blast learning about Gatsby. You’re certainly passionate about it, and great product to put out there… Excited to see how it’s turned into a business; I’m looking forward to seeing how you sustain the business long-term. You’ve got great ambitions towards it, and I can’t wait to see what you guys execute on.

Yeah, thanks so much for having me. This was a blast, and I’m looking forward to doing all that stuff myself.