The Changelog: Software Development, Open Source - The Great GatsbyJS (Interview)

Episode Date: July 18, 2018

From open source project to a $3.8 million dollar seed round to transform Gatsby.js into a full-blown startup that's building what's becoming the defacto modern web frontend. In this episode, we talk with Jason Lengstorf about this blazing-fast static site generator, its building blocks and how they all fit together, the future of web development on the JAMstack (JavaScript + APIs), the importance of site performance, site rebuilds, getting started, and how they're focused on building an awesome product and an awesome community.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at rollbar.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is sponsored by our friends at Rollbar. How important is it for you to catch errors before your users do? What if you could resolve those errors in minutes and then deploy with confidence? That's exactly what Rollbar enables for software teams. One of the most frustrating things we all deal with is errors.

Most teams either A, rely on their users to report errors or B, use log files and lists of errors to debug problems. That's such a waste of time. Instantly know what's broken and why with Rollbar. Reduce time wasted debugging and automatically capture errors alongside rich diagnostic data We'll see you next time. Welcome back, everyone. This is the ChangeLog, a podcast featuring the hackers, the leaders, and the innovators of software development. I'm your host, Adam Stachowiak, editor-in-chief of ChangeLog. On today's show, Jared and I are talking about Gatsby.js with Jason Lengstorf. Jason is a developer advocate at Gatsby.

Gatsby is a blazing fast static site generator for React. And we talk about that term too, and how it applies to Gatsby and maybe even how it's misleading. We talked about their recent raise of $3.8 million, a seed round that takes them from open source project to full blown startup. They're hiring by the way. We also talked about the building blocks of Gatsby and how they all fit together. The future of web development on the Jamstack, which is JavaScript and APIs. The importance of site performance, site rebuilds, getting started, and how they're focused onatsbyJS raised a $3.8 million seed round is now a startup. GatsbyJS is a static site generator. And so the question that just leaves out of my tongue is like, how is a static site generator raising almost $4 million and going to 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, is this is something we're struggling with at Gatsby right now is that 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. So 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, like all of the optimizations that need to happen, preloading 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 going to perform better than most as soon as you ship it. And that's even more important, you know, like we, I don't know if you saw, uh, here a couple of weeks ago, or I guess it was not that, not that long ago, there was a, an announcement from Google that they're going to start using mobile, mobile page performance as an indicator in search

range, your search engine rankings, which is, you know, that's going to be a big deal. And so that's something that Gatsby is, is very well suited to handle. 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. So we can take data from pretty much anything that it can expose a JSON object. We can take, you know, a database, we can take markdown files, we can take your, you know, any rest API endpoint. We can even take like an Excel sheet, like Google sheets, and we can consume that and we put it into a central data endpoint, like a GraphQL endpoint. And 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, when this is where we think the big change is, content editors, like the content team is working in WordPress. The, uh, the sales team is working in Salesforce. The, uh, you know, the, 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, and, uh, and a completely cohesive experience, despite the fact that data is coming from all over the place. Um, so I think those are like our two key competitive advantages. And I think the reason that people are interested, um, and the other reason is just, I think our long-term vision, which is, is, uh, 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, you know, GatsbyJS.org does show, you know, a blazing fast static site generator is Jamstack something that you all are trying to align yourself with or is it? It absolutely is. So Kurt Kemple is one of our one of our our developers, and he is he's famous for making like silly stickers. Uh, at

one point he made socks with like Ken Wheeler from formidable labs, uh, his face on the socks, like the, 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. Um, and it, which led us to having this conversation about like, can we make actual like fruit preserves and make that part of our swag? Cause it just seems like such a fun thing to do. Um, especially cause there's so many pun opportunities. Like 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% going to be called the grape Gatsby. Come on. Like it's such a,

like 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. Yeah. It's interesting. Now you're stealing my episode name ideas. So I'm going to have to come up with something else. Certainly is helpful considering all that,

that, uh, which may be where it stems from, but the color purple was your brand color. So, I mean, it's, it's a personal brand. Yeah. I mean, so it's actually, um, that had nothing to do with our decision-making. Um, we, we actually chose that particular shade of purple. That's, um, Rebecca purple, which was named after, uh, Eric Meyer's daughter. Um, so it's kind of a little homage to, you know, the stuff that he's done for the web and, and, uh, just, you know, uh, we, 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 palette.

Wow. So you have big ambitions, the static site generators, open source projects, like things like these don't usually start with the big ambitions. Like sometimes it grows. Some people start with like huge ambition. Who's the fellow, Adam, who's doing Redox OS? Like someone who's like, I'm going to write an operating system in Rust. Like that is a huge ambition.

But somebody who's going to take, you know, some things and process them and spit them out in HTML. We've all I mean, many of us have kind of done that, like we were in our own little, you know, site generators. And so there's lots of these things. And maybe you weren't there for the for the genesis of Gatsby. But do you know, like, 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. So Gatsby was created by Kyle Matthews.

