Getting Into Gatsby

About Jason 

Meet Gatsby, an open source React-based framework for building super fast websites and apps. In this episode, we talk with Jason Lengstorf to discuss the GatsbyJS project and what it solves.

Project Pick:

https://gatsbyjs.org

Interview

• What's your role at Gatsby, when did you start?
• How did you get involved in the project? 
• What did you do before Gatsby?
• What is Gatsby?
• How do you feel about the response from the community about Gatsby?
• Did you think it would take off as it has?
• Why should an org choose it over a traditional CMS?
• What separates Gatsby from other static site generators?
• What features is the team currently working on?
• Closing comments

Transcript

Mark Casias:  Welcome to Mediacurrent's Open Waters podcast, navigating the intersection between open source technology and marketing. I'm Mark Casias and with me as always is Bob Kepford.

Bob Kepford: Hello, everybody.

Mark: And Mario Hernandez.

Mario Hernandez: Hi, everyone.

Mark: And this episode, we're going to be talking with Jason Lengstorf from Gatsby to talk about the GatsbyJS project and what stuff it solves. How's it going there, Jason?

Jason Lengstorf: Hey, how are you doing?

Mark: All right, but before that, let's go ahead and let's guess what the Pro Project Pick's gonna be.

Bob: Let me see. Maybe GatsbyJS.

Mark: That's a good one. That's a good one. We here at Mediacurrent have a lot of, a lot of work with Gatsby in the last couple of months. Bob just tied off a project. I just tied off a project. Mario, have you tried anything off lately?

Mario: Not with Gatsby except for my personal blog.

Mark: There we go. We're all loving this thing and we're happy to have Jason to talk about it.

Mario: Jason, we want to welcome you. And before we get into the details and the technicality of what Gatsby is and all that good stuff let's, let's talk about you. Tell us about yourself, you know, what is your role at Gatsby and and when did you start with the Gatsby team?

Jason: Sure. So I I started up with Gatsby in the beginning of last year. So around February or March was when I had my first day. And I came on actually without really knowing what my job was going to be. So I I had been talking to Kyle Matthews, the founder, and I wasn't really happy with my, my existing role. And he mentioned that they had the ability to hire. And so when I came on, it was like, well, you're going to be doing development, we think. And then when we showed up, you know, my, my experience has been kind of all over the map. And I've ended up working in a lot of different roles, everything from, you know, development to design, to sales, to marketing, to you know, management, admin, all that stuff. And because of that, I have an interest in just diving into different chaotic pieces of any, any system that's being built.

And as we were kind of trying to figure out how Gatsby was going to function as a company, cause you know, I was the fifth person on the team, if you don't count the founders, I think I was employee number three. And so we were just like, all right, what does this look like? What are we going to do? And I started to drift toward the kind of community building, the developer relations, somewhat working on Docz. We had Shannon Soper who has owned our Docz for a long time until just recentlym Marcy Sutton took over as our Head of Learning. But you know, it's, it's effectively, I've just kind of taken on the role of what I've been joking is human duct tape, where everywhere that we see a gap in the company, oftentimes I'm able to at least temporarily fill that gap while we work out some processes and figure out how we're going to solve that in a more sustainable way. But yeah, the thing that I'm moving toward most these days is developer relations. Right?

Mark: I love that that phrase, human duct tape. That toes pretty much describe my role as well.

Mario: Yeah, Markie does a little bit of everything, he's everywhere helping us with all kinds of initiatives. You mentioned the community, you want to focus on the community and you know, one of the things that I've noticed about your team you know, which is relatively new, is you guys are out there, you are helping initiatives, you are sponsoring events, you are creating your own events. But the one thing that I noticed is that you guys are always accessible and that is very important and it reassures, you know, how committed your team is to the project and open source in general. So we want to thank you for that. You also mentioned Docz for Gatsby. That is one of the things that is so impressive, how well your documentation is put together. So those are a couple of comments that we wanted to make on that. So as you start development and you are, you know, like I said human duct tape you're focusing more on development now, are there specific areas of the Gatsby project that you are personally involved or is it just a general development workflow?

