This course has been updated! We now recommend you take the Intermediate Gatsby, v2 course.
Transcript from the "What is Gatsby" Lesson
[00:00:00]
>> Jason Lengstorf: Another way to think of it is that it's a Progressive Web App generator. So because we are shipping static assets that rehydrate in the react apps, that also means that using things like service workers allows us to catch offline versions and upload a manifester plug-ins for both of those things that make it relatively straight forward to make your apps available offline using Gatsby.
[00:00:23] That obviously isn't gonna solve the client site problem, but it will make all of the build time data and all of your static assets available so that someone could save it offline for use later. Ultimately, the goal with Gatsby is to make the right thing the easy thing.
[00:00:37] The idea is to set good defaults so that if somebody just leaves it as is out of the box, they're gonna get a good result. Another way to say that is that we're trying to design tools so that somebody who is completely under deadline pressure and takes every shortcut in the book, delivers an excellent experience to the people using the website.
[00:00:59] So Gatsby under the hood is setting good defaults. It's following the purple pattern, which if you follow Addy Osmani, or the Google Chrome dev team, I think is who could put this out which is all about like. How to structure data request for pre-loading and rendering in the background and lots of things that make it more performing on the website.
[00:01:22] I'm not gonna go into the details of that, the purple pattern is worth looking up though. It also generates only static assets which again taking the server out of the equation, that's one less hop that your users have to make to get to the data. And then Gatsby will optimize an lazy-load assets, so you can take, instead of a single three megabyte image off of your phone that you've uploaded to your blog.
[00:01:43] That'll get compressed, cut down, turned into the right size image for the viewport loading it, and it only gets loaded when it shows up in the viewport, which saves your users megabytes of data transfer and potentially never loads it at all if they don't scroll to that part of the page.
[00:02:00] It'll normalize third party data as well. So again, we talked about the data access through GraphQL. By doing that, you don't have to figure out how to asynchronously load a bunch of third party API's and try to make that performance. If you end up in a situation where you're making lots of asynchronous calls, you're probably gonna be tempted to use async await.
[00:02:21] But if you use async await, and you're not setting up like a promise dot all, then they're actually blocking and running sequentially. So inadvertently, you'll make your pages really slow. By normalizing that data into GraphQL, Gatsby handles all of that for you. So you don't actually have to think about how to get that data in quickly.
[00:02:38] And because you're doing it at build time, you feel that pain as a developer, if you do something that's not performing because the build is slow. But the static assets that get generated are fast. And so your users don't feel the pain if you do something silly with your data management.
[00:02:54] I mean, you wanna fix that obviously, but it becomes your problem not theirs, right? The other thing that I think is really important about this is that, while Gatsby has a lot of opinions and sets up a bunch of defaults. It also gives you a huge amount of control.
[00:03:08] So you can get all the way down to the Webpack config, you can get all the way down to the Babel config. But the thing that's important is that Gatsby uses a model that I I've started calling progressive disclosure of complexity. I don't think I made up that term but I've co-opted it.
[00:03:23] Which is the idea that, when you want to modify something, you should only have to eject the piece that you want to modify. We've probably all seen this when you use some kind of a boiler plated tool that it does all the things that we want and then we hit an edge case and suddenly, all of the config is managed by us.
[00:03:40] The entire app becomes objective, and now any change that happens upstream, we have to manually migrate. There are a lot of pain points involved in that. So Gatsby tries to get rid of that by only exposing pieces one section at a time. If you make a Babel adjustment, you don't have to eject the entire Gatsby build pipeline.
[00:03:58] You're just injecting that one little piece of Babel config. So, to kind of recap this, Gatsby is fast and all the ways that matter, it makes you faster as a developer, it makes you faster. The experience that your users will see is faster. And it's fast to get started, fast to ship and iterate.
[00:04:19] And those are all really important things. And lets you bring in your data from anywhere because it can use the file system, API, software as a service. It doesn't restrict you as a developer on what you can build or where you can build it from. It does the right thing by default by setting up good guard rails in defaults, you're able to cut most of the corners and still get a good result.
[00:04:39] And I think this is probably the most important thing for me. Gatsby actually made web development fun for me again, if I have a silly idea for a project, I actually build it now. Because before I would get halfway through a web pack config, and then I would get disheartened, and I wouldn't wanna do it anymore.
[00:04:55] And so with Gatsby, when you just say Gatsby new use your template, it will just give you something that you can run Gatsby development. It's in the browser and it's working and I'm immediately writing UI code. I'm not trying to figure out how to get my boilerplate to work so that I can ship something.
[00:05:12] So, that's kind of the overview, right? That's my pitch on why Gatsby is worth looking into and why it's worth taking seriously as a web technology. But the rabbit hole goes so much deeper and that's what we're gonna do today.