Yeah, it's exciting. With us, we have the creator of GatsbyJS, which is he is also the founder of GatsbyJS, which is a startup based out of San Francisco. We're going to find out more in a little bit on what you're doing there. His handle on Twitter is KyleMatthews. You would never guess, but his name is als Kyle Matthews. Welcome, Kyle.

Kyle Matthews:

Hey, glad to be here.

Matt Kleve:

Hey, Kyle. You're in San Francisco, right?

Kyle Matthews:

Yeah. Yeah.

Matt Kleve:

Isn't that where all tech people are?

Kyle Matthews:

Well, some of us, yeah. It does seem a lot out here. Yeah.

Matt Kleve:

Also with us today to help me out a little bit, we have senior front-end developer at Lullabot, John Hannah. Hey, John.

John Hannah:

Hey, how's it going?

Matt Kleve:

Awesome. John is the creator and curator of JavaScriptReport.com, which is an amazing website and newsletter for keeping on top of the JavaScript ecosystem. You're from who knows where in the United States, right?

John Hannah:

That's right. Parts unknown. Yeah.

Mike Herchel:

Are you moving to Florida?

John Hannah:

I don't know yet.

Mike Herchel:

John's in a car somewhere.

John Hannah:

No. I'm actually packing as soon as we're done here, and I'm going to head down to Florida for a month.

Matt Kleve:

The remote nature of Lullabot is pretty nice, isn't it?

John Hannah:

Yeah. Yeah, it makes life nice.

Mike Herchel:

Yeah, John can be found on Twitter at J__Hannah with a [inaudible 00:02:08] two underscores on that, it looks like.

John Hannah:

Yeah.

Mike Herchel:

And also JS_Report on Twitter with one underscore. You're kind of scraping the bottom of the barrel for usernames there, John.

John Hannah:

You're right. John Hannah is just a famous actor named John Hannah.

Mike Herchel:

Yeah, so was the John Hannah with one underscore already, or the J Hannah with one underscore already taken?

John Hannah:

It was taken. It was totally taken.

Mike Herchel:

[inaudible 00:02:32]. That's awesome.

John Hannah:

J Hannah, it could be like Jeff Hannah. Anyway, I did what I could.

Mike Herchel:

All right. You did what you could. All right. Let's kind of get down to it. Kyle, you're on kind of a mostly Drupal based podcast. For a Drupal developer who's not terribly familiar with JavaScript, what exactly is Gatsby? Is it Gatsby or GatsbyJS? Kind of give us the 10,000 foot overview of it.

Kyle Matthews:

Yeah, so it's basically I created Gatsby because I started with Backbone six or seven years ago, BackboneJS doing kind of rich JavaScript applications. Then when React came out, I jumped into that and really loved it. Anyways, I've been using React about a year. My love for React to reach the fever point that I didn't want to do anything, use any other system ever again sort of thing.

Kyle Matthews:

I needed to build a website for a startup I was actually working on at the time. I was like, "How do I use React to build website?" Because normally, of course, React is used for applications, web applications. That's not a great fit for websites, because it's slower to load, and you don't have ... The SEO kind of bot crawling aspect is weird, and that sort of thing. I was like, "Okay, how do I kind of make React work for website?" That's where Gatsby came out originally was it was kind of like had this technique for making that process pretty simple and approachable.

Mike Herchel:

So Gatsby makes websites?

Kyle Matthews:

Yeah. It's React for websites.

Mike Herchel:

Yeah, React for websites. So it's a static site generator, right?

Kyle Matthews:

Yeah.

Mike Herchel:

Yeah, so it can ingest X data from somewhere, and at that point what generates React files and something like that and static? Like static HTML files with React in it?

Kyle Matthews:

Yeah, exactly. Yeah. You install Gatsby, and Gatsby's a node app. You just [inaudible 00:04:46] install, whatever. All the normal stuff there. Then you build the site. You run Gatsby Develop, and it kind of has a development server with hot reloading and everything that makes it really kind of convenient to build stuff. Then when you want to do a production deploy, you run Gatsby Build, and that builds HTML files, and it builds a bunch of JavaScript bundles that kind of have ... Because Gatsby does what we call code splitting. It kind of takes all the different code for different pages in your site and splits it up into little bundles so that when you load the site, you're only loading the JavaScript necessary for the portion of the site that you're on. Then as you navigated around, it's lazy loading in different parts of the application.

Mike Herchel:

When you built Gatsby, did you take any inspiration from any other existing projects or systems or anything like that?

Kyle Matthews:

Well yes.

Matt Kleve:

An F. Scott Fitzgerald novel, perhaps?

Kyle Matthews:

Yeah. I just had a feverish dream after a late night of reading Gatsby.

Matt Kleve:

Or it was the Leonardo DiCaprio movie, one or the other.

Kyle Matthews:

Yeah. It's been a while now. Yeah. That's hard to answer, because it's like, well, of course I did, because it didn't come out of nothing, but it's not ... Yeah, there's not any one thing that was the direct inspiration. It was kind of more of a conglomerate of inspirations. It took a lot of inspiration from kind of existing [inaudible 00:06:27] generators, like Jekyll. Actually, the initial version of Gatsby I released three years ago was basically Jekyll, but with React components. It did the same sort of thing where you have markdown files and whatever. It's since diverged somewhat from then.

Kyle Matthews:

Yeah, so it took a lot of inspiration from that. It also just took a lot of inspiration from just the React world. My intention was that it should feel like you're building a React app, but it would produce a very fast website. You have kind of the really nice kind of development experience that you get when you're building a React app, but what it spits out is every bit a website, as far as performance goes.

