Revision 390: The great Gatsby.js

Schepp had the great opportunity to sit together with Jason Lengstorf to talk about Gatsby.js

Show notes

[00:01:40] Gatsby.js

There hasn’t been a static site generator that got so much buzz like Gatsby.js. Based on React and GraphQL, it not only takes the hottest new techniques, but bridges the gap between static sites and app like no other. Plug any content into any page, and get some nice HTML to deploy anywhere you like. Jason talks at lenghts about the big benefits from Gatsby.js, how it is build and why it is a little bit more than just a static site generator. Namely a application framework based on pregenerated content. We also talk about where Gatsby still needs improvement: How incremental builds shall slow down build times tremendously, and how investment in DX and learning will improve onboarding of new developers. Last, but not least, we talk about how Gatsby.js the open source project differs from Gatsby.js, the company, and how filling the shortcomings of traditional static site generators shall create a sustainable pricing model. Enjoy!

Transcript

The fine folks from Gatsby provided a transcript of the show. Click on the details button to see the whole show in text:

The Transcript

Schepp 00:00: Hello, and welcome to Working Draft, Revision 390.

Peter 00:35: This Revision of Working Draft is brought to you by Storyblok. Storyblok is a headless content management system with an impressive visual editor that lets you change your webpage while you’re browsing. This is quite useful, but in my opinion, the most important thing about Storyblok is that it works with any technology stack that you can think of. Storyblok works with PHP, and also with Node and of course with Ruby and with Gatsby and with basically everything else.

Peter 00:59: And it does not only work with just about everything, but there’s also documentation for just about everything. The Storyblok team will even write a tutorial just for you, and your strange tech stack, if whatever you’re working with is not covered by their existing documentation.

Peter 01:13: You can try Storyblok for free for an unlimited time, as long as it’s just you as a single user. So get started now at storyblok.com. That’s story, B-L-O-K, .com. Our thanks to Storyblok for supporting this Revision of Working Draft.

Schepp 01:29: As you might suspect, we will have a guest today. Usually, we’re not in English. We are two people. I’m Christian, and our guest is Jason Lengstorf. Hello.

Jason Lengstorf 01:42: Hey, thanks for having me.

Schepp 01:44: Thanks for coming. So Jason, it’s the first time that you appear in our podcast, so maybe you can tell the people who you are and what you’re doing.

Jason Lengstorf 01:55: Sure. My name is Jason Lengstorf. I am the Head of Developer Relations at Gatsby. Gatsby is a React and GraphQL powered framework for building really high performance websites and apps that compile down to static assets, so they’re easy to deploy.

Schepp 02:13: All right, and where do you live? So where are you connected from?

Jason Lengstorf 02:20: I am based in Portland, Oregon, in the US.

Schepp 02:24: All right, so it’s basically the Brighton of the US, so to say, like the creative city. Is that correct?

Jason Lengstorf 02:35: I mean, it is one of the creative cities. Actually, the reason that I moved out here is that years ago, I owned my own agency. And my agency was originally based in Montana, which is where I grew up. But I wanted more geographical credibility, I wanted people to think that it was a hip agency.

Jason Lengstorf 02:54: So I moved to Portland, specifically, so people would hear it and say, „That’s a hip agency. They’re based in Portland.“

Schepp 03:00: Yeah, sure. It’s the same in Germany. So you need to be in one of the bigger cities or, yes, in a hip city. All right. So for how long are you now, have you left behind your own company and have you joined Gatsby, the Gatsby team?

Jason Lengstorf 03:21: I sold my agency in 2014, and then I did a little bit of consulting, I worked at IBM for a while. And then I joined up at Gatsby in February or March of last year.

Schepp 03:38: And that is also due to Gatsby being quite a fresh project. So not too old. I think it started in 2017. So you couldn’t really join much earlier than that.

Jason Lengstorf 03:52: So Gatsby got funding in 2017, but it has been a project since I believe 2015. Kyle Matthews, our CEO, was experimenting with React and GraphQL when they were really, really new technologies. And he’s got a very right place, right time, he bet on the right horses, basically. And the framework that he put together for Gatsby has, it kind of matured at the same time that the dev world was really embracing React, and we’re seeing GraphQL become very stable.

Jason Lengstorf 04:29: So it’s kind of a perfect storm of everything falling into place for us.

Schepp 04:34: Okay, nice. I heard for Webpack, it was a similar story, that Webpack was also around for much longer, and then at a certain point in time, I think Instagram adopted it, and it was just the right thing at the right time, and then it just exploded. So it sounds pretty similar to Gatsby.

Jason Lengstorf 05:00: Yeah, mm-hmm (affirmative).

Schepp 05:01: Also, I’ve followed JSConf EU, the last week. I don’t know if you’ve been there. I wasn’t there, but I followed along and I’ve seen one talk about the JavaScript ecosystem on the server side. And Gatsby was also like the system right after the, let’s say the old chap, Express, that was leading the pack. So pretty popular.

Jason Lengstorf 05:37: I think the stats were really impressive. I think it was Gatsby and Next had, I think Gatsby it was like 8% of NPM users are using Gatsby, which was a great, like really, really encouraging for us to hear. And I think Next had a pretty similar number.

Jason Lengstorf 05:54: So it’s very cool to see that people are starting to embrace the server side or in Gatsby’s case, kind of pre-rendering and the kind of letting a framework make a lot of the boilerplate decisions, so that you can focus on building something, rather than having to set up all the foundational yak shaving work to even start building.

