Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier.

Chris Coyier: Hey! This is going to be a good one. On this show, we talk a heck of a lot about front-end Web design and development, like Dave just said, but also things like fancy new JavaScript frameworks and certainly CMS is the topic I'm endlessly fascinated by; the storage, the grand storage of data on the Internet.

We have a special guest all the way from GatsbyJS. It's Jason Lengstorf. Hey, Jason.

Jason Lengstorf: Hey! How are you doing?

Chris: Yeah, you're at Gatsby now, yes?

Jason: I am. I joined up over a year ago now. I joined last February.

Chris: Right on. Right on. Was it kind of like, "I think Gatsby is cool. I'm going to see if I can get a job there"? [Laughter] Or did it come about in some other way?

Jason: I tell this story a lot, and I feel like it puts IBM in a bad light, but I'm going to tell it anyway.

Chris: That's fine.

Jason: I worked at IBM before--

Dave: [Laughter] That's exactly what we want to hear.

[Laughter]

Dave: Yes.

Jason: I worked at IBM for a while before I moved over to Gatsby. While I was there, part of what I was doing was trying to fix front-end performance on a lot of the IBM cloud offering. Part of my strategy, on the one hand I was doing a lot of stuff with GraphQL trying to normalize the data layer. On the other hand, I was just trying to eliminate a lot of the bloat that was happening on the front-end because IBM had this very prescriptive approach to front-end where everybody had to do everything exactly the same way. As you might imagine, the developers mutinied and then they overcorrected by saying everybody can do whatever they want with no direction, which meant that one of the APIs or one of the services I was working on had Dojo plus jQuery plus React plus Polymer all loading in the same thing and they were loading sequentially, not asynchronously, so this was two minutes to load a UI.

As I was starting to look at solutions for this, I dug into things like Next and Hugo and Gatsby and, ultimately, got really excited about the Gatsby approach because it was the closest to our existing workflow and would cut out all of these complexities that we were running into. Then I got entrenched in, like, a nine-month battle with management trying to convince them that the thing they said they wanted was possible without having to start the company over. I spent a whole lot of time in meetings. While I was doing this, I would get on the phone with Kyle Mathews from Gatsby and ask him questions.

At a certain point, I was just venting one day about how frustrating the meetings were. He was like, "Hey, so it sounds like maybe you don't want to do that anymore." I was like, "Yeah, well, it's a job." He goes, "What if you could have a different job?" [Laughter]

[Laughter]

Jason: From there, we started having--

Chris: Did that coincide with the money at Gatsby? We can get to that a little later, but were you kind of pre-money?

Jason: This would have been three or four months after Gatsby had its actual funding.

Chris: Okay.

Jason: I was very early. I think I was the fifth person to join, if you include the founders, so really, really early on in the Gatsby ramp up. Yeah, it wasn't like he got the money and then immediately recruited me. It was very much a right place, right time. I was frustrated, he was growing, and it just seemed like a good match.

Chris: Sure. How many are you now?

Jason: [Laughter] Thirty, thirty-five.

Chris: Oh, wow. Great. Yeah. Well, it was a big investment. It seems like that's what the money is always for.

Jason: Exactly.

Chris: That type investment.

Jason: Yeah, and we're trying to spin up a lot of different things, so we've got a commercial cloud team that's working on our products. We've got a dedicated team on open source. We've got a dedicated team on our docs because we consider that to be a product. Then we also have sales and marketing and operations. There are a lot of different things that all need to be done.

Chris: Yeah. Yeah, that sounds about right. For the audience of this show who care about the JavaScript-y stuff and building websites and stuff, I guess this is how I think of it. It doesn't even call itself a static site generator. How do you talk about it? Do you use words like that on your team, like, "Gatsby is a static site generator"? Not really? It's called a framework on the homepage.

Jason: Yeah, we've started calling it a progressive Web app generator. That seems to be the closest that we can get to a good description.

Chris: Ah, okay.

Jason: The problem that we ran into was, when we said static site generator, people immediately assumed that that means that it can only generate--

Chris: You're a Jekyll competitor or whatever.

Jason: Or that it just can only generate static content. That's actually not true because when you build a Gatsby site, you're generating static assets. But when it hits the browser, it rehydrates into a full single page React app.

Chris: Right.

Jason: You have all the dynamic asynchronous capabilities that you would have in any SPA. You're just doing it all from static assets as opposed to running a server in the background.

Chris: Right on. Yeah, but you build in React and that's one of the non-options. There are all kinds of interesting optional things you can do with Gatsby, particularly with data sources and stuff, which is fascinating. But React is non-optional, right?

Jason: Yeah. React is very core to how Gatsby works.

Chris: People love React. It's huge. It's easily the biggest JavaScript framework, so probably a decent call there when you're doing it. To me, at a thousand feet view, I'm like, yes; this industry is pumping out React developers. To some degree, I would attribute some of the momentum, thrust, and excitement, and usage of Gatsby to the idea that you can build these sites and you get a lot for free. You get performance, speed, and stuff, and you're kind of following some best practices, too.

If you're going to make a site that kind of deserves to be static, you might have something in the back of your head that says, "You know, this really shouldn't maybe be React because it's really just some content or whatever, but I like React. I want to build it in React." Gatsby allows you to feel good about that. I can just stay in React, in my comfort zone, and know that I'm producing a site that is the right technology for it.

I just finished building a Gatsby site that I felt that way on it. I kind of wanted to build in components because components is a damn fine way to build a website. I'm already comfortable in React anyway, so it was kind of fun to stay there and know that the final product was going to be -- server side rendered is one way to put it, but I kind of stopped saying it that way because I deploy it on a place that doesn't really need any server, side technology. You're still deploying. You're deploying static assets, so I guess I lean on, you know, it's a prebuilt site or a statically generated site.

Anyway, is that what you think too? Do you think there's some value to just, like, I don't know, "I just like working in React and Gatsby gives me a lot of stuff and makes me feel good about the site that I produce, so Gatsby"?

Jason: Yeah. Philosophically speaking, the goal of any framework, I think, should be to make the right thing the easy thing. If you assume that even the most motivated and well-meaning developers will eventually get kind of burned out on the technology or jaded or they'll move on to the next thing they're excited about and they'll start taking shortcuts with the older, less exciting technology.