Jason: So I do, most of the development work that I do these days is more on the kind of building examples side. So I have done a lot of work with showing off ways that you can integrate Gatsby with different tools, how to use Gatsby for different use cases like, hey, let's build a dynamic app by adding, you know, an Apollo gGraphQL layer on top of the generated Gatsby site or, Hey, let's build an e-commerce site by integrating with Shopify and Shopify's client sided SDK. And so a lot of what I do is not necessarily core work so much as it is experimenting with what Gatsby is capable of and trying to build up a real-world use cases of, of how you could use Gatsby to solve those problems. The other thing that I'm involved pretty heavily in is, we don't have a name for this.

Jason: We kind of call it the island of misfit toys internally, which is probably not a good business term, but we have all these properties that aren't actually part of our commercial team. and they're not actually part of the core open source repo. Stuff like our website at gatsbyjs.org or our swag store, various micro apps that live on gatsbyjs.org, like the the site showcase or the plugin library where they're very related to Gatsby core, but they're not part of it. So like our core maintenance team doesn't really have bandwidth or even context a lot of the time to work on that stuff. And so that means that that my team and I end up picking up a lot of those types of work. So like the swag store is something that I did the first version of that. The second version was built with my team. Amberley Romo, community members have contributed a lot on that. And so it's been, yeah, it's been really, really interesting to see how the projects kind of have spread into these different camps where you've got, you know, everybody still works together, but we're definitely starting to specialize, which is a cool thing about watching a company form, you know?

Bob: Yeah. I've actually watched one of your, what do you call them? Are they code with me?

Jason:Yeah. Learn with Jason, the my, my weekly live stream.

Bob: Yeah. It was really helpful. The one you did, I don't know, fairly recently. That was a good one. So thank you for doing those. Those are extremely helpful. Just sometimes you just don't know where to start with something and it's just easy to watch someone kind of go through it. It's also cool to see somebody like, try to figure it out, you know, as you go.

Jason: Yeah, that's actually like one of the major motivations for why the live streams are done that way. So like my formula for this is I call somebody who's doing something that I think is cool. And I asked them if they'd be willing to do a live stream, and if they agree, I do Auth0 preparation. Like I have no idea how anything works.

Mark: Kind of like this show. (everyone laughs)

Jason: I do that intentionally because you can find a lot of tutorials that show how to do the things that I do on the show, like how to set up Auth0. But really what I think is valuable is that I don't know how to do it. And so I have to ask these questions and I'm going to stumble. I have to Google things. I have to, I'm going to break it and have to debug the error.

Jason: And in structured tutorials or in in prerecorded, planned tutorials, a lot of that struggle gets edited out and you just see the happy path of where everything works. There are no errors. And that is really, really useful for, you know, for certain use cases. Like I don't necessarily want to watch 90 minutes of somebody struggling to set something up if I mostly get how it works, but if I've never seen it before, I'm going to hit those errors, I'm going to run into those walls. And I want to see somebody debug it to be, you know, to, to help me contextualize what's going on and understand more about what's happening inside the code. And then just beyond that, like I also feel like we have a tendency, anybody who has over a certain number of Twitter followers, Is sometimes held at a level of like, ah, they must be a like, you know, a capital developer where they know all the things and they don't make mistakes. And I think that it's nice to contextualize that, like, it doesn't matter how many Twitter followers you have, you're still spending most of your day developing on, like, Stack Overflow, you know, like we all, we all struggle through this the same way.

Mark: I always say if it was easy, none of us would have jobs.

Jason: That's true. Yeah. If it was easy, we would have written the bot to do it for us, actually.

Bob: Jason, what did you do before Gatsby? I mean, kind of what led you to this interesting, working for a company that's an open source based company, and how did you get here?

Jason: I mean, maybe a good question here is, do you want the short version or the long version?

Bob: I think we have to go with the short version, although I would really like the long version.

Mark: Is there a medium, can we?