Schepp 06:17: Yes, yeah. That’s really nice. You said it’s based on React. You said that a few sentences before, and also on GraphQL. And it’s basically a CMS, or maybe not a CMS, but a static site generator, sort of.

Jason Lengstorf 06:44: I would characterize Gatsby as a content orchestration layer. So we have, Sam Bhagwat, one of our co-founders wrote this article that sums up the concept really well as the content mesh. And it’s the idea that originally, everyone had to use kind of a single CMS system, where it was monolithic. The CMS handled all of the data, all of the presentation layer, everything in between.

Jason Lengstorf 07:12: And as a result, when you were trying to build a website, you had to make these trade-offs. Well, we do a blog and eCommerce and then you had to decide which one was more important from a content management standpoint. And then choose the one that was pretty good, or like great at the thing you needed, and only pretty good or even terrible at the thing that you also needed that wasn’t its kind of core focus.

Jason Lengstorf 07:33: A good example, this would be something like if you ever had to build a Magento site, and get it to do anything other than eCommerce, it was a nightmare. As the web has evolved, we’ve been seeing this move toward more headless CMSs. And what headless means is that you can take the CMS and then use it via API. So you’re no longer bound to that CMS as a presentation layer. It’s only managing the data.

Jason Lengstorf 07:57: And with this, that opens up the door for you to say, hey, well, we have eCommerce and a blog, what’s the best blogging CMS? And you can go out and look around and find that. And then you can say, well, what’s the best eCommerce CMS? And you can go and look at that as well.

Jason Lengstorf 08:13: And then you pull those together into what we call the content mesh. And the way that Gatsby does that and the reason that we use GraphQL is that we’re able to pull in data from any number of backends, whether that’s headless CMSs, databases, REST APIs, or even the file system, we pull all that together and put it into a GraphQL layer, that for the frontend developers building the site, the people actually building the Gatsby site, it feels the same. Because the queries are similar, you say like give me all Shopify data or all WordPress blogs or all markdown files and then you just query the data inside of those and put it on the page.

Jason Lengstorf 08:50: So it feels very uniform. It’s very transferable. You don’t have to become a Drupal expert, or whatever framework, Django. You don’t have to learn the deep, dirty details of how that system works. You just need to know how to install the plugin and get an API key, so that we can pull that data in and let you use it.

Jason Lengstorf 09:11: In the sites that we build, they’re static assets, but that’s not to say that they’re static sites. So once they hit the browser, they actually rehydrate into full React apps. So once it’s in the browser, it’s a full single page app. So you’re able to do asynchronous data calls, you can do authentication, dynamic routing, all sorts of things that normally a static site might feel like a bad match for.

Jason Lengstorf 09:39: But with Gatsby, because it starts as a static site, and then rehydrates into an app, you don’t face those same limitations. You can do all the same things you would do with any React app.

Schepp 09:50: Right? So that would also probably mean that that GraphQL instance is not just used during build time, but it’s present all the time. So you can-

Jason Lengstorf 10:06: No.

Schepp 10:06: No? Okay.

Jason Lengstorf 10:08: It’s only available during the build. There is talk of figuring out how to make it available during the runtime. But one of the reasons that I actually like it as a build only tool is that once that site is built, once it hits the browser, there’s no longer any path back to a server. So you can’t really hack a Gatsby site, because there’s nothing underneath it to hack. It’s sitting on a CDN and it doesn’t have a live connection to a server, it doesn’t have a connection to a database.

Jason Lengstorf 10:41: So if it gets hacked, all you can do is deface the static files. And that to me is a very powerful way to approach that. So I tend to set up like a serverless API to handle any interactions. So on my site, for example, I’ve got a newsletter signup, or on our Swag Store we’ve got, you want to be able to log in and claim a discount code.

Jason Lengstorf 11:06: So when you hit those buttons, that just goes back to a Lambda function and that Lambda function has the privileged access. But you have to go to it to a very specific API. So it makes it more difficult… It just eliminates a lot of the attack surface that other, like WordPress is kind of a classic example, because it’s such an easy target.

Jason Lengstorf 11:27: But because the whole thing is sitting right there, the auth model, the users, everything is right there, right below the surface of that site. So there’s a bigger attack surface, there a lot of ways to try to get at it. And Gatsby, because that GraphQL data layer is only available during the build time, you can worry a little bit less about the security of that data layer. And instead, just expose very specific Lambda functions or an API or whatever you choose as a backend, to expose just the bits that you need, without exposing any of the other access.

Schepp 12:02: Makes sense. And GraphQL is, as you said, it’s like the unified data mesh, or the technical manifestation of that. Why… So for me, it sounds like the Gatsby makers came from a situation where they had like database specialists, and then frontend people and wanted to like have a clear cut and a nice interface between the two. But as a solo person working with Gatsby, what would be my benefit then? Or could I also circumvent GraphQL and go right to those other APIs if I wanted? Would that make sense or is it just nonsense?

Jason Lengstorf 13:05: Well, I’ll answer that in reverse. So your last question was, can you circumvent GraphQL? And absolutely, you can. So the way that I kind of explain this is we have a section on our docs called why Gatsby Uses GraphQL and it comes along with some videos and everything to try to explain this.

Jason Lengstorf 13:23: But ultimately, when you build a page in Gatsby, we have an API. So under the hood, Gatsby is just a collection of API hooks, and you can attach functions to those, to do various things. One of them is called create pages. And when you make a request to create a page, all you have to pass in is a path, so where you want the page to live and a component. And that’s a React component, and that React component will be rendered into your page.