If you think about React as something that is maybe super exciting for people at first, when it starts becoming the day-to-day thing that you work on in your job, it just becomes another thing that you have to overcome. If we set up the right defaults where, even if you take all the shortcuts, even if you don't change any of the settings, even if you don't do performance tuning, you're going to get something that loads quickly, that's easy to use, that's fairly maintainable, and that requires a lot less complexity to both get started and to deploy, then we're making it so that you can focus just on building the thing that you want to build and we'll take care of the performance tuning, the deployment pipeline, and all this other stuff and just kind of get that off your plate so that you don't have to be an expert or even know that it exists. You don't have to care at all and it's just going to go well.

That's kind of been the motivation for a lot of the things that we do and a lot of the things that we're working on. It kind of rolls up to this idea that we've called the progressive disclosure of complexity where, ultimately, you shouldn't even have to know how to code to deploy a site, but that shouldn't come at the expense of not being able to code when you decide that it's time to customize something, if that makes sense.

Chris: Wow. That seems -- I mean I wouldn't have expected you to say that because it seems like this is a very code-y framework. It's for coders.

Jason: We're working on themes right now. Our ultimate goal -- I would agree with you; right now, it is very code-y, but a lot of the codiness comes from having to use GraphQL and from the kind of complexity of generating custom pages and that sort of thing.

Really, a lot of times you're just doing something that is done the same way no matter where it comes from. You know, I need to get a blog up on the Internet. It doesn't matter if that data is coming out of WordPress or Markdown files or an enterprise CMS. It's ultimately going to end up in the same place. It needs to be on the screen and it needs to look good.

With theming, what we're trying to do is take that abstraction even a step further and get it to the point where you can say, "I want a blog," and, by installing that blog, it's like one line of config that says, "In my Gatsby config file, use this theme. The data source is here, and here is my API key." Then it drops in a fully functional blog. All you have to do is choose some colors which, theoretically, could be done through a UI wrapper around the config file and you're off to the races.

Then later, if you want to expand it, a developer can go in and build it; build those extensions and customizations using React, using GraphQL. They're still using modern tech that's easy to maintain and extend. It just doesn't necessarily require you to become an expert to get started.

Chris: Let's do the data source thing just for a minute because I think that's essentially the most exciting part about this to me is that you don't see this very often. You might see a CMS-like, something like Contentful, which is a popular cloud-based CMS. I hate to put words in their mouth because I've never really talked to anybody from Contentful or whatever, but it's a CMS in the cloud and they give you an API to the data in there. Essentially, they're saying, "I don't care what you do with the data from the CMS. We just want to be your CMS."

Jason: Yeah.

Chris: You can consume it in any dang way you want to. Build it any way you dang want to. Do anything you want with the content from it.

They don't really give you themes. As far as I know, there's no Contentful themes. It doesn't really make sense. It's just an API for some data.

Jason: Right.

Chris: That's really liberating, interesting, and cool. Gatsby is happy, I think, to connect to your Contentful database and have that be the data source.

Jason: Mm-hmm.

Chris: You don't often see it be the other way around. You don't see frameworks say, "I don't care what the data source is. Feed me anything you want and I'll make a thing," but Gatsby does. That's an interesting thing that, sure, your data could be in Contentful or it could be in a bunch of Markdown files, which is, I would think, probably a pretty common way to do it only because your predecessors and the world of static site generators -- people think in that way. At least a lot of nerdy devs that I knew do.

Jason: [Laughter]

Chris: Then it's all in your Git repo and it's just easy to reason about in that way.

Jason: For sure.

Chris: But Gatsby is so weird that it can be like, "I'll hit your WordPress REST API for data. I don't care. You can have a bunch of stuff on Redis. We'll hit that. You could have a big JSON file. We'll use that as your data source.

Jason: [Laughter]

Chris: It will expose all that data through a GraphQL API. I don't know how standardized it is or whatever, but at least when you're working in Gatsby, you know that GraphQL is the tool to access that data. It seems unusual to have a CMS or have a site generation framework like Gatsby not care what the data source is, is pretty unusual.

Jason: A big motivation for us is kind of this trend that we've seen toward things going headless and also this trend that we've seen towards specialization in CMS providers. With someone like Contentful or other CMS in that category, they're specifically talking about content modeling for pages. I'm going to define a page as a collection of blocks and those blocks have images or whatever. That's like I'm going to layout content for the Internet.

Then there are other providers like if you want to do tabular data, maybe you use Airtable. If you want to manage inventory, you're going to use something like Shopify to do your e-commerce.

Chris: Mm-hmm.

Jason: You wouldn't necessarily want to use Contentful to run an e-commerce store, and you wouldn't necessarily want to use Shopify to run a blog. But they're both really, really good at the thing that they're good at.

Rather than what I think you would see pretty commonly in the past, which is blog.mysite.com and shop.mysite.com, we've started seeing the ability with Gatsby to create what we're calling a content mesh. You choose the best possible solution for managing a specific type of data. Then all the other types of data, you also choose the best possible solution for managing that data.

It doesn't matter where it comes from. It just gets pulled into this central layer that we normalize reasonably well with GraphQL and then you're able to use that data in any combination that you want to build out your website. That way you can have yoursite.com/shop or /blog and it doesn't matter that the data is coming from completely different places because, ultimately, Gatsby doesn't care as long as the data is available.

Chris: You might even think, "Oh, God. Isn't that slow?" Well, not really when your site is rebuilt.

Jason: Yeah.

Chris: Built as a built-in.

Jason: Because we're pulling everything ahead of time, there's actually no data access at all on a standard Gatsby site. Out of the gate, what we're going to do is, when you run a build, we'll build on your computer or your CI server and the static assets that come out have any public data already embedded in them is like static JSON files, which means that, for the person loading it, this site is going to load extraordinarily fast because there is no API call to be made. There is no server to be hit to render a page. It's just a static asset on a CDN. That's what CDNs are world-class at is delivering static assets very quickly.

Chris: Yeah. You have this wide funnel of input from different data sources. You don't really care what they are. And you have this wide funnel output, too, because you don't really care what people do with it on the way out.

Jason: Mm-hmm.