Jason: All right, let me I'll do, I'll do the medium version. So, when I was, I'm going to go all the way back to high school. When I was in high school, I played in a band, and I had a brief failed stint in college, but when I came back to my band, we decided I'm going to be a rock star. Like that was the plan. My, that was, that was, what are you going to be in five years? I'm going to be on MTV. Like, that was the goal. And so in the course of doing that, I ended up filling all these roles that I wasn't planning to inside of the band. I was learning, you know, we didn't have anybody to design merchor flyers. So I was designing those. I had to figure out how to customize her MySpace page.

I built us a website. I wanted to learn how to play our music. So I learned action script and, you know, I kept like, learning all of these things so that I could do stuff that the band needed and I enjoyed doing it, so I kept trying again. I was like, well, that site doesn't look very good. Maybe I'll build this a new one. Probably built 14 different iterations of our band's website over the course of the time we were touring together. And each time it got a little bit better and I was always having fun doing it. And so when I came out of the band, I've learned, and then on top of that, I also, I had to negotiate with the venues to get gas money, you know, because I was like, look, you, you either give us a hundred bucks for gas or I live at your house now.

So, you know, you gotta solve that problem. And so I learned how to ask for money. I learned how to negotiate with people. I learned how to, like, build a community like I had to build a street team. And when you work with a band, you have no budget. I couldn't buy advertising. I had to figure out ways to organically get people interested in coming to our shows and telling other people to come to our shows. So that led to me when I, when the band broke up, I realized I was actually a terrible musician, but I was pretty good at the rest of the stuff. So maybe I should start something that was all the things except music. So I started a design agency. Out of my design agency, I did that for, for a little over a decade and stopped doing all the things I liked.

I went almost entirely into like management and logistics. So I spent all my time paying bills and negotiating contracts instead of actually building or designing or thinking about things. So I sold the agency, started working contracts for a while, ended up at IBM as a front end architect. And at IBM, I was trying to push this agenda of like, hey, let's simplify our stack. Let's go with static front ends. Let's get away from this like really heavy microservice architecture for all of our UIs, which led me to experimenting with a lot of the newer technology I was, I was playing with Nex. I was playing with Gatsby. I was playing with, you know, there were a few other ones that I was playing with as well, but ultimately landed on Gatsby is what I wanted to do. And I was having a lot of bureaucratic trouble because IBM's huge, you know, there's 700 developers on the team. You don't, you don't get those changes put through quickly. And I was on a call like venting about this to Kyle Matthews, as I was asking him about how I would solve some IBM specific problem with Gatsby. And he just said, Hey, you seem kinda frustrated. Would you, would you be interested in working at Gatsby? And I was like, hold on. Is that on the table? Cause yes, I would.

Bob: That's awesome.

Jason: That was slightly longer than medium, but yeah.

Mark: I will have to say this. You did date yourself a little bit. Not only did you reference that your band was on Myspace, but then you were talking about your band playing on MTV when MTV actually had music on. So what was the band name, by the way?

Jason: It was called Minus My Thoughts. And if you want to hear some terrible emo-screamo music, it is absolutely on Spotify.

Mark: Awesome. I'm going to have to check that out.

Mario: So it sounds like, It sounds, I'm sorry, Markie, it sounds like even back then, you were already thinking about a static front end. You mentioned that?

Jason: Well, no, not, not in the band. I didn't know anything about it when I was in the band. It was when I got to IBM was where I was really thinking about it because my role as the front end architect there was, we needed to get something really high performance to the browser in a very short amount of time and also make sure that we were making it possible for any developer to maintain it. So I couldn't build this really thick stack of like, oh yeah, we've got a varnish cache, and then we've got this like edge network, and then we've got, you know, this engine X config on top of the red is cash. Like I can't hand that to a front end developer and say, Hey, why don't you why don't you maintain this? Like, they'll, they'll break it. You know, that's not their job. They shouldn't have to know any of that stuff. So we were looking for ways to cut that stack down, but still keep it fast. And the easiest one was, Hey, what if I just had like an HTML file that I put on a CDN? Like everybody can do that. When we learn, we upload an HTML file to an FTP server. This is the same thing. Like any front end developer can do that. And so that was what led to the strategy of trying to move to static sites.

Mark: One thing that, that I just realized that we should probably touch on because not everybody's going to know this. Can you kind of give us your definition of what Gatsby is?