Jason Lengstorf 13:50: So at minimum, you can just hardcode content into the React component and it’s going to work, you’re going to have a page up. If you want to take that a step further, your React component could make an asynchronous call to load data. Or, we have a context object that you can pass in with your create page call, that would allow you to set a title and body and categories and author and… it’s arbitrary data, whatever you want to pass into that context object. And then you can retrieve that from the props of the React component. So you can hardcode, that you could pull that in from… you could do a fetch call, and just loop through the response data and stick that in.

Jason Lengstorf 14:33: Where GraphQL starts to really show its power is when you start to look at the relationships between things. So if you’ve got a post and that post has an author and you want to get related posts and you want to get comments, what you would have to do is either build a very specific REST API, or you end up making a lot of different REST calls to load in data.

Jason Lengstorf 14:57: And that starts to put a lot of business logic into your web app. And your frontend shouldn’t necessarily have a lot of business logic. When I was working at IBM, one of my big goals there was to get as much business logic out of the UI tier as I could. And the reason that we turned to GraphQL is that GraphQL acts as this kind of data unification layer that allows arbitrary access by the frontend teams, where I can say, yeah, give me the post, and then give me the author and then give me that author’s posts. And then we filter out the one that matches this one.

Jason Lengstorf 15:32: And those are just nested GraphQL queries. Under the hood, GraphQL will do all that work to resolve the different calls and get the data from the right places and everything. But from a frontend developer standpoint, they just get to make up what would traditionally be kind of a bespoke REST endpoint that was, oh, for this UI at this URL, we need this data. So can you give us a REST endpoint that gives us that data? Which is a lot of work for the backend team. GraphQL just turns that into kind of an arbitrary like, well, let me plug in this field and this field, and let’s see what comes out.

Jason Lengstorf 16:06: And the way that GraphQL is set up during development, you can actually open a GraphQL, it’s called a… What is it? A playground. Or, there’s another tool called Graphical. And in both of those, you’re able to just write GraphQL queries and execute them in the browser and see what data comes back. And then when you’re happy with that, you can copy, paste that query into your frontend, and know that that data will be available as a prop in your React components.

Jason Lengstorf 16:34: So it’s a really, from the frontend developer experience standpoint, excuse me, from the frontend developer experience standpoint, it’s brilliant. Because it cuts out so much context that is usually required to access data. You don’t have to know how to send fetch calls, you don’t have to know how to deal with middle tiers, you don’t have to worry about database access or the security implications of that. You just get to say, I need some data to put on the screen and GraphQL handles that for you.

Schepp 17:03: And you also, you don’t need to wait for anybody to create your REST endpoint with exactly the data you need, because you can just, like you can request it such via GraphQL. And then it’s there.

Jason Lengstorf 17:22: Exactly.

Schepp 17:23: And probably also-

Jason Lengstorf 17:23: It cuts down iteration times.

Schepp 17:26: It also reduces latency, because you just have like one call and not many calls that you need to then mesh together in the client.

Jason Lengstorf 17:38: So when the GraphQL layer is implemented properly, yes, but like I said, under the hood, GraphQL is still making all of those calls-

Schepp 17:46: But on the server side.

Jason Lengstorf 17:47: But there are ways… On the server side, typically. And so when you see that, like it should improve performance. And there are ways that GraphQL is designed to de-duplicate calls and to have like short-term caching and to reuse calls when they go across queries. So it’s designed to be better at performance, but it is something that the implementing developer needs to think about. It’s not like magic. You have to make sure that you test that.

Jason Lengstorf 18:20: That’s not a Gatsby concern, to be clear. That’s if you’re building your own GraphQL server.

Schepp 00:18: :53] funded, then I would expect that there must be some business model somewhere.

Jason Lengstorf 19:00: There is a business model, but the ecosystem is not it. So our ecosystem, we have currently close to 900 plugins. And those plugins range from like data source plugins, where you can pull in stuff from you pretty much anything that you can imagine. Stripe, Shopify, Magento, big commerce, whatever you got, we can probably pull in the data from that through a source plugin.

Jason Lengstorf 19:25: And if you can’t, we’ve got docs on how to build a source plugin and we’d love to see that. There are also transformer plugins, so if you need to like change a JSON or YAML file into a queryable object, like we can do that for you. And then we have miscellaneous plugins to add, if you want to add analytics or you want to add Twitter embeds. Or, Benedict Ray put out this really cool oEmbed thing, so that you can write markdown and just paste in the URL of various social media things and it expands into a full embed.

Jason Lengstorf 19:57: So there’s a lot of really powerful stuff there. And then eventually, what we want is we want to create a marketplace where people can sell premium plugins. And that’ll be a small part of Gatsby’s revenue model, because we’ll be hosting that and handling returns and customer support and everything. So we’ll charge a fee on top of the resellers.

Jason Lengstorf 20:18: But the core of our business model is that we want people to be able to stand up like the infrastructure that makes it easier to collaborate and use Gatsby on bigger teams. So our first example of that, the first product that we released in beta is called Preview and it’s part of our Gatsby cloud offering. And Gatsby cloud is kind of the core of our commercial venture here.

Jason Lengstorf 20:44: And so in Gatsby cloud, we have this preview functionality where you’re able to, if you’re on Contentful, Sanity or any other supported headless CMS, you’re able to install a preview button in your CMS, make draft changes to the content, click that button, and it’ll open a private URL that you can password protect if you want, that you can then share it around to people to get feedback on draft content.