I think it's three years old now. And it was right when React and GraphQL were starting to be recognized. I think this predated Apollo. It was on the relay in 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, the good react development workflow that he liked without giving up all the control that, you know, a CMS would, would give him. And so he started just kind of

scratching his own itch and over time it expanded and expanded. And, and there was suddenly there was a plugin ecosystem and people were getting excited. And, and, and there was suddenly there was a plugin ecosystem and people were getting excited. And, and I think he just, he was very fortunate to have just backed two technologies at the right time to have a good influx of like early adopters to help push the project forward. And, and we had, you know, amazing input from people all over, like the Facebook team has contributed. The GraphQL core team has, has been involved in discussions. Um, there's, there's been a really, it was a really good, um, like an intersection of like, Kyle's 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 is about the same time. I think I might have my timelines mixed up here, but this is about the same time that headless CMSs started to become something that people were like really interested in. So it was, it was just a lot of like good timing mixed with a solution that was flexible enough to, to adapt as people were coming up with newer and better ideas. Um, and, and, you know, now it's grown into, I think about the time V1 hit, um, it, it had just seen this, there was just this amazing core group. We had hundreds of developers at that point contributing to the Gatsby core. Um, and that's about the same time that, that Kyle started thinking, Hey, maybe this is like a business. And that was, I can't remember when V1 was released, but in 2017 was when they started, Kyle and Sam Bhagwat, who was the other, the co-founder, they started really talking about

this in earnest and shopping 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 got to think about who's going to buy it. So a business is something that actually earns money from sales of some sort, right? So what is the sales for Gatsby, you know, the dot-com version, the business version? Yeah, so what we're trying to do with Gatsby is, like, Gatsby as an open source product is not really going to change. Gatsby is an open source product is

not really going to change. It's going to 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 like these build times of, you know, five minutes, 10 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 like the changes go live when, when CI completes. But if you're pushing to master and then you get to walk away and like the changes go live when, when CI completes. But if you're somebody who's editing content, like if you're a, 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 backend ecosystem, 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. So 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, et cetera, et cetera. Um, you can also event in the future where we're getting ready to launch an alpha. Um, 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. And then we also want to build an infrastructure that would allow for, you know, extremely fast rebuilds so that an enterprise client, you know, somebody who's got like a

Wikipedia sized page will be able to make a change and see that change go live near instantly. So you basically, we're trying to, to create the infrastructure that works around the limitations of statically building sites. So that puts you in competition with a, with a Netlify then, or? I don't think so because Netlify is solving a different use case. Like Netlify is an excellent platform for the vast majority of people who use Gatsby. We're, we're going kind of further along to very specialized use cases where you've got, you know, 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. That's, you know, now

you're, you're like running a server to the side of Netlify and when they publish, you could still publish to Netlify using this, this system. And then if your site grows to where you need, um, extremely fast turnaround, like one of the problems that, that you run into with Netlify is with a big site, they have a timeout and like 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 and then your build fails. And now, you know, you, you have to like 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, like the enterprise grade build a Gatsby site solution. So it's going to be highly tailored to us, highly tailored to using Gatsby. So, you know, it's, it's not something that we think Netlify is really going to be interested in doing because it's extraordinarily coupled to our particular platform. That makes sense. There, there's a lot of these generators out there, as I mentioned before, and then many of us, you know, cut our teeth on Jekyll. Um, some plenty of people still using Jekyll today, if you're publishing the GitHub pages

or even to your own site. I know for myself personally, I, my blog is still on Jekyll, which is why I don't write for it anymore because over time as I got enough markdown files in my repo, uh, it just took too long to, uh, to compile. And so like the writing processes became painful. And so that's my excuse for not writing quite so often.

Um, but when it came to speed, like Hugo, Hugo came around and I'm not sure exactly when he 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 like what makes Gatsby stand out. And so there are other blazing fast at excite generators.

And so to me, it seems like the big differentiator beyond that is the react and the graph QL is kind of these core components that are burgeoning and people are excited about. Have you found that a lot of like the blazing fast is nice to have and is definitely a feature but do you think people are coming for blazing fast are they coming for react and graphql well i i think i mean the answer to both is yes but i i think there's um there's a distinction that should be drawn hugo is a an extremely fast build um but gatsby is a blazing fast product so like the 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 what the the blazing fast in gatsby's case is that we will um we've got such a finely tuned build pipeline, like the stuff that we're doing with web pack and code splitting and preloading and all these things. The site that comes out the other end is, is basically going to ace that lighthouse audit right out of the box. Uh, whereas a Hugo site absolutely can, you know, I, I use Hugo before I switched to Gatsby a little 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 those manual tune that any of that manual tuning. It just did the stuff right away because that's what Gatsby is optimized to do.

So what's the stuff? So there, there are a few things that, that you're going to be expected to do to pass the Lighthouse audit. The first one is like you don't want any blocking scripts. You want to make sure that you're only sending render critical stuff down to the viewport. So basically not rendering anything off screen. You're lazy loading your images. You've got like the proper code splitting so that you're not loading CSS. It's not being rendered on the page.