Jason: Sure. So Gatsby is, depending on the day and your mood, it's either a tool, a framework, or a platform that allows you to very quickly build websites using react and a GraphQL data layer. The goal is you want to be able to pull your data from anywhere. Gatsby has a bunch of APIs and over 800 plugins now where you can just say, I want to use WordPress data or Instagram data or Shopify data and you pull that in, build your site with, with React and GraphQL and then that compiles down to static assets. Those static assets can live on any CDN. We like Netlify, we've seen it used with like AWS, Amplify is great for this. And then once it hits the browser, it rehydrates into a React app so you can do any of the dynamic things that you can do with react on the client side. So that's the very high-level version but, you know, there there's a lot more you can do with it, but you got to dig a little deeper.

Mario: Yeah. I think there's, it's kind of like full circle, you know, coming back to static front end from back in the days. But so to me it's amazing to see how quickly Gatsby has taken off. And is it kinda unbelievable to think that this idea was not, you know, brought in by someone else before that only now we're seeing, at least to this level, right? Because your system is sophisticated that, I mean, it's really impressive, and are you impressed on how well the community has received your product and your projects. And what do you think is the main reason for the huge adoption of Gatsby?

Jason: So to, to kind of, to take a half step back into the, the early part of that question, when you were talking about why somebody hasn't done this before, I think that Gatsby is very much like a right place, right time kind of technology, because, you know, if you look at the progress of technology over time and the state of the market over time, we weren't there yet. Like CMSes were monolithic. If you wanted to manage your content in a content management system, you would have the, like, the database and then the admin dashboard and the front end all managed inside of this same kind of code base, it was monolithic. And if you wanted to do something different with that, it was, you were wrestling against the tools to make that work.

We also didn't have this explosion of software as a service where, you know, there were just all these purpose-built tools for managing data with really robust API APIs for getting at that data. We also were seeing that like, front ends were good, but they weren't great. And we were watching frameworks like React and Angular and Vue, and even before that, you know, Ember and Backbone, were starting to make front end development a really good experience as opposed to this kind of arcane science of wrestling with browser incompatibilities and in dealing with the complexities of like state management in a front end application. So I think that the kind of twin advancement of decoupling CMSes to where they're now running headless, you know, like we're seeing it with decoupled Drupal, we're seeing it with WordPress opening an API.

We're seeing it with a lot of different companies that are basically launching services that don't deal with UI at all. They're just strictly headless CMS. And then on the other side, we're seeing like React and Vue and Angular are like, those are full on stable, front end frameworks. You can do almost anything with these, and that that creates a condition I would call it the, I think I read a book a while back that calls this the adjacent possible, and it's the idea that in order for something to be possible, a bunch of like preliminary things have to be true. And only recently has it been true that what Gatsby does is actually possible. And so I think that, you know, like I said, it's right place, right time where Gatsby was, it's been around for a long time too, so it's also important to remember that Gatsby is not like we didn't create this last year.

Gatsby is four years old. I think the first commits were in 2015. So it's a, it's a relatively mature piece of software that, I think, the market and Gatsby's maturity and the technologies and the way that people are building businesses have all kind of converged into this point where we were ready for Gatsby and Gatsby was ready. And so that's why I think that we are where we are. I also think that we only have a short window before a lot of services emerge that do the same thing the Gatsby does.

Mark: So, I mean, you definitely have a great service, a great software. Did you think it's going to take off? Cause like it's become every community's darling, almost, like a lot of people are, there's a lot of buzz about it.

Jason: I am really happy with the way that the community responded to Gatsby. And I think, you know, to his credit, Kyle just built really good software and I think that the community is recognizing that. It's a high quality piece of software. On the other side of it, we put so much effort into trying to build a good community and supporting the people who contribute and, you know, making sure that we aren't controlling ownership, like our plugin ecosystem means that anybody can change the way that Gatsby functions and they don't have to ask our permission, they don't have to get a pull request approved, they just publish a plugin and it just does it. And so I think that all of those things combined and the fact that performance is really starting to be the thing that matters most.