Jason Lengstorf 21:06: So as developers, this isn’t a big deal to us, because we have the local development environment, we can make some changes, we can mess around with stuff, and then just send that off to people as a staging branch or whatever we want to call it. But for someone who’s not a developer, this is a huge pain. And it’s been a big blocker for large teams, because the developers are very happy with Gatsby, but the content team, they’re really frustrated because they don’t want to have to install a local development environment. They don’t want to have to start, they never want to open their command line, they’d prefer to not know it exists.

Jason Lengstorf 21:38: So what Gatsby cloud is looking to do is take some of the stuff that teams have been standing up on their own, like a preview service and offer that as managed infrastructure. We will do it for you and we’ll do it for a lot less money than you would spend to pay somebody to set that up and manage it over time.

Jason Lengstorf 21:57: We’re looking to do the same thing with like highly optimized Gatsby builds. So if you have a huge site, and you need it to be up for a few seconds, we are working on the ability to run these incremental parallelized builds, that will drastically cut down the amount of time it takes to build large sites.

Jason Lengstorf 22:20: And so this would be, like Netlify is such a powerful tool. Once you hit a certain limit though, like it’ll timeout and it wouldn’t make sense for them to highly specialize on Gatsby, because they are a general tool. So we’re looking at like what happens once you exceed the limits of what Netlify is kind of incentivized to fix?

Jason Lengstorf 22:41: Well, then that’s where we would step in and build this kind of like highly customized build system. So that you’re able to then take your custom stuff, get those incremental builds going, get all that infrastructure. And again, this is something you could probably set up in-house, but it would be really expensive, you’d need people to man it full time.

Jason Lengstorf 22:59: But we want to kind of take that sort of work and make that something that you as a team can consider a solved problem. The same way that on the frontend, the reason that we ship Gatsby is so that you can consider performance and like easy deployments as a solved problem. We want to just kind of continue to step that out to support larger teams.

Schepp 23:22: Sounds really nice. Cool, so I’m going to ask you, maybe later a bit more about the cloud service. So I’d like to talk a bit about the frontend itself or the templates or the template engine and also the structure. So how would it work like creating a site?

Schepp 23:53: So I can probably just use, so it’s React based, so I can probably use the tools I know from the React ecosystem and Gatsby will just lay out my site based on, for example, React Router, stuff like that. Or is it more that it works similar to Next.js, or Nuxt, where you have a certain folder structure and that will end up as the pages later? No, it’s probably React Router, right?

Jason Lengstorf 24:32: Well, we can do both. So by default, if you were to create a new Gatsby site, you could initialize the package, install Gatsby, React and ReactDOM. Those are your three core dependencies. And then you could create a source pages, index.js. And then you could run Gatsby develop. And that would create a site with a homepage of whatever the content of index.js is.

Jason Lengstorf 24:59: As you start to expand, you can create custom pages using any of our APIs. And we use a Gatsby dash node or Gatsby dash browser or Gatsby dash SSR to those files. Sorry, Gatsby node, Gatsby browser and gatsby-ssr.js, that sit next to your package JSON. And those are where you would kind of register the custom hooks to do custom pages and any of those things.

Jason Lengstorf 25:26: Under the hood, what we’re doing is we’re taking anything in that pages folder, and anything that’s registered with the create pages API. We then stick that into Reach Router, which is Ryan Florence has been working on an accessible version of… He was working on React Router, and then he worked on Reach to focus on accessibility of routing.

Jason Lengstorf 25:48: And now there’s a plan to merge that backend. So Reach Router version five is going to adopt a lot of… React Router version five is going to adopt a lot of the Reach Router APIs and kind of take the best of both worlds and combine those together. So under the hood, we’re taking all of the pages that you’ve registered, setting them up as Reach Router routes, so that when you rehydrate on the browser, it works like a single page app and you’re using a routing solution.

Jason Lengstorf 26:17: So you can use anything from the React ecosystem. The only got you for Gatsby development is that if you’re going to access the window, you need to guard that statement by either putting it in a component did mount or use effect if you’re using React hooks, or you can do a check for like, if window is undefined, then skip this next step.

Jason Lengstorf 26:41: Those are really the major things that you’ve got to consider is like, if it’s compatible with server side rendering, it’s compatible with Gatsby, is kind of a general rule. And the way that we’ve set this up is we want this to be something where if you built an app with create React app, if you want to go the next step further and have it be statically compiled, putting it into Gatsby should be very near to a copy, paste effort.

Jason Lengstorf 27:08: It’s not quite that simple. But once you get the pages set up, it’s pretty straightforward and the React components are… We have helpers that Gatsby ships, like our GraphQL helpers, we have helpers for links and images. But for the most part, everything that you’re writing is just React. And you can use, like we use Formic, we use various design systems, we’ve seen people pull in all of the different flavors of CSS management, from plain CSS to CSS modules to CSS and JS and all of its various iterations.

Jason Lengstorf 27:45: All of those things are compatible with Gatsby. So yeah, it should be as simple as just like whatever you would do in a React app, you can do in Gatsby, as long as you’re guarding against window and you can shortcut things by putting things in that pages directory and getting those autorendered for you.

Schepp 28:02: All right. And then I have the impression that Gatsby also has some nice tricks up its sleeves regarding performance, like link pre-fetching and stuff like that. Is that correct?

Jason Lengstorf 28:22: Absolutely. One of the core philosophies of Gatsby is to make performances solve problem. And the way that we aim to do that is by taking all the recommendations of the web performance community. So code splitting and route pre-fetching, image lazy loading, asset management optimization, as many of those things as we can, we’ve just baked right into the Gatsby core.