You're not loading JS. It's not being rendered on the page. You're not loading JS. It's not being rendered right now. And all of this is possible to do with Webpack and various JavaScript modules. So what Gatsby is doing is it's pre-configuring these things. So 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, let's say like two or three megabytes,

we can send down 300 kilobytes 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. Um, the images that are off screen, all of that stuff happens after you get to your initial paint, which means that the, you know, on 3g, um, the rule, the kind of the, the guideline that is put forth by Google is that if your site doesn't load in three seconds, you're going to lose 50% of your visitors. Um, on 3g, I think the last average that I saw was that sites are taking between like 12 and 16 seconds on 3g on average, a Gatsby site on the other hand is going to take

like one to five seconds, depending on how much stuff you're putting on the page. So it, and that's just what we've baked into the core. And obviously you can make decisions that will make your site slow. We've, we've seen some Gatsby sites that are scoring like zero on the, 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, if you follow our recommendations and use the tooling that we've built, like our image handling and that sort of stuff, your site is going to probably score in the high 90s on Lighthouse by default. That's a nice bonus. Yeah, so that's the differentiation.

That's a heck of a distinction because when I see Blazing Fast Generator, I think the generation is fast. I don't think the end product is fast. Yeah, this is something that when we took the funding, we realized that our messaging was written for an open source project. We put no time or effort into it. So we're, we're trying to figure out how to explain this in a way that doesn't, um, like we, you know, we don't want to get hypey, but we also want to make sure that we're being clear about what we're saying. And like blazing fast is a, is it's true, but what do you want to make sure that people know how it's true? Because I, I've had like, that's a very common misconception that like when,

when Hugo is fast and Gatsby is fast, it's fast the same way. And that's actually very, it's 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 got.org.com.

So for listeners, you can see both those. Gatsbyjs.org and.com. .com is the business. .org is the open source. But you 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 want to 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, that they were paying $5,000 a month in hosting. They reconfigured to use Gatsby with, I believe, Contentful as their backend and some Lambda functions to handle any backend processing that needed to be done async. And they went to a $5 a 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, but it, it turns out that was, uh, they were paying for like these big bare metal servers to handle the server loads, uh, 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 searches. So you, you're basically paying, you're already paying in your CDN fees for that kind of traffic. And typically most of us never use it. So, so basically we're all amortizing the cost of like big sale day launches for other people on the same CDN. Um, so yeah, it was, it was extraordinarily cheap for them once they, once they cut out the need for those, uh, those traffic resistant servers. This episode is brought to you by DigitalOcean.

DigitalOcean is a cloud computing platform built with simplicity at the forefront. So managing infrastructure is easy. Whether you're a business running one single virtual machine or 10,000, DigitalOcean gets out of your way so teams can build, deploy, and scale cloud apps faster and more efficiently. Join the ranks of Docker, GitLab, Slack, HashiCorp, WeWork, Fastly, and more. Enjoy simple, predictable pricing. Sign up, deploy your app in seconds head to do.co slash changelog and our listeners get a free 100 credit to spend in your first 60 days try it free once again head to do.co slash changelog so jason let's talk about some of these moving pieces i did go through the tutorial today and i npm installed gas bcli 211 packages from 105 contributors so uh good old-fashioned javascript open source just tons of tons of uh sand on the giants

sitting on the shoulders of many giants um the two i mean the three i would name would be react graphql and webpack um 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 Allenson or Mikhail, I'm going to murder his last name, Pikowski, I think it is. They're the three kind of like core OSS maintainers.

But yeah, React, GraphQL, and Webpack, I would say are the three that are most notable. Yeah, and huge things I think make it stand alone in many regards to some of the other offerings out there. So let's zoom in on the GraphQL 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 like disparate sources in the file system, a CMS with a JSON endpoint, like 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 this, if I had to take a guess on what gets people most excited about Gatsby and why they stay, um, it's, it's this, and it really, so I, um, prior to coming to Gatsby, I was a front end architect at IBM and one of my big pro I guess, like the big project that I did there was I rolled out a GraphQL layer to, um, one of IBM's products. And it was, it was amazing to watch the shift in velocity for teams that went from using like traditional multiple rest

endpoints to load data for UIs to using a centralized GraphQL service as the way to get data. It just fundamentally shifts the way that you build front ends because, you know, 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 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. And so when we rolled out GraphQL as a service on these teams in IBM, we saw things that were taking six months, 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 contexts. They were, they were looking at GraphQL. They would define the, I mean, GraphQL, the way that it's, it's easy to describe it. This isn't technically accurate, but you basically write an empty JSON object. And what comes back is just that JSON object with values attached. Um, there's more to it than that. There's a little more nuance in there, but, but fundamentally, like as a conceptual model, that's, that's how you're working. So the, 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 and they, they can test this in a user interface. Uh, it's called graphical, um, or they can use, uh, uh,