Chris: It's just some static file, so go nuts. Put them wherever you want. Pretty cool.

Jason: Yeah.

Chris: React is a non-optional technology here too. It doesn't seem like Vue Gatsby is coming anytime soon, but feel free to correct me if I'm wrong. [Laughter]

GraphQL is the other kind of non-optional technology, but it's kind of on purpose, right? It's like this is the -- like right in this way on purpose is a database abstraction, in a way, or a data abstraction, almost like a whatever -- what do they call that in Rails, Dave?

Dave: Inventions?

Chris: When you say, "This is the data I want from the data source," but it doesn't matter what that data source is.

Dave: Oh, like an active record….

Chris: Yeah, it's like GraphQL is your active record.

Jason: That is true, but it's not a requirement. You are completely capable of building a full Gatsby site and never writing any GraphQL because, ultimately, our create page API just takes a path that you want to create and a component, and that component could be rendered with hard coded text.

Chris: It could be static. Sure.

Jason: It could render a loader and then run an async call to load that data dynamically the way you would do in a create-react-app setup. We have seen people do that.

Chris: Will it do that? Will that have to hydrate to get that content or will it do that at build time?

Jason: That would have to hydrate to load that content.

Chris: Okay.

Jason: We have seen people do that as kind of like a migration path to Gatsby.

Chris: Sure.

Jason: Even if you don't use the build time data rendering, you still get a lot of benefits in terms of the code splitting and the other optimizations that we do by using Gatsby, even without the data layer. What we've found is that, typically speaking, the GraphQL stuff becomes less optional the more complex your data gets because it's just really difficult in any application to manage a lot of relationships between different types of data, especially if that data comes from different places.

If you avoid GraphQL, you end up doing a lot of client side business logic, which I can say from my own experience at IBM and consulting for bigger apps; when you start moving that business logic into the client side, it starts to get duplicated across different interfaces. That's when you really get into a lot of trouble because, now to change anything, you've got to change it in multiple places and it's not always managed by the same team.

Chris: Well, it's pretty cool. I definitely have talked to people where Gatsby is the only time they've ever used GraphQL because it's just kind of like their intro to it, which makes a lot of sense. I think you brought a lot of clout to the GraphQL world, in a way.

It happens to me in unexpected ways. Even if you just do the folders full of Markdown thing because you're going to statically generate content from that, I don't know if you need a plugin for it or what. You probably do because it seems like everything is a plugin in Gatsby.

Jason: Mm-hmm.

Chris: That becomes a GraphQL endpoint, too. You can query your folders of Markdown, strangely enough, right?

Jason: Yeah.

Chris: There's front matter in that Markdown and you can query that front matter, which is like, wow, that's cool. [Laughter]

Jason: Yeah, that was a really novel use of GraphQL that I'd never seen before. Yeah, I guess, in version two, or maybe it was version one, Kyle made the decision to start making the file system something queryable, which is a wild idea but it's really, really powerful because, in addition to the Markdown stuff, it also lets you get at images or YAML files or JSON files or whatever you've got. Then we can apply transformers to those to give you optimized images or convert your JSON to GraphQL data that you can query against and create relationships between those things where, if you've got a JSON file and it references an image with a relative path, we'll convert that automatically into a file node that, if you've got the right plugins installed, we'll auto-optimize for you and do all the various image optimizations so that you get lazy loaded images out of your JSON data without you having to do any image manipulation at all.

Chris: Yeah, that's cool. It seems like some of these things you get some best practices out of for pretty little work, right?

Jason: Yeah, that's the hope.

Chris: Yeah. Even stuff like the navigation; you're kind of forced to use the link element, like the special React-y, fancy one from Gatsby to make anchor links internally because then they work both as anchor links that point to the correct place semantically and they kind of upgrade themselves to SPA-like links once it's hydrated and stuff. You're like, "Cool. That's good," but along for the ride came the fact that the current page that you're on get the ARIA current attribute on it automatically. You didn't have to think about that.

Jason: Mm-hmm.

Chris: You just kind of got that for free; a little best practice that came along for the ride.

Jason: Yeah, and we just decided to really double down on our accessibility. We hired Marcy Sutton as our head of learning, and so she's doing a ton of work in that space to help us catch the parts that we missed, to help us audit various things on an ongoing basis, and make sure that that's a core focus of what we're doing as we keep moving the platform forward.

Yeah, another thing that that link element does, which is really exciting, is it sets up pre-fetching. We're using the link rel pre-fetch for subsequent routes. If you are on the homepage and you've got links set up for the about and contact page, if those are in the viewport, we'll, in the background if you're on a fast enough connection, we do the slow connection detection.

Chris: Really?

Jason: Yeah.

Chris: In the viewport?

Jason: Yeah.

Chris: It detects that it's visible and it does some bandwidth testing thing?

Jason: Yep. Yeah, so if it's visible and….

Chris: And it pre-fetches. Wow!

Jason: Yeah, and so that makes it feel instantaneous to move between pages on the app because all the data is already in your cache by the time you click on it.

Chris: Yeah, that's pretty cool. Sometimes, the old-time-y developer in me rolls my eyes when frameworks say how fast they are because you're like, "You have very little control over the ultimate speed of this website. I can easily screw up the speed…."

Jason: [Laughter]

Chris: [Laughter] But when it does clever stuff like that, I feel like you kind of deserve it. Okay, the speed comes from not only the fact that it's just this static rendering thing, which a ton of the speed just comes from that, but clever stuff like that is speedy.

Dave, what do you think about all this?

Dave: Yeah, so I guess -- what comes with Gatsby? I'm looking at the doc and it's like, yeah, it's fast. Yeah, it has GraphQL. Yeah, it's like React. Do I get any prefab components or is it all through plugins? Is it all through extensions and stuff we install? What comes when I NPM install Gatsby?

Jason: Out of the box, we try to have relatively few opinions because we're so flexible on where data can come from. What we'll do out of the box is we set up all of the kind of performance optimization and build pipeline stuff, but the actual React components that will ship are Reach Router under the hood for, on one level, just making--

Dave: The accessible navigations?

Jason: Yeah, that's what powers the link component that we ship. Then you also get a bunch of access to the location object, history, and that sort of stuff. Then we also have -- it's a separate package, but it's more or less baked into the core of Gatsby is Gatsby Image, which is a way to lazy load images.

