Kyle Mathews:
This is my first acquisition. Things take a while, you have these two very complicated machinery. It's trying to put gears together that just don't fit. You keep having to [inaudible] until finally they catch.

Noel:
Hello and welcome to PodRocket, a web development podcast brought to you by LogRocket. My name's Noel and with us today is Kyle Matthews. Kyle is the founder of Gatsby and we're just here talk about Gatsby at large. I feel like the big news is the Netlify, Gatsby merging coming together, acquisition, one of many terms. Before we get into that, can you just give us a little bit of your background, how you found yourself playing in this frontend space and what drove you to creating the Gatsby framework?

Kyle Mathews:
I got into programming in college to build websites for different projects I was working on. I was a research assistant. At the time, this was mid to late 2000s. Drupal was the cutting edge. I got pretty deep into Drupal and spoke at several Drupalcons and did Google Summer of Code and stuff, did a lot of contracting on my own stuff. And that was my introduction to programming, general web world and open source and so on. Learned a lot there. Then tried doing my own startup end of college.
My whole career is entrepreneurship. That's pretty much I've done in a variety of guises. And then tried to do a startup first year after college, which perhaps predictably didn't go very far because I had no idea what I was doing, but learned a lot. And then after that I joined Pantheon. Some of you might know, it's one of the main Drupal WordPress cloud platforms. I worked there for two and a half years, and JavaScript web apps was still pretty early then. This was like Backbone.js was brand new at the time.

Noel:
Yes, Backbone. Yeah, it's been a while.

Kyle Mathews:
Yeah, good old Backbone. So we had Backbone, we had Socket.IO, we built a convoluted mess [inaudible], but it worked. You can make almost anything work if you poke at it hard enough. Some twisted Python API backend, but it worked and it was fast and people loved it. So anyways, had a great time just diving deep into building big web apps, realtime [inaudible 00:02:24], all that stuff. And then after a while there we were exiting the early stage at Pantheon. We got to 45 people. So I was like, it's getting a little more boring here. So I was like, I'm going to jump up and do my own thing again.
So I did another startup which was completely unrelated to web development. It was a Salesforce, SaaS related thing. But along the way, we started 2014, React and open source to about eight or nine months before. And I saw React and I was like, React solves 80% of the problems that we had building the Pantheon dashboard, it's just a huge leap forward. And so started building our product with React and then about a month or two into building it, GraphQL is open source. And I was like, this solves 80% of the problems I have with REST APIs. And probably was one of the very first React GraphQL, I was using Relay too.
So all that stuff was very early on. So got a fun deep dive into some really significant new technologies that come out, which is a real leap forward in how we did stuff on the web. And then out of that brew came Gatsby because we had a product, we had made a few sales. We're like, "We need marketing. Tell the world about our exciting sales SaaS thing." I wasn't going to just use WordPress or something. So I was like, well I want to use React of course. So that's going to make building our two-page brochure site so much more enjoyable. Some people build a game to build a game, other people build games to build a new game engine or something.
So I have that feel, whenever I'm building a product, I'm trying to build a new framework or something along the way. So Gatsby was like, I'm going to build a React static site generator that can power our website, that can build, pop into a Docker container, shove in our little cluster and off it goes. And because I've been using React and Webpack and everything else. So I was quite familiar with that stack and so I was like, I could just take these things and stick it in a package. I just run a command and off it goes. So it does its thing. So I did a week of that, built a website, open sourced it and went back to working on product.
And Gatsby was what we now call meta-frameworks. It wasn't technically the first one. There was a few other ones, but they were all, I rebuilt my blog and throw the code over the wall. They weren't actual projects. Where I intended Gatsby from the beginning to be usable in a variety of context, and I was supporting it and fixing issues. And I wasn't really trying to promote it because I was like, this is just a little side fun thing. But I was tweeting about it and excited when other people used it and retweeted stuff, whatever. So I was doing some minimal Twitter promotion, that was May, 2015.
And then next year, January, February was the second React conference, and so I did a lightning talk. Just being there I was surprised how many people had used and liked Gatsby, and I was like, "Oh okay, this is a lot more traction than I thought." Then on [inaudible] failing. That led to me saying, "There's this potential to build a new breed of JavaScript based, React based web framework that's a lot more faster to build stuff and produces better sites," and so on. And so that's when I went full-time at Gatsby and led to re-architecting it for V1 and the plugin in for architecture, the data layer, and then launch V1 in 2017. And that just was a big woo explosion, and then raised seed round with my co-founder Sam that fall, started hiring. So dot, dot, dot, rest of history.