Jason: Like, I feel like performance is the new responsive. For a while we were trying to argue over whether or not a site should needs to be responsive. And you know, those of us who were paying attention were like, yeah, obviously and I think that there have been a lot of people who were saying do sites need to be performant and, you know, those of us who were paying attention were like, yeah, obviously, but now the business case for it is becoming so much more obvious so that executives are now saying performance needs to be a primary consideration. And the fact that we've baked that into Gatsby, you know, we're doing all the performance enhancements, code splitting, prefetching, image optimization, lazy loading of assets, all those things are just baked in. You don't have to do anything, they just happen.

That, to me, we're just removing the overhead. There's no boilerplate to get set up on a Gatsby site. The dev ops overhead is almost zero. So the experience of building with Gatsby is extremely pleasant. And the outcome, like what gets shipped to the end user, is also really pleasant and those two factors combined, I think, you know, we call it making the right thing, the easy thing you, you get to be lazy and you get a great outcome. And I think that's the best way to drive adoption of any tool.

Bob: Yeah, definitely. One of the things that's interesting to me is that what this skyrocketing rise of Gatsby and a lot of static site and JAMstack as a term and that type of approach, we have more people asking like, well, should I stick with a traditional CMS, or should I go off and try try Gatsby or some combination of the two? What is your kind of general advice on when an organization should, choose Gatsby or something like that over the traditional content management system, like Drupal or WordPress?

Jason: I mean, my opinion is you should use both because both Drupal and WordPress can be used to power a Gatsby site. And,, from my opinion, you know, like the whole goal of Gatsby is we have a term, we call it the content mesh, and it's this idea that content content is coming from wherever it makes the most sense to get content from. And you, as a business, shouldn't be making choices based on the technology that's available to you. You should be making choices based on business needs. And if you need e-commerce, you should choose the best in class e-commerce platform. If you need a blog, choose the best in class blog platform. And if you want to manage tabular data, use a Google spreadsheet, who cares? You know, whatever makes the most sense for the kind of data that you're going to be managing, use that.

Jason: And then Gatsby just allows you to install a source plugin for your Google spreadsheets, for your Shopify blog, and for your decoupled Drupal instance, and pull those in all into the same website, work with that data through a kind of normalized data layer, and build an incredible experience that performs really well on the client side. So I don't think it's a choice. I think that you get to keep using the CMS that you like., you're just changing the way that you build the front ends that those CMSes are powering.

Bob: Yeah, that's great.

Mark: So we've talked, you know, about the performance of Gatsby and the fact that there are other things that may come up, there are other static sites generated out there. What would you say, and I think it kind of touched on this earlier, but I kind of want to ask the question, what would you say separates Gatsby from the other ones out there, the other static site generators?

Jason: I think the biggest difference in my mind is that right now Gatsby, by default, isn't actually a static site generator. It's a static asset generator or, we've been calling it a progressive web app generator, because when it hits the browser, it's going to become a fully dynamic app again. So it's not really a static site. And you can do the same thing that you do with Gatsby using Hugo or Jekyll or Hexo, or whatever your static site generator is, but you're on your own to do it. You know, you have to set up Hugo to serve a React app and mount that and deal with all of those things on your own whereas with Gatsby, that's just kind of the way that it's built. We expect it to do that. And so it, again, it's kind of, we want to smooth that path. Well, I'll give you a perfect example.

Jason: So with with something like a regular static site, you're going to generate out static HTML, which means that if you click from the homepage to the about page, you need to do a full browser refresh to switch from home dot HTML, to about dot HTML. With a Gatsby site, we're going to render, or we're going to generate, index dot HTML and about dot HTML, and whichever one you load, we'll pull up, you know, we'll load about dot HTML, but then we rehydrate into a React app and we lay a router on top of that so that when you click from the about page to the index page, you're not doing a full browser refresh. We've pre fetched, all the routes that are linked on that page already so you get an instant reload using reach router. So it's an app like experience, it feels native as opposed to requiring a full browser refresh. And that's the sort of stuff that we just baked in, because that actually leads to better performance. Like, it's always faster, you load a piece of a page versus the entire page. And, you know, that kind of routing is, that's why we try to do that.