We don't ship a lot, though. Our goal isn't necessarily to tell you how to build websites. Our goal is to create a platform that eliminates a bunch of boilerplate so that you can focus on building a website instead of figuring out how to build a website.

Dave: Yeah, that's interesting. It's not like a -- I'm trying to think. You do WordPress or something and you get a post table. Then you have to customize from there. You're saying it just comes down with the image component and the link component. Then it's more or less just the build process that sets come conventions to build a smart and fast site.

Jason: Yeah. By default, anything that's in the source pages directory is going to be -- any component that you put there will get exported to its own route. If you create a source pages index.js, that will become your homepage by default. If you create an about.js, that'll become your about page.

Chris: Mm-hmm. That's how Next works. That's how 11ty works. It's pretty cool, right? I just want to put some crap in a source folder and you figure it out. It's kind of nice.

Jason: Yeah, and that's also the benefit of, if you just need to get something up quick, you don't have to set up data sources. You can hard code your content into your index.js and everything will work as expected. Later, when you want to do something more advanced, you can always refactor that to pull that content from a Markdown file, your CMS, or whatever you want.

Out of the gate, you don't necessarily need to set anything up. You can just create a Gatsby or you can install Gatsby, React, and ReactDOM and then create source pages index and write some content in there. That's it. That's a whole Gatsby site.

You don't necessarily need anything at all to make that work. We'll take care of all that for you.

[Banjo music]

Chris: Hey, ShopTalk Show folks! There's a conference coming up in Toronto September 13th and 14th, so there's plenty of time to get this done. It's called Web Unleashed, put on by the FITC people. I've been before and loved it. That's why I'm going back this year, so I'll be at it speaking. I can't wait. It's such a really well put on conference in Toronto in Canada. Plenty of time to figure this out, people. Get on it.

There's a bunch of actually good speakers being there, too. Simona Cotin will be there, who I met at the last JamStack conference. They call her the Queen of Serverless, which is a topic near and dear to my heart. That's going to be great.

I believe you're listening to this spot on the show with Jason Lengstorf, who is from Gatsby who will be there too. Jason is a great guy.

Let's see. Who else is on the list here? Shirley Wu, I've never met Shirley but she does just the greatest data visualizations ever. She's the favorite person on earth that does those things and I really hope I get to meet her, so I'm going to go to Web Unleashed and hope that happens.

It should be great. I hope to see you all there. It's like other conferences in that there are workshops too. If you really want to level up some particular skills, check them out. There's actually kind of a bunch of them.

There is a deep dive into JavaScript one and a Gatsby one and a Vue one and a variable fonts one. Ooh, Jason Pamental is going to be doing that one. He's great and really will convince you, after meeting Jason, that variable fonts are very important for the Web. I'm drinking that Kool-Aid.

Anyway, yeah, we'll see you there, Web Unleashed Toronto, September 13th and 14th.

[Banjo music]

Chris: I was wondering, when React changes, how does that screw stuff up for you or what? I don't even know how caught up with current React you are or if it's totally decoupled or whatever.

At one point I was like, "Oh, this is a perfect thing to write a hook for. I'm going to write a hook," and it just worked. [Laughter] Apparently, you're not very far behind on React versions, if at all.

Jason: Yeah, we don't have -- I don't think we have too many dependencies on React internals, so it's fairly painless for us to upgrade the versions. Really, what we've found is the biggest problem is that people build things on top of Gatsby and so, if we bump a major version of a dependency, we also need to bump the major version of Gatsby.

When we bumped Gatsby V2, we made a jump from Webpack 1 to Webpack 4 because, prior to that, we weren't willing to do a breaking change of Gatsby to update the underlying Webpack config, right?

Chris: Yeah, I see. That's going to be an ongoing complication for you, I'm sure.

Jason: Exactly, and so we kind of thing there is a decent chance that Gatsby version three might actually just be major upgrades for Babble, Webpack, and React, assuming that they ship those because React has been pretty good at not doing major breaking changes.

Chris: Mm-hmm.

Jason: We've kind of realized that we have to coordinate that way, so a lot of the major break, like anything that we want to do that's going to break, we're going to time it to go with our major dependency upgrades as well so that we have as few breaking changes as possible. We want to minimize churn and, ultimately, we would like for Gatsby to be more on the React model where stuff that you wrote -- I think Dan Abramov, on Twitter today, was talking about how there are components written in React at Facebook that are from 2011 that still just work with very minimal changes.

Chris: Wow.

Jason: I like that philosophy.

Chris: I think I saw that thread. He said that what tends to break more often in React land is stuff that people write on React, like libraries and stuff.

Jason: Mm-hmm.

Chris: The one everybody complains about is React Router, of course. You'll never have to deal with that one because you don't even use router in Gatsby, right? Gatsby has its own kind of routing switch. You don't ever need router in Gatsby, right?

Jason: We use Reach Router under the hood, and so there is going to be some churn there because Ryan Florence and Michael Jackson decided to merge Reach Router and React Router back together in React Router 5, I think.

Chris: Yeah, I heard that, but it's going to be more like Reach Router than the other one, so you should be kind of okay.

Jason: Right. Yeah, that's our hope. Our hope is that the APIs that get kept are going to match what we're using in Gatsby so that we don't have to change anything. We'll see.

Chris: That's kind of like your problem, not our problem, right? We don't see any of that stuff as authors.

Jason: Yeah, and worst case scenario is that Reach Router will continue to work for the foreseeable future and we will wait until we do a major launch to upgrade to React Router V5 so that it's all kind of contained and we can hopefully code mod any of the major stuff so that it's pretty painless to move forward - is the hope.

Chris: Are you going to buy Gatsby.com in a major release pretty soon?

[Laughter]

Jason: I have no idea. I think we've reached out to the person who owns it and there's no response. I love domain squatting. It's like my favorite thing in the world.

Chris: Yeah, it's not a particularly useful site, unfortunately.

[Laughter]

Chris: It looks like an architect firm that doesn't exist anymore.

Jason: Yeah.

Chris: I'm sure they'll be pleasantly surprised when they finally do get that email.

Jason: [Laughter]

Chris: I'm sure that they'd let it go for a chunk of that VC action.