Noel:
Yeah, we had you on back in June here, 2021 and V3 had just went live. So that's what you guys were talking about at the time. I wasn't hosting that episode. I feel like a lot of the cool stuff was starting to manifest there with Gatsby. The incremental builds and stuff were starting to happen where you could just see these quick builds on massive sites backed by 20,000 WordPress posts or something.
And that stuff was really cool to see. Again, I think there's a lot to talk about here. In the future with Netlify and how that's all going to look, I think I'm most curious about the stuff that is happening in Gatsby Cloud, what you think the future is going to look like there, if you anticipate everything will merge and they'll become one eventually. Or what that's going to look like for users of one or either platform right now.

Kyle Mathews:
This is my first acquisition. People tell me this is pretty normal. Things take a while, you have these two very complicated machinery. It's trying to put gears together, they just don't fit and you keep having to whatever until finally they catch and so forth. It's pretty easy I think compared to perhaps a lot of acquisitions, given that Netlify and Gatsby, we have very similar DNA, very similar goals. We support very similar types of customers, the cultures are quite similar. The eventual goal though is to bring the best of Gatsby Cloud into Netlify.
Both in the sense that there's Gatsby Cloud, we have preview for Gatsby and we have incremental builds, incremental deploys and so forth, which is a huge speed-up. And so supporting all of Netlify's, Gatsby's customers with that, so then we transitioned over at some point. But then also just in general, we have some other interesting technologies that we've developed or are developing that'd be pretty exciting to see how they play out in Netlify. One is something called Firecracker VM. It's a Docker-esque type approach to running code. You can encapsulate a process and have security guarantees and so forth, resource constraints.
It has a really cool feature that you can suspend a running process. You have a service which is running and it's not getting any traffic and you can just say, "Stop." And it's just stops exactly there. And then what you can do then is as soon as another request comes in or if somebody needs that service, you can spin it up again and they have a ton of optimizations in it, so it could start running again in less than a second. Basically the end user doesn't even know. AWS developed this for [inaudible], this is what powers them. And that's how...
There's the Cold Start problem, but it's still pretty fast given that they have these functions running. So we've been gradually rebuilding all of our infrastructure, moving it from Kubernetes based stuff to Firecracker, and it's really improved the experience and reduced the cost. Because we'd be really aggressive about spending down stuff where before we had to be like, "The spend of cost is expensive." So the long story short is, build processes are typically thought of as these batch things where you have to spin up a fresh instance and set up a bunch of stuff and download code and whatever.
But what if you could have the build process snapshot-ed, and so starting a new build is almost instantaneous. That's like Gatsby Cloud, we do builds in seconds and that's basically what we've done. And then taking that same idea and technology and applying it to any number of frameworks and build processes. All the things Netlify supports, it's pretty exciting.

Noel:
Yeah, that's cool to see behind the curtain a little bit as it were. We use Gatsby for our marketing site. We're always impressed by how quick the bills are. Somebody makes an update in Sanity or something and incremental builds are so fast. It's always very impressive. How about other stuff that's come out recently? Valhalla's a big one, that data layer that you guys come out with six months ago, maybe a little less at this point. What's the future look like there?

Kyle Mathews:
Valhalla is basically... The idea is, people think Gatsby's like a React framework. And it was always frustrating because well no, it is a React framework, but it's also got this middleware piece, the data layer, which does a bunch of stuff that other frameworks don't do. And what we realized is there's no point in trying to tightly couple this, why not just break out the data layer so that anybody can use it? And so then we're not only trying to... The only people that can use it are people who've also opted into Gatsby. You could use it with Next.js or Remix, you can use it with Vue, but you could use it with PHP or something like that.
The data layer, the whole idea is you have n number of content backends that you want to pull into your site. So you can have [inaudible], Shopify, you could have WordPress, et cetera. And what we've done with that and with cloud is it's very trivial just to say, "I need to pull content from this source." And then it's instantly available through our QL API, and you can start pulling it into different components of your site. So anyways, we're trying to create that same experience where you just click, click, I need these data sources.
We create the API for you and then you can just start pulling that continent into whatever frontend you're using. That's been pretty exciting because Gatsby is used by a lot of people. But total number of ways of building websites is vastly larger, and so there's been a great response to that. That's a part of the reason why Netlify is interested in buying us, is being able to give their customers a unified content API.