the Prisma team has something called GraphQL Explorer, I believe, which is a great tool. Um, but you just, you do this right in the browser and then you drop that into your code and it just works. Like you're no longer writing, writing, you know, async request. You're not dealing with like any of the AJAX stuff that usually trips people up. It's a it's a really, really powerful thing to do. And so 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. So we have, I think the Gatsby ecosystem now is over 300 plugins. Many of those are source plugins. And so you can get, I think there's a, you know, 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, those endpoints and say like, 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 you didn't, as a developer, you didn't have to do anything. You just went and found, you know, your, your API token for whatever service and drop that into our plugin. And now you've got it. Um, and the, the documentation on how to create source plugins is, is pretty straightforward. You know, I, I just had to create one for, um, Shopify's by SDK, uh, that was compatible with version two. And I think it took me, you know, like a couple hours because the,

the documentation is like, okay, get an object, drop in the object and all right, you're done. Um, and you know, there's nuance to that as well, but, but overall there's just, it just eliminates this whole category of what effectively feels like busy work when you're trying to build a UI. Um, and I think that's like, once you've worked that way, I, I recently, after, after using Gatsby for a while, went back and maintained one of the other sites that I built just for fun. And it's got this kind of like async like 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 I don't have to do this anymore. I feel like it really 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, so 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. So Gatsby, just like I just got the boxes today, got some t-shirts and everything.

And so 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, you know, we're now we're like a funded company. We want to make sure that like people know we really, really appreciate that. And the open source part of Gatsby is still super dependent on open source, the open source community. Because, you know, we're never going to keep up with, with demand for open source. So we wanted to give, like, come up with a way to give back. So I built a store using Auth0, Shopify, GitHub, MailChimp. And I think that was it.

And we we made it so that anybody who contributes to Gatsby gets automatically invited to be a maintainer on the org. So you can like review and merge pull requests and stuff because we want to give the power to the community. And then we also automatically qualify you to get a discount code to claim for a t-shirt or socks. You can, so through the Shopify store, like we built the store with Shopify, but then we pull 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. And so, yeah, you log in with Auth0. It's kind of, once you get into the authenticated part, it's just a React app.

Like Gatsby doesn't do anything there. It's basically identifying like, oh, once you get to slash account, it's a react app, let it be just a react app. Um, and then on the front end, we're loading in the, the Shopify products, displaying those, and you can add them to your cart, check out all the same way that you would through a Shopify store, but it's all being done through like a Gatsby react based website. Um, but yeah, that's, that's our, exactly our intention is to make it so that literally anything that exposes an API where you can, 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? So I'm thinking, thinking you know you say you have this exact setup maybe each

product each t-shirt has its own page on your site and so at build time gaspy would you know 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 loop 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 side? Is there like a...

It does. And Shopify has webhooks. So we build... The Gatsby store right now is built on Netlify. And 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 like disabling or at the speed of rebuilding the Gatsby site, which that one takes a couple of 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 modification, munging, things that typically take CI processes, which you mentioned earlier. You know, a long time if you're at larger content site, like why rebuild the whole thing when you could 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. So funding gives us the ability to like dedicate people full-time to it. And we have a really like a great team of, um, open source people who are like working. We, we basically have a combination of like open source contributors,

full-time people at Gatsby and, uh, and a couple of contractors to solve specific problems. Like, you know, we hired, uh, 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. And like, we have a problem, cool, hire the person from that, that project and like pay them to solve a problem that, that makes their product better and helps us solve an issue that we're overcoming. I mean, to answer your question in a like 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? Like for one thing, it's a business now, right?

You graduated from open source to funded proving out a business model. It's like you are a business, but you're 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, like, do you have competition who competes with you? Are you, are you in a blue ocean?

Uh, it, I mean, I guess it depends on what we ultimately end up offering for sale. Um, it, it feels very blue ocean in a sense, because Gatsby has some maturity that a lot of other projects in the ecosystem just, you know, they just haven't been around as long. Um, that being said though, there's some really, really exciting stuff happening in the view space that is, uh, you know, we were seeing things come up that were like, oh, man, we should build that. So I think that we're going to see some stuff. I think like view press is one of them. e-commerce view platform that's, that's offering a really similar kind of solution to what Gatsby does that, uh, that's, you know, like we were like, oh man, that's also a really good idea.

So I think, um, we, there's not a ton of competition now, but we're seeing things coming out and like react static is an excellent tool. Um, there, uh, you know, we're, we're seeing, um, just some really, really fast builds and the stuff that Tanner's working on is, is really exciting. Um, so there, there's competition, but there's not formal competition. Like, I don't think there are businesses that are specifically pursuing, like, can we auto generate massively performance sites and like do this at scale? I think that that is a very,

very limited window though, because I think it's coming. Maybe this is more of a question for you, but then it is for Jason, but like, 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. I haven't, I mean, everybody seems to be like coming to our camp whereas gatsby's like playing whatever sandbox you want to will just be your front end and the way you build your site and we'll be partnered with anybody pretty much out there rather than competition yeah i mean it might be unique it might be things that we don't know about. There are some companies that I think are doing similar things, but the, so like 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 want to make it easy to use. Um, what I think is unique about Gatsby is that Gatsby is kind of spanning from the, like all the way in

