Brian: PodRocket is sponsored by Log Rocket, a frontend monitoring and product analytic solution. Don't know what that is? Go to logrocket.com. Thanks. Ben: Hey everyone. Today, I'm here with Kyle Mathews. Kyle is the founder and CTO of Gatsby. Welcome Kyle. Kyle Mathews: Thanks for having me. Ben: Yeah. So, maybe just to start, I mean, I know at this point, Gatsby, I feel like it's pretty ubiquitous, but I'm sure there's some people that haven't used it or haven't heard of it. So maybe you could start by giving us a brief introduction to what is Gatsby, and why should anyone use it? Kyle Mathews: Sure, sure. Yeah. So Gatsby is a React framework, and we focus on helping people build really fast websites, kind of more like sort of traditional content-driven sites, like you use a CMS for. And so Gatsby, with Gatsby cloud, we have a kind of full preview support for content editors, along with of course, really great, kind of like, sort of the developer experience that you expect from, working with React. And we've been around for like six years now, the open-source project, and then my co-founder and I, we created the company kind of early start of 2018. So we've been a company for a few years, and launching, we launched a lot of things in Gatsby cloud recently, like hosting a function support. So turning to know really kind of first-class platform for running Gatsby sites. Ben: And so, you said something interesting, which is that Gatsby is primarily geared towards content websites, and traditionally I think many people think of React is what you use when you're building like a web application. You need a lot of, one of these fat web applications with a ton of clients side logic, but you know, increasingly people are using React even for what would typically be like a static HTML/CSS website. So like, what is the advantage of being able to use React for a simpler content website? Kyle Mathews: Sure. That was a great question. And we definitely get asked that a lot. So my background is, I spent a lot of time in sort of the CMS world. So, in college I started doing like freelance building, like mostly like Drupal sites for clients. I spent a couple of years working on like a startup, and I worked at Pantheon as a frontend engineer. And for people who don't know, Pantheon is a Drupal WordPress kind of hosting company. And so, spent a lot of time as both like, front engineer and PM there, working with all of our customers who are all using Drupal and WordPress extensively, to build lots and lots of sites for lots of people. So anyways, so kind of like really familiar with that world, both living in it and supporting it in, tooling. Kyle Mathews: So like the problem with, there's kind of a, why Gatsby has a place here, and it makes a lot of sense is that, CMS is focused largely on, sort of the content aspect of the problem. They're helping marketers, they're helping people create large quantities of content. So there's a lot of like organizations that work, tagging structures, categorization, all the taxonomy stuff. There's like marketing workflows, a content workflows, who can create stuff and when and how, and who has to review it. And anyway, there's just like a lot of complexity there that CMS has handled for you, like organizations that have lots of content and lots of people working on content. But the problem though, is that typically, both the fronend developer experience kind of suffers by comparison. They'll typically give you just some simple templating stuff, and some rudimentary CSS and JavaScript support. But all of the huge innovations that we've seen in the frontend world have kind of not, you can like get them in the CMS space, but it's like, it's kind of a lot of extra work. Kyle Mathews: And then also in the same way, we've learned a lot about how to build really, really fast websites, like CDN for static assets everywhere, a lot of, kind of like, advance compilers stuff to squeeze every bit of performance of your HTML and CSS and JavaScript, lazy loading... Anyways, there's just a really long list of stuff. And again, like these have been kind of slow coming towards the CMS world. There's still like adding a bunch of script tags and CSS links things, and anyways, if you look at a lot of... People in the WordPress world or Druple world would be like, well, you can make your site fast if you do all this caching magic and you do all these things, but it's not the default. Kyle Mathews: So it's like, for your typical agency, freelancer, it's just not going to be necessarily the best kind of user experience that comes out of the box. And so where we see Gatsby as like, we're sort of like the new frontend to the CMS. There's a lot of complexity in the backend and like pairing the great back ends that the CMS is built, for managing content, with Gatsby, which is like, Hey, we're taking care of creating an incredible developer experience, creating great integrations with the CMS's, handling like the marketer flows of like, I, you know, I'm editing something. I need to see a preview of what it looks like. And then of course creating like a really great user experience, that's where we come in. So yeah. So it's like the CMS is a CMS problem, but with a new front end. Ben: Got it. So basically it's like your kind of content or marketing team can choose whatever their favorite CMS is. And then for the engineering team building the frontend on that CMS, Gatsby streamlines that process and gives you good developer tooling. And it sounds like performance is a first class citizen. And earlier I said, I had two questions, my second was going to be about performance. Just like, I think people typically think about React as being maybe okay with performance. And if you're building a complex web application, page loads, or things like that, maybe not quite as important, but when you're building a blog, or a content website, or stuff, performance is everything. And so maybe we could talk a bit more about like some of the things Gatsby does out of the box to help build performance sites and to make React faster. Kyle Mathews: Totally. I mean, React by itself is, kind of the actual React core code is about the same size as jQuery. And like we've been loading jQuery insights for... JQuery feels like an eternal part of the web, but I got, whatever it is now, like 10, 12 years old. So yeah, the problem React sites get into, is that it's really easy to just start pulling in stuff, and React by default, like create React app, and most sort of default webpack setups. They kind of like pull all of your JavaScript for your entire site into one bundle. And that gets super slow. Because you'd be across the site, we have like a megabyte of JavaScript and do you really need to load and make a bite on every page? Kyle Mathews: So one of the really critical things that Gatsby does out of the box is that, we split up your code per route. So, you have a front page route, then you have like the blog index route, and then you have like a blog page route. And each of those components use, you have your own JavaScript, maybe you pull on the library to do something, but it's only going to get loaded if it's actually needed. And so what that means is that yes, if you click to every page on the site, you'll still load a megabyte, but you know, loading the first page is going to be very fast because that's going to pull in maybe 120 kilobytes. And so it's a very, yeah, it's a very fast experience. Ben: I think I've seen, Gatsby does some interesting stuff with images. Is that right? And curious, maybe you could talk more about that. Kyle Mathews: Yeah, yeah. So, the bundling is something we do out the box is really nice, beyond that, there's kind of like a couple other key things to do to make your site fast. There's how you create the HTML and how you got the CSS. So one of the things that we do is, we inline your CSS for each page too. And so that avoids like an extra request and can be a pretty significant speed up, and then images, performantly loading images, there is just kind of this deep pool of complexity that you have to handle. There's like a source set, which like allows you to say like, for a mobile device load this image, for this device load this image, for desktop, load this image, for a very wide desktop, load this image. Kyle Mathews: And then there's like kind of different image formats, because the smart people working on image compression, they're always coming out with like new versions. So lately there's like WebP and then avif, and these are awesome. They're huge savings over, the kind of, the tried and true JPEG, or PNG, but not every browser supports them yet. And so the browsers have created ways to sort of like conditionally load these different formats, but the image, the image element, it seems simple. It's like, image source equals this, alt equals this, but then once you're like accounting for all these things, you have to generate like 80 lines of a HTML, to kind of really performantly load an image. And then you throw in like, lazy loading and fallbacks for browsers that don't support images, anyways. Kyle Mathews: And there's also like, you want to, whatever, I won't go into every last little detail, but the point though, is that, what Gatsby does for you is, it's really nice, is that it kind of like hides all that complexity behind our image component. So we have a React image component that says, okay, you want fast images, that's really key, but there's all this complexity in sort of the raw HTML and CSS to make it happen. And then JavaScript too, this kind of like JavaScript, that little glue JavaScript to make it all work. We're just going to turn that into a component that kind of takes you back to the simplicity of the original image component, that you just like import the Gatsby image component, and you just say source equals this and then you're kind of done. And so, that's something that people really love about using Gatsby, is that... Just so your images are great and it doesn't take a lot of work. Ben: Yes. I can, having worked on many websites, I can attest to images, always being a problem. So definitely sounds like Gatsby make things a lot easier there. And so moving on a bit, there's a lot of frameworks out there for building web apps, and each kind of has its own use case and some are focused more on kind of that rich client side, web application, some are much more in the kind of a content website area, which seems like Gatsby is. But maybe you could speak a bit, NextJS is kind of the big one that comes to mind, that's been growing in popularity. Like, what is Gatsby better for maybe what is Next better for how should someone choose between the two when building a new web project? Kyle Mathews: Sure. Yeah. Next is doing a great job. It's kind of a venn diagram. There's definitely places where, well, obviously Next is better for this and like, obviously Gatsby is better for this. And then there's like a big overlap where it's kind of like, I don't know, like it's kind of up to you. It doesn't really matter too much, because in the middle stuff it's like, well, I mean, they're both React. So if you, if you're choosing React and you're writing React components, it's like both Next and Gatsby are pretty much identical in that aspect. I mean, we're both using webpack and babble and et cetera, et cetera. So the experience of building a site is pretty much identical for both of them most of the time. Where Next is probably clearly a better choice is, Next is like a lot lower level than Gatsby, has a lot less assumptions about how you're going to use it, where Gatsby is like, Hey, we have opinions about how you're building your site, and we have the plugin architecture, we have kind of like a data layer, et cetera, et cetera. Kyle Mathews: And opinions are good, if the opinions match what you're doing. Opinions are bad, if you want kind of like maximum flexibility. So if you're building a product, like kind of a long running product, then Next's lack of assumptions is good, because it allows you the flexibility to do whatever you want. Where if you're building a more standard kind of content site, then Gatsby's opinion is actually helpful, because there's a lot, I mean, it's like if you're building an application, you're doing a lot of novel stuff, but a lot of websites are kind of like cookie cutter. Like why reinvent the wheel when you don't have to? Kyle Mathews: And that's the advantage of plugins and opinionated architecture is that, we spend a lot of work, both the Gatsby team and the whole Gatsby community, and all the people working, all the plug-ins, everything, we're all spending incredible amount of work solving the same problems that you have. So you kind of walk into a space knowing that a lot of smart people spend a lot of time working on the exact same problems that you're facing. Because if you're building a content website, there's absolutely nothing novel about what you're doing. It's like, you need to hook up to a CMS, you need to like pull it in and efficiently, you need to drive content workflows, you need to have sort of a previous service agent server, you need to load images performantly, look at the page, make sure the site is fast. Kyle Mathews: And so there's a lot of common problems that you'll hit, and that's where Gatsby thrives. There's also like, it's like kind of a content site. It's kind of an app site. And I would say Gatsby is an excellent choice, that this is sort of the middle of the Venn diagram, because again, we're React, we have great support for client side routes. So you can say, Gatsbyjs.com. We obviously have a lot of marketing stuff on there, we have a lot of docs pages, where the marketing stats pull from Contentful and WordPress. We have like docs that are pulled from like markdown files, but we also have the Gatsby cloud app. And it's just sort of running in the same architecture, and Gatsby, you could just say, this section of the site is just sort of a normal React app, and then everything works kind of like you'd expect to with like create react app, and so forth. Ben: Got it. Well, that's a good segue to my next question, which I want to talk about Gatsby Cloud. So yeah, what is Gatsby Cloud, what are some of the tools in the suite of cloud tools, and how do Gatsby developers use those today? Kyle Mathews: Yeah, yeah. So, our mission with Gatsby Cloud is just to be the best place to run Gatsby sites, and solve, again, these sort of common problems that you have building sites in a really nice way. Kind of long-term vision is, well, all this stuff is like, you shouldn't have to worry about making your site fast. Like it should just be kind of there out of the box. You shouldn't have to worry about setting up all these workflows with a developer workflows, and other things. And a lot of, when I worked at Pantheon, people doing like Drupal, WordPress, like having a staging server was always a manual. There is like starting to be like hosting stuff where people are like, okay, we'll host your site, and they do a reasonably good job, but actually having a full blown, dev stage production workflow was like, something you had set up for every content site. Which meant that, most people weren't. If you're doing WordPress, you're FTP, and changes to your PHP files up to the hosting service though. Kyle Mathews: It was just madness. And so it was this just like indicative, like how far the industry has come in, like the last 10, 15 years. And that now, Gatsby Cloud, Netlify, Vercel, Lambda, whatever, or not Lambda, but Amplify, well, a lot of these... There's a lot of people now offering this sort of... Like you put up a PR and we'll build a site automatically for you type thing. And Heroku of course, which kind of grandfathered all this stuff. And that's like a huge improvement to do the developer experience, that every project you start, you instantly have a really nice setup where you can, make changes, get feedback on that, deploy to production is really simple. And Gatsby Cloud, we do the same sort of stuff. Kyle Mathews: We follow that same sort of pattern, but we make it just, because we're Gatsby experts, the builds are as fast as possible. We do a lot of tricks to make builds, like really, really fast, whatever the kind of the scale site you're working on. And we have a lot more improvements that we're working on there, and we'll continue to roll out. And then the other part is like, there's developer workflows, but particularly for content sites, it's you have the content authors and editors and marketers and executives, and all sorts of people who are working on the site. It's not just a few devs, like whipping out something, it's like a whole team effort to push that site forward. Kyle Mathews: And for a lot of organizations, their website is like utterly key to the company, that is their product basically. And how they present themselves to the world. And so having a kind of marketer workflows be really smooth as well, it is something that we focus a lot on Gatsby cloud. And so your CMS has a preview button that you can click on, and it opens the right page on your site. And we're doing some work to have some automatic indications when things are reloaded, and there's a lot we're doing to really smooth out that experience for you. Ben: So how does Gatsby cloud compare to hosting your Gatsby built application on Netllify, that's actually what we do here at LogRocket, are logrocket.com is Gatsby. And then we just, we use Netllify because that's what we've been using for awhile, but yeah. Curious. Because they have some of this functionality, but it sounds like they don't have quite as deep support for Gatsby as Gatsby cloud. So what are some of the advantages we might get from switching to Gatsby Cloud? Kyle Mathews: Sure. Yeah. So, for the actual hosting aspects, Netlify has built their own CDN. They've done a great job with that. Gatsby cloud uses Fastly, and Fastly, they IPO'd a year or so ago, they're huge. They, well, they're huge. And they run kind of like a good chunk of the internet. Reddit.com was on Fastly. So it's super fast, super stable. It is, but I mean, I can see the hands of CDN at some aspect. So that's not two different. The big difference is just the build speed, because we do a lot to make each build as incremental as possible. And we go really deep on that. So people moving from like Netlify to Gatsby Cloud often see like 2, 3X speed up, on their builds, which just makes a big difference just to, kind of, what is the experience like working on a site. And like I said, we're working on some huge initiatives right now, which basically a build. Kyle Mathews: So you have things even more, because basically build is just like a CP problem. So we're like, okay, how do we bring in more machines to paralyze your builds and speed things up even more? And so there's going to be some exciting stuff later this year on that. Ben: So looking at kind of the... You mentioned you started Gatsby first, and then a few years later built, started the business around Gatsby. And I believe now you've raised over 40 million. Is that accurate? So you have a lot of fundraising. Tell me a bit about how you're thinking or maybe already monetizing the business? Is Gatsby cloud kind of the primary product and where you see the business being built around, or if not, or in addition, what are some future plans? Kyle Mathews: Yeah. It's Gatsby cloud, because yeah, it's like Gatsby, like super framework for building, websites, apps. And then Gatsby cloud is, the workflow support and the tooling support and the hosting that you need to run stuff, because you need code and then you need infrastructure. And, and the idea is that they're paired really beautiful together. Ben: And then Gatsby Concierge, is that your professional services branch, to help teams that need help with performance, or other tricky things about building apps? Kyle Mathews: A lot companies that are doing high profile, got to be stuff, they're like, Hey, we need some extra help. We're running into some problem that we can't figure out. And then they turned to us and then yeah. Ben: Got it. So in the future, what's on the roadmap for, I guess we could look at both the Gatsby framework and then Gatsby cloud, just curious next few years, like what are you most excited about? Kyle Mathews: I mean, yeah, so I got mentioned, it's like, we're working on some initiatives, that's going to speed up builds by a ton. So that means faster builds and sites that maybe Gatsby doesn't quite scale to right now. If you have like a hundred, 150,000 page site, builds can take a few minutes too long. Yeah. Kind of varies. It's a little bit harder to predict. Anyways, it's not a pleasant experience, but our goal is that regardless of the size of your site, you deploy changes in seconds. It's always under a minute and even under like 10 seconds for a lot of stuff. And really excited, we already hit that threshold for most sites that are on our platform, but we're doing a lot to make that a kind of guaranteed experience for people. Kyle Mathews: And then, yeah. So real excited about that. And then also really excited about just all the improvements we're working on for the preview marketer workflow type stuff. Because that's traditionally been a big headache with sort of this headless CMS world. Because in a CMS it's all integrated and works nicely, but there's a lot of practical problems you run into once you kind of split the brain, and you have a different front end from the backend, and we're smushing them back together. It's a little graphic, but anyways, we're making the experience really smooth for people, and that's pretty much everyone running content sites. That's the biggest ask for us, make that incredible. And you have our business, we'll put every cent in Gatsby Cloud. Kyle Mathews: Because as a developer, headless is awesome. Because you're like sweet, someone else is running it for me, it's like super easy to set up, it gives you a lot of flexibility in you're frontend, you can reuse the content, and the different areas you can like, oh, we could build a mobile app, we could build multiple websites. There's just like a ton of architectural freedom that opens up when you split the frontend, and the back end, of a CMS apart from each other. But the experience for everyone else using the CMS typically gets a lot worse. And our goal is like, we've done a lot to transplant already. It's like that you can actually move from WordPress, full-stack WordPress, if you will, to WordPress is only on the back end, and then Gatsby on the frontend, and people, the non-developers working in WordPress, won't even notice the difference, that it can be that seamless. Kyle Mathews: And we're pretty close to that. And then beyond that, React 18 has a ton of really exciting improvements that will be really helpful for people building Gatsby sites. One of the big ones, there is just partial hydration in sort of simple terms like right now. So what Gatsby does, and all React frameworks like Gatsby does, is that you have your page, and then we turn that page, we take that page and like the page component, I guess, the code for the page, and we generate an HTML version of it. And then in the browser we run the React app again and sort of reattach it to the instrumentals loaded. So we generate the HTML build time, that loads into the browser. Then we kind of like rehydrate it, and then turns it back into a working React. Kyle Mathews: But the problem with that, is that right now, React needs all the code that was used to generate the page to be there in the browser before it can rehydrate it. So it's sort of like an all or nothing type thing. Either it's just like straight HTML, or you have all the jobs and are going to rehydrate it. And the problem with that is that, for most pages you have, you don't actually care if most of it's like hydrator interactive. It's like most of the stuff, people aren't actually doing things with. And be much better if you can just be like, okay, there's this little... there's a search bar, and then there's this little contact form at the bottom, and we want those to be hydrated right away. And then only load the JavaScript for that. Kyle Mathews: And that might be like 20% of the JavaScript or 30% of the JavaScript for the whole page. And so React 18, and Gatsby is gonna ship full support, fairly soon for this. With React 18, you'll be able to say, okay, these three components should be hydrated immediately. And then it'll just start to work. Anyway, the practical benefit of this is that making your size performance will be, you'll have like a really powerful tool for ensuring that every page loads really fast, because longer, more complex pages, it just becomes tricky to make the site fast because of the JavaScript that you're necessarily loading. With this, you kind of have a scalpel to be like, okay, only load in this bits first. And then the rest of it can kind of lazily come in. Ben: Got it. And specifically for folks that are already using Gatsby or Gatsby nerds out there, I believe version three is the latest version of Gatsby? What is exciting and new and Gatsby version three? Kyle Mathews: Yeah. Great question. So V3, there's some big under the hood upgrades. So like webpack 4 to webpack 5, which brought the big change there. There's some improvements to like tree shaking, and other kind of stuff. Big improvements though that most people notice is a webpack 5 has like a really nice caching layer. And so for sites with more Java Scripts, with caching, we're rolling out the cachet right now. So 3.7, it's like turned on for like 20, 30%, it's behind a flag, and then 3.8, we'll roll it out for everyone. But anyways, with caching enabled by the JavaScript building portion of things can drop like 10x or something like that for warm builds. Which is super nice for speeding up build times. And then along with that, just some nice build performance improvements. Kyle Mathews: And then also we have kind of a incremental build support behind a flag in v2, that we've been working with community and do. And in v3 we did a lot of work to kind of move that into open source, and turned on for everyone. And so this saves a lot of time for bigger sites, again. It's like, you run a build and then on subsequent builds, you say, okay, which page is actually changed. And then because Gatsby's data layer makes it really, it can sort of like intelligently figure out which pages changed between builds. And I'll say, okay, actually only these seven pages have updates and then only rebuild those, not the other 10,000 pages or something like that. And so that, that can lead to really significant speed ups on builds. Ben: So, I believe you just recently released functions as part of Gatsby Cloud. So everyone's talking about functions nowadays. So what's unique or interesting about Gatsby's version of functions that just came out. Kyle Mathews: Yeah. So people have used server less functions with Gatsby pretty much the whole time Gatsbys been around. It's a super nice fit. The whole idea behind Gatsby in general is don't run servers. Running servers is a lot of hard work. That's not specifically unique to your staff. And it also just causes a lot of trouble, because, ideally your architecture is sort of like scale free. So if you have like a simple small site, you just have a little bit of, you're paying just a little bit for hosting, but then as it scales, it just kind of automatically scales up with traffic. And that's really, really, really hard to do and just not worth it for yourself. So Gatsby architecture is like, Hey, build out static pages, and then a CDN can just scale up and down as needed and you pay as you go. Kyle Mathews: And like server less functions gives you that same kind of really nice properties, but for backend type stuff. So you want to do like custom backend functionality. If you create a Node.js API and then you deploy it yourself, you get a spike in traffic and like goodbye Charlie. The poor thing's just going to die. But serverless functions, it just scales up and down. So AWS Lambda is a super common place to run functions. If you deploy your node.js Backend there, you get a million visitors, or no visitors, it's all the same to you. And it's all the same to AWS Lambda. And so what we want to do with Gatsby functions is bake it into Gatsby itself. Kyle Mathews: So the problem with using AWS Lambda for example, is that you have to like run a separate dev environment, separate build environment, you got to do a bunch of stuff yourself to get them working. And then we want to bake them to Gatsby itself, so that everything just kind of works out of the box. So starting with Gatsby 3.7 is when I went GA. Just like we have a source pages directory, there's now a source API directory. And if you put a function in there, then it just sort of automatically starts responding. It can automatically start responding to two kind of API requests. And that's like, it's just super nice. It's just like a really, really simple developed environment. I like to think it was like the simplest possible dynamic backend that you could have. Kyle Mathews: And so, oftentimes you're building a website and you're just like cruising along, building out the different pages, but then you're like, oh, I need to connect the service or, oh, I need a form here. Like where does it go? And oh, I need to load data from a database or from somewhere. And it just started a record scratch on everything, kind of like stops because you're like, oh no, I have to like build such things. But now it's no problem. You can just like create a little function and off you go. And the ad, well, Gatsby cloud, we kind of like deeply integrated it so that, all the stuff that you expect works, works. So like you put up a PR with some changes to a function, then like the deploy preview includes your changes and you can like test it against that and so forth. Routing works in production of course, and then routing and production works because that's like another kind of weird problem with server less functions is that it's like deployed to some backend URL, but you have to like route it correctly and whatever. Kyle Mathews: And so all that's like a hundred percent seamless. So you don't have to think about it beyond, you writing the code. So very excited about it. It solves a ton of problems, and really kind of makes it a lot easier to build dynamic stuff with Gatsby. Ben: Awesome. Well, Kyle, thanks so much for joining us today. This has been super interesting to learn about Gatsby. For folks out there who want to learn more, I guess they can go to Gatsbyjs.com. And are you guys hiring if people are interested in working on Gatsby? Kyle Mathews: Yeah, I think, yeah, we have a careers page there we have. Yeah. We have like a couple of frontend positions actually open right now. So love to have you apply. Ben: Awesome. Well, thanks so much. Kyle Mathews: Yeah. Thanks for having me. Brian: Hi. Thanks for listening. Please remember to like, subscribe, email me, if you want, even though none of you do. Go to logrocket.com and try it out. It's free to try, then it costs money, but yeah, we'll see you next time. Thanks.