Noel:
Yeah, it makes sense just for a multifaceted hosting platform because again, Gatsby Cloud always seemed very Gatsby focused on making websites. But with our larger product offering, it's like, "We also have this data layer abstraction, regardless of what frontend, whatever you're building, you could still have this ingestion piece that builds up this abstraction, puts it all in a nice GraphQL API for you, makes it easier to consume.
I always felt that data layer abstraction was both a blessing and a curse for Gatsby. Once it was understood by a developer, it's, "Oh cool, I get this. I'm humming now." But I did think it was a barrier to entry a lot of the time to people who are in the field more fresh, they're just not as experienced with it. Especially if they're diving into the deep end, this is their first project ever. It's wait, "There's another whole GraphQL that gets built. What does this do?"

Kyle Mathews:
I just barely figured out the idea of asking another service for something.

Noel:
Yeah, exactly. It's like, now this other thing's going to ask the service for you, then you're going to query this API and it's going to fill in your view. Do you feel that that data layer abstraction makes it challenging for new devs to come in and get started with Gatsby? And if so, what would you recommend to them?

Kyle Mathews:
For the very, very beginning, absolutely. We saw lots of people struggle with that. But if you're somewhat familiar with web stuff, what we hear from a lot of people is that they love not having to learn the idiosyncrasies of whatever content API. Because they're like, "Sweet, this is..." If you already know GraphQL a bit, you already know React a bit, then you're like, "Sweet, I have this new project and use WordPress backend. I don't have to care at all about whatever WordPress is doing with whatever API. All I know is that the source plugin abstracts it away and just gives me the data."
So what we found is that anybody who builds, maintains multiple sites found it a huge time saving. So agencies are one of the predominant group of people that use Gatsby because that's exactly what they do. They have n number of projects going on any one time and however many in the past they're maintaining. And so Gatsby just simplified down a whole bunch of stuff. Because we talked to a lot of agencies that are like, "Oh yeah, we have Drupal specialists and WordPress specialists, so we have specialists in this technology and this technology." And it made it really hard to figure out who's going to be available to us on any project because if your Drupal person was busy then you couldn't work on anything else.
But Gatsby tracks away, the back ends enough that Gatsby can work on pretty much any flavor of site. So that was really nice. And then also a lot of enterprises, the same situation where big company N has 100 sites built over the last 15 years and 20 different technologies or something like that. And so being able to say, "We're going to have a React component library and then going to start tying everything together through this data layer, abstraction." Simplifies your life a lot again. But on the flip side though, if you already knew the backend API, it's like, "Why am I going to learn something different?" Or if you're building your own backend, that's a big issue too.
It's a bespoke API, "I have to write my old source plug in now. What the heck?" And so retrospect, hindsight, 2020 vision, whatever, keeping that decoupled like we're doing now, we're decoupling them. That probably always would've been the right approach. So Gatsby could've been just a lightweight framework, Next.js, a Remix esque. And then you could have pulled in the data layer if you wanted to, or you could just make direct API calls. That would've simplified the adoption story a lot because if you don't need it, you don't need it. If you do need it, then you pull it in.

Noel:
I think that makes a lot of sense. Had it been abstracted and another thing that one, a developer had to glue together and figure out themselves that might have also hurt you and that it was pretty easy if you had a WordPress backend to be like, "I can get a Gatsby site running real..." I don't even need to really know how the data layer works. I can just go in and get my feet wet. And it's like-

Kyle Mathews:
Yeah, just wrote a few things and I don't know, it's working.

Noel:
Yeah, exactly. I think that was a cool thing. And again, maybe there's some theoretical paths where both are possible, but I think it'll be in a good place. But you walked right into my follow-up question there. Does separating them then make that journey easier in the future, potentially? Sounds like you think that it will.

Kyle Mathews:
Yeah.