the back, like how, how do we get data, um, 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. So I think it's, we're not unique. I think we just are in kind of a very niche space. So we, 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 web hooks and the like re-triggering builds of course when you get your incremental builds out there then everything will be faster and and maybe you can even just you know have your site rebuild once every five minutes and you know what will come what may but and what about when

you're trying to integrate with a cms that doesn't have the hooks that a shopify has or a github has maybe i don't know if google sheets has the ability to like trigger a thing when you update the spreadsheet data are there situations where you're kind of hamstrung because you can't ping gatsby and say hey rebuild rebuild yeah And we tend to just solve that problem with like, uh, we solve it with a hammer, you know, we just set up cron job. Yeah. Um, it's, we're finding it's, it's not as common as we had feared to, to have sites that just like, don't play well with web hooks. Um, the, the thing that's really nice about the modern web is that I feel like companies are much more open to the idea of being part of an ecosystem instead of being the ecosystem.

You know, back in the day you would have like before WordPress made the decision to become a headless CMS in addition to being just a CMS, it was, it was kind of like, Hey, if you're going to use WordPress, you got to to go all WordPress. Um, and you would see the same thing with like Magento is kind of like that. If you, if you're going to use Magento, like your data's in Magento, your front end's in Magento. And I don't even think they, they might have plans, but I haven't seen like a Magento API so that you can get data out. Um, but then you look at it. If you're on Magento, you're probably never going to get off to Magento. That's where you are and that's where you'll live the rest of your days. But then in contrast, you've got companies like Shopify where Shopify is like, we don't,

we don't care. We're going to like handle your products and inventory and we'll like process orders for you. And if you want to display it through Shopify, great. Here's some tools. If you don't, great. Here's an API, a contentful graph CMS. Like they're all doing the same thing, these open CMSs.

And then on the back end, you've got things like Netlify, where Netlify is like, yeah, we want to host your stuff, but we don't care where it comes from as long as it's like files. to realize that like 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. Cause you know, we've, we've seen it happen over and 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 those other things suck or your main thing starts to suffer because you're converting too many resources to the other things. And that,

you know, I I'm really happy that that's no longer like a default business model. This seems like the, the ultimate sample it wherever you want kind of mentality where like, if this is the way you build your site, but you can get your data and things from anywhere else when you know, Shopify tanks, which it never will, of course course it's awesome it's ran by phenomenal teams but let's say it changes its business model to something you don't agree with and you want to 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 you can easily move to something new or sample the the modern way to do things. It seems, you know, it seems very logical, but it took a long time for somebody to come up with this idea of Gatsby. Yeah. I mean, it's, it's, I think one of those, those things, it was just like, it, it fit a need at the time when that need was capable of being met. But I mean, it like, it's, it opens such exciting possibilities. Like for example, you could, 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 like get a dump of your WordPress database and shape it to whatever the new CMS thing was. And of course, a lot of CMSs are going to 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 posts from that blog get built in the exact same place. And like, you know, time goes on and like, that's it. So it, 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, you can have a consistent web experience and completely change the underlying pieces,

um, without, without the introduction of tremendous tech debt. I mean, obviously there are ways you could create tremendous tech debt, but this is a, if well-considered, you can shave off a lot of, of migration paths and, um, and like 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 know, you've got some examples on your site. Is 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? Any, anybody that's like you'd mentioned a $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? Uh, yeah, I think, I think a couple of cool examples,

like one that I love is the React docs are using Gatsby. And so 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 like the frozen in time version of like the, the react version 15 docs. Um, another really cool example is that I think I, I hope I'm getting the name right. Escalade sports. Um, they built a site called Cajun bow fishing.com, which uses, um, I don't know if it's salesify or salsify, but it's, uh, it's like a product coordination thing. Um, I don't know,

it, it sounded very, very powerful. And, and I, it was clearly something that I didn't quite grasp how they did it, but coordinates product data from all over the place. Um, but so they, you know, they're pulling this like archive of data from all over the place and updating their site without having to rewrite a bunch of their backend. Um, or even like a kind of a silly example. Um, Ryan Florence of react router fame has recently started this business called workshop.me and he didn't really want to deal with a CMS. So he has people like 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 want to 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. So it's, it's kind of like, you know, use data the way that it fits into your workflow. You don't have to do these, these, 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 suits you. now partner with Algolia. If you've ever searched Hacker News, Teespring, Medium, Twitch, or even Product Hunt, then you've experienced the results of Algolia's search API. And as we expand our content, we knew that one day we'd have to either roll our own search solution on top of Postgres, or we could partner up with Algolia. And I'm happy to report that phase one of our search is now powered by Algolia. We're able to fine tune our indexing,

gain insights from search patterns and analytics. We can create custom query rules to influence ranking behavior, as well as improve our search experience by adding synonyms and alternative corrections to queries. Sure, we could build search ourselves, but that would mean we would be busy doing that instead of shipping shows like you're listening to right now. Huge thanks to our friends at Algolia for working with us. Check the show notes for a link to get started for free or learn more by heading to algolia.com. So Jason, with all things surely it's not all rainbows and unicorns i know we've been talking about the stuff that gets excited and i'm excited about gaspy it seems like there's tons of potential