Jason Lengstorf 28:49: So when you build a site, we’re going to do route based code splitting. When you use Gatsby link, we’re going to look at the visible links on the screen and any relative links will get pre-fetched in the background, which there are some considerations there. We won’t do that if you’re using data saver. We won’t do that if you’re on a slow connection.

Jason Lengstorf 29:10: But assuming you’re on a faster computer and that you don’t mind, we will pre-fetch in the background. We also do like image optimization, if you use Gatsby Image and the related plugins there, where we will generate all the different versions for different resolutions. We will create small preview images, so that you can do like Medium’s blur up effect is something that you can do with Gatsby just kind of out of the box. We can do traced SVGs so that it’s kind of a silhouette version that the computer finds the edges and traces a two tone version of the image. And then that’ll blur up.

Jason Lengstorf 29:49: There are all sorts of different options for how you can do these optimizations, but like all of them are set up to just happen out of the box. If you take our default starter and run it through performance tests, you’re going to score 100% on the Lighthouse test, you’ll get straight As on the webpagetest.org. That’s our target, we want to set people up to succeed by giving them a perfect starting point, or not perfect, but like a really, really strong starting point. So that they don’t have to do the performance tuning, they don’t necessarily need to think or become experts at performance. They just need to monitor that they’re not introducing degradations as they build.

Schepp 30:34: There’s a lot of stuff behind that. And I think it’s just so much to learn, and you’d still want to have a site that compares well to others and not just wait two years until you’ve dropped everything yourself. So that’s really nice.

Jason Lengstorf 30:55: Yeah, it’s one of the things that I talk about a lot, like performance is a career, there are multiple people who have made it their entire life’s work to get good at web performance. So expecting that someone whose job is to make a wonderful web experience to also become an expert in performance, you’re kind of asking them to do two jobs.

Jason Lengstorf 31:17: And we recognize that and not every team is able to afford a performance expert. So a lot of times what happens is that people do the things they know. And then they kind of do what they can with performance or with accessibility or with various DevOps setups. And then they have to stop and move on, because you have to ship things.

Jason Lengstorf 31:39: So we don’t want to put people in a position where they have to choose between performance and a good web experience. And by baking that performance in and we’re doing a lot of work to bake accessibility in and to make it easy to deploy, we want people to be experts… they should be able to be experts in what they’re experts in and not have to start these separate careers.

Schepp 32:01: Makes perfect sense. People can still evolve into that after a few years, but yeah, nice. You also touched accessibility. I’ve seen Marcy Sutton join your team, like maybe two, three months ago. So my question would be, what type of things are happening in the accessibility areas? So one thing is the usage of Reach, the Reach Router. Is there more you know of?

Jason Lengstorf 32:43: Yeah, Marcy is working on, so Reach was something that we started around the same time that we started talking to Marcy and kind of… Amberley Romo on our team has been a really good advocate for accessibility as well. And so she kind of brought some stuff up, we’ve always wanted to focus on it. And when Reach came out, it was just such an obvious like, oh, of course, we should do that. Like let’s bake accessibility into the routing solution.

Jason Lengstorf 33:11: What Mercy’s doing is, she’s helping us find the gaps in that, because automated testing, like the Lighthouse accessibility testing is good, but it’s not a magic bullet, it’s not going to solve all of your problems. So you still need to be mindful and understand how all of the things that you can’t automatically test, work.

Jason Lengstorf 33:34: And so Marcy has been really, really helpful at both helping us clean up our starter projects to make sure that they have all the accessibility that needs to be baked in, baked in. She is telling us about things that we didn’t know existed, she is setting us up for accessibility audits, by companies that are specifically set there. She wrote up an accessibility statement to kind of reinforce our commitment to doing it and to help hold us publicly accountable for meeting those commitments.

Jason Lengstorf 34:02: And along the way, she has also just like been teaching us so much. I did a live stream with her a while back on my Twitch channel, where we built a feedback widget. And just that little feedback widget, there were five or six things that I just did not know that I needed to consider when I was building interactions to make it accessible.

Jason Lengstorf 34:24: And so going through that with her and seeing her feedback on pull request is such an eye opening experience, because none of it is hard. It’s just stuff you have to know. And again, like it’s very difficult to become an expert in everything. So with Marcy on the team, we’re able to leverage her expertise to try to get as many good baseline defaults set, so that people don’t have to become accessibility experts.

Jason Lengstorf 34:49: And we’re also trying to work on like, can we do better automated testing, are there things that we can do in Gatsby that are harder to do in a generic sense, like Lighthouse that will help us catch more, and help us fix more of the accessibility problems that happen kind of inadvertently?

Jason Lengstorf 35:09: I mean, I feel like very little accessibility stuff, I feel like it doesn’t get ignored maliciously, it gets ignored because we don’t know that we should even be looking for it. So this is having someone, having two people, really, with Marcy and Amberley, both keeping us accountable and calling us out when we get things wrong, it helps remind us of what we don’t know. We’re seeing what we don’t know and then we just fix it.

Jason Lengstorf 35:35: And when we can do that in a way that scales out to everybody using Gatsby, that’s a huge win for the internet at large.

Schepp 35:41: Yes, especially if Gatsby is getting more and more popular and more and more sites are based on Gatsby, then it will really pay off to have some accessibility mindset. Also, I think it’s hard to do everything right, but if you already have all the maybe ready made components accessible and if you have these tutorials and if you have accessible routing and stuff like that, that’s already a huge win.