Noel:
Just a quick pause here to remind you that PodRocket is brought to by LogRocket. LogRocket can help you understand exactly how users are experiencing your digital product with session replay, error tracking, product analytics, frustration indicators, performance monitoring, UX analytics, and more. Machine learning algorithms surface the most impactful issues affecting your users, so you can spend your time building a better product rather than hunting through tools.

Kyle Mathews:
Yeah, they're just separate products really. Maintaining the data layer thing is very different than the framework, and so keeping them separate makes a lot of sense. So framework innovation can happen independently of data layer innovation.

Noel:
We like it when things are modular and can be put together in various ways. It is a boon for innovation, I think. How about more broadly than a Jamstack ecosystem at this point? I feel like we've seen a lot of changes in the last couple years and just how it's set up. We've had big acquisitions, got Remix and Shopify, and like you said, Next and Vercel, and now Gatsby, Netlify. Do you have any thoughts about how we have these frameworks that are more closely tied now with these large hosting providers? Do you think that's going to be net positive or will there be some potential negatives there that everyone has a major capitalist ship that they're bolted onto at this point?

Kyle Mathews:
In the developer world, there's infrastructure as a service, which is go to the cloud giants and they offer pretty low level primitives. So S3 is like writing to a hard drive, but it's in the cloud, you get a computer in the cloud. So it's pretty low level stuff, and then you can cobble that together to build whatever. That was much better than actually setting up hardware yourself and whatever. But there's always then existed another layer on top of these infrastructure as a service and platforms as a service. And these are like [inaudible] we worked at was a pass, Gatsby Cloud was a pass, Vercel's a pass, Netlify's a pass, WP Engines a pass, [inaudible], render.com is a pass.
There's gazillions of them. And the reason these exist is that for many people, many projects, going straight to the low level primitives is either prohibitively complicated or just pointlessly complicated. Websites are a canonical example of this. It's like, if you're building a website, you don't care about the technology of the website per se. 99.7% of people don't care about the technology. They just want a website that they can customize to some extent and runs well without them thinking about it. And then the content folks, the marketing folks, can do their thing. Because the point of a website is generally speaking for marketing folks to do their stuff.
It's not like a developer's play toy. There's no differentiation in your website. It's just got to be a clean, simple, fast. So minimizing cost makes a lot of sense, and one ways to minimize cost when there's no differentiation is to hand it off to a higher level abstraction thing. Generally the most successful passes tend to be in the web world because if you're building an application, almost always you're like, "I'm doing something specific custom, so I need parameters." But the web and technology isn't the point, we just need to customize it a bit. And so pass is this middle ground of where it gives you some control, but you don't have to worry about most of the details.
So frameworks being adopted by these... And Shopify is another pass. So frameworks are being adopted by these passes. And the reason is, and this is my insight too with Gatsby Cloud, is that the question is, so you have the abstraction over the cloud primitives, but what is the right abstraction? What's the right entry point into making the pass do what you want? And so, early pass is like Heroku, where much lower level than what we have now. Heroku is basically pre-Docker containers that ran your code. But now what all the frameworks do is you configure the framework and it runs locally and then it also automatically configures the cloud for you.
And so you just write code and it magically makes all the stuff happen in the cloud that you don't really think about. And it's owning a popular framework and building your cloud features in tandem with your framework features is then really powerful way to move forward because someone can incrementally adopt a new framework feature and then all of a sudden their cloud experience gets a lot better too. When Gatsby got through cloud, we're like... Incremental bills and deploys, there was no, you didn't have to do anything. You just upgraded your site to the latest Gatsby version and then all of a sudden we made it a ton faster.
And of course, Vercel gets a lot of that with Next.js is their new Next.js feature, which coincidentally is tied to a new Vercel feature. And they've been building these new primitives, of course too than the other frameworks can build too. So they're trying to be the pass operating system. Instead of frameworks having to understand the underlying stuff, now there's an abstraction layer. So Next.js is tightly tied to Vercel. Remix of course is trying to be a bit different where they're like, "We have these action layers that work with any number of cloud providers."
I think they're up to Fastly Compute@Edge just launched support. So I think they have six official compatibility. I think that's just trend where the framework presents this nice simple interface. You're like, "I'm just building a monolith thing and it's doing its thing and I have this nice simple dev environment." And then all sorts of weird stuff happens once you push it out to the cloud. Google Cloud, they just released a new Go framework.
The idea was, you have this Go framework and then you write the normal monolith Go code, but it can automatically split up the site and deploy it out and scale up each piece independent of other ones, which is exactly how all of the new Java Square frameworks work because Remix Next.js, each route becomes its own serverless function. And so if you have one function which has a million visitors or whatever, you just scale up 100 servos functions for that and the rest of the site's fine. This also has a lot of evidence in advantages too, which is used to be with a true monolith, there's an uncut exception, bam, your whole site's down.
Where now, it's just basically one person. Well anyone visiting that route and reps, or perhaps whoever's triggering that exception. But it's much more robust against problems, this approach. And so it is a pretty magical developer experience. There's this nice simple little framework that I'm doing and then somehow or another, when I deploy it's perfect. It just works. And that's only possible because the deep integration between the framework and the pass. And that's really been the big evolution of passes over the last 10, 15 years.