Matt Kleve:

Yeah, for speed and performance, it sounds like were really kind of your biggest end goals.

Kyle Matthews:

Yeah. Yeah, it's definitely speed of the site and speed of the building process. Yeah, because I like to ship things, and I like fast sites. These things I cannot lie. Anyways, yeah. Yeah, I've never seen the point of slow website. It seems almost like, "Of course it should be fast."

John Hannah:

[crosstalk 00:07:42]. Yeah.

Kyle Matthews:

Yeah, but actually that is an interesting point though that most website frameworks, like speed is a possible condition, if you will, of the framework, but it's not necessarily something that's done by default or even easy.

Matt Kleve:

Yeah, it's never a bad thing, but it's not always something that was put in the forefront to begin with.

Kyle Matthews:

Yeah. Yeah, so static sites, just by their very nature, tend to be quite fast.

Matt Kleve:

Yeah, turns out Apache's really good at serving files.

Kyle Matthews:

Right, right, right. It turns out it's super convenient just to be able to distribute your files all around the world on a CDN and have them five milliseconds of latency away from your browser and stuff. Yeah, so just the very nature of static sites solves a lot of performance problems, but I don't know. Yeah, it's just something that I've always been interested in is what makes websites fast. I've read a ton of blog posts and research on this and stuff. It was just kind of an interesting design challenge. It's like, can you make performance a first class part of a framework? That it's not that your website can be fast, but it's more it flips it on the head. It's like, "Well, your site can be slow if you do it sufficiently bad. If you mess it up sufficiently bad, your site can be slow." Under normal conditions, it's just by default super fast is the goal.

John Hannah:

That's cool.

Mike Herchel:

Can you run us through maybe some of these optimizations on why it's fast? I know you have Service Workers, PRPL Pattern, I'm sure a lot of people don't know what those are. If you can kind of explain how they're used and maybe just give a brief overview.

Kyle Matthews:

Yeah. When people talk about fast, there's a few different ways you can think about it. There's one that's time to first byte, how long does it take to get any data to the browser? That's largely solved by putting things on the CDN, because it's very close, and then the CDN has static files that just returns immediately. That kind of solves the time to first byte problem.

Kyle Matthews:

Then the next thing is time to first paint. That's largely around delivering a very lean HTML file that has only the critical resources. You're only grabbing the critical resources, and hopefully as much of them are in-lined so that the browser says, "Give me the site," and then the HTML starts streaming back. Then the browser is like, "Sweet. I already have everything. I don't have to go make a bunch of JavaScript and CSS requests that's blocking in the head." It's just like, "I got everything," and then it can render right away. If you have a very lean, streamlined HTML file, then your time to first paint is extremely quick.

Kyle Matthews:

Gatsby actually does a lot of ... It'll automatically in-line critical CSS in your head for you, which is a lot of people are like, "Hey, that'd be cool to do," but it's a lot of work actually to set up, so most people are like, "I'm just trying to ship this thing," and it doesn't end up happening. But because it's built in, you just get it by default, unless for some reason you break it or whatever. You're going to have kind of that in-line critical CSS really fast initial paint experience by default.

Kyle Matthews:

Then yeah, past that, there's also what can affect the perception of how fast your site is is what's called time to interactive. That's when the browser UI thread is not busy anymore, meaning it can respond to scroll events. It can respond to clicks and so forth. If you load a site and it's just pegged, like the CPU is pegged, everything is jerky, you click on things, and nothing happens. As a user, you're just like, "Oh, this is super frustrating, and it feels slow and broken and dumb."

Kyle Matthews:

The trick to solving that is basically to only, again, load the critical JavaScript, because JavaScript is typically what's pegging the CPU. What Gatsby tries to do is it tries to automatically split up your JavaScript so that on a given page, it's only loading the JavaScript that's actually necessary for that page. If it's only 100 kilobytes or whatever, then the time to interactive is very fast, because even low-end devices can go through 100 kilobytes pretty quickly sort of thing.

Kyle Matthews:

Yeah, so that's kind of like the initial quick sprint into loading your site. Gatsby tries to make kind of that critical path for getting pixels on the screen and making your site responsive, like ready to interact with, make that as fast as possible.

Kyle Matthews:

Beyond that, there's a few other things that Gatsby does that have a huge impact on kind of the perceived site performance. One of those is ... Where was I going? Oh yeah, image loading. A common problem is you have a long page, and then there's a dozen or two dozen images on it. If you just have all those images in the HTML, when you load the page, the browser is going to kind of parse through the HTML and it'll be like, "Sweet. This page wants me to go get 20 images," and then off it'll go and try to get them all at once, which can really clog down fetching additional things for the page.

Kyle Matthews:

Ideally, you're lazy loading in all your images so that you only load images that are actually in the [inaudible 00:13:55]. Gatsby has a React component that does that for you in a really slick way. Another part around image loading that is hard to do and often not done is just having what's called a placeholder. Kind of a common one is having a fuzzy, blurry, low-resolution version of the image, and then showing that immediately. Then when the actual image comes in, kind of fade in that. That's also something that Gatsby image can do, tied in with Gatsby's data layer. Anyway, there's a bunch of [inaudible 00:14:37] images.

Kyle Matthews:

Another things that we do is that because it's an actual React app that's running, and it's all kind of client-side driven, Gatsby has a little runtime that loads with your site. As soon as it loads, it starts saying, "Hey, what page am I on? What pages is this person likely to click on next?" Then it immediately starts pre-fetching the resources, the JavaScript and data for those pages.