Jason Lengstorf 36:21: Absolutely, yeah. And we’re trying to, I’ve loved what the React community has been doing. I think Ryan Florence has done great work with Reach. Because Reach is not just a router, it’s also a UI. So there is like tab boxes and modals and all these components that are pretty common, and he just built them out to be accessible by default.

Jason Lengstorf 36:44: There’s another one that I think is called react Reakit, or I think that’s how you pronounce it, that’s another kind of accessible by default component system. And so we’ve been talking with the author of that to figure out like, how can we make sure this is Gatsby compatible and what can we do to help? So that, again, we’re able to ship very accessible by default, everything.

Jason Lengstorf 37:07: And Gatsby by default isn’t going to make a lot of assumptions about your UI. But as we get deeper into themes, people are going to be packaging up more and more UI functionality that is powered by Gatsby. So if we’re thinking about how are these design systems built, and are they as inclusive as they need to be? We can nudge people in the right direction by making sure that our theme starters are showing people how to do it the right way.

Jason Lengstorf 37:38: Or, if somebody is using a design system, we can recommend the accessible ones, so that people just kind of by default, start choosing solutions that like make their lives easier, because they’ve got all these prepackaged functionality. But that also solve a bunch of problems that they might not even know existed, like how to make a tab box accessible.

Schepp 38:01: That’s nice. I also felt for a long time that you had these accessibility people, these old school accessibility people that knew a lot, but that never made really the move into the JavaScript ecosystem. And then you had the JavaScripters, and they never made the move over to digging accessibility. And so it’s nice to see more and more of these hybrid people that are good at both things and that share their knowledge and teach people, like Marcy and Ryan and maybe also Manuel Matusovich and Hayden Pickering, for example.

Jason Lengstorf 38:55: I’ve been really, really happy to see… the world seemed to be shrinking. Because as the tools solve more and more of the generic problems, it leaves us extra time to focus on the hard problems. And I feel like for a long time, we were trying to figure out, well, how do we bundle JavaScript?

Jason Lengstorf 39:17: And that’s feeling more and more like a solved problem between Parcel and Webpack, you don’t really have to think about it too much. Because everybody ships with a preconfigured Webpack solution. Parcel is super easy to set up if you want to do something custom. And so you don’t really have to think about that so much. I mean, now you’ve got mental bandwidth.

Jason Lengstorf 39:37: And on top of that, the people working on the platform, have done a brilliant job of making JavaScript, even something that can be accessible. And I think that maybe a lot of the initial problems were around just like, how do you get a screen reader to read JavaScript? I actually have no idea what that path looked like, or how we got to where it works.

Jason Lengstorf 40:02: But that work needed to be done before people who were working in accessibility could even approach JavaScript. And the JavaScript folks needed to get to a point where accessibility was something that they understood was a problem. And I think that we’re starting to see that in the community, where more and more people are starting to embrace accessibility as a first class consideration.

Jason Lengstorf 40:25: It’s not a nice to have. It always kind of breaks my heart when you see somebody say like, well, we’ll get to accessibility if we have time. And it’s like, well, hold on, you’re just going to cut off like that many people from your website, because you don’t have time? Maybe deprioritize the animation first or something.

Jason Lengstorf 40:44: And so it’s really cool to see that both the tools and the platform have gotten us to a point where we have the bandwidth to focus on people, instead of focusing on wrangling technology. And you see that now, where developers have this focus on, how do we take care of the people who use our stuff? How do we take care of each other? How are we going to make JavaScript more welcoming?

Jason Lengstorf 41:12: We’ve seen it in the shift in Stack Overflow’s community policies, we’ve seen people like April Wensel launching Compassionate Coding. We’re seeing more and more communities focus on like being inclusive and welcoming, and not so elitist and kind of shutting people out. And all of that, I think, is adding up to be a really big net positive for the development community, we’re focusing on including everyone.

Jason Lengstorf 41:40: And that means, how can we make sure that our code is accessible? How can we make sure that our code isn’t inadvertently cutting people off? Or, like the web sites that we build aren’t shutting out like whole groups of people that maybe aren’t like us? It’s really interesting, and really heartening to see how many people are raising that banner and starting to work that way on the web.

Schepp 42:05: Yeah, definitely. Yeah. There’s also more and more of these talks popping up on conferences. It’s a nice development. Yes, indeed. So now, I’m totally hooked and I’d like to start creating my first site with Gatsby, how would I start? I would think on the Gatsby website, because there’s probably a tutorial or like a quick start section, sort of?

Jason Lengstorf 42:38: What I would recommend for everybody, if you’ve never used Gatsby before, is our tutorial is really, really thorough. And we have a, if you’re not super comfortable with like the command line or various parts of the ecosystem that we use, we have a part zero, which is going to do everything to get you started up from like how to use the command line on your computer, what is React, what is GraphQL? As basic as we can be, to try to give you the context and vocabulary that we’re going to use.

Jason Lengstorf 43:10: And then we just step through using Gatsby from installing the Gatsby CLI, building your first site and then we’ll walk through the simple stuff, like putting your first page in and slowly get more and more advanced as we go. Until by the end, you are writing custom GraphQL queries, you’re optimizing images, you’re deploying the site to Netlify, you’re doing all sorts of great stuff.

Jason Lengstorf 43:32: And so I think that’s a really good way to go. We do have a quick start, if you’ve used React and GraphQL before, that could be useful for just standing something up and seeing it work really fast. Or, if you just like to learn by diving into code, which that’s actually kind of how I like to learn is I want to open up a repo and pick it apart and see what it does.