here but um being so close to it i'm sure you know all some of the warts some of the drawbacks some of the cons i want to provide the drawbacks, some of the cons. I want to 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 the stuff that you can do, especially the GraphQL layer is really awesome. But where are some of the places where Gatsby lacks or there's holes or headaches in using this technology? Sure. I think like the places where we've been seeing the most struggles are, you know, what we were talking about with build times, that's probably the biggest, most obvious pain, um, as your site grows and as you see more and more content coming into

it, it, you just see the build times start to grow. Um, and sometimes we've been seeing them grow like non-linearly, which we're trying to figure out why. Uh, and we're, we've been seeing them grow like non-linearly which we're trying to figure out why uh and we're we've got a pr open right now where um kyle has he's calling it his hulk smash uh pr and he's just been working on a ton of different build time optimizations and we're seeing i mean it really is like a lot of improvement is coming but for the time being builds are still not as fast as we want them to be. Um, it can be difficult to use Gatsby on a mixed team. So if, if not everybody on the team is a developer, it can be challenging to work through some of the, 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. Um, that's going to be one of the, like the doc, like the Gatsby Inc, um, commercial products is going to be like, you get an account to preview things live without having to use any code. Um, another one that we're struggling with is, is some of the more advanced use cases. Like we don't have a good internationalization story. You can do it, but basically you're, you're rolling your own solution when you start doing internationalization in Gatsby. Um, and so we're, we're trying to figure out like, is that something that Gatsby

itself should have an opinion on? Like, should we have an official Gatsby internationalization plugin that solves that problem for you? And then, you know, when you get into the kind of the depths of our really like low level things, the documentation just isn't quite finished. But we're trying to, you know, that's a big focus of ours. We've got multiple people who are working really hard on docs. Like Shannon, um, is doing, uh, uh, Shannon Soper is, is managing like an information architecture overhaul of our documentation. She's finding the gaps in it and making sure that it's, it's actually meeting the needs of the people who show up on the site.

Uh, but in the meantime, it's, you know, you'll, you'll find some gaps. And if you get down into the low level APIs, you're going to be like, I have literally, I know, I have no idea how this works and you're going to find yourself reading source code to figure it out. Um, but so like a lot of it is, is edges that we haven't run into yet. Um, are still kind of like you, you cross that edge of the map and now it's, you're, you're like building it yourself edge of the map and now you're building it yourself. You're back on your own. And 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, um, we're, we're trying to do things like that, but we're also trying to figure out like, uh, we were in talks with, uh, Leonie Watson about how can we make it so that when you navigate between pages, screen readers will actually announce that a page change. That's a pretty classic problem with single page apps is that when you navigate between pages using react router, um, there's no indication

to the person who's using a screen reader that the navigation is complete. They just have to like guess. And that's a problem. So we, we, we haven't solved that problem either. Uh, but it's something that we're working toward and it looks like, uh, Ryan Florence, I believe is working on something called reach router, which I believe solves that problem. So we're going to try to migrate over to that to have a better accessibility story inside of Gatsby as well. But yeah, I mean, it's like 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, we haven't had the time to, 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, you know, the Firefox dev tools added an inspector, you know, we'll have better auditing for these things

and accessibility is really hard to get. I mean, it performance is accessibility in certain ways, but, um, it's, it's a hard thing to do well and often. And so like the more that tools give us the ability to, you know, be winners and not losers in that you're going to empower a lot more people to have much better experiences. So that would be something that I think would definitely differentiate it. Um, yeah. And, and I think that we need to, we need to make that part of like the core technical, technical offerings that we have because we have amazing people out there, you know, like Leonie Watson that I mentioned before, we've got Marcy Sutton. Um, we've got like, there's this whole group of people doing amazing work in, in evangelizing accessibility, but the vast majority of us have probably not seen their talks. And 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, like 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. Like that's our entire goal with Gatsby is like,

we want to make the right thing, the easy thing. And we've started by doing that with performance. And we're, we want to kind of expand that to cover additional stories like internationalization and accessibility. Well, now you have 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 you expand in the team. Tell us about that side of 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 10 people. We've got a few contractors that we're, that we've hired to help us solve very specific problems. So we're, we're trying to overcome a few different things. Like there's, 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? Um, and that's one of the reasons why, like I'm putting such a big focus on, like, I want to make sure that the people who community, who are part of the Gatsby community and the open source community in general are just taken really good care of. Um, you know, the, the swag store is one of the ways that we're doing that. We just started a program where, um, me, uh, Kyle Matthews, Mike Allenson, Mikhail Pekowski, Kurt Kemple, we're all going to do community pairing hours where anybody in the community can ask for like 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, you know, ostensibly, we're going to work on something Gatsby related.

But honestly, we just want to help people in the community. So what can, you know, what can we help with? Let's debug something. Let's get started on your first Gatsby project. Let's build something together to just try to like 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 want to make sure that that like 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 like a place where it's being soaked up. We want, we want the value to stay distributed. And then we're also trying to figure out like, how do we scale properly? You know, we, we started out by hiring