Mark: I love that that qualification about it, just not being a static site generator, and a lot of people think of it that way. And it's good to hear the actual answer. You know what I mean?

Bob: Yeah. I mean, I thought of it that way before Decoupled Dev Days last year in New York and Kyle...

Mark: Now called Decoupled Days.

Bob: Yeah, in New York, small plug for that conference, but Kyle spoke there, and I was in a session and it really opened up my mind about what was possible with Gatsby, and the rest is history.

Jason: Yeah.

Bob: What features are the team working on now, the folks over at Gatsby? What, what are you guys excited about and what are you working on?

Jason: Probably the most exciting thing that we're working on right now is what we're calling themes, which is a little bit of a misleading name, because when you think about themes in the context of something like WordPress it tends to mean like, oh, here's some templates and some styles to make those templates look nice. And while that is true about Gatsby, that's what Gatsby themes will do, we also have this additional layer of functionality where you can effectively like compose websites together. So something that's really cool about this is like, if you build a Gatsby site and it's a blog, you can turn that into a theme so that the person who wanted to use it would be able to just create like a folder full of markdown files and install this theme. And the theme will read that folder and there is no code required.

It's just, you know, here's my theme that I want to use these markdown files. There's also, if you wanted to set it up to use decoupled Drupal, you would have the, you know, the theme here's my use Drupal theme and my API key to read that, and no code is required. You don't even need a folder. You just install that. And it pulls the data from, from Drupal. But where this gets really powerful is that if I wanted to use Drupal for my blog, but Shopify for my e-commerce, I could install two themes and install them both, one for blog, one for shop, and they would both get rendered. And then you can do horizontal and vertical composition here, so if both of those exposed design tokens, I can have a parent theme or a child theme that inherits from both the shop and the blog, but overrides their design tokens so that the whole site looks like the same site and not like two themes that have been smashed together.

Jason: So there's this really, really powerful composition model in place. We've also done some, some more advanced stuff that most people probably won't need to deal with. But, for example, if you want to override the header, you can selectively eject one or more components from a theme and override it in a child theme without having to rewrite the entire app or deal with that. You just basically create one new component and name it a special way that says this is replacing X component in the parent theme and it just gets picked up and read. It's a really, really powerful model where we're going to be able to do some just absolutely incredible things. It's in experimental mode right now, so you can use it today. Docz are a little bit light, we're mostly moving off of like code examples. But yeah, we're, we're also really excited to talk to people about it. So you can tweet at me or tweet at a Chris Biscardi and John Otander who are two of the people who are driving that effort. If you, want to see more and learn more, get involved.

Bob: Yeah. That sounds really useful.

Mark: Yeah, absolutely. I'm kinda excited about that because, especially the fact that you can do multiple themes from different sources, which is always a pain because you never know if the data is correct, and then also the child theme ability where you can punt out the header, like, like you said, is gonna be really, really cool. So things like that can be shown at Gatsby days, Gatsby Days was just out in New York for those who missed it. When would be the next one? Because I went to the one in California in December, and then I didn't realize this one was happening until it was too late for me to go, but when is the next one?

Jason: The next one is going to be in London. We're super excited about that and I think our intention is to try to do these a little more frequently. We're trying to, we're trying to get, you know, Gatsby Days, ultimately we want this to be a good enough model that anybody can spin up a Gatsby Days in any city at any time and we'll just give them the formula to make it run. In the meantime, we're kind of running them manually to try to get our feet under us and make sure they run smoothly before we, you know, unleash this on unsuspecting community members.

Mark: It will be the DrupalCamp of Gatsby.

Jason: Cool. Yeah, that's actually really what we're after is we, we want that community driven model where people who are building stuff and people who have a lot to teach all of us about how to use Gatsby can just stand up an event and get the support they need to make it run well.

Mark: Awesome, Jason, thanks for coming in. That's it for today's show. Thanks for joining us, looking for more useful tips, technical takeaways, and creative insight? Visit mediacurrent.com/podcast for more episodes and to subscribe to our newsletter. Thanks for playing.

Links: 

• Jason’s site
• Learn With Jason
• Minus my thoughts  (Jason’s Band)