Jason Lengstorf 9:00: a.m. Pacific time, where I build, almost every week it ends up being a Gatsby site of some sort. But I work with somebody from the community, from another company, and we use their tool to build something.

Jason Lengstorf 44:21: So we’ve got videos for how to build eCommerce with Stripe or how to use state machines. I did one with David Corsi on that, which was really fun. Marcy and I built that accessible feedback widget. We’ve built all sorts of things. And we’ve got some really exciting ones coming up as well, which are all listed on the Twitch page. Its twitch.tv/jlengstorf.

Jason Lengstorf 44:43: But yeah, there are a lot of ways to get in. We do our best to be kind of in every media, so that depending on what your preferred learning style is, we’ve got you covered.

Schepp 44:55: Nice. And the other thing would be, I’d like to come back once more to that cloud solution. So you said it’s still in a beta state, right? Is that correct?

Jason Lengstorf 45:12: Yes. So Gatsby cloud currently has the preview service, which is in a beta. We’re hoping to get that opened up soon, though I don’t know the exact dates. And we also have the incremental build system, is in like a very early alpha right now. So both of those products are coming down the pipeline, we’ve got a lot of plans on what we expect to launch kind of on the heels of this.

Jason Lengstorf 45:44: A lot of what we’re doing with commercial right now is laying a foundation, so that we can build the ambitious stuff that we think is kind of a uniquely Gatsby offering. Because Gatsby is an interesting tool, because we actually own the whole experience, like from where you start your website to where you theoretically deploy your website.

Jason Lengstorf 46:09: We have the ability to kind of touch the website at every stage. So we can do things that are pretty advanced, like pretty deep static analysis, and we know what Gatsby’s opinions are. And so we can dive into things that are difficult to do in a generic way.

Jason Lengstorf 46:28: So it should open the door for some really interesting reporting and profiling and different like performance and accessibility and other types of tuning that are uniquely possible, because Gatsby has those opinions and sets those defaults and guardrails. So stay tuned in this space, because I think Gatsby cloud is going to start out kind of like, that seems like a cool feature, to where I think the follow-on stuff is going to be really exciting, I think.

Schepp 47:05: Sounds good. I guess it’s also a matter of time, of having bigger and bigger customers, that then formulate new requirements or ideas that just happen when you scale. And then probably just do it sort of in a partnered way with you.

Jason Lengstorf 47:33: Yeah, I mean, that’s one of my favorite things about Gatsby is that we don’t really see ourselves as being competitive by nature. We see Gatsby as being an inherently collaborative tool, because we rely on third parties like the headless CMSs or deployment platforms like AWS, or Google Cloud, or Netlify. Each of those things is the thing that we like, we see ourselves as a partner to them, we’re sending them business, and they’re sending us business.

Jason Lengstorf 48:04: And as they improve, that makes the Gatsby experience better. As Gatsby improves, that makes their experience better. And I love that model of business, where each of us is kind of adding to the tide that lifts all ships, as opposed to saying like, well, it’s winner take all, we’ve got to take out this company or this company, so that we create space in the market. It’s like, no, we want to help that company. Because if their customers are happy, then those customers are going to be happy with our service too, because they add on to each other.

Jason Lengstorf 48:36: That’s important to me. I’m not a very competitive person. I like cooperative sports, not competitive sports.

Schepp 48:44: Yeah, they those are also the more interesting ones. I think if you reach a point where you have market saturation, and it’s just competition and taking over market shares, then it maybe also gets a bit boring, sort of. Might be.

Jason Lengstorf 49:05: I don’t know. I think there are people in many different camps. So I think everyone has their preferred working style. And I’ve heard this categorized a lot of different ways. One of the more recent ones that I’ve heard that I like, is this idea of like pioneers, town settlers and city planners. And so like in the early days of anything, it’s just kind of uncharted chaos. And so people who like to pioneer really enjoy that chaos, they’ll dive in, they’ll just try stuff, everything’s breaking all the time. It’s loosely controlled disorder, as you just explore and try things.

Jason Lengstorf 49:43: And as ideas start to form, then the pioneers tend to get bored, because there’s less chaos, things are starting to feel more stable. And then someone like a town settler comes in and takes the thing that is stable, but still pretty immature and then they kind of take it from being an immature seed of an idea that’s stable to an actual functional thing.

Jason Lengstorf 50:05: And then someone who’s more of a city planner is going to take something that’s matured, like this would be somebody who just really wants to go in and work on a product that is established and has a market share. And they want to incrementally improve it over time, and just make it into the best possible version of itself.

Jason Lengstorf 50:22: And all three of those roles are extremely valuable. And finding out which role suits your particular personality type is so… To me at least, learning that I kind of fall right between pioneers and town settlers, like I love experimentation in chaos, and I love taking something that’s new and making it viable. How can we turn this great idea into a business?

Jason Lengstorf 50:50: Knowing that about myself has really informed the way that I make decisions about my career. And I love talking to other people about this as well, because a lot of times people haven’t thought about it this way. And when they start thinking, they go, oh, so that’s why I really love this job, and then stop liking it. It’s because I shifted, I was a town settler, and then I shifted into being a city planner, and I don’t like city planning.

Jason Lengstorf 51:11: Or somebody else will say like, oh yeah, I hated this job, because it just felt like I never knew what was going on or everything was always so ambiguous. And it turns out they want to be a city planner, they want like clear cut goals and KPIs and something that they can really own and work toward, without that ambiguity or chaos.