people directly from the open source community. Um, but that has like advantages. We've got people who are extremely familiar with how Gatsby works technologically. Um, but it has disadvantages like, you know, people who work on GitHub are predominantly white males. And so we have, have a disproportionately, uh, white male team right now. And so now we're trying to figure out, okay, how do we work with like underrepresented communities? Um, how do we make sure that we're reaching out to the right people? So we're, we've been in talks with, um, 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? Um, we're in talks with, uh, a group in Portland where I live, uh, called women who code and we're, we're attempting to, um, like put together some workshops to,

to try to train. So I'm not, I'm going to run one workshop, but I'm going to have somebody from, um, 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 going to be there at all. They'll be able to just run that workshop. So we're trying to train up people in the community to be kind of on, like be able to take value out of Gatsby on their own. And hopefully we'll be able to hire those people and, uh, and grow our team in that way. So we're, we're doing, you know, we, and like, how do we do that in a way that is, you know, sustainable, that's going to help us grow and, and make sure that we're not,

uh, tripping over our own feet there. There are a lot of really, really interesting and really not related to code questions that we're, we're trying to figure out as we scale, which is like both extremely fun because we get to look at like, okay, we, we've always worked at companies and we've, we, you know, I don't know if you've had this experience, but like every company I've ever worked at, uh, 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. 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 going to make the company that we always wanted to work at?

And, you know, what are we going to do to make sure that this is a company that not just I want to work at, but that everybody wants to work at? How can we make sure that like when we open a job opening, we get flooded with resumes from literally everyone, like every corner of the internet, every different group, like, you know, we want to be that company. And 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 like their technology of choice? And beyond that, how do we make a Gatsby into a company that is like a model company for the, for the tech world, for companies in general, that is a place that people are

excited to work at that, you know, if you say, Hey, I work at Gatsby, people go, Oh man, I'm so jealous that you get to work there. That sounds so awesome. Um, really this is a, the most terrifying and most exciting challenge that, that I've ever had. And I think that everybody in Gatsby right now shares that, that excitement and terror that, uh, we, we really want to get this right, like on all fronts. And so we're, you know, I've been reading books. I just like, just ravenously reading books on like team culture. How do you make communities welcoming? How do you make people feel safe? Um, I'm like, I was on Twitter, like, Hey, help me, like send me books so that I can be less of a, of a jerk to, to my team and like more make people feel comfortable giving me feedback. Um, and, uh, it's, it's, uh, I don't know, man, I'm terrified, but I'm also having a lot of

fun. Where does community live at for you? I mean, is there a central place where you do community? Like, 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 and Twitter right now. And we haven't really had the chance to think through how to centralize that because we want to 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 going to be a GitHub user. We could potentially use something like, uh, like discourse or, uh, you know, um, you want to, you know, one of those, one of those types of, of, uh, community services. Um, but we're not sure if you've got ideas on, on all ears, because we just, we, we aren't quite sure how to scale properly. Well, the one idea I'd give, and Jared, you've heard me give this, this advice every single time when we have this kind of question or have this conversation around community is like,

you've got to put a community link in your main navigation, right? If people got to find it, search it, or like, ask the question like me, where's that? Then, you know, it's, it's your first step is shooting yourself in the foot. It's like if there's no community button that says, hey, here's where you come to find out where it begins. Then you're really – that's your first step there is kind of identifying that. Because if you have – Don't mind me.

I'm just taking notes in the background. I do see discourse as an icon over to the right in the.org's main navigation. But, you know, to me, I feel like when you put a community link in your navigation, it's like it's an invitation. Right. Yeah. And then you say, here's who everyone's welcome here. Yeah. We I'm only we get this right because I had thought through this and we do have community in that in our main navigation. And we do say, Hey, everyone's welcome here.

Like this is where you can hang your hat. This is where you can hang out with fellow developers, ask questions, whatever, like you're welcome here. And I feel like that's a core step to getting it right. And if that's so important to you, you know, that could be a first step for you, but you know, I love that, but getting it right though i mean 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 want to work at when they hear that you work there but the pair programming thing is pretty interesting you know it gets people on board faster as you know you kind of knocked your docs a little bit i think your docs are maybe they're not as fully featured as you want them to be, but they're so easy to navigate. I think you've done a really great job on that front there. In terms of scaling your team, I mean, geez, that's every startup's hardest part is scaling, right? Right. Yeah. Yeah.

No, I definitely agree with you. And, you know, I think when I hear this from probably any other startup, I'm like, I, I, I definitely agree with you. And, um, you know, I think when, when I hear this from probably any other startup, I'm like, yeah, yeah, that sounds hard. And now that it's me, I'm like, Oh my God, I'm going to, we're going to get this so wrong. I like how you said that's your 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. I can get it right.

And that's that's the fun part. Yeah. Yeah. I think that's where I want to live in the Venn diagram. Yeah. The overlap between excitement and terror is probably the best place to be in a startup. And it certainly suits my personality best. You know, one of the reasons I left IBM was because it felt like all