Jason: Yeah, no kidding.

Chris: Gosh. What else? I think Dave had some questions about that, right? I think it was a weird day when the Internet found out that a static site generator just got millions of dollars.

Jason: [Laughter]

Chris: You're like, "What?!" I feel like I get it more and more, but… hmm, that's weird. It seems like a first, in a way. Like, this is just some open source thing. I'd love to have a recording of the meetings that happened there. What did all these investors see in this thing? Do you feel like that changes the market for other static site generators? Do they need millions of dollars too now? Dave, what were your thoughts?

Dave: Yeah. Does 11ty now need to go out and get VC? Just Jekyll? I guess they're owned by GitHub, so they're Microsoft bucks now. [Laughter] Do you think that just the very notion of a -- you're calling it a framework, but I guess maybe more at the time it was just a static site generator. Does it just change the landscape of how we build websites game now that there's VC involved?

Jason: I don't think so. I think Gatsby is kind of a unique position because of its data source model. What we stand to do, if we have, basically, the horsepower to do it, is to create a layer that allows all of these companies that are investing in APIs to have a readymade solution for how to use those APIs.

Some of the other static site generators are getting into this game. I think I saw, like, Hugo is figuring out how to do data source plugins and I think Gridsome, which is a Vue port of Gatsby, is getting pretty good at this.

Chris: Is it really? We were just looking at that before the show because, in Vue land, there is Nuxt and VuePress and Gridsome, at least.

Jason: Full disclosure; I know very, very little about Vue. All I know is that the Gridsome team keeps shipping features. I haven't tested any of those features.

Chris: It's spiritually connected in that there's that GraphQL assumption, like you all have.

Jason: Mm-hmm.

Chris: But I don't know. I don't know anything about it either. I just saw it for the first time the other day and I was like, oh, that's interesting.

Jason: Yeah.

Chris: I also know very little about Vue. Dave does, though.

Jason: Yeah, it's actually something that I want to learn a lot more about. I've never seen a community as engaged with their framework as the Vue community. I love the Vue vixens and this whole concept. People get really stoked about it. I know people do the same thing for React, but I love the excitement around Vue, so I would like to learn a lot more about it really for that reason. I love that community.

To keep answering the original question about VC, I think that Gatsby has a very specific business plan that is built around -- a static site generator, in general, is extremely useful to developers. Chris, you said it earlier that, for a developer, static site generators make sense because the whole thing is managed in GitHub. My content is in a Markdown file. My components are written in whatever my preferred language is. There's a build process that matches those things together into pages and we're all happy.

As soon as you bring in someone who is not a developer who doesn't want to work on GitHub, using static site generators suddenly have this precipitous drop in value because, for someone who wants to work on a CMS, they can't do any of the things they're used to, and so they're going to hate working on a static site generator. I ran into this problem. I was using Jekyll to run docs for an internal IBM project and everybody loved it until the marketing team was like, "Oh, can we use these docs?" I was like, "Sure," and then everybody hated it because they didn't know Markdown; they didn't know GitHub.

Through no fault of their own, they were making all these mistakes that were creating extra work for the developers, and so the developers were mad. Everybody was frustrated. Ultimately, that results in us going back to a CMS solution so that there's a way for people who don't want to be developers to manage content.

What Gatsby sees as its kind of business opportunity here is, how can we be the bridge between developers having a really, really good developer experience and people who aren't developers still having a really, really good content management experience? That's again coming back to this idea of, you should be able to choose the best tool for the job and not have to worry about how everything fits together.

We're doing things like our first product; we've been calling it Preview, and it's part of what we're ultimately rolling up to Gatsby Cloud. Preview is a way for someone who is not a developer to open up Contentful or Sanity or one of these other headless CMSs, make changes to a draft, and then hit a Gatsby Preview button that gives them a private URL of the draft of their post.

Chris: Yeah, I'm sure that's research-based too. I'll tell you; anybody who runs a CMS like WordPress or Craft or anything, that prospect is a lot easier to do because you just save that content in a little, temporary database location, render the template with that new data.

Jason: Mm-hmm.

Chris: That's a big deal, feature for a CMS like Craft or WordPress. The fact that you can't do that in a static site generator is an issue. It's kind of no surprise that you're tackling that, which is great. I have a feeling we have yet to see most of the Gatsby business plan. [Laughter]

Jason: Right. Yeah, and so a lot of what we're working on is the Preview thing is a big one. That helps bridge the gap between developers and content folks in a way that lets both of them do the thing they like in a way that's pleasant to use. Where we're trying to expand beyond that is, we want to get into, like, how can we really optimize the Gatsby build because building a static site takes time, especially with Gatsby, because we have to go out and hit all of those third party APIs. We have to pull that data down. We're optimizing images. All of those things add up and end up creating pretty long first build times.

Chris: What's funny that you're not going to get into the data game so much other than you can deal with the Markdown situation or whatever local files, but it seems like you probably want to stay out of the CMS game a little bit because it's kind of like if some company makes office furniture and you book a bunch of contracts with Walmart and some local distributors of office furniture. Then one day you're like, "Oh, we sell that furniture too."

Jason: Yeah.

Chris: All those people that you sell furniture to are not super happy about that.

Jason: Yeah. That was actually a big reason why I came to Gatsby is because I love that the business model is not a competitive business model. We're not looking at a winner take all market. We're looking at, when we make improvements, it makes the people in our area better. When they make improvements, it makes our offerings stronger. It's very much like we want to be part of the tide that's lifting all these ships.

If we got into the CMS market, you're absolutely right; we'd suddenly become competitors. I don't think that we're -- I mean I'll never say never because I don't make all the business decisions, but my guess is that that would be a foolish thing for us to pursue right now.

Chris: You think of that Preview thing as a CMS-like feature, but it's not in this case.

Jason: Yeah. The way that it works functionally is with the CMSs that we're tightly integrated with, like Contentful and Sanity. We just shipped this for Sanity Studio. You log into Sanity Studio. You install the Gatsby Preview plugin. Then you get a button on your Sanity dashboard that says, "Show me a draft preview," and it opens up the Gatsby Preview link. What we're doing is effectively allowing someone to see their content in context of the site they're building at a shareable private URL.