Jason Lengstorf 51:28: I don’t know, I kind of got a little philosophical here, but I love this approach.

Schepp 51:34: I see your point. Totally. You’re right.

Schepp 51:42: One more question regarding the Gatsby cloud. So there’s just certain features that are beta, but the hosting is… right. Is that correct?

Jason Lengstorf 51:54: Sorry, can you say that again?

Schepp 51:56: So you mentioned the preview feature, and also the incremental build feature being beta and alpha. That would mean that the cloud or the hosting service that you offer, is that already available?

Jason Lengstorf 52:12: We don’t offer a hosting service. And I will never say never, but at the moment, what we prefer is to be, I kind of see us like when we offer like deployment, that deployment is going to go to Netlify for hosting or AWS or any kind of like bucket based storage. Because for us to stand up a hosting service seems, in my opinion, a little silly, because it’s like, well, why would we try to compete with something that’s so thoroughly established?

Jason Lengstorf 52:48: To me, that doesn’t make a whole ton of sense. So if we do have a hosting service, it’s probably going to be a white labeling instance of like, Fastly or something. So to me, it’s like, all right, well, if we’re going to white label Fastly, why not just have like Fastly as a deploy target? You know what I mean? Like maybe we’ll have a convenience layer where you can say, I don’t want to choose, just do a thing.

Jason Lengstorf 53:10: But ultimately, I think it’ll be more like I want to run a Gatsby deploy command, and it’ll go to, your preferred hosting provider will handle the orchestration of it.

Schepp 53:21: Yes. Okay. I just misunderstood. I interpreted it that way, that you offer similar things to Netlify or maybe also to I think SiteHQ, or now how is it called? And that’s why I asked you about the cloud services one more time.

Jason Lengstorf 53:48: I think over time, there will start to be some overlap. But at the moment, we think that both Zeit and Netlify are doing an amazing job, and it doesn’t make sense for us to try to compete, we should just work together. And there are things that it doesn’t make sense from a business standpoint for either them to focus on, because it’s hyper Gatsby specific. So we’re going to focus on the hyper Gatsby specifics at first. Because that’s clearly like where we can provide unique value.

Jason Lengstorf 54:16: And like maybe over time, there starts to be more overlap. But to me, it makes sense to avoid, like I said, avoid competition as long as possible. Let’s be as friendly as we can and kind of buoy each other as much as possible for as long as possible.

Schepp 54:35: I think there’s always enough stuff to find to work on. Right?

Jason Lengstorf 54:40: Mm-hmm (affirmative).

Schepp 54:42: Cool. So I don’t know, I have the impression that we got a nice overview of what Gatsby is, and also how you work with it and also what’s to come. I don’t know, did we forget anything? So I think we’ll write show notes, we’ll link to different things, we’ll also link to your Twitch, and to your Twitter account, of course.

Jason Lengstorf 55:17: And then the only other thing that we might want to include is just about our kind of community model. We talked a lot about including people, but we didn’t exactly talk about the specifics of Gatsby’s community. Because we have a lot of programs that we offer specifically to get people involved in open source. We do a free pair programming call where you can get 60 minutes with somebody on the core team to work on any open source project or getting involved in like your first pull request.

Jason Lengstorf 55:50: We also have a kind of contribution model, where if you get a pull request merged into the GatsbyJS.org, we will upon merging that PR, invite you to become a member of the org and also send you a discount code so you can claim some swag from our Swag Store. You get access to kind of like a private maintainers only group on GitHub, where you can get access to kind of our maintainer call and a lot of different discussion that happens about like very, very experimental features. So you kind of keep your finger on the pulse of where Gatsby’s going, you have influence over like where Gatsby goes, because you’re part of that early discussion.

Jason Lengstorf 56:32: Those are all really, really interesting things that we’re trying to do. Like, again, one of our company values is you belong here. And we really deeply want everybody, whether you’re a seasoned veteran or a first-time contributor to get involved in open source. And we’ve designed systems at Gatsby specifically to make that an approachable goal. So that’s something that’s really important to us, and that we’d love to see more people doing.

Schepp 56:59: Sounds really nice. I wouldn’t have expected that. Cool. Yes, thumbs up from my side. Good.

Jason Lengstorf 57:12: The link for that is, if you go to gatsby.dev/contribute, there’s a whole page on our docs about that.

Schepp 57:22: Yes. I just found it, also. Nice. Nice. We’ll read through it Cool. Well, Jason, thank you very much for sort of pinging us on the social channels. And I’m also super lucky that we saw that, and that we approached you and that you came into our show.

Jason Lengstorf 57:56: Yeah, thank you so much for the invite. I really appreciate it. I always have a blast doing these, so thanks a lot.

Schepp 58:04: All right. And so any of the listeners that wonder if this is a new podcast they should listen to, maybe not so much, because usually we are in German. It’s a long story. But basically, it’s just that in the German space, there was no podcast, whereas in the English space, there’s plenty. So we thought we would need something to cover that as well.

Schepp 58:34: And from time to time, we do English podcasting and I would suggest Follow us on Twitter. Our Twitter handle is workingdraft, and then you can already spot when we release new episodes. If it’s a German episode, which is usually the case, or if it’s an English one, because sometimes we have guests like Jason and sometimes we also go to conferences, where we pick the brains of speakers in shorter interviews. So have an eye on that.

Schepp 59:09: And that being said, thank you very much for listening. And again, thank you very much, Jason, for coming. Have a nice day. Bye.