Kyle Matthews:

When the user then goes to click on something, instead of you load a site and it just sort of chills until the user says, "Oh, I want this other page," we're actually like, "Hey, let's use this time that they're looking at something to go out and pref-fetch stuff." Then when I click on it, it's like everything's already loaded, and then like, "Boom," you just do kind of instantaneous page transition.

Mike Herchel:

I've done my personal home page/blogging in Gatsby before, and I had a lot of fun doing it, but one of the coolest things was just looking at the network tab and going onto the homepage. Then I scroll down, and as I scroll down, I see all these network requests, fetching, and JavaScript and stuff like that, and it just pops in. It's so cool. If I go to my homepage, which is Herchel.com, it's the best website on the internet, and without the S. Just a C in there. You scroll to the bottom, and you click on the bottom, it's just instantaneous. It just loads probably in under a second. That's pretty cool.

Kyle Matthews:

Yeah. Yeah, yeah. Yeah, and it's just something that people want to do. It's kind of a ... Yeah, anyways, this is again, if we make performance a first class principle of Gatsby, and we put in the effort to make these things kind of happen automatically for you.

Mike Herchel:

Cool.

John Hannah:

Kyle, I've got a question, kind of followup on that with the Service Workers stuff. What do you guys do with that, and how big of a pain did you find the Service Workers stuff?

Kyle Matthews:

Yeah, Service Workers are weird. That's for sure. Yeah, so this is something that we think is really an amazing addition to the web platform, because again around how do you make websites feel fast? You just look at all the different ways that people interact with websites. You load it the first time. You're clicking around pages. There's big images that are loading. There's all these things you can do to make the site feel perceived as faster.

Kyle Matthews:

Anyways, yes, Service Workers is awesome, because people often go to a site, and they often return. If they return, why should you have to go back to the server to get the site again if you've already been there before? So Service Workers is like, "Hey, let's give you a really smart cache that you can programmatically control. Then if somebody comes back, you can immediately just serve the site from there instead of making them go back to the server," which is often fast, but often people are also on their smart phones or whatever on 3G or whatever. Then it's really slow. Service Workers does a really brilliant job in solving that kind of repeat visitor kind of experience.

Kyle Matthews:

Yeah, so Service Workers can be really weird. It's just like kind of a trippy programming model. It definitely has a lot of [inaudible 00:18:26]. You can dramatically break your site in interesting ways that are hard to debug or even know that they're happening. They could just be people around the world are just ... Anyways, yeah, you don't want to just jump into it.

Kyle Matthews:

We have a plugin called Gatsby Plugin Offline, which especially with the ... We've done some improvements for the V2 version of it, but I feel like now it's actually really, really solid. It was pretty good in V1, but now I feel it's really solid V2. Yeah, so Service Workers are definitely worth investigating. It's actually pretty workable with Gatsby. It's just simplified because we [inaudible 00:19:12] just static files. That does simplify the logic a lot of pulling stuff from the cache and just serving it again. Definitely recommend Service Workers, but do you research and experiment first.

Mike Herchel:

How is Service Worker caching different than just regular browser caching? You mentioned that the Service Worker, you can control it programmatically. Is it any quicker, or is that just it right there, the fact that it's programmatic, you can control it better?

Kyle Matthews:

Yeah, it's just that it's programmatic. Yeah, because it's programmatic, you can do new things, where before, you couldn't basically serve ... Well yeah. Yeah. It's just like serving ... You could serve a whole site offline, because the service workers, it's more of a proxy than a cache. The proxies can act as a cache, but the point is that you can intercept every recept that your browser makes and then do whatever you want, which enables stuff like true offline support, which just the browser cache wouldn't work for that.

John Hannah:

What is the best use case for Gatsby? One of the things I heard is we've been talking about static sites. If you wanted to do auth, if you need user profiles, or personalization, or whatever, that Gatsby is not ... or any other static site, is maybe not the right thing, that Gatsby wouldn't be the right path. But then I've seen [Netrufy 00:20:50] has some product that is like an auth for Gatsby. Then I also saw you had these starter kits. I saw one that had auth for Firebase. I was kind of wondering what the deal was? What's the sweet spot for Gatsby? What sites should Gatsby probably not be used on, if any?

Kyle Matthews:

Yeah. That's a great question. Gatsby has heritage. It kind of pulls inspiration from static sites, but we don't really think of ourselves as a static site generator, per se. The best way to think about Gatsby is it's React for websites. It makes using React, in kind of website use cases, practical. But at the end of the day, when your site is running, it's just a React app like anything else. If you can build an application with React with authentication, personalization, whatever, you can build the exact same application with essentially no changes in Gatsby as well.

Kyle Matthews:

Yeah, so it's just like if you're familiar with how to do JavaScript applications, then Gatsby is exactly the same as what you do there. Using something like Auth0 or [Netifys 00:22:08] authentication service or Amazon's authentication service or whatever, basically you load ... So you have Gatsby site and it loads, and then there's a login button. Then they authenticate somewhere somehow. Then you have a JavaScript ... You have some sort of token then. Then you can sort of make an authenticated request to an API and then render whatever you want on the client.

John Hannah:

Cool, so there really aren't too many limitations like that for Gatsby.

Kyle Matthews:

Mm-mm (negative). Yeah.

John Hannah:

Cool.

Kyle Matthews:

Yeah, we really try it's like, "Okay, what are the best ideas from the app world? What are the best ideas from kind of the website world? How do we blend them together?" Because to us, the app versus site distinction is pretty artificial. It's more of kind of a community path dependency technology divide that websites came first, and then apps were this offshoot that then kind of grew into its own full-blown thing. Then there's kind of this mutual incompatibility between the tech stacks. Gatsby is like, "Hey, how do we sort of reconcile them and bring them back together?" Because at the end of the day, we're just all shoving stuff on the browsers.

John Hannah:

All right. Cool. That's it.

Matt Kleve:

Or these screens.

Mike Herchel:

Yeah, I think that's a quote I heard from you, Matt Kleve,

that at the end of the day, we're all just concatenating stings together, right?

Matt Kleve:

Yep.

John Hannah:

Yeah.

Kyle Matthews:

Yeah, exactly. Yeah.

John Hannah:

Cool.

Kyle Matthews:

Yeah, so Gatsby is like, "Well, why don't you use the same tool to do app stuff and site stuff? Why do you have to learn multiple technologies when there could be one tool that is a really great fit for all of them?"

Mike Herchel:

Make sense, but Gatsby does connect into Drupal, WordPress, and other content management systems, correct?

Kyle Matthews:

Yeah, yeah. That's one of the big features that we added in to V1 last summer, which was the ability to have plugins which pull data from basically any system with an API you can pull in data and then build your site with it.

Mike Herchel:

That's pretty cool. We can talk about that a little bit later.

Kyle Matthews:

Cool.

Mike Herchel:

You mentioned you were talking about Gatsby Develop and Gatsby Build and the developer experience with Gatsby. Can you maybe, I don't know, if there's anything else that you want to talk about, we don't have to edit webpack configs or anything like that, do we?

Kyle Matthews:

No, no. Yeah, yeah, yeah. Yeah. The idea is that with Gatsby, we know what you're doing basically. We can have a kind of community maintained really, really optimized webpack config, Babble config, etc, post CSS config, or SAS config or whatever that just kind of takes care of things for you, because we can make ... When you have a higher order tool, you can make more assumptions about how it's being used, and pretty much everyone's webpack at the end of the day kind of ends up being the same.

Mike Herchel:

Cool.

Matt Kleve:

Sure. We're talking GatsbyJS with Kyle Matthews, the creator of Gatsby. Kind of a little bit of a stretch here from the normal things we talk about here on the Lullabot podcast, don't you think, Mike?

Mike Herchel:

Yeah. Yeah, definitely was pretty cool.

Matt Kleve:

Yeah, but it's all about this web of technology that you end up picking and choosing for your projects.

Mike Herchel:

Mm-hmm (affirmative). There's a lot of choices.

Matt Kleve:

We'll get to talk a little bit about the future of Gatsby, what's going on as well as get a little further in depth coming up right after this.

Hey, there. We've got some new tutorials on the way on deployment workloads that's going to augment our series on configuration management. Tess Flynn has been working on those for us. Tim Millwood is working on a series of tutorials on content moderation, and we're looking to release those in the fall. Lullabot Education is working on a new site, ReactforDrupal.com. Sign up for the mailing list to get notified when they release new tutorials.

Amber:

Finally, Joe Shindelar and I will be at Drupal Dev Con presenting our Beginning Drupal 8 gaming workshop. It is sold out, but if you're at Dev Con, please come and say hello. We'd love to say hi.

Mike Herchel:

Hey, welcome back. We're on the Lullabot podcast, and we're talking about GatsbyJS with Kyle Matthews, who is the creator of GatsbyJS. But before you did Gatsby, Kyle, I've heard that you actually have a history with Drupal, is that correct?

Kyle Matthews:

Yeah, that's correct actually, yeah.

Mike Herchel:

Yeah, so how did you escape?

Kyle Matthews:

Well, it's a multi-year process.

Mike Herchel:

Have they been tracking you down, sending web check [inaudible 00:27:08] knocking on your door?

Kyle Matthews:

No, no, no, no. I had kind of a leveraged escape [inaudible 00:27:15]. I don't know. Yeah, so I started ... Drupal is actually one of the very first programming things I ever did back in 2006, I think, so I was a sophomore in college. Drupal 5 was in one of its last betas. I don't think I'd ever done any PHP or MySQL kind of stuff before. I kind of laboriously figured that all out, how to get it going in Windows or whatever I was using back then. Then hours went by, and then I was so excited when the Drupal blue install screen finally popped up. I was like, "Yay, this is so amazing. I'm a developer, sort of."

Kyle Matthews:

Anyways, yeah, so I started doing just side projects. Some roommates and I, we built a t-shirt company. Very classic college thing to do, I guess. Anyways, I built a little e-commerce site with Drupal. I can't remember which plugin I used. It was one of the early e-commerce-

Mike Herchel:

Is it like Ubercart or commerce or one of the two?

Kyle Matthews:

Yeah. I think it might have been Ubercart. I think that was fairly new at the time, and so I used that. That was cool. Then I was like, "Sweet, I built an e-commerce store." We made several thousand bucks.

Matt Kleve:

Nice.

Kyle Matthews:

Definitely worked. Yeah, and then I was working with some professors building sites for kind of social learning purposes, if you will, so just letting students post basically blog posts, kind of, and then other students can comment on and whatever. I got really into that. I was kind of like, "School sucks. It should be better. Let's rebuild it on the internet," or whatever. I don't know. I actually tried doing ... This was back in the hay day of the Drupal [Distro 00:29:09] stuff. I actually tried doing a little startup building the Drupal [Distro 00:29:15] called [Eduglue 00:29:16], which is one of the few installable ones that ever were built, I think.