Chris: Are you cloud rendering it somehow?

Jason: Exactly. Yeah.

Chris: Really? Fancy.

Jason: [Laughter] A lot of our business plan is, we're going to provide the managed infrastructure to do stuff that people have been doing on their own that's really hard and expensive. We're effectively running a cloud instance of Gatsby Develop that can listen for webhooks, rebuild this content, make sure that it's up, do password protection, and all these things that you can absolutely do in-house if you want to, but they're going to be expensive and probably going to have to have somebody full-time managing it, so it's not really worth it when you could just pay us to manage that for you.

[Banjo music]

Chris: Hey! This episode of ShopTalk Show is brought to you in part by WooCommerce. That's W-O-O, woo-woo, WooCommerce.com. [Laughter] It's e-commerce for WordPress. If you run your own WordPress site like I do, like ShopTalk is on, like CSS-Tricks is on, like the CodePen blog is on, like most sites I've built in my career are on.

I'm kind of a fan of WordPress. It's been solving problems for me forever. I think there's an awful lot of sites that WordPress is the right answer for.

If you need to add WooCommerce to any of those or add e-commerce, generally, the concept of selling things to any of them, I think WooCommerce is the obvious choice. Yes, absolutely. I've used it a number of times for that and had a great experience doing it. In fact, the Code-Pen store right now is running WooCommerce to sell our shirts, hats, and all that stuff. It integrates with all kinds of stuff nicely.

They don't really tell you. I don't think it's really part of their marketing to say, "This is the easiest e-commerce platform out there." If somebody who has never touched a computer in their life came up to you and asked you, "I want to start a website and start selling things online," sure, you could help them get started with WooCommerce. I think that'd be nice.

If they were doing it all by themselves, there's probably other platforms. I hate to say that as part of a sponsored message, but that are technically easier to get started with, but WooCommerce is part of WordPress anyway, which is the right answer for so many sites, and you can just do anything with it. It's super, super customizable with how you want to sell stuff and how your cart works, how taxes are applied, how inventory is managed, and what other services it integrates with.

Then once it's on WordPress anyway, there is so much more you can do with your site. I just think it's a really great answer to e-commerce. I think the world generally agrees with me because it's mega-mega popular and it's also free to get started with anyway. You can just download it, install it on your WordPress site, and get going. Then it's like certain plugins, if you need them, that are the things that cost money with WooCommerce. There are plenty of things you can do without spending anything at all. Check out WooCommerce.com.

[Banjo music]

Chris: Well, that's cool. What's your relationship with Netlify? It seems like an awful lot of Gatsby sites are probably -- it seems like there's a lot of synchronicity there, so it'll be interesting to see. It's a really happy world now.

Jason: Mm-hmm.

Chris: Netlify is this amazing product that developers love and certainly shipping a Gatsby site to Netlify is like a match made in heaven kind of thing.

Jason: Mm-hmm.

Chris: Netlify might be incentivized to offer some kind of preview situation too. I wonder how long before there's a little toe stepping. [Laughter] I mostly want to paint a rosy picture here, but--

Dave: Yeah. Yeah, stir up the drama.

Chris: Stir up, yeah.

Jason: No, I mean it's a question worth asking because I think that you're right that Netlify and Gatsby are probably moving into the same direction. Where I think we're going to see the divergence and why I still see Netlify and Gatsby being close partners and pretty friendly is that Netlify is working on kind of a broader solution for a broader problem, and so they're not necessarily interested in building highly Gatsby specific solutions. For the vast majority of people, highly specific Gatsby solutions probably won't be necessary.

Then in the edge cases, for the really big companies, the Gatsby specific solutions start to really matter. When you need a parallelized incremental Gatsby build because you've got hundreds of thousands and pages, that's not something that I don't think Netlify would be interested in doing. I don't know what they're talking about internally, but from the Gatsby standpoint, that's what we're starting to look at is, well, what if somebody does want to run Wikipedia on Gatsby? Can we provide the infrastructure that makes that possible? What does that look like as a business model?

Chris: Right. That seems like the most likely thing. There are wildly beloved, powerful, useful tools like Zeit or whatever and Netlify that have these command line driven things or whatever you're like, "Well, how convenient is that to spin up a NextSite and then distribute it on Zeit in two seconds?"

Jason: Mm-hmm.

Chris: Gatsby is already so command line driven, too. Why not type Gatsby deploy and have it go up to some Gatsby cloud and have a Gatsby Preview URL and have a Gatsby--? Then you buy a domain name through Gatsby too and map it. Let's just leave it all in Gatsby land. That seems like a pretty natural direction that certainly nobody would blame you for. That's nice.

Jason: Yeah, and I think, on the long-scale, that's probably a likely outcome. But something that's really interesting about this is, Gatsby has built its whole value on leveraging existing tools.

Chris: Right.

Jason: The fact that we get all of our data from third party sources, there's a decent chance that we'll have some kind of a plugin model where you'll also be able to just say, Gatsby deploy, and choose Netlify as a target.

Chris: Right. Right. You almost already do. Not quite. Maybe that's a little bit more manual at this point. Yeah.

Anyway, you've got this big, wide funnel on the inside. The incoming funnel is more interesting, I think, to you all. That's more unique. I think any framework can say, "Oh, you can publish us anywhere."

Jason: Mmm.

Chris: It's whatever. Anybody can do that. The incoming thing is more interesting, so if you made some money on the outgoing -- anyway. We're talking business plans. I have no horse in this race.

Jason: [Laughter]

Chris: I just think it's fascinating.

Dave: I'm good at this. Let me do it, armchair CEO.

Chris: Yeah, let's armchair CEO this thing.

Dave: Enterprise companies are notoriously dumb, so you just come up with a plan that's very expensive and they'll just buy it….

Jason: [Laughter]

Chris: Yeah, just put "Enterprise" in front of it. That's how you'll make all your money.

Dave: Yeah.

Jason: Yeah.

Dave: That's how you do it.

Jason: We'll launch the platinum executive enterprise plan, which, actually, all it is, you're paying for one appearance from me. [Laughter]

Chris: Oh! Does that work? Email me if that works.

Dave: No, you get Jason comes once a quarter and will just hang out.

[Laughter]

Jason: I show up with cupcakes. I make you all feel really smart.