Noel:
Was a lot of your motivation for Gatsby Cloud originally was that you just knew that there were performance benefits or maybe developer experience benefits, that the only way to realize them would be to have a cloud offering that could be running code all the time as a service?

Kyle Mathews:
Yeah, exactly. It's just how do you create great user experience? It is just this deep vertical integration between all the pieces just to make that happen. Because if there's gaps, then it requires each developer, each team to figure out those things. And I've talked to old web heads who have worked on the HTTP cashing tooling and standards and stuff, and they're always just a very high percentage of people never set cash control inhibitors. And those that do, a lot of them set it wrong. And so you just have this massive performance problem that's trivial to fix.
So when you have the framework strongly push you towards stuff, because the framework is the user interface to the developer, because cloud stuff is so low level, it doesn't really tell you at all what to do. So you have to build up a lot, so you just get a lot of things wrong inevitably. Where the framework is very high level and it's like, "No, do these things because you're directly doing stuff and it can tell you when you're doing it wrong," and whatever. And then the cloud can also have extra enforcements, but also just then responding to that. Anyways, it all leads to a much higher likelihood of good stuff happening versus older style passes, which are lower level and then the cloud stuff, which is even lower level.
I had early Gatsby talks... The Russian writer, Tolstoy, Anna Karenina, one of his famous novels, it starts with, "Every happy family is the same, but everyone have unhappy family is unhappy in their own way." And I took that to web performance. Just in general building complicated stuff for the web, there's lots and lots of ways to do it wrong. There's lots of ways to slow down your site, but all fast sites are pretty much the same. They all do the same practices. And so how in a framework and in a cloud offering, strongly guide people towards that while still allowing maximal freedom to build whatever they want.

Noel:
I feel like most devs, they understand that there are limits to the things that they know. Somebody that's spent the last five years working in React and they're super competent on frontend behavior and weird nuances of React built. You ask them to set up an Engine X server and they're like, "I can set one up, but I don't really know how to configure it to do what I want."

Kyle Mathews:
Yeah, exactly.

Noel:
So it feels like those abstractions make a lot of sense.

Kyle Mathews:
The trick is always, of course, it's abstractions then limit you. And so the question when creating abstraction, is there enough people that need the abstraction to make it worthwhile? Because they're costly to create and maintain and so forth. And generally speaking, actually the answer is no. The abstractions aren't worth it. If you look at Jamstack space, what is the total revenue versus AWS? We're like a little pimple on the nose of AWS. There're billions of dollars in Jamstack because I don't know, a hundred million or something.
Which is not trivial, of course. Well also, it's funny too, if you think about it, cloud isn't even the majority of compute spend. That's a different story. So Jamstack passes, specifically Jamstack style pass where you're composing together frameworks and different services, credit application. It is a pretty high level abstraction, but it does lead to a very nice dev experience for a lot of stuff. And it's big enough to create its own self-sustaining momentum.

Noel:
Nice. What are you looking forward to, in the Jamstack? Or what do you think the future next five years is going to look like?