Kyle Matthews:

Anyways, that was pretty fun. Got really deep into Drupal with that. Also did Google Summer of Code with Drupal in 2008, I think, whatever. Anyways, yeah. So did quite a bit back then, and spoke at several Drupal Cons. Then yeah, when [Eduglue 00:29:48] was starting to ... I didn't really know what I was doing back then, so it didn't really have much chance of going anywhere, but anyways, I worked on it for a couple years and was kind of losing steam.

Kyle Matthews:

I was like, "Okay, I really got to quit this, because I don't know what I'm doing. It's not being successful." I was like, "Okay, what do I do next?" Because I didn't do CS, and I didn't really ... Anyways, at that point I was like, "I like programming. I like startups. The next natural step, of course, to go to Silicon Valley." Then I was like, "Okay, now I'm here. What do I do now?"

Kyle Matthews:

Pantheon was pretty new at the time, and so I'd heard about them, and I was like, "Oh, that sounds pretty fun." I was also getting really interested in just kind of JavaScript web apps, because it was like, "Okay, PHP is cool, and you can do a lot with server rendered stuff," but I was like I could see there's a ton of potential if you can run a real application in the browser, because then all the interactions have instantaneous feedback and kind of feels very app-like once you're doing that. I was like, "Okay, that's like the future. I want to do stuff like that."

Kyle Matthews:

I was like, "Okay, Pantheon is doing really cool stuff." I kind of was like, "Okay, that'd be a great kind of way to get into that, because I already have a connection there and understand it from the Drupal world, but also they're pretty ambitious in doing interesting things, so I can then have a chance to learn those skills."

Kyle Matthews:

Actually, I went to [inaudible 00:31:17] camp and talked to Josh. I was like, "Josh, do you need a JavaScript engineer?" He was like, "Yes we do." We got lunch, and then yeah, so joined there in late 2011 I think it was. Kind of end of 2011. Yeah, so then I worked there, built out their dashboards and all that jazz for a few years. Then left there to try another startup. Then when I was working on that startup is when Gatsby came about. Then that startup failed, but it got to be it did fail. It kind of went out of control, and now I'm doing another startup with [inaudible 00:31:58] Gatsby.

Kyle Matthews:

It is funny though, yeah, because now all of a sudden we're talking to all these Drupal people again. I'm like, "Oh." It's like old friends back then.

Mike Herchel:

Yeah, we're coming back to get you.

Kyle Matthews:

Yeah, yeah, yeah, yeah, yeah. One way or another. Yeah. Yeah.

Mike Herchel:

But Gatsby does interface with Drupal, correct? Right?

Kyle Matthews:

Yeah. Yeah, yeah, yeah.

Mike Herchel:

How would I go about and do that?

Kyle Matthews:

Yeah, so basically Gatsby has this data layer that lets you pull in data from anywhere and then hook it up to your React components, and then kind of add build time, kind of combine the data and your components and create the static site. It's actually pretty straightforward. You just need ... There's a Gatsby Drupal plugin that you install and add it to your Gatsby site. Then you just point it at a Drupal 8 site with the rest module installed. I think you need the JSON API [inaudible 00:33:04]. I haven't looked at it in a little while.

Kyle Matthews:

Anyways, the instructions are in the plugin. You add that. Then at that point, it's pretty much automatic. You just start up Gatsby, and then there's kind of this interactive console where you can write queries and look at your data. At that point, you'll have access to all your Drupal data, and you can write GraphQL queries, what it's called, and then pull in the data to your components using that, call your Drupal data.

Mike Herchel:

That sounds pretty cool. So the GraphQL doesn't run at runtime. That's generated during the build step. Is that correct? Like the actual JSON or HTML?

Kyle Matthews:

Yeah.

Mike Herchel:

Yeah.

Kyle Matthews:

Yeah, exactly. Yeah. GraphQL, it's just queries. It's like SQL or whatever. We use that to, yeah, build time to know what data you need for each page.

Mike Herchel:

Gotcha. Gotcha. Yeah, yeah, yeah. That's pretty interesting. I've used that. I don't have my personal site hooked up to Drupal or anything. I'm using Markdown, but when developing for Gatsby, you're actually even querying Markdown with GraphQL, which is pretty neat. There's the utility, a website based utility that's included with GraphQL, which is included with Gatsby. Is that called [GraphicQL 00:34:25] or something like that? Is that right?

Kyle Matthews:

Yeah, yeah. [GraphicQL 00:34:28]. Yeah, yeah. That's kind of the [inaudible 00:34:32], if you will, for playing around with queries.

Mike Herchel:

Yeah.

Kyle Matthews:

Yeah, it's super cool, because it has an auto complete and you can just try out different queries and explore your [inaudible 00:34:43] marks for the different ways of querying. Then you instantly see what data you get back.

Mike Herchel:

Yeah, it's a really cool experience, like for me who has never played with GraphQL before, it enabled me to actually write queries without knowing what the hell I'm doing, which was pretty fantastic.

Kyle Matthews:

Yeah, yeah. Exactly. Yeah, yeah. Yeah, it's because it's super nice when you're building out a new screen or something. You can just sort of sketch. You can wire frame it out, and you go like, "Oh, what data do I need?" Then you just jump into [GraphicQL 00:35:12] and you can poke around your data and you're like, "Okay, I need this field, I need this field, I need this field." You just keep tweaking your query until you have all the data you need. Then you copy that over into your component. Then your component instantly has all the data, and then off you go. It's a really nice experience.