Chris: Yeah.

Dave: Then you'd kind of talk them into upselling them to the next three products you've made or are under development.

[Laughter]

Chris: That's the trick. You just tell them whatever they're already doing is a good idea. Yeah.

Dave: I was -- anyway, I shouldn't….

Jason: You're prodding it by….

Dave: …actually how these stories started.

[Laughter]

Dave: Ah! NDAs!

Jason: You're prodding at my emotional scarring right now. [Laughter]

[Laughter]

Dave: Flashbacks. But anyway, so I think this has been very helpful for me. I just always mentally put Gatsby in the static site bucket, but now I'm really kind of understanding its sort of like a -- I don't know. It's the tie that binds the content people and the developers together in maybe a more sane way or more manageable way than it kind of historically has done.

I think Gatsby is kind of agnosticism about what it's connecting to. It seems like also its strong point.

Chris: Mm-hmm. Yeah. You want to be the tie that binds, and you're doing that, so that's cool.

Jason: Yeah.

Dave: I feel like Hugo, not to trash -- if you find it valuable, it's awesome. But it's like, "Oh, I just don't want JAM on those templates. I want to write it how I like to write it," or even Jekyll. I definitely see the thing where it's like, "Okay, well, marketing to get creative inside the Markdown files and now they're kind of very hard to manage HTML files."

Chris: That's the thing that we didn't bring up here, though. There is this rise of the CMS that sits on top of flat files, in a way.

Jason: Mm-hmm.

Chris: Have you all seen Stackbit? I'm sure Gatsby is well aware of it because it's pretty cool. It's one of the supported things there. It's just a little meta, help me spin up a site where pick and choose from some technologies. In Stackbit, you pick a theme and, apparently, these themes work with any -- they must have done a lot of work with the themes because they'll work for a Gatsby site or an 11ty site or whatever.

You pick a theme, but then you pick which framework do I want? Which static site generator do I want to use? Then you pick a CMS and you're like, "Well, that's weird. Didn't I just pick a CMS?" It's like, "No, you didn't."

I feel like we started talking about that a little bit. You picked a static site generator. Now you pick the CMS on top of it, but the CMSs that you pick are very few. They're this kind of new category of CMS that kind of like looks at your flat files and gives you a GUI on top of them based on that structure so they're like Forestry and Netlify CMS and stuff, which just blew my mind when I first understood it. I'm like, "What?!"

It's like you open up a Markdown file, edit it, which is the kind of thing that you could hand off to marketing. Maybe this would have helped you at IBM or whatever.

Jason: Mm-hmm. Oh, yeah.

Chris: You get this GUI with a bold button and a link button and all that comfortable CMS looking stuff. Then you hit "save" and it's through the magic of modern Internet. It basically makes it a Git commit.

Jason: Yeah.

Chris: You're like, "Oh, wow. That's cool." That's a new breed of CMS, in my mind.

Jason: Yeah, it's a fascinating approach too. What we found was that -- this is what I love about it is it puts it on a spectrum because I feel like, before, it was very much you just had the tradeoffs. Whichever team had more influence, their tradeoffs won. If it was a marketing driven company, marketing would say, "Well, we want to use," let's say, "Adobe Experience Manager and, developers, you just get to deal with whatever the fallout is of that."

Chris: [Scoffs]

Jason: If it's an engineering driven company, then the engineers say, "Well, we want to manage Markdown files so, marketing, you get to learn how to use Markdown in GitHub." It's like whichever team had more influence gets to win.

What I see as a big possibility with these kind of bridge CMS, like Netlify CMS and Forestry or the even more separated, but still combined approach, of using, let's say, Contentful and Gatsby with a preview layer in the middle. It means that you're no longer making those tradeoffs. The marketing team gets everything they wanted. The developing team gets everything they wanted. The process of building things stays pleasant on both sides. It's not like one team won. Both teams got exactly what they wanted and the result ends up being better because of it.

Chris: We're piecing together the pieces of technology that just seem to work the best. That's very much in the spirit of all this JamStack stuff. When you start going down that route, you're like, "I'm going to pick whichever cloud hosting provider seems to be the best for this. I'm going to pick whatever service processes forms that I like the best. I'm going to pick whatever media hosting solution I like the best," and stuff. These modern websites are kind of pieced together from companies that are highly incentivized to do the best they can at what that little piece is, which is, in a way, cool because I think the incentives for those companies are right.

Jason: Yeah.

Chris: We're going to do the best we can and is worrisome to some people that are like, "Oh, my God! This website is strung together from some crazy ass spaghetti stuff.

[Laughter]

Chris: You know.

Jason: Well, that's one of the things that I think is powerful about Gatsby is that, because all the data gets brought into a central point, it's less spaghetti-ish. I've seen this on other JamStack sites where you pull your blog post from here and your comments from another engine and your newsletter over here. Those are all these kind of like stacked together API calls that all run on the client side.

You know like I was talking about putting business logic on the client side. That turns into a really hard to manage mess, and it means that you've got these domain experts where one team knows how Adobe Experience Manager works, but one team only knows how Drupal works. Those teams can't really transfer between each other.

With Gatsby, because the development process is more normalized, the data, no matter if you're pulling in data from Magento's headless version and then you're also pulling in decoupled Drupal, those teams might not necessarily have a lot of overlap in their skill with the CMS but, in Gatsby, it'll feel the same no matter where that data is coming from. That's a really kind of powerful model.

It gets even more powerful when you start to think about the way this enables workflows in the same company. If your site has a blog, an e-commerce store, documentation, and whatever else, then you can theoretically have a marketing team that's writing the blog, an ops team that's managing the e-commerce store, and a developer team that's writing the docs. They might want to manage those through, let's say, something like WordPress for the blog and Shopify for the e-com and Markdown files for the docs. All three teams get the workflow that they want and the people working on the website don't have to care because they access the data in the same way.

Chris: I like these meta stories. It's pretty cool that it solves things that you wouldn't maybe expect them to solve but is kind of a bigger deal than the technology itself, in a way. Wasn't that a big part of the responsive design story was that this is cool technology and us nerds like it because we can make some grids go from four column to two column or whatever. The real story behind responsive design was much bigger than that. It changed how organizations work and it eliminated duplicate effort, multiple teams, and overspending on stupid projects. That was the bigger story.