the decisions had been made. Um, so being, being in a startup where, you know, almost none of the decisions have been made is significantly more stressful, but it feels like good stress. It doesn't, you know, I don't wake up dreading my life. I don't wake up in cold sweats or anything, but I am absolutely like every day thinking, okay, well we get to make decisions today that will echo through the rest of our company because we're, 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 these bad habits, this culture, you know, it's going to implode in the future. So we need to be thinking

like, how do we make sure that everybody in the company is, 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? Um, and then once we've become a culture, how do we make sure that we're a culture that, that is headed in the right direction and has the right values. And there, there was a, I mean, 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 I mean, there's a, there's a, it's a really, really interesting and fascinating place to be. And, um, it gives me an excuse to read a lot of books that I've been putting off for a long time. So it's, you know, if nothing else, I, I at least get to do some great reading.

That's always fun too. Whenever you step into a job, um, not that you haven't done this before, but you step into a job to have the feelings that we just talked about, but then also be like, I've got to 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 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, you know, as whatever I'm doing, like 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. So that's interesting.

There was a recent blog post that you all had. We kind of cover 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 to maybe 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 really 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. Where do you point people to? And what do you, what do you link them up to? What gets people to that first step to say, aha. So our tutorial gets, um, a lot of props for, for getting people to that aha moment. Um, I think what, what we're trying to do is, you know, we, we want to 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. It's you're back in high school doing math and you're just kind of wondering like, when am I ever going to use this? And so Gatsby, um, 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, is designed to be, um, visual, you know? So we, we took away a lot of the, the initial boiler plate and configuration. So you can just install a starter and hit, you know, run Gatsby develop, and you're just looking at a real website. And if you go in and change one of the files, you see that website update in real time. So it's, it's a little easier to start to feel the repercussions of what happens when you change code, um, as opposed to, you know, 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, 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. So we're trying to flip that on its head. We want to, 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'll 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. I mean, what you were already starting to. Is there a slash get started? You know? Oh, yeah, yeah, yeah, yeah. There's a gatsbyjs.org slash tutorial. There is, it starts from absolute zero. Like 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 and CSS to building a page with graphical queries, transforming plugins, all that good stuff. Yeah. And there's a really cool pull request in progress right now with Shannon Soper and Florian Kisling, who Shannon's doing our like UX and information architecture research. And then Florian is our, 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, on the Gatsby repo that has the new, there's a preview to see the, the Netlify branch that has those, the new docs information architecture. It's a, it's pretty cool. And there were some design updates, makes it look really nice. Nice. Well, since you mentioned up next, what, what else is upcoming that we're not aware of that can be like, you know, whoever's listening is like, I really got to try this now you hear this and it's like, I really got to try it now you hear this and it's like I really got to try it what's coming up we are trying to get version 2 to stable so version 2 is in beta right now you can use it it's significantly faster than version 1 we added some things that make uh make it less there's no more magic in Gatsby we uh we're using the standard react way of doing things now

um so there's a change log that you can look at to see that. But I think the, the things that I'm like really most excited about, we have someone working on putting schema stitching into our GraphQL like schema so that you don't have to build a plugin if you already have a GraphQL endpoint. So for example, like 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, like low poly versions, which basically means it starts to look like impressionist art. Like it, it turns your photo into 12 triangles and rectangles that, uh, that roughly resemble

the image. And then your, your high res image fades on top of it. It looks amazing. Um, and, uh, outside of that, we're just doing a, Oh, the, 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 going to have swag available for you as a thank you. And anybody who contributes a merged PR is going to automatically be invited to become a maintainer,

which means you'll have the ability to review pull requests and merge pull requests. We want to really make sure that Gatsby is in control of the open source community. We always want to 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. I mean, 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 on.

This was a blast. And I'm looking forward to doing all that stuff myself. All right. Thanks for tuning into this episode of The Change Law. Talking about Gatsby JS. Wow. $3.8 million raise to build this from an open source product to a company. Super impressed.

Super impressed. If you enjoyed this show, do us a favor. Share it with a friend. Rate us on iTunes. Share a link on Twitter. Blog about it. And, of course, thank you to our sponsors, Rollbar, DigitalOcean, and our newest partner, Algolia. Also, thanks to Fastly for our bandwidth.

Head to Fastly.com to learn more. And we catch our errors before our users do here at Changelog because of Rollbar. Check them out at Rollbar.com slash Changelog. And we're hosted on Leno Cloud servers. Head to Leno.com slash Changelog. Check them out. Support this show. Jared Santo and I host this show every single week.

We love doing it. The mix and mastering is done by Tim Smith. The beats are by Breakmaster Cylinder. And you can find more shows just like this at changelog.com. When you go there, lots to catch up on. The Changelog, JS Party, Founders Talk, Away From Keyboard, a brand new show from Tim Smith, a brand new show called Practical AI. Lots to catch up on. Subscribe through the master feed. Thanks for tuning in. We'll see you next week.