Mike Herchel:

That's pretty cool.

Matt Kleve:

Are there any other plugins that might be particularly useful or cool in the Gatsby ecosystem these days?

Kyle Matthews:

Yeah. There's a ton of them now. We have a plugin library, gatsbyjs.org, that you can browse and search all them. I think the last time I looked, the last day or two, there's 375 now. These plugins, they run the gamut from all the kind of source plugins that connect to different data sources. There's 100 plus now data sources that are supported, which is really cool, because often times you're building a site, and okay, you have your CMS where your content people are maintaining and adding content, but you often have other services that you might want to use in your site.

Kyle Matthews:

A really common thing for companies is they have a job page. You're probably using some sort of service like Greenhouse to kind of track your open jobs and submissions and so forth. It's really easy to just add the Greenhouse source plugin. Then you create a jobs page by just querying all the open jobs from Greenhouse. Then you're a recruiter or whatever, all you have to do is you add a new job to greenhouse, then automatically gets added to Greenhouse. Then you fill the job, and it automatically gets removed from the website. Stuff like that is really nice. You just have different sources of truth wherever it makes sense to maintain that data. Then it all is directly drives your website.

Mike Herchel:

Yeah, that's pretty cool. There's also a number of plugins for standard, what do you call them? React, I don't know, plugins. Like one of the ones that I'm using for CSS is Emotion, which kind of lets you write normal CSS syntax, but within JavaScript and all that type of stuff. At least last time I checked, which is probably several months ago, there were several different Gatsby plugins for various CSS and JS solutions and stuff like that. They all look pretty straightforward to do.

Kyle Matthews:

Yeah, yeah. Exactly. Yeah. It's kind of a blessing and a curse how many different CSS options there are these days. Yeah, so all of them, optimizing your CSS is a big part of what makes the site fast. Yeah, there's plugins that people have made that kind of make sure that you're only pulling in the critical CSS for each page and so forth. Yeah, what's cool is that the plugins, you just drop it in, and it just works without having to do too much, which is really nice.

Kyle Matthews:

Yeah, so there's also plugins for stuff like Google Analytics, which can be a little bit tricky if you're not ... One interesting thing about moving to Gatsby is you can't think about the world in quite the same way as you do with a server driven website. For example, like Google Analytics, it normally pings, so every time the page loads, it says, "Hey, here's a new page, the new page." But when everything happens client side, there's not an unload event or whatever that Google Analytics can use to do that ping.

Kyle Matthews:

Gatsby actually has an on route update event hook that you can hook into so that then Google Analytics plugin, it just listens for on route update, and then fires off to Google saying, "Hey, here's a new page." That sort of thing. Yeah, so there's stuff like that, stuff for integrating with different third-party systems, but most of the time once you get past, "Okay, how to pull in data, and what sort of styling option are we choosing?" Most of the time all you need is just React components, just normal React components. Building out the site is basically just either pulling in open source components or building your own, and then designing and building your UI.

Kyle Matthews:

We tried to make Gatsby as kind of streamlined and behind the scenes as possible so that most of the time it just feels like you're writing React components, as you would normally.

Mike Herchel:

Pretty cool. So you also have starter kits. What's a starter kit, if it's not immediately apparent to our listeners?

Kyle Matthews:

Yeah.

Mike Herchel:

What types of starter kits are apparent and popular and stuff?

Kyle Matthews:

Yeah, yeah, yeah. Gatsby is kind of low level in that it doesn't make too many assumptions about what you're doing, which is awesome, because then it's very flexible and very powerful, and you can use it in all sorts of different ways. The tricky part though is then if you're new to Gatsby, it's like, "Well, okay, I want to build a blog. How do I do that?" You don't want to read through all 375 plugins and figure out how they work and which ones that are used together and whatever.

Kyle Matthews:

We have these starters that people can build out different Gatsby sites, kind of like half-built Gatsby sites that are aimed at different use cases. It's like, "Hey, here's most of what you need for a blog. You can then take that and just tweak it to kind of fit whatever vision you need, but you don't need to figure out how to process Markdown. You don't need to figure out how Google Analytics, or you don't need to figure out how to add metadata to your site head and all that jazz that otherwise you'd have to."

John Hannah:

One of the things I'd love to know about is your startups. It's based off of Gatsby. You have this open source project, GatsbyJS. From what you've said when you were first creating it, you weren't expecting it to just explode and go nuts, and it has. Then now you've got a business around it. Can you talk a little bit about that and how that all came to be and what you guys do?

Kyle Matthews:

Yeah, totally. Yeah, so when I first started Gatsby, yeah, it was just like, "Hey, won't this be fun?" Sort of thing if it was easy to make a website with React. As it turned out, lots of other people wanted the same thing. It just started getting lots of contribution, lots of uses and so forth, to the point that it was kind of hard to juggle startup and working on Gatsby. It was kind of like I felt bad. I was stealing startup product time to work on this open source thing that was demanding more and more of my attention.

Kyle Matthews:

But as I thought about it more and more, I was like, "Okay, this thing has a ton of potential," and I knew that I could take it pretty far by myself and with the community's help and so forth, but any larger project, it just needs a team of people behind it. It's just too much for one person to work on. Once I saw that Gatsby had the potential to kind of demand investment from a big team of people working on it, the obvious next question is like, "Well, okay, you need some sort of business model to support that company." Anyways, yeah, that's the goal with Gatsby Inc is to make Gatsby everything it needs to be. It both needs a lot of investment, but also needs a business model to kind of support that.