Kyle Mathews:
That's a great question. It feels like we're in this maturing phase where a lot of the core pieces are well understood, they're just maturing. So it's the whole rewrite all the tooling and rest. They're not innovating in the sense of, it's new in some way or another. It's just like, "What if we make this 10x faster?" That would be great. And it is great. It's nice to have your dev tools pop up and churn through big stuff and have to wait minutes for [inaudible 00:25:49] to finish and whatever. So there is huge advantage of that. But that's evidence of we're in a maturing space, things are understood, we're just making them better. There's a lot of examples of that. So it's just the different pieces.
There's content infrastructure APIs, CMSs, headless CMSs, that space is maturing rapidly, the database in the cloud. It's funny now, but 5, 10 years ago using a hosted database was wild. And now it's like, "Why would you ever not use a hosted database? How do you set up backups?" I don't know. So hosted databases are pretty mature and always used. So there's frontier stuff. So edge databases is... Edge functions, now there's a lot of them out there. A lot of people are starting to experiment with them or use them, but we really need some way of synchronizing data or subsets of data to edge databases so that you can not just do transforms at the edge but actually query data and whatever.
And there's a ton of people working on that. I'm really interested in local first type approaches where the application data lives in the browser and then is synchronized to authoritative back ends into other users. Because I have been experimenting a decent bit the last few months. And it's just such a pleasant way of building application because everything is just read, write to a local store and it just magically ends up elsewhere. Because a lot of the complexity in building applications is just sending data back and forth. And if you can make it so that the abstraction is basically you're like, "I'm just reading, writing data basically inside the browser," it's a much simpler mental model to work in.
And it also ends up with much faster applications. Everything is instant, 60 frames per second, which is great. The problem also with passes is that they have this DX advantage over the cloud giants, but they don't have a cost advantage. Because generally speaking, they're built on top of those. And so it's cost plus cost, but it's worth it because it's so much easier and faster. But it's always the Empire Strikes Back sort of thing. It's like, what's... AWS Amplifi or something is basically they're pass equivalent but cheaper. So how long can pass sustain a big developer experience advantage over the cloud giants? And then how do they keep differentiating themselves over time? Because right now the develop experience gap is quite large.

Noel:
Yeah, it's big.

Kyle Mathews:
It's inevitable that that will shrink. An interesting example of that too is I recently saw there's a few startups that are building services which set up Netlify, Vercel experience of connecting to GitHub and building your stuff, deploying stuff, whatever. But they run directly on AWS. So they claim to give you 80% cost advantage. And so anyway, is it going to appeal to everyone because it is going to be more raw, whatever.
And so some people who want a really curated experience with support people and tell me what to do and whatever are still like, "No, we need the path. We don't want to deal with all that." But yeah, it does start bleeding into the differentiation still again. It's a very dynamic space. AI people are like, "Well, why do we even need websites? Just give a conversational bot and it'll sell the product for you," type thing. Is the current concept of marketing sites going to survive in its current form?

Noel:
Inevitably, at the very least, there's going to be a content explosion on the website beyond even what we've seen right now. You Google a recipe and you end up on all these recipe blogs that are just rehashing the same data and putting their ads in there. We're going to see that probably proliferate into almost everything now, it is going to be so easy to just spit content out.

Kyle Mathews:
So the AI mediated... AI generating a bunch of crap, so now I need AIs to summarize and condense all the crap.

Noel:
Yeah, exactly.

Kyle Mathews:
And so, the AI wars have begun, but whenever there's more crap than people have carefully really thoughtful, really well-designed stuff that stand out even more. Which it's like the Amazon versus Shopify. Everything's here and it's all presented in a generic way, which is great when you're looking for a new cup measure or something for your kitchen. You don't want some differentiated thing. But Shopify's like, "Hey, we're the opposite of that."
We're these really awesome companies building amazing products that are going to change your life. And so that's why Shopify's invested in Remix. Because they're like, "We want to help people create these incredible marketing sites that are dynamic and immersive and have video. Do whatever you want," because that's how they're differentiating from Amazon. Amazon's generic commodity stuff and Shopify's differentiated high-end design stuff. So there's always going to be that interplay of the more junk there is, the more really good stuff stands out.

Noel:
For sure. Is there anything else you wanted to share or anything else you're excited for that's coming out?

Kyle Mathews:
Valhalla, it's chugging along, so I think that's going to be very exciting. Coming to Netlify account near you. But yeah, bridges are messy stuff, so it's going to be a little bit.

Noel:
Thank you so much for coming online and chatting with me, Kyle. It's been a pleasure.

Kyle Mathews:
Yeah, my pleasure as well.