Jason: Mm-hmm.

Dave: I have a question about tying in. Let's say I have a Rails site, Dave's Rail site. I have an API there. Then I am writing my Gatsby site and I want to get some data from Dave's Rail site.

GraphQL is my only kind of method of doing that. Do I have to set up GraphQL on my Rail site or is it like I have to write Gatsby-connect? Do I have to write a plugin, like, connect to Dave's Rail site, or something? How does that kind of flow work?

Chris: Interesting.

Jason: The way that Gatsby works is, under the hood, we've just got a series of API hooks that you can use. For the exact instance that you're talking about, you would use an API called Source Nodes. That one has the ability. You would basically just say, "I'm going to do a request," using whatever request library you want, so Rest, File System, GraphQL, whatever. You're going to get back the response and that'll be an object or an array of responses.

Then you would loop through those responses and stick them into Gatsby's data layer using create node, which is a helper action that we provide. We have a couple required fields, like you've got to set up a content ID and a content digest and a type for the data, but those fields, we have helper methods for all of that, so you just kind of run -- create node ID, run create content digest and, after that, that data is now available. If your type was Dave's API, you'd be able to query Dave's API with a sort and a filter and all that or you can run all Dave's API and get all the responses that were returned from the API.

Dave: Hmm, okay. Cool. Then that's now in my Gatsby site or at compile time?

Jason: At compile time, so it'll make the query. When you run the Gatsby build command, we'll send off whatever API query you sent and pull down that data. Then your API could also, if you wanted, implement a Web hook that says, "Whenever something changes, notify this URL," and then you can send that through Gatsby Preview or Netlify or whatever. That'll rebuild your Gatsby site with the new data.

Chris: Gatsby Preview already exists?

Jason: Yes. It's in beta right now. It's not quite open yet.

Chris: Cool. Well, wow. We covered a lot of ground there, eh?

Jason: [Laughter]

Dave: Yeah, thank you so much, Jason, for coming on. I know we've been like, "We should talk more about Gatsby."

Chris: There's some fun history. A long time ago, Jason and I collaborated on a series of articles for CSS-Tricks, which taught you how to build a to-do application using pretty much just raw ass PHP and jQuery. To this day, I get emails that are like, "Where is the source code for that?"

Jason: Oh, yeah.

Chris: I always reply with this, like, "The Web has evolved four times since then to the point where I can't even give it to you in a good conscience," and not that PHP and jQuery are bad or anything, but it's like I just feel like if you're learning from scratch right now, that's not the tutorial to learn from. I feel like you should maybe reach for some new--

Jason: Our history goes back even a little bit farther than that because the very first article that I ever wrote that wasn't for my own blog was on CSS-Tricks. It was on building a PHP CMS from scratch. It went really wild. It went wild, back when Dig was relevant, and it hit the front page of Dig. That article actually led to the rest of my career. It got me my book deal. It got me some job offers.

Chris: Wow!

Jason: All sorts of stuff that happened, so I'm actually pretty indebted to you and CSS-Tricks for letting me write that article.

Chris: That's great. I like hearing stuff like that. I mean I had no idea, really. Maybe it was more clear back then as I was excited about the traffic Dig was sending me or whatever.

[Laughter]

Chris: That's nice, and I think of that. That's why I still have as many guest authors as I do now, let them kind of write whatever they want because I feel like -- you know, not that I don't try to clean it up and present it as good as I can, but it's helpful to some people to have a good byline on their resume.

Jason: Mm-hmm.

Chris: Anyway, it led to good things for you.

Dave: Awesome.

Chris: Anybody, just feel free. Do you want to launch a career and write a book? First, you have to write for CSS-Tricks. Step one.

Jason: That's right.

[Laughter]

Dave: Chris, you know I want to write a book.

Chris: Dave, I don't even have -- there's not even a Dave byline on CSS-Tricks yet.

Dave: I know! What's going on, dude?

Chris: I know.

Dave: All right. Hey, well, thank you, Jason, for coming on the show. For people who aren't following you and giving you money, how can they do that?

Jason: The easiest way to find me is on Twitter. I'm @jlengstorf, which is impossible to spell so, I guess, look at the show notes. [Laughter]

Dave: That'll work. That'll work.

Jason: I've also got a website, lengstorf.com, and you can always hit us up on the Gatsby repo. We really, really love first-time contributors so, if you're interested in getting into open source, please, please, please reach out to us. We've got so many different ways to do it and we work really hard to make that comfortable for you if you've never done it before. I hope I see you there.

Dave: You have a Twitch stream we saw you are doing.

Jason: I do. Yeah, Twitch.tv/jlengstorf. Every Thursday at 9:00 a.m., I pair up with somebody from the community and they teach me something. I show up completely unprepared. I don't look at the technology beforehand. I usually sign up for the account on the spot. Then they show me how it works.

Chris: That's so awesome. I'm so jealous. I've wanted to do that exact thing. You've just got to do it, right?

Jason: Yeah, you've just got to do it. It's so much fun because it's just 90 minutes of live coding, and I try something I've never tried before. It usually goes pretty well. Sometimes it goes spectacularly poorly and it's always a lot of fun.

You get to do it with a live audience where people are chatting at you and telling you all the things you're doing wrong, so that's also super fun. [Laughter] I don't mean that sarcastically. It's actually great to have people watching you code and say, "Oh, you made this mistake." I'm like, "Oh, thank you for not making me debug that."

Dave: Awesome. Well, cool. It sounds fun. I'll subscribe and smash that Twitch….

Jason: Smash that button.

Dave: I can do that. [Laughter] Anyway, thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.

If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people….

[Laughter]

Chris: That's the right URL, man. You nailed it.

Dave: Did I?

Chris: Nailed it.

Dave: Oh, my gosh. Three hundred and sixty-some shows in and I panicked about the URL. I'm sweating right now. What happened?

Chris: People that have already moved onto the next podcast in their queue, they're already gone. Believe me.

Dave: They don't even know how much panic and sweat I just endured forgetting the URL. Oh, my gosh. Anyway, Chris, do you got anything else?

Chris: Maybe we'll get a short URL. Ah, ShopTalkShow.com.