Mike Herchel:

Are you going to be doing maybe support for enterprise level Gatsby websites? Is that how it's going to generate money, or custom builds, or something else?

Kyle Matthews:

Yeah, yeah, yeah. Support is what we've started with. We already have a number of support contracts and we'd love more. Listeners like you, please sign up. Yeah, but we intend to be kind of a mix of support and product. We actually launched recently our first product, our first kind of cloud product called Gatsby Preview. We did this three weeks ago now I guess? Yeah. Anyways, the idea of Gatsby Preview is when you have a static site, one of the things that you lose out from compared to a CMS is that you're editing content, and then in CMS you have a preview button. You're like, "Hey, this is what my site will look like now with this content," but with a static site, you don't see that. You can't see the effect of your changes until you rebuild that site.

Kyle Matthews:

With Gatsby Preview, you kind of eliminate that gap in feedback. You can be editing content in a CMS and click preview, and it will show you on our hosted Gatsby Preview service a kind of instantly what your site will look like, kind of just like normal. That's something that is pretty hard to do technically and requires deep understanding of Gatsby and requires a cloud service and so forth. I think it's a natural product for us to offer to people that are using Gatsby in interesting ways. We have a number of other related products that we're working that would be really interesting to people using Gatsby in interesting ways.

John Hannah:

That Preview thing sounds really cool. That is hard.

Kyle Matthews:

Yeah.

John Hannah:

Yeah. If you guys don't mind me cutting in, I want to ask him another question before we close out. It's just I saw-

Mike Herchel:

I totally mind.

Matt Kleve:

No.

John Hannah:

It's kind of about the technical direction of Gatsby. I saw this tweet from Ryan Florence, and he said something about, "I'm working with Kyle Matthews on putting Reach Router into Gatsby." Are you guys pulling ar React router out, or is this an also/or/other?

Kyle Matthews:

Yeah, yeah, yeah. So Ryan is one of the original authors of React Router. This Reach Router is kind of a new attempt on his to kind of clean up some of the design sprawl that happened in React Router, plus picks kind of one of the big, glaring flaws of React Router, which is that it's not suitable for screen readers.

Kyle Matthews:

Anyways, we're switching to Reach Router basically to kind of fix accessibility of Gatsby sites, because that's something that's really important to us.

John Hannah:

That's cool.

Mike Herchel:

It's very important. Yeah.

Kyle Matthews:

Yeah, but it's basically it's a pretty easy transition. I'm actually finishing up the PR for it right now, this afternoon after this podcast. Yeah, since he designed both, and React Router is quite mature, most design decisions carry over. Most people, like 95% plus of people won't notice any difference at all. It's actually slightly smaller. It's probably like three or four kilobytes smaller, and yeah, now all your sites will be accessible, which is great.

Mike Herchel:

Nice. So Gatsby 2.0 is currently in beta. Can you talk a little bit about he new features compared to the 1.X version? Also, should new people be starting with that, or continuing on the 1X version or what?

Kyle Matthews:

Yeah. Yeah, so 2.0 is almost out. We're actually hoping to get an RCL next week, maybe even the final version, if things are feeling really smooth. We've been working on ... I would say yeah, so V1 of Gatsby came out a year ago July, so just over a year ago. Yeah, so we've been working on it a while, and we're super excited to get all of the improvements in it and out the door finally.

Kyle Matthews:

Some of the big changes are Gatsby's built on a number of really popular JavaScript tools. React obviously, but also Webpack and Babble. Both Webpack and Babble have had major version releases since Gatsby V1. Were updating Gatsby to the latest versions of those. That's super nice, because there's more JavaScript features that are supported. They're faster, their output is leaner.

Kyle Matthews:

Yeah, so just by upgrading to this, Gatsby sites are smaller, faster, and so forth, which is awesome. That's one of the nice things about building Gatsby now versus maybe a while ago is that we can leverage these really mature, really awesome open-source projects, and that's just doing a fantastic job at kind of making Gatsby what it is. That's a big part of the upgrade.

Kyle Matthews:

We've also done some API tweaking. We added a ton of [inaudible 00:49:24] in V1, and luckily most of them really helped up really, really well with all the new plugins and different things people were trying to do with Gatsby, but there's a few that were like, "That wasn't quite right." Better to kind of break APIs now than keep them around forever is our philosophy.

Kyle Matthews:

There's a few breaking changes around APIs, but those are also mostly of interest to plugin authors. Generally speaking, it's not, yeah, something you worry about as a site builder. Then the other big kind of push that we've been making is improving the site build performance. Yeah, because Gatsby V1, it was perfectly fine up to around 1,000 pages or so, but past there, just for a variety of reasons, site build started getting slower and slower.

Kyle Matthews:

We've gone through basically all subsystems of Gatsby and done a ton of profiling and kind of deep examinations of the algorithms we're using and so forth so that now larger sites, like, say, 5, 10, 15, 20,000 are easily 80, 90% faster for doing site builds, which takes them from being not really feasible [inaudible 00:50:51] with Gatsby to being actually quite practical to build with Gatsby.

Kyle Matthews:

We have several benchmark sites now that we're using, and kind of our super stripped-down, Hello World kind of Gatsby site, you can build 100K site in I think the fastest we've done is 88 seconds.

Mike Herchel:

When you say 100K site, that's 100,000 pages?

Kyle Matthews:

Yeah, 100,000 pages.

Mike Herchel:

