BROADCASTS.com

Schepp had the great opportunity to sit together with Jason Lengstorf to talk\nabout Gatsby.js\n\n\nOUR SPONSOR\n\nThis Revision is sponsored by Storyblok. Storyblok is a headless CMS that\nstraddles the line between a CMS and a page builder like no other. Managing\ndigital content with a CMS can be a difficult task. Without a visual preview,\neditors are often lost and need instruction even for simple changes. Storyblok\nhas the user experience of a page builder with a modern, fully API-based\narchitecture behind. That gives the developer freedom in choice of technology\nand the editor a self-explaining and intuitive interface. For the Gatsby.js\nlovers: There is also a tutorial on how to integrate Storyblok in Gatsby.js.\n\n\n\nYou can read more about Storyblok and try their free plan, reach them on Twitter\nor in their live chat.\n\n\nSHOW NOTES\n\n[00:01:40] GATSBY.JS\n\nThere hasn\u2019t been a static site generator that got so much buzz like Gatsby.js.\nBased on React and GraphQL, it not only takes the hottest new techniques, but\nbridges the gap between static sites and app like no other. Plug any content\ninto any page, and get some nice HTML to deploy anywhere you like. Jason talks\nat lenghts about the big benefits from Gatsby.js, how it is build and why it is\na little bit more than just a static site generator. Namely a application\nframework based on pregenerated content. We also talk about where Gatsby still\nneeds improvement: How incremental builds shall slow down build times\ntremendously, and how investment in DX and learning will improve onboarding of\nnew developers. Last, but not least, we talk about how Gatsby.js the open source\nproject differs from Gatsby.js, the company, and how filling the shortcomings of\ntraditional static site generators shall create a sustainable pricing model.\nEnjoy!\n\n\nTRANSCRIPT\n\nThe fine folks from Gatsby provided a transcript of the show. Click on the\ndetails button to see the whole show in text:\n\nThe Transcript\n\nSchepp 00:00: Hello, and welcome to Working Draft, Revision 390.\n\nPeter 00:35: This Revision of Working Draft is brought to you by Storyblok.\nStoryblok is a headless content management system with an impressive visual\neditor that lets you change your webpage while you\u2019re browsing. This is quite\nuseful, but in my opinion, the most important thing about Storyblok is that it\nworks with any technology stack that you can think of. Storyblok works with PHP,\nand also with Node and of course with Ruby and with Gatsby and with basically\neverything else.\n\nPeter 00:59: And it does not only work with just about everything, but there\u2019s\nalso documentation for just about everything. The Storyblok team will even write\na tutorial just for you, and your strange tech stack, if whatever you\u2019re working\nwith is not covered by their existing documentation.\n\nPeter 01:13: You can try Storyblok for free for an unlimited time, as long as\nit\u2019s just you as a single user. So get started now at storyblok.com. That\u2019s\nstory, B-L-O-K, .com. Our thanks to Storyblok for supporting this Revision of\nWorking Draft.\n\nSchepp 01:29: As you might suspect, we will have a guest today. Usually, we\u2019re\nnot in English. We are two people. I\u2019m Christian, and our guest is Jason\nLengstorf. Hello.\n\nJason Lengstorf 01:42: Hey, thanks for having me.\n\nSchepp 01:44: Thanks for coming. So Jason, it\u2019s the first time that you appear\nin our podcast, so maybe you can tell the people who you are and what you\u2019re\ndoing.\n\nJason Lengstorf 01:55: Sure. My name is Jason Lengstorf. I am the Head of\nDeveloper Relations at Gatsby. Gatsby is a React and GraphQL powered framework\nfor building really high performance websites and apps that compile down to\nstatic assets, so they\u2019re easy to deploy.\n\nSchepp 02:13: All right, and where do you live? So where are you connected from?\n\nJason Lengstorf 02:20: I am based in Portland, Oregon, in the US.\n\nSchepp 02:24: All right, so it\u2019s basically the Brighton of the US, so to say,\nlike the creative city. Is that correct?\n\nJason Lengstorf 02:35: I mean, it is one of the creative cities. Actually, the\nreason that I moved out here is that years ago, I owned my own agency. And my\nagency was originally based in Montana, which is where I grew up. But I wanted\nmore geographical credibility, I wanted people to think that it was a hip\nagency.\n\nJason Lengstorf 02:54: So I moved to Portland, specifically, so people would\nhear it and say, \u201eThat\u2019s a hip agency. They\u2019re based in Portland.\u201c\n\nSchepp 03:00: Yeah, sure. It\u2019s the same in Germany. So you need to be in one of\nthe bigger cities or, yes, in a hip city. All right. So for how long are you\nnow, have you left behind your own company and have you joined Gatsby, the\nGatsby team?\n\nJason Lengstorf 03:21: I sold my agency in 2014, and then I did a little bit of\nconsulting, I worked at IBM for a while. And then I joined up at Gatsby in\nFebruary or March of last year.\n\nSchepp 03:38: And that is also due to Gatsby being quite a fresh project. So not\ntoo old. I think it started in 2017. So you couldn\u2019t really join much earlier\nthan that.\n\nJason Lengstorf 03:52: So Gatsby got funding in 2017, but it has been a project\nsince I believe 2015. Kyle Matthews, our CEO, was experimenting with React and\nGraphQL when they were really, really new technologies. And he\u2019s got a very\nright place, right time, he bet on the right horses, basically. And the\nframework that he put together for Gatsby has, it kind of matured at the same\ntime that the dev world was really embracing React, and we\u2019re seeing GraphQL\nbecome very stable.\n\nJason Lengstorf 04:29: So it\u2019s kind of a perfect storm of everything falling\ninto place for us.\n\nSchepp 04:34: Okay, nice. I heard for Webpack, it was a similar story, that\nWebpack was also around for much longer, and then at a certain point in time, I\nthink Instagram adopted it, and it was just the right thing at the right time,\nand then it just exploded. So it sounds pretty similar to Gatsby.\n\nJason Lengstorf 05:00: Yeah, mm-hmm (affirmative).\n\nSchepp 05:01: Also, I\u2019ve followed JSConf EU, the last week. I don\u2019t know if\nyou\u2019ve been there. I wasn\u2019t there, but I followed along and I\u2019ve seen one talk\nabout the JavaScript ecosystem on the server side. And Gatsby was also like the\nsystem right after the, let\u2019s say the old chap, Express, that was leading the\npack. So pretty popular.\n\nJason Lengstorf 05:37: I think the stats were really impressive. I think it was\nGatsby and Next had, I think Gatsby it was like 8% of NPM users are using\nGatsby, which was a great, like really, really encouraging for us to hear. And I\nthink Next had a pretty similar number.\n\nJason Lengstorf 05:54: So it\u2019s very cool to see that people are starting to\nembrace the server side or in Gatsby\u2019s case, kind of pre-rendering and the kind\nof letting a framework make a lot of the boilerplate decisions, so that you can\nfocus on building something, rather than having to set up all the foundational\nyak shaving work to even start building.\n\nSchepp 06:17: Yes, yeah. That\u2019s really nice. You said it\u2019s based on React. You\nsaid that a few sentences before, and also on GraphQL. And it\u2019s basically a CMS,\nor maybe not a CMS, but a static site generator, sort of.\n\nJason Lengstorf 06:44: I would characterize Gatsby as a content orchestration\nlayer. So we have, Sam Bhagwat, one of our co-founders wrote this article that\nsums up the concept really well as the content mesh. And it\u2019s the idea that\noriginally, everyone had to use kind of a single CMS system, where it was\nmonolithic. The CMS handled all of the data, all of the presentation layer,\neverything in between.\n\nJason Lengstorf 07:12: And as a result, when you were trying to build a website,\nyou had to make these trade-offs. Well, we do a blog and eCommerce and then you\nhad to decide which one was more important from a content management standpoint.\nAnd then choose the one that was pretty good, or like great at the thing you\nneeded, and only pretty good or even terrible at the thing that you also needed\nthat wasn\u2019t its kind of core focus.\n\nJason Lengstorf 07:33: A good example, this would be something like if you ever\nhad to build a Magento site, and get it to do anything other than eCommerce, it\nwas a nightmare. As the web has evolved, we\u2019ve been seeing this move toward more\nheadless CMSs. And what headless means is that you can take the CMS and then use\nit via API. So you\u2019re no longer bound to that CMS as a presentation layer. It\u2019s\nonly managing the data.\n\nJason Lengstorf 07:57: And with this, that opens up the door for you to say,\nhey, well, we have eCommerce and a blog, what\u2019s the best blogging CMS? And you\ncan go out and look around and find that. And then you can say, well, what\u2019s the\nbest eCommerce CMS? And you can go and look at that as well.\n\nJason Lengstorf 08:13: And then you pull those together into what we call the\ncontent mesh. And the way that Gatsby does that and the reason that we use\nGraphQL is that we\u2019re able to pull in data from any number of backends, whether\nthat\u2019s headless CMSs, databases, REST APIs, or even the file system, we pull all\nthat together and put it into a GraphQL layer, that for the frontend developers\nbuilding the site, the people actually building the Gatsby site, it feels the\nsame. Because the queries are similar, you say like give me all Shopify data or\nall WordPress blogs or all markdown files and then you just query the data\ninside of those and put it on the page.\n\nJason Lengstorf 08:50: So it feels very uniform. It\u2019s very transferable. You\ndon\u2019t have to become a Drupal expert, or whatever framework, Django. You don\u2019t\nhave to learn the deep, dirty details of how that system works. You just need to\nknow how to install the plugin and get an API key, so that we can pull that data\nin and let you use it.\n\nJason Lengstorf 09:11: In the sites that we build, they\u2019re static assets, but\nthat\u2019s not to say that they\u2019re static sites. So once they hit the browser, they\nactually rehydrate into full React apps. So once it\u2019s in the browser, it\u2019s a\nfull single page app. So you\u2019re able to do asynchronous data calls, you can do\nauthentication, dynamic routing, all sorts of things that normally a static site\nmight feel like a bad match for.\n\nJason Lengstorf 09:39: But with Gatsby, because it starts as a static site, and\nthen rehydrates into an app, you don\u2019t face those same limitations. You can do\nall the same things you would do with any React app.\n\nSchepp 09:50: Right? So that would also probably mean that that GraphQL instance\nis not just used during build time, but it\u2019s present all the time. So you can-\n\nJason Lengstorf 10:06: No.\n\nSchepp 10:06: No? Okay.\n\nJason Lengstorf 10:08: It\u2019s only available during the build. There is talk of\nfiguring out how to make it available during the runtime. But one of the reasons\nthat I actually like it as a build only tool is that once that site is built,\nonce it hits the browser, there\u2019s no longer any path back to a server. So you\ncan\u2019t really hack a Gatsby site, because there\u2019s nothing underneath it to hack.\nIt\u2019s sitting on a CDN and it doesn\u2019t have a live connection to a server, it\ndoesn\u2019t have a connection to a database.\n\nJason Lengstorf 10:41: So if it gets hacked, all you can do is deface the static\nfiles. And that to me is a very powerful way to approach that. So I tend to set\nup like a serverless API to handle any interactions. So on my site, for example,\nI\u2019ve got a newsletter signup, or on our Swag Store we\u2019ve got, you want to be\nable to log in and claim a discount code.\n\nJason Lengstorf 11:06: So when you hit those buttons, that just goes back to a\nLambda function and that Lambda function has the privileged access. But you have\nto go to it to a very specific API. So it makes it more difficult\u2026 It just\neliminates a lot of the attack surface that other, like WordPress is kind of a\nclassic example, because it\u2019s such an easy target.\n\nJason Lengstorf 11:27: But because the whole thing is sitting right there, the\nauth model, the users, everything is right there, right below the surface of\nthat site. So there\u2019s a bigger attack surface, there a lot of ways to try to get\nat it. And Gatsby, because that GraphQL data layer is only available during the\nbuild time, you can worry a little bit less about the security of that data\nlayer. And instead, just expose very specific Lambda functions or an API or\nwhatever you choose as a backend, to expose just the bits that you need, without\nexposing any of the other access.\n\nSchepp 12:02: Makes sense. And GraphQL is, as you said, it\u2019s like the unified\ndata mesh, or the technical manifestation of that. Why\u2026 So for me, it sounds\nlike the Gatsby makers came from a situation where they had like database\nspecialists, and then frontend people and wanted to like have a clear cut and a\nnice interface between the two. But as a solo person working with Gatsby, what\nwould be my benefit then? Or could I also circumvent GraphQL and go right to\nthose other APIs if I wanted? Would that make sense or is it just nonsense?\n\nJason Lengstorf 13:05: Well, I\u2019ll answer that in reverse. So your last question\nwas, can you circumvent GraphQL? And absolutely, you can. So the way that I kind\nof explain this is we have a section on our docs called why Gatsby Uses GraphQL\nand it comes along with some videos and everything to try to explain this.\n\nJason Lengstorf 13:23: But ultimately, when you build a page in Gatsby, we have\nan API. So under the hood, Gatsby is just a collection of API hooks, and you can\nattach functions to those, to do various things. One of them is called create\npages. And when you make a request to create a page, all you have to pass in is\na path, so where you want the page to live and a component. And that\u2019s a React\ncomponent, and that React component will be rendered into your page.\n\nJason Lengstorf 13:50: So at minimum, you can just hardcode content into the\nReact component and it\u2019s going to work, you\u2019re going to have a page up. If you\nwant to take that a step further, your React component could make an\nasynchronous call to load data. Or, we have a context object that you can pass\nin with your create page call, that would allow you to set a title and body and\ncategories and author and\u2026 it\u2019s arbitrary data, whatever you want to pass into\nthat context object. And then you can retrieve that from the props of the React\ncomponent. So you can hardcode, that you could pull that in from\u2026 you could do a\nfetch call, and just loop through the response data and stick that in.\n\nJason Lengstorf 14:33: Where GraphQL starts to really show its power is when you\nstart to look at the relationships between things. So if you\u2019ve got a post and\nthat post has an author and you want to get related posts and you want to get\ncomments, what you would have to do is either build a very specific REST API, or\nyou end up making a lot of different REST calls to load in data.\n\nJason Lengstorf 14:57: And that starts to put a lot of business logic into your\nweb app. And your frontend shouldn\u2019t necessarily have a lot of business logic.\nWhen I was working at IBM, one of my big goals there was to get as much business\nlogic out of the UI tier as I could. And the reason that we turned to GraphQL is\nthat GraphQL acts as this kind of data unification layer that allows arbitrary\naccess by the frontend teams, where I can say, yeah, give me the post, and then\ngive me the author and then give me that author\u2019s posts. And then we filter out\nthe one that matches this one.\n\nJason Lengstorf 15:32: And those are just nested GraphQL queries. Under the\nhood, GraphQL will do all that work to resolve the different calls and get the\ndata from the right places and everything. But from a frontend developer\nstandpoint, they just get to make up what would traditionally be kind of a\nbespoke REST endpoint that was, oh, for this UI at this URL, we need this data.\nSo can you give us a REST endpoint that gives us that data? Which is a lot of\nwork for the backend team. GraphQL just turns that into kind of an arbitrary\nlike, well, let me plug in this field and this field, and let\u2019s see what comes\nout.\n\nJason Lengstorf 16:06: And the way that GraphQL is set up during development,\nyou can actually open a GraphQL, it\u2019s called a\u2026 What is it? A playground. Or,\nthere\u2019s another tool called Graphical. And in both of those, you\u2019re able to just\nwrite GraphQL queries and execute them in the browser and see what data comes\nback. And then when you\u2019re happy with that, you can copy, paste that query into\nyour frontend, and know that that data will be available as a prop in your React\ncomponents.\n\nJason Lengstorf 16:34: So it\u2019s a really, from the frontend developer experience\nstandpoint, excuse me, from the frontend developer experience standpoint, it\u2019s\nbrilliant. Because it cuts out so much context that is usually required to\naccess data. You don\u2019t have to know how to send fetch calls, you don\u2019t have to\nknow how to deal with middle tiers, you don\u2019t have to worry about database\naccess or the security implications of that. You just get to say, I need some\ndata to put on the screen and GraphQL handles that for you.\n\nSchepp 17:03: And you also, you don\u2019t need to wait for anybody to create your\nREST endpoint with exactly the data you need, because you can just, like you can\nrequest it such via GraphQL. And then it\u2019s there.\n\nJason Lengstorf 17:22: Exactly.\n\nSchepp 17:23: And probably also-\n\nJason Lengstorf 17:23: It cuts down iteration times.\n\nSchepp 17:26: It also reduces latency, because you just have like one call and\nnot many calls that you need to then mesh together in the client.\n\nJason Lengstorf 17:38: So when the GraphQL layer is implemented properly, yes,\nbut like I said, under the hood, GraphQL is still making all of those calls-\n\nSchepp 17:46: But on the server side.\n\nJason Lengstorf 17:47: But there are ways\u2026 On the server side, typically. And so\nwhen you see that, like it should improve performance. And there are ways that\nGraphQL is designed to de-duplicate calls and to have like short-term caching\nand to reuse calls when they go across queries. So it\u2019s designed to be better at\nperformance, but it is something that the implementing developer needs to think\nabout. It\u2019s not like magic. You have to make sure that you test that.\n\nJason Lengstorf 18:20: That\u2019s not a Gatsby concern, to be clear. That\u2019s if\nyou\u2019re building your own GraphQL server.\n\nSchepp 00:18: :53] funded, then I would expect that there must be some business\nmodel somewhere.\n\nJason Lengstorf 19:00: There is a business model, but the ecosystem is not it.\nSo our ecosystem, we have currently close to 900 plugins. And those plugins\nrange from like data source plugins, where you can pull in stuff from you pretty\nmuch anything that you can imagine. Stripe, Shopify, Magento, big commerce,\nwhatever you got, we can probably pull in the data from that through a source\nplugin.\n\nJason Lengstorf 19:25: And if you can\u2019t, we\u2019ve got docs on how to build a source\nplugin and we\u2019d love to see that. There are also transformer plugins, so if you\nneed to like change a JSON or YAML file into a queryable object, like we can do\nthat for you. And then we have miscellaneous plugins to add, if you want to add\nanalytics or you want to add Twitter embeds. Or, Benedict Ray put out this\nreally cool oEmbed thing, so that you can write markdown and just paste in the\nURL of various social media things and it expands into a full embed.\n\nJason Lengstorf 19:57: So there\u2019s a lot of really powerful stuff there. And then\neventually, what we want is we want to create a marketplace where people can\nsell premium plugins. And that\u2019ll be a small part of Gatsby\u2019s revenue model,\nbecause we\u2019ll be hosting that and handling returns and customer support and\neverything. So we\u2019ll charge a fee on top of the resellers.\n\nJason Lengstorf 20:18: But the core of our business model is that we want people\nto be able to stand up like the infrastructure that makes it easier to\ncollaborate and use Gatsby on bigger teams. So our first example of that, the\nfirst product that we released in beta is called Preview and it\u2019s part of our\nGatsby cloud offering. And Gatsby cloud is kind of the core of our commercial\nventure here.\n\nJason Lengstorf 20:44: And so in Gatsby cloud, we have this preview\nfunctionality where you\u2019re able to, if you\u2019re on Contentful, Sanity or any other\nsupported headless CMS, you\u2019re able to install a preview button in your CMS,\nmake draft changes to the content, click that button, and it\u2019ll open a private\nURL that you can password protect if you want, that you can then share it around\nto people to get feedback on draft content.\n\nJason Lengstorf 21:06: So as developers, this isn\u2019t a big deal to us, because we\nhave the local development environment, we can make some changes, we can mess\naround with stuff, and then just send that off to people as a staging branch or\nwhatever we want to call it. But for someone who\u2019s not a developer, this is a\nhuge pain. And it\u2019s been a big blocker for large teams, because the developers\nare very happy with Gatsby, but the content team, they\u2019re really frustrated\nbecause they don\u2019t want to have to install a local development environment. They\ndon\u2019t want to have to start, they never want to open their command line, they\u2019d\nprefer to not know it exists.\n\nJason Lengstorf 21:38: So what Gatsby cloud is looking to do is take some of the\nstuff that teams have been standing up on their own, like a preview service and\noffer that as managed infrastructure. We will do it for you and we\u2019ll do it for\na lot less money than you would spend to pay somebody to set that up and manage\nit over time.\n\nJason Lengstorf 21:57: We\u2019re looking to do the same thing with like highly\noptimized Gatsby builds. So if you have a huge site, and you need it to be up\nfor a few seconds, we are working on the ability to run these incremental\nparallelized builds, that will drastically cut down the amount of time it takes\nto build large sites.\n\nJason Lengstorf 22:20: And so this would be, like Netlify is such a powerful\ntool. Once you hit a certain limit though, like it\u2019ll timeout and it wouldn\u2019t\nmake sense for them to highly specialize on Gatsby, because they are a general\ntool. So we\u2019re looking at like what happens once you exceed the limits of what\nNetlify is kind of incentivized to fix?\n\nJason Lengstorf 22:41: Well, then that\u2019s where we would step in and build this\nkind of like highly customized build system. So that you\u2019re able to then take\nyour custom stuff, get those incremental builds going, get all that\ninfrastructure. And again, this is something you could probably set up in-house,\nbut it would be really expensive, you\u2019d need people to man it full time.\n\nJason Lengstorf 22:59: But we want to kind of take that sort of work and make\nthat something that you as a team can consider a solved problem. The same way\nthat on the frontend, the reason that we ship Gatsby is so that you can consider\nperformance and like easy deployments as a solved problem. We want to just kind\nof continue to step that out to support larger teams.\n\nSchepp 23:22: Sounds really nice. Cool, so I\u2019m going to ask you, maybe later a\nbit more about the cloud service. So I\u2019d like to talk a bit about the frontend\nitself or the templates or the template engine and also the structure. So how\nwould it work like creating a site?\n\nSchepp 23:53: So I can probably just use, so it\u2019s React based, so I can probably\nuse the tools I know from the React ecosystem and Gatsby will just lay out my\nsite based on, for example, React Router, stuff like that. Or is it more that it\nworks similar to Next.js, or Nuxt, where you have a certain folder structure and\nthat will end up as the pages later? No, it\u2019s probably React Router, right?\n\nJason Lengstorf 24:32: Well, we can do both. So by default, if you were to\ncreate a new Gatsby site, you could initialize the package, install Gatsby,\nReact and ReactDOM. Those are your three core dependencies. And then you could\ncreate a source pages, index.js. And then you could run Gatsby develop. And that\nwould create a site with a homepage of whatever the content of index.js is.\n\nJason Lengstorf 24:59: As you start to expand, you can create custom pages using\nany of our APIs. And we use a Gatsby dash node or Gatsby dash browser or Gatsby\ndash SSR to those files. Sorry, Gatsby node, Gatsby browser and gatsby-ssr.js,\nthat sit next to your package JSON. And those are where you would kind of\nregister the custom hooks to do custom pages and any of those things.\n\nJason Lengstorf 25:26: Under the hood, what we\u2019re doing is we\u2019re taking anything\nin that pages folder, and anything that\u2019s registered with the create pages API.\nWe then stick that into Reach Router, which is Ryan Florence has been working on\nan accessible version of\u2026 He was working on React Router, and then he worked on\nReach to focus on accessibility of routing.\n\nJason Lengstorf 25:48: And now there\u2019s a plan to merge that backend. So Reach\nRouter version five is going to adopt a lot of\u2026 React Router version five is\ngoing to adopt a lot of the Reach Router APIs and kind of take the best of both\nworlds and combine those together. So under the hood, we\u2019re taking all of the\npages that you\u2019ve registered, setting them up as Reach Router routes, so that\nwhen you rehydrate on the browser, it works like a single page app and you\u2019re\nusing a routing solution.\n\nJason Lengstorf 26:17: So you can use anything from the React ecosystem. The\nonly got you for Gatsby development is that if you\u2019re going to access the\nwindow, you need to guard that statement by either putting it in a component did\nmount or use effect if you\u2019re using React hooks, or you can do a check for like,\nif window is undefined, then skip this next step.\n\nJason Lengstorf 26:41: Those are really the major things that you\u2019ve got to\nconsider is like, if it\u2019s compatible with server side rendering, it\u2019s compatible\nwith Gatsby, is kind of a general rule. And the way that we\u2019ve set this up is we\nwant this to be something where if you built an app with create React app, if\nyou want to go the next step further and have it be statically compiled, putting\nit into Gatsby should be very near to a copy, paste effort.\n\nJason Lengstorf 27:08: It\u2019s not quite that simple. But once you get the pages\nset up, it\u2019s pretty straightforward and the React components are\u2026 We have\nhelpers that Gatsby ships, like our GraphQL helpers, we have helpers for links\nand images. But for the most part, everything that you\u2019re writing is just React.\nAnd you can use, like we use Formic, we use various design systems, we\u2019ve seen\npeople pull in all of the different flavors of CSS management, from plain CSS to\nCSS modules to CSS and JS and all of its various iterations.\n\nJason Lengstorf 27:45: All of those things are compatible with Gatsby. So yeah,\nit should be as simple as just like whatever you would do in a React app, you\ncan do in Gatsby, as long as you\u2019re guarding against window and you can shortcut\nthings by putting things in that pages directory and getting those autorendered\nfor you.\n\nSchepp 28:02: All right. And then I have the impression that Gatsby also has\nsome nice tricks up its sleeves regarding performance, like link pre-fetching\nand stuff like that. Is that correct?\n\nJason Lengstorf 28:22: Absolutely. One of the core philosophies of Gatsby is to\nmake performances solve problem. And the way that we aim to do that is by taking\nall the recommendations of the web performance community. So code splitting and\nroute pre-fetching, image lazy loading, asset management optimization, as many\nof those things as we can, we\u2019ve just baked right into the Gatsby core.\n\nJason Lengstorf 28:49: So when you build a site, we\u2019re going to do route based\ncode splitting. When you use Gatsby link, we\u2019re going to look at the visible\nlinks on the screen and any relative links will get pre-fetched in the\nbackground, which there are some considerations there. We won\u2019t do that if\nyou\u2019re using data saver. We won\u2019t do that if you\u2019re on a slow connection.\n\nJason Lengstorf 29:10: But assuming you\u2019re on a faster computer and that you\ndon\u2019t mind, we will pre-fetch in the background. We also do like image\noptimization, if you use Gatsby Image and the related plugins there, where we\nwill generate all the different versions for different resolutions. We will\ncreate small preview images, so that you can do like Medium\u2019s blur up effect is\nsomething that you can do with Gatsby just kind of out of the box. We can do\ntraced SVGs so that it\u2019s kind of a silhouette version that the computer finds\nthe edges and traces a two tone version of the image. And then that\u2019ll blur up.\n\nJason Lengstorf 29:49: There are all sorts of different options for how you can\ndo these optimizations, but like all of them are set up to just happen out of\nthe box. If you take our default starter and run it through performance tests,\nyou\u2019re going to score 100% on the Lighthouse test, you\u2019ll get straight As on the\nwebpagetest.org. That\u2019s our target, we want to set people up to succeed by\ngiving them a perfect starting point, or not perfect, but like a really, really\nstrong starting point. So that they don\u2019t have to do the performance tuning,\nthey don\u2019t necessarily need to think or become experts at performance. They just\nneed to monitor that they\u2019re not introducing degradations as they build.\n\nSchepp 30:34: There\u2019s a lot of stuff behind that. And I think it\u2019s just so much\nto learn, and you\u2019d still want to have a site that compares well to others and\nnot just wait two years until you\u2019ve dropped everything yourself. So that\u2019s\nreally nice.\n\nJason Lengstorf 30:55: Yeah, it\u2019s one of the things that I talk about a lot,\nlike performance is a career, there are multiple people who have made it their\nentire life\u2019s work to get good at web performance. So expecting that someone\nwhose job is to make a wonderful web experience to also become an expert in\nperformance, you\u2019re kind of asking them to do two jobs.\n\nJason Lengstorf 31:17: And we recognize that and not every team is able to\nafford a performance expert. So a lot of times what happens is that people do\nthe things they know. And then they kind of do what they can with performance or\nwith accessibility or with various DevOps setups. And then they have to stop and\nmove on, because you have to ship things.\n\nJason Lengstorf 31:39: So we don\u2019t want to put people in a position where they\nhave to choose between performance and a good web experience. And by baking that\nperformance in and we\u2019re doing a lot of work to bake accessibility in and to\nmake it easy to deploy, we want people to be experts\u2026 they should be able to be\nexperts in what they\u2019re experts in and not have to start these separate careers.\n\nSchepp 32:01: Makes perfect sense. People can still evolve into that after a few\nyears, but yeah, nice. You also touched accessibility. I\u2019ve seen Marcy Sutton\njoin your team, like maybe two, three months ago. So my question would be, what\ntype of things are happening in the accessibility areas? So one thing is the\nusage of Reach, the Reach Router. Is there more you know of?\n\nJason Lengstorf 32:43: Yeah, Marcy is working on, so Reach was something that we\nstarted around the same time that we started talking to Marcy and kind of\u2026\nAmberley Romo on our team has been a really good advocate for accessibility as\nwell. And so she kind of brought some stuff up, we\u2019ve always wanted to focus on\nit. And when Reach came out, it was just such an obvious like, oh, of course, we\nshould do that. Like let\u2019s bake accessibility into the routing solution.\n\nJason Lengstorf 33:11: What Mercy\u2019s doing is, she\u2019s helping us find the gaps in\nthat, because automated testing, like the Lighthouse accessibility testing is\ngood, but it\u2019s not a magic bullet, it\u2019s not going to solve all of your problems.\nSo you still need to be mindful and understand how all of the things that you\ncan\u2019t automatically test, work.\n\nJason Lengstorf 33:34: And so Marcy has been really, really helpful at both\nhelping us clean up our starter projects to make sure that they have all the\naccessibility that needs to be baked in, baked in. She is telling us about\nthings that we didn\u2019t know existed, she is setting us up for accessibility\naudits, by companies that are specifically set there. She wrote up an\naccessibility statement to kind of reinforce our commitment to doing it and to\nhelp hold us publicly accountable for meeting those commitments.\n\nJason Lengstorf 34:02: And along the way, she has also just like been teaching\nus so much. I did a live stream with her a while back on my Twitch channel,\nwhere we built a feedback widget. And just that little feedback widget, there\nwere five or six things that I just did not know that I needed to consider when\nI was building interactions to make it accessible.\n\nJason Lengstorf 34:24: And so going through that with her and seeing her\nfeedback on pull request is such an eye opening experience, because none of it\nis hard. It\u2019s just stuff you have to know. And again, like it\u2019s very difficult\nto become an expert in everything. So with Marcy on the team, we\u2019re able to\nleverage her expertise to try to get as many good baseline defaults set, so that\npeople don\u2019t have to become accessibility experts.\n\nJason Lengstorf 34:49: And we\u2019re also trying to work on like, can we do better\nautomated testing, are there things that we can do in Gatsby that are harder to\ndo in a generic sense, like Lighthouse that will help us catch more, and help us\nfix more of the accessibility problems that happen kind of inadvertently?\n\nJason Lengstorf 35:09: I mean, I feel like very little accessibility stuff, I\nfeel like it doesn\u2019t get ignored maliciously, it gets ignored because we don\u2019t\nknow that we should even be looking for it. So this is having someone, having\ntwo people, really, with Marcy and Amberley, both keeping us accountable and\ncalling us out when we get things wrong, it helps remind us of what we don\u2019t\nknow. We\u2019re seeing what we don\u2019t know and then we just fix it.\n\nJason Lengstorf 35:35: And when we can do that in a way that scales out to\neverybody using Gatsby, that\u2019s a huge win for the internet at large.\n\nSchepp 35:41: Yes, especially if Gatsby is getting more and more popular and\nmore and more sites are based on Gatsby, then it will really pay off to have\nsome accessibility mindset. Also, I think it\u2019s hard to do everything right, but\nif you already have all the maybe ready made components accessible and if you\nhave these tutorials and if you have accessible routing and stuff like that,\nthat\u2019s already a huge win.\n\nJason Lengstorf 36:21: Absolutely, yeah. And we\u2019re trying to, I\u2019ve loved what\nthe React community has been doing. I think Ryan Florence has done great work\nwith Reach. Because Reach is not just a router, it\u2019s also a UI. So there is like\ntab boxes and modals and all these components that are pretty common, and he\njust built them out to be accessible by default.\n\nJason Lengstorf 36:44: There\u2019s another one that I think is called react Reakit,\nor I think that\u2019s how you pronounce it, that\u2019s another kind of accessible by\ndefault component system. And so we\u2019ve been talking with the author of that to\nfigure out like, how can we make sure this is Gatsby compatible and what can we\ndo to help? So that, again, we\u2019re able to ship very accessible by default,\neverything.\n\nJason Lengstorf 37:07: And Gatsby by default isn\u2019t going to make a lot of\nassumptions about your UI. But as we get deeper into themes, people are going to\nbe packaging up more and more UI functionality that is powered by Gatsby. So if\nwe\u2019re thinking about how are these design systems built, and are they as\ninclusive as they need to be? We can nudge people in the right direction by\nmaking sure that our theme starters are showing people how to do it the right\nway.\n\nJason Lengstorf 37:38: Or, if somebody is using a design system, we can\nrecommend the accessible ones, so that people just kind of by default, start\nchoosing solutions that like make their lives easier, because they\u2019ve got all\nthese prepackaged functionality. But that also solve a bunch of problems that\nthey might not even know existed, like how to make a tab box accessible.\n\nSchepp 38:01: That\u2019s nice. I also felt for a long time that you had these\naccessibility people, these old school accessibility people that knew a lot, but\nthat never made really the move into the JavaScript ecosystem. And then you had\nthe JavaScripters, and they never made the move over to digging accessibility.\nAnd so it\u2019s nice to see more and more of these hybrid people that are good at\nboth things and that share their knowledge and teach people, like Marcy and Ryan\nand maybe also Manuel Matusovich and Hayden Pickering, for example.\n\nJason Lengstorf 38:55: I\u2019ve been really, really happy to see\u2026 the world seemed\nto be shrinking. Because as the tools solve more and more of the generic\nproblems, it leaves us extra time to focus on the hard problems. And I feel like\nfor a long time, we were trying to figure out, well, how do we bundle\nJavaScript?\n\nJason Lengstorf 39:17: And that\u2019s feeling more and more like a solved problem\nbetween Parcel and Webpack, you don\u2019t really have to think about it too much.\nBecause everybody ships with a preconfigured Webpack solution. Parcel is super\neasy to set up if you want to do something custom. And so you don\u2019t really have\nto think about that so much. I mean, now you\u2019ve got mental bandwidth.\n\nJason Lengstorf 39:37: And on top of that, the people working on the platform,\nhave done a brilliant job of making JavaScript, even something that can be\naccessible. And I think that maybe a lot of the initial problems were around\njust like, how do you get a screen reader to read JavaScript? I actually have no\nidea what that path looked like, or how we got to where it works.\n\nJason Lengstorf 40:02: But that work needed to be done before people who were\nworking in accessibility could even approach JavaScript. And the JavaScript\nfolks needed to get to a point where accessibility was something that they\nunderstood was a problem. And I think that we\u2019re starting to see that in the\ncommunity, where more and more people are starting to embrace accessibility as a\nfirst class consideration.\n\nJason Lengstorf 40:25: It\u2019s not a nice to have. It always kind of breaks my\nheart when you see somebody say like, well, we\u2019ll get to accessibility if we\nhave time. And it\u2019s like, well, hold on, you\u2019re just going to cut off like that\nmany people from your website, because you don\u2019t have time? Maybe deprioritize\nthe animation first or something.\n\nJason Lengstorf 40:44: And so it\u2019s really cool to see that both the tools and\nthe platform have gotten us to a point where we have the bandwidth to focus on\npeople, instead of focusing on wrangling technology. And you see that now, where\ndevelopers have this focus on, how do we take care of the people who use our\nstuff? How do we take care of each other? How are we going to make JavaScript\nmore welcoming?\n\nJason Lengstorf 41:12: We\u2019ve seen it in the shift in Stack Overflow\u2019s community\npolicies, we\u2019ve seen people like April Wensel launching Compassionate Coding.\nWe\u2019re seeing more and more communities focus on like being inclusive and\nwelcoming, and not so elitist and kind of shutting people out. And all of that,\nI think, is adding up to be a really big net positive for the development\ncommunity, we\u2019re focusing on including everyone.\n\nJason Lengstorf 41:40: And that means, how can we make sure that our code is\naccessible? How can we make sure that our code isn\u2019t inadvertently cutting\npeople off? Or, like the web sites that we build aren\u2019t shutting out like whole\ngroups of people that maybe aren\u2019t like us? It\u2019s really interesting, and really\nheartening to see how many people are raising that banner and starting to work\nthat way on the web.\n\nSchepp 42:05: Yeah, definitely. Yeah. There\u2019s also more and more of these talks\npopping up on conferences. It\u2019s a nice development. Yes, indeed. So now, I\u2019m\ntotally hooked and I\u2019d like to start creating my first site with Gatsby, how\nwould I start? I would think on the Gatsby website, because there\u2019s probably a\ntutorial or like a quick start section, sort of?\n\nJason Lengstorf 42:38: What I would recommend for everybody, if you\u2019ve never\nused Gatsby before, is our tutorial is really, really thorough. And we have a,\nif you\u2019re not super comfortable with like the command line or various parts of\nthe ecosystem that we use, we have a part zero, which is going to do everything\nto get you started up from like how to use the command line on your computer,\nwhat is React, what is GraphQL? As basic as we can be, to try to give you the\ncontext and vocabulary that we\u2019re going to use.\n\nJason Lengstorf 43:10: And then we just step through using Gatsby from\ninstalling the Gatsby CLI, building your first site and then we\u2019ll walk through\nthe simple stuff, like putting your first page in and slowly get more and more\nadvanced as we go. Until by the end, you are writing custom GraphQL queries,\nyou\u2019re optimizing images, you\u2019re deploying the site to Netlify, you\u2019re doing all\nsorts of great stuff.\n\nJason Lengstorf 43:32: And so I think that\u2019s a really good way to go. We do have\na quick start, if you\u2019ve used React and GraphQL before, that could be useful for\njust standing something up and seeing it work really fast. Or, if you just like\nto learn by diving into code, which that\u2019s actually kind of how I like to learn\nis I want to open up a repo and pick it apart and see what it does.\n\nJason Lengstorf 9:00: a.m. Pacific time, where I build, almost every week it\nends up being a Gatsby site of some sort. But I work with somebody from the\ncommunity, from another company, and we use their tool to build something.\n\nJason Lengstorf 44:21: So we\u2019ve got videos for how to build eCommerce with\nStripe or how to use state machines. I did one with David Corsi on that, which\nwas really fun. Marcy and I built that accessible feedback widget. We\u2019ve built\nall sorts of things. And we\u2019ve got some really exciting ones coming up as well,\nwhich are all listed on the Twitch page. Its twitch.tv/jlengstorf.\n\nJason Lengstorf 44:43: But yeah, there are a lot of ways to get in. We do our\nbest to be kind of in every media, so that depending on what your preferred\nlearning style is, we\u2019ve got you covered.\n\nSchepp 44:55: Nice. And the other thing would be, I\u2019d like to come back once\nmore to that cloud solution. So you said it\u2019s still in a beta state, right? Is\nthat correct?\n\nJason Lengstorf 45:12: Yes. So Gatsby cloud currently has the preview service,\nwhich is in a beta. We\u2019re hoping to get that opened up soon, though I don\u2019t know\nthe exact dates. And we also have the incremental build system, is in like a\nvery early alpha right now. So both of those products are coming down the\npipeline, we\u2019ve got a lot of plans on what we expect to launch kind of on the\nheels of this.\n\nJason Lengstorf 45:44: A lot of what we\u2019re doing with commercial right now is\nlaying a foundation, so that we can build the ambitious stuff that we think is\nkind of a uniquely Gatsby offering. Because Gatsby is an interesting tool,\nbecause we actually own the whole experience, like from where you start your\nwebsite to where you theoretically deploy your website.\n\nJason Lengstorf 46:09: We have the ability to kind of touch the website at every\nstage. So we can do things that are pretty advanced, like pretty deep static\nanalysis, and we know what Gatsby\u2019s opinions are. And so we can dive into things\nthat are difficult to do in a generic way.\n\nJason Lengstorf 46:28: So it should open the door for some really interesting\nreporting and profiling and different like performance and accessibility and\nother types of tuning that are uniquely possible, because Gatsby has those\nopinions and sets those defaults and guardrails. So stay tuned in this space,\nbecause I think Gatsby cloud is going to start out kind of like, that seems like\na cool feature, to where I think the follow-on stuff is going to be really\nexciting, I think.\n\nSchepp 47:05: Sounds good. I guess it\u2019s also a matter of time, of having bigger\nand bigger customers, that then formulate new requirements or ideas that just\nhappen when you scale. And then probably just do it sort of in a partnered way\nwith you.\n\nJason Lengstorf 47:33: Yeah, I mean, that\u2019s one of my favorite things about\nGatsby is that we don\u2019t really see ourselves as being competitive by nature. We\nsee Gatsby as being an inherently collaborative tool, because we rely on third\nparties like the headless CMSs or deployment platforms like AWS, or Google\nCloud, or Netlify. Each of those things is the thing that we like, we see\nourselves as a partner to them, we\u2019re sending them business, and they\u2019re sending\nus business.\n\nJason Lengstorf 48:04: And as they improve, that makes the Gatsby experience\nbetter. As Gatsby improves, that makes their experience better. And I love that\nmodel of business, where each of us is kind of adding to the tide that lifts all\nships, as opposed to saying like, well, it\u2019s winner take all, we\u2019ve got to take\nout this company or this company, so that we create space in the market. It\u2019s\nlike, no, we want to help that company. Because if their customers are happy,\nthen those customers are going to be happy with our service too, because they\nadd on to each other.\n\nJason Lengstorf 48:36: That\u2019s important to me. I\u2019m not a very competitive\nperson. I like cooperative sports, not competitive sports.\n\nSchepp 48:44: Yeah, they those are also the more interesting ones. I think if\nyou reach a point where you have market saturation, and it\u2019s just competition\nand taking over market shares, then it maybe also gets a bit boring, sort of.\nMight be.\n\nJason Lengstorf 49:05: I don\u2019t know. I think there are people in many different\ncamps. So I think everyone has their preferred working style. And I\u2019ve heard\nthis categorized a lot of different ways. One of the more recent ones that I\u2019ve\nheard that I like, is this idea of like pioneers, town settlers and city\nplanners. And so like in the early days of anything, it\u2019s just kind of uncharted\nchaos. And so people who like to pioneer really enjoy that chaos, they\u2019ll dive\nin, they\u2019ll just try stuff, everything\u2019s breaking all the time. It\u2019s loosely\ncontrolled disorder, as you just explore and try things.\n\nJason Lengstorf 49:43: And as ideas start to form, then the pioneers tend to get\nbored, because there\u2019s less chaos, things are starting to feel more stable. And\nthen someone like a town settler comes in and takes the thing that is stable,\nbut still pretty immature and then they kind of take it from being an immature\nseed of an idea that\u2019s stable to an actual functional thing.\n\nJason Lengstorf 50:05: And then someone who\u2019s more of a city planner is going to\ntake something that\u2019s matured, like this would be somebody who just really wants\nto go in and work on a product that is established and has a market share. And\nthey want to incrementally improve it over time, and just make it into the best\npossible version of itself.\n\nJason Lengstorf 50:22: And all three of those roles are extremely valuable. And\nfinding out which role suits your particular personality type is so\u2026 To me at\nleast, learning that I kind of fall right between pioneers and town settlers,\nlike I love experimentation in chaos, and I love taking something that\u2019s new and\nmaking it viable. How can we turn this great idea into a business?\n\nJason Lengstorf 50:50: Knowing that about myself has really informed the way\nthat I make decisions about my career. And I love talking to other people about\nthis as well, because a lot of times people haven\u2019t thought about it this way.\nAnd when they start thinking, they go, oh, so that\u2019s why I really love this job,\nand then stop liking it. It\u2019s because I shifted, I was a town settler, and then\nI shifted into being a city planner, and I don\u2019t like city planning.\n\nJason Lengstorf 51:11: Or somebody else will say like, oh yeah, I hated this\njob, because it just felt like I never knew what was going on or everything was\nalways so ambiguous. And it turns out they want to be a city planner, they want\nlike clear cut goals and KPIs and something that they can really own and work\ntoward, without that ambiguity or chaos.\n\nJason Lengstorf 51:28: I don\u2019t know, I kind of got a little philosophical here,\nbut I love this approach.\n\nSchepp 51:34: I see your point. Totally. You\u2019re right.\n\nSchepp 51:42: One more question regarding the Gatsby cloud. So there\u2019s just\ncertain features that are beta, but the hosting is\u2026 right. Is that correct?\n\nJason Lengstorf 51:54: Sorry, can you say that again?\n\nSchepp 51:56: So you mentioned the preview feature, and also the incremental\nbuild feature being beta and alpha. That would mean that the cloud or the\nhosting service that you offer, is that already available?\n\nJason Lengstorf 52:12: We don\u2019t offer a hosting service. And I will never say\nnever, but at the moment, what we prefer is to be, I kind of see us like when we\noffer like deployment, that deployment is going to go to Netlify for hosting or\nAWS or any kind of like bucket based storage. Because for us to stand up a\nhosting service seems, in my opinion, a little silly, because it\u2019s like, well,\nwhy would we try to compete with something that\u2019s so thoroughly established?\n\nJason Lengstorf 52:48: To me, that doesn\u2019t make a whole ton of sense. So if we\ndo have a hosting service, it\u2019s probably going to be a white labeling instance\nof like, Fastly or something. So to me, it\u2019s like, all right, well, if we\u2019re\ngoing to white label Fastly, why not just have like Fastly as a deploy target?\nYou know what I mean? Like maybe we\u2019ll have a convenience layer where you can\nsay, I don\u2019t want to choose, just do a thing.\n\nJason Lengstorf 53:10: But ultimately, I think it\u2019ll be more like I want to run\na Gatsby deploy command, and it\u2019ll go to, your preferred hosting provider will\nhandle the orchestration of it.\n\nSchepp 53:21: Yes. Okay. I just misunderstood. I interpreted it that way, that\nyou offer similar things to Netlify or maybe also to I think SiteHQ, or now how\nis it called? And that\u2019s why I asked you about the cloud services one more time.\n\nJason Lengstorf 53:48: I think over time, there will start to be some overlap.\nBut at the moment, we think that both Zeit and Netlify are doing an amazing job,\nand it doesn\u2019t make sense for us to try to compete, we should just work\ntogether. And there are things that it doesn\u2019t make sense from a business\nstandpoint for either them to focus on, because it\u2019s hyper Gatsby specific. So\nwe\u2019re going to focus on the hyper Gatsby specifics at first. Because that\u2019s\nclearly like where we can provide unique value.\n\nJason Lengstorf 54:16: And like maybe over time, there starts to be more\noverlap. But to me, it makes sense to avoid, like I said, avoid competition as\nlong as possible. Let\u2019s be as friendly as we can and kind of buoy each other as\nmuch as possible for as long as possible.\n\nSchepp 54:35: I think there\u2019s always enough stuff to find to work on. Right?\n\nJason Lengstorf 54:40: Mm-hmm (affirmative).\n\nSchepp 54:42: Cool. So I don\u2019t know, I have the impression that we got a nice\noverview of what Gatsby is, and also how you work with it and also what\u2019s to\ncome. I don\u2019t know, did we forget anything? So I think we\u2019ll write show notes,\nwe\u2019ll link to different things, we\u2019ll also link to your Twitch, and to your\nTwitter account, of course.\n\nJason Lengstorf 55:17: And then the only other thing that we might want to\ninclude is just about our kind of community model. We talked a lot about\nincluding people, but we didn\u2019t exactly talk about the specifics of Gatsby\u2019s\ncommunity. Because we have a lot of programs that we offer specifically to get\npeople involved in open source. We do a free pair programming call where you can\nget 60 minutes with somebody on the core team to work on any open source project\nor getting involved in like your first pull request.\n\nJason Lengstorf 55:50: We also have a kind of contribution model, where if you\nget a pull request merged into the GatsbyJS.org, we will upon merging that PR,\ninvite you to become a member of the org and also send you a discount code so\nyou can claim some swag from our Swag Store. You get access to kind of like a\nprivate maintainers only group on GitHub, where you can get access to kind of\nour maintainer call and a lot of different discussion that happens about like\nvery, very experimental features. So you kind of keep your finger on the pulse\nof where Gatsby\u2019s going, you have influence over like where Gatsby goes, because\nyou\u2019re part of that early discussion.\n\nJason Lengstorf 56:32: Those are all really, really interesting things that\nwe\u2019re trying to do. Like, again, one of our company values is you belong here.\nAnd we really deeply want everybody, whether you\u2019re a seasoned veteran or a\nfirst-time contributor to get involved in open source. And we\u2019ve designed\nsystems at Gatsby specifically to make that an approachable goal. So that\u2019s\nsomething that\u2019s really important to us, and that we\u2019d love to see more people\ndoing.\n\nSchepp 56:59: Sounds really nice. I wouldn\u2019t have expected that. Cool. Yes,\nthumbs up from my side. Good.\n\nJason Lengstorf 57:12: The link for that is, if you go to gatsby.dev/contribute,\nthere\u2019s a whole page on our docs about that.\n\nSchepp 57:22: Yes. I just found it, also. Nice. Nice. We\u2019ll read through it\nCool. Well, Jason, thank you very much for sort of pinging us on the social\nchannels. And I\u2019m also super lucky that we saw that, and that we approached you\nand that you came into our show.\n\nJason Lengstorf 57:56: Yeah, thank you so much for the invite. I really\nappreciate it. I always have a blast doing these, so thanks a lot.\n\nSchepp 58:04: All right. And so any of the listeners that wonder if this is a\nnew podcast they should listen to, maybe not so much, because usually we are in\nGerman. It\u2019s a long story. But basically, it\u2019s just that in the German space,\nthere was no podcast, whereas in the English space, there\u2019s plenty. So we\nthought we would need something to cover that as well.\n\nSchepp 58:34: And from time to time, we do English podcasting and I would\nsuggest Follow us on Twitter. Our Twitter handle is workingdraft, and then you\ncan already spot when we release new episodes. If it\u2019s a German episode, which\nis usually the case, or if it\u2019s an English one, because sometimes we have guests\nlike Jason and sometimes we also go to conferences, where we pick the brains of\nspeakers in shorter interviews. So have an eye on that.\n\nSchepp 59:09: And that being said, thank you very much for listening. And again,\nthank you very much, Jason, for coming. Have a nice day. Bye.