Wow.

John Hannah:

In 88 seconds, wow. Yeah, but that's with stripped down, not a lot of plugins. Correct?

Kyle Matthews:

Yeah, yeah. So any real world site will be slower. It kind of depends how slow. Depends what you're doing exactly how slow it gets. Yeah, but the point is, yeah, it basically makes Gatsby practical for much larger sites.

Kyle Matthews:

Post V2, there's a ton more optimizations that we can do in open source, but we're really excited though about ... Because at some point, Node is a single-threaded application, it's a single-threaded programming model. You're doing one thing at a time. At some point, you can only make it go as fast as it can go, and you're not going to make it go any faster.

Kyle Matthews:

What we're working on, we've hired some really awesome back-end engineers, like cloud engineers who we're working together to build a kind of cloud version of Gatsby that can take all these heavily CPU-bound things that Gatsby has to do, like render pages and run queries and so forth, and we're going to make them [paralyzable 00:52:43]. "Hey, we want to take a million page site," which would take kind of forever to do if you only had one Node process doing all that, but what if you split that up across 10,000 different workers? Then that million pages won't take very long at all to build out.

Kyle Matthews:

Anyways, we have a lot of things like that that we're working on that will take stuff that ... Our goal is basically to methodically take the 20, 30 different things that slow down Gatsby sites, and then either eliminate them, if possible, or significantly speed them up, or paralyze them in our cloud publish platform so that you can take any site and it'll be just really fast to build.

Mike Herchel:

Nice. Do you recommend a newbie coming in, starting on 2.0?

Kyle Matthews:

Yeah. Actually, at this point, it's pretty stable, and it's a lot better. We're not quite ready to switch to flip to call it actually stable, but at this point, we've had probably many dozens of people, if not hundreds of people upgrade to V2 who've been very happy. A lot of people kicking the tires on it. Relatively few problems have been reported, and we've fixed most of them. Yeah, at this point, if you're jumping in, it's a great time to jump to V2.

Mike Herchel:

How is the upgrade process?

Kyle Matthews:

Yeah, we have a pretty extensive migration guide. For most people, it's probably less than an hour of work to upgrade. It kind of depends on how you built your V1 site, but even worst case, you're looking at a few hours of work to upgrade.

Mike Herchel:

[inaudible 00:54:39].

Kyle Matthews:

Yeah. Something we're really pleased about is that the design has successively kind of encapsulated all the webpack and Babble and so forth. Even though we're making major upgrades, yeah, for most sites, it's pretty much the same thing.

Mike Herchel:

Cool.

Matt Kleve:

Hey, Kyle, I hear in an effort to get you back into the Drupal fold, you'll be talking at Decouple Dev Days.

Kyle Matthews:

It's true. It's true.

Matt Kleve:

Yeah? What are you going to be talking about?

Kyle Matthews:

Okay. Yeah, yeah, a lot-

John Hannah:

Gatsby.

Kyle Matthews:

Gatsby. Yeah, basically a lot of stuff we've been talking about here. It's just what is Gatsby, and why it's a great fit for building high end websites with Drupal, like how you can build incredibly fast sites using React and [inaudible 00:55:37] and all sorts of interesting client-side stuff.

Matt Kleve:

Right on.

John Hannah:

Sounds cool.

Kyle Matthews:

Yeah.

Matt Kleve:

Do you have anything else you want to add?

Kyle Matthews:

Yeah, I'm just really excited about getting really great integration with Drupal and Gatsby going. It's already very usable, but stuff with Gatsby Preview and Gatsby Publish will make it so that it's very practical, like an awesome experience to build Gatsby sites in Drupal, Gatsby Drupal sites.

It's pretty quick, but I have one criticism. It looks like it's a Drupal site.

Mike Herchel:

I actually have this cool little Easter egg. If you're on a wide enough monitor, and you go up outside of the content area and you click and you drag your mouse, it'll change colors. You can change that color into something else.

Matt Kleve:

Ooh, I see it. Yeah, it's yellow now. Ooh, ooh.

Mike Herchel:

Yeah, so it's pretty cool. When I was messing around with CSS variables, Gatsby, and React, and all that type of stuff trying to learn all these newfangled stuffs.

Matt Kleve:

It changes hue from left to right and saturation. No, the other way. The other way. Hue is up and down. I see. That's neat.

Mike Herchel:

Yeah.

Matt Kleve:

Hey, John Hannah, have you been a Gatsby user?

John Hannah:

I've just played around with it. Yeah. It looks great. I think I'd seriously consider it for some of the client projects that we have when it's appropriate, but it looks like it'd be appropriate for a lot of cases. It's interesting.

Matt Kleve:

Yeah.

Mike Herchel:

Yeah, well now you have to.

John Hannah:

Yeah, I see on your site, Herchel, you've got 8th grade-

Mike Herchel:

Yeah, I'm an 8th grade-

John Hannah:

... geography bee champion.

Mike Herchel:

I am. I am. That's my claim to fame. In Murray Middle School down in Stuart, Florida, I won the 8th grade geography bee in 1993, I think like that. It was a little traumatic, because I should have won the whole middle school thing, because they asked me what direction is Portugal from Florida, and I said, "West. Wait, east," like that. Then they disqualified me like that. It was complete bullshit. Anyway, I am not bitter about that bullshit at all today.

Matt Kleve:

If you were good enough, you could have met Alex Trebek.

Mike Herchel:

Right, yeah. I should have been. I should have been. Anyway, we're kind of getting off subject, aren't we?