Noel:
Hello, and welcome to PodRocket. I'm Noel and joining me today is Khaled Garbaya. He's an Engineering Manager at Gatsby here to talk to us about what's coming up new with the Gatsby framework. How's it going, Khaled?

Khaled Garbaya:
Good. Thanks for having me.

Noel:
Of course, of course. Yeah, we've got a whole bunch to jump into today. Maybe before we get into the nuts and bolts of what's coming up though, tell us a little bit about yourself, how you found yourself on the Gatsby team and working in the front-end space.

Khaled Garbaya:
Yeah. I guess, my experience goes back to the, I guess, a hundred years ago to being a Flash developer. I started Flash building interactive apps and games for agencies, and then moved a bit into a deeper level into gaming, building game engines, and then was interested more in Node.js when the whole ecosystem started. So, I was, for a long time, for at least five years, at Contentful maintaining the SDK, and how I got introduced to Gatsby. Actually, I was maintaining the source-contentful plugin. It's one of the popular ones that sourced the data into Gatsby, and then I ended up contributing the Gatsby a lot. I had a lot of their [inaudible]. And then, after a while I had the opportunity to join them and it was actually really interesting because you'll have the influence on the framework from the inside.
I used Gatsby a lot. I also did a lot of courses using Gatsby in Contentful, and I fell in love with the framework as a whole, so it seemed to be the next move. And here I am supporting the framework team, responsible of everything you see on the open source. And when you do Gatsby something, that's my team. And we recently... I mean, almost getting done with Gatsby v5, which is very exciting. We actually released the beta yesterday, so that's also very exciting and hopefully, we can go in detail about it in this podcast.

Noel:
Yeah, yeah. I've got a bunch of questions. We're Gatsby users at LogRocket as well. We use it for the website, and we're working on transitioning the blog to it. It's kind of a big project because the blog is pretty big, and there are a lot of moving pieces and it's kind of tightly coupled with a lot of WordPress stuff, but we're getting there. The plugins make it super easy. Your perspective, though, being at Contentful probably, I'd imagine, would give you a good user experience for how the people writing plugins and being in that intermediary layer of the Gatsby ecosystem probably works. Is there a lot of people on the Gatsby team now, at this point, that have that background, or are you pretty unique in that regard?

Khaled Garbaya:
I think, the team, yeah, definitely, you can find a lot of diversity in thoughts, in skills and everything. You can see people coming in with a Drupal experience. Some people also have WordPress experience, and we are so fortunate that we have people actually were hardcore users of these CMSs and data platforms in general, and then they can apply that knowledge into the plugins, or even the core experience to support it.
And Gatsby has been sourcing the data for a long time, so I think we're in a very good spot right now to pretty much... You can get anything that has an API, or source the data. You can use it with Gatsby, and that's through a lot of experience, and trial and error, and all of that. So, we made a lot of mistakes that shaped up this framework and especially the sourcing part.

Noel:
Nice, nice. I'm going to take us off the outline slightly, but this leads me to an interesting question. I've been thinking about this a little bit lately. Do you think that Gatsby's big advantage right now, comparing it to something just like using Next, Raw, is that it kind of has this opinionated way of pulling data, or there's plugins that have strong opinions that you can just then include and get data working right away versus Next's approach that's intrinsically a little bit more kind of DIY; figure out how to get the data into the app yourself?

Khaled Garbaya:
Yeah. I think, yeah, that part where with Gatsby you can definitely get a lot of... There's opinionated ways of getting things but it's the... You can think about it as there's a lot of these boilerplate things. Let's say, you're sourcing a data. So, basically, at Next, you will be creating your own... You get a library and get the data, and then try to share it across multiple pages and then do much more requests and stuff. But then, Gatsby, the idea is very simple. You get any shape, you just adapt it to our GraphQL schema, and then you'll have it available everywhere. So, there's no, let's say, crazy, for example, collections or arrays that you will throw around and then do your own manual filtering and stuff. You use, actually, GraphQL, which is best for querying data. You get only what you need, and it's a nicer, much more intuitive developer experience.
So that's the part and I think yeah, there should be always a balance between getting opinionated thing but also have the flexibility for more advanced use cases, which is the case here. So you can have your own plugin, but other people also, if they don't like how things approached, which hopefully they will talk to other maintainers and then or have one plugin, but you can also even let the plugin bring in the data for you and write some more code on your Gatsby node to for example, alter these fields and customize them, add more stuff to it so that way you'll focus only on customizing the data but then how you grab it, you can leave it at someone else for someone else like the plugin and so on.

Noel:
Yeah. And even just like, again, talking about sourcing large amounts of data and only pulling data that you need to pull to get things updated as you go, I feel like having someone that's done a lot of the work that's already specific to the domain from which you're pulling the data, it's like you don't have to solve all these problems that have already been solved when you're using a plugin and can pull it off the shelf. So, that's super nice.
I guess, maybe we should take a little bit of a step back for those listeners who aren't in the front end ecosystem and super familiar with the Gatsby, Next, and all these things. In your words, what do you think the value that Gatsby brings is? Why do devs reach for Gatsby?

Khaled Garbaya:
So, you can think of Gatsby as... I call it a web framework for highly efficient and very fast front ends. But then, I mean, that's the main use case. I think, Gatsby also excels really well if you have a data heavy app. Performance is already baked in in a lot of ways. Accessibility is already baked in if you look at the reach/router that we use, or the router. We keep improving it, by the way, and how we do pre-loading and everything and apply all the best practices. So, you don't need to worry about that. You focus on what you do best, which is building apps and building front ends for your company, or product, or everything. But then, you can also go a level beyond. You can start from a basic, like the normal side, but then if you want to add more stuff on top of it, we have, for example, DSG, so you can defer a lot of pages.
Let's say, you have millions of pages but only your users are interested in the first hundred, or something, you can defer a lot. That's a really clever way of handling big sites. We have also SSR. If you want to add some user-based content, or user-generated content, it doesn't make sense to build a page for every user so you can use a bit of SSR. And they all work together seamlessly. You don't need to do any extra work here and there to do that. So, I guess, in a few words, Gatsby would be... Our aim is to be kind of zero-compromise web framework to help you build really fast and performant web apps ranging from having data, but also you can build apps on top and everything.

Noel:
Nice, nice. Well said. So, let's talk a little bit about what's coming in v5. What's new? What are the big improvements that we'll be able to leverage?

Khaled Garbaya:
Yeah. I guess, when we talked before the podcast, we're talking about Alpha. Now, we actually have also Beta, so it can actually move fast. So, Gatsby 5, I'm very proud of this version. I would call it the best version yet that we built.

Noel:
That's good.

Khaled Garbaya:
Two of the main features that we really put a lot of thought in them is Slices and Partial Hydration. We wanted to improve all the aspect of Gatsby, so we can take first the build time. Build time, Gatsby is actually really good at caching and know what to build, when to build, but there's a few problems. Let's say, you have a shared component that you have in every page. Navigation, for example, footers, banners, everything. Before, there was no way that you will display the data unless you rebuild all the pages because that one is dependency for every page. Let's say you have a thousand blog post page and every one of them has this author component. Let's say you changed something, like a name, and you have an author who authored a 10,000 blog post. You need to build a 10,000 page.
Slices, what it does is, actually, we can define that highly shared component into a slice, and then when it changed, like if you do a code change or if you receive a data update that affects only that component, we will rebuild just that component, and then we stitch it. So, there's going to be stitching afterwards. We did some benchmarking, and in some sites reduced the build time up to 90%. So, we've seen... For example, we did some tests on gatsbyjs.com, which is one of our customer zeros, I call them. We test on it. Builds went from two minutes and 30 seconds to five, six, sometimes eight seconds, maximum. So, that's a huge leap especially in build time, and it will help people to preview and review changes very fast.
One of the things we joke about is when you make a typo, and then publish your site, and then you're waiting five minutes to realize, oh, you made a typo, and then change it again and then wait another five minutes. So now, it's a matter of seconds. Building just the slice, in the benchmarks, took 500 or 700 milliseconds. And then, there's obviously uploading the HTML to hosting and all of that. So, I think, I'm very excited about that. I'm looking forward for especially big customers to try that and work with it.
Then, Partial Hydration. I guess, I would say, a lot of people have heard of about React Server Components. It's been there for the last, what, four years, five years. So, what we have is, Gatsby can also hydrate that HTML and turn it into a React application. But in a lot of cases, you might not need all that JavaScript. And now, using the React Server Components, you can build your site and then tag the component that you have to use. If you look at the spec, the old one was you do a ".server.client". That was not very user friendly.
Then, in the RFC, there was a suggestion made and a new experimental version released with where you do similar thing like use strict, like in the old days. You would have a string and have it like a client export. There, then, we will ignore everything. We want ship the JavaScript for your page, we'll only ship just the bit for... Let's say you have an interactive navigation, or a counter, or something like that, we'll only ship that JavaScript for your component to work, and then the page will be stripped down.
However, this is still a highly experimental feature. Even in the documentation, we tell you to install React Experimental. Spec changes, the bundling and the works, still, there's few edge cases. It's not stable right now, but if you want to play around with it and try it out, yes, it's part of Gatsby 5 Beta. So, that's definitely something I encourage people to try out and see.
And we actually... If you look at Gatsby, I think, we are one of the first that released something that actually works using the server component and the newest spec, which is... It's a really hard problem to solve. I've seen the engineers spending a lot of time on it, but I think we're at a okay state, at a good state right now, but still experimental. You won't probably see all the benefits that the server component promises, but I think, by the time we have React stable with Server Components, we'll have it also ready in Gatsby.

Noel:
Do you guys have any grasp on the number of sites that are using Gatsby currently? Gatsby cloud, or something, if you have that data that are largely static, that could benefit pretty substantially from having components that aren't ever hydrated?

Khaled Garbaya:
The first one I can tell you about is gatsbyjs.com. There's a bit of interactive elements, like navigations and so on. But then, let's say a big chunk of it is blog posts, and blog posts are static so we don't need that JavaScript just for the navigation piece. And I think it's the same in a lot of customers. I think, there's a lot of potential for people to use Partial Hydration and also Slices because if you combine both, you will have the benefit of the build time but also less Javascript shipped. This will definitely improve also your lighthouse scores and especially the TBT, Time Before...

Noel:
It's that first render step when loading, is that the TBT?

Khaled Garbaya:
Total Blocking Time, sorry. It's the Total Blocking Time. So, this is when the browser try to parse your JavaScript and blocks the rest of the thread until that's done. So, that will definitely go down because you have less JavaScript eventually. Especially if you're a site that's mainly consuming data and then having pages, let's say, marketing sites and everything, there's a benefit. But also if you have a part that's an app and a static, you'll benefit on that static site.

Noel:
The reason I ask is because I... I have no data to support this, so my suspicion is that a lot of people have been reaching for Gatsby over the last couple years for their sites that are a little bit interactive in one or two places, but largely static for the most part. And that has given them a lot of benefit thus far, but I think it can continue to give us more here.

Khaled Garbaya:
Yeah, the good thing, already, there's the tree shaking in place. We have and we do really good job at chunking the JavaScript and load it kind of on demand when you are on the page. But this one, even a step further removing all the unnecessary stuff for static page.
And just, I guess, to close up with Gatsby 5, we have also features like the HEAD API. Instead of React Helmet, now you can natively add meta tags and links. The script component, actually, are also very nice, allows you to add third party scripts. You can also use Partytown there. You can control when a script is loaded off-thread, or pre-hydrate, or after rehydrate, and all of that. So, you have granular control, and this will also improve your app interactivity.
These are some of the features. But then, I will encourage people to go to the Umbrella Discussion. There, you have a list of all of their things, some slight breaking changes. I don't think that's going to be a lot. It's going to be very... For most of the people, it would be super smooth experience. You just upgrade and you have it working.

Noel:
Nice. Nice, cool. Yeah. I've got a couple more questions, but before I get to them I want to encourage listeners to go follow PodRocket wherever you get your podcasts. Go, subscribe, like, and do all the things that you can do to keep this going here so we can keep bringing you content like this.
Yeah. Again, I do have some questions a little bit more on the technical specific side on the hydration flags and how this stuff works under the hood. Mainly in that... I'm not sure. I haven't kind of gone down this path in a while, but is there... So, in my head now, I'm kind of building this model where there's a few different flavors of components that I would've to think about when being a developer working on this. It'd be components that are strictly static and I don't care about interactivity at all, which I could then flag as never needing hydrated. They can utilize new partial hydration. And then, components that can be rendered on the server, but they also then need to be hydrated and become interactive. And then, components that can't even really be rendered server side for whatever reason that may be. Is it easy to make the delineation between those two, three things, or I guess, is that a good way to think about this, or is there some other way to view these separations of types of interactivity?

Khaled Garbaya:
I will talk from user perspective when using Gatsby in this case. Static, this means it's server-side. [inaudible], so it's generated. In other frameworks might be server-side rendered, or something, but since Gatsby has a build step, that static component will be built for you. So, that's the static one.
And then, anything that has an interactive thing in it, right now, you need to manually tag it to say, "Okay, this one is interactive." And then, we'll know, okay, this will be a separate chunk and then gets loaded in this page in here.
Then, there is the other flavors, like, okay, what happens if I'm... Let say I have a lot of components and now I use Gatsby, will all of my component by default will be static? That thing is... Some of that work will be moved to the React world because mostly the React and Webpack. But we were talking about actually some more possibilities to not even have people input this client export, or to have these components, but then we detect if there's a use effect for example. We assume that's an interactive one, and then we do that. But for now, we're using just the client export, which is now, I think, they opened a new RFC. It's called use client, or something like that.
That's, right now, how it's working, but again, a very experimental thing. We need to still work through it to have, I guess, a better and better experience.

Noel:
Yeah. Did you guys decide against trying to inspect, do a reflection on the code itself, and look at what hooks are being used to determine if it needed to be hydrated or not? Did you decide against that because there was too many edge cases and it was error prone and confusing, or what was the decision there?

Khaled Garbaya:
Always in web development, I wish there's only one way to do one thing, but it's not. There's like a million way to do things, and we wanted to first deliver the first experience. Make it work, and then make it right, and then make it fast. That's what we try to do. We definitely have this ideas on people like, "What about the use effect? What about using this? What about using that?" And just by having all these ideas, you can see already this thing coming bigger and bigger and bigger. So, for now, it's good to provide the user with a way of tag your interactive components, and then in the future, we will learn from, I guess, the experience and how people are using it, and then we can decide on that.
It's the same thing if you look at Slices, we also had ideas of, "Okay, what if we detect these highly shared components and we do the slicing automatically for you? Or something like that." But then, we decided to first let people define these slices, then we learn the usage pattern, and then the next thing is making it even faster for the user and more useful.

Noel:
Gotcha. So, for Partial Hydration then, do you think it'll be opt-in when v5 goes live? Like, you'll have to go in and set a flag so you know what you're doing?

Khaled Garbaya:
Yeah. Partial Hydration is not going to be on by default. You need to define... I think it's called Partial Hydration. In your Gatsby config, there's a flags object you can throw in, Partial Hydration, and then we will let you know we're doing that. And you have also the experimental warning on the console.

Noel:
Yeah. I ask because I feel like these kinds of features are ones that could end up being kind of common places where people new to the framework, or maybe they're new to React at large, could be very confusing to get this initial, or this additional layer of having to understand interactivity and server side rendering and what JavaScript ends up getting bundled to give you that interaction and all that stuff. So, I think, that's probably a wise choice. Is it frustrating at all when you're having a release like this and all of the big, cool, flashy features are opt-in? Is that a little bit frustrating?

Khaled Garbaya:
I think the only one opt-in now is Partial Hydration. Slices, it's a completely separate API, and then when you use it, it's there.

Noel:
Sure.

Khaled Garbaya:
Usually, we tend to not have opt-in flags unless there is either experimental feature, or something that might change entirely the behavior, and maybe people are not a hundred percent ready for it so we slowly cannot roll it out with a flag. Partial Hydration because it'll affect your bundling and everything. And since we know it's still not a hundred percent also stable from the React side, we don't want to mess up too much with your bundle. We don't want to break your app basically. But it's there for, I guess, the brave people, or the people who wants experiment and try it out with their current projects and so on. And then, hopefully, once everything is in a stable state, we will make that... By default, we make it on. We might keep the flag also, but I don't know. Less JavaScript is always beneficial, right?

Noel:
Yeah. Who's like, "No, I want additional Javascripts you guys know is unnecessary. Please give me that."?

Khaled Garbaya:
Yeah.

Noel:
Yeah, more stuff sent to the client. Cool. And you touched on it briefly, the breaking changes for the upgrade, are most of those... We don't have to go into them in detail, but are most of them pretty quick for a lot of apps, or is there a lot of higher level stuff that needs to be tweaked?

Khaled Garbaya:
There's the two breaking change, which is... For example, React, the minimum version now is 18. React 18 has been unstable for over six months, so that's totally fine. And usually, React, there's no breaking change on the surface unless you are very advanced, you have a very advanced use case, very mature one.
For Node, we will also require version 18 and up. Some people might ask why not 16? 16 seems to be a short-lived LTS, and for us to just support that, then we need another breaking change for some time, so we kind of went ahead to 18. Gatsby is mostly built locally, or on Gatsby Cloud, so there's no hard requirement on Node. You're not building anything server side, so that's fine.
We have the static query using the old way render props, but also, we have the use static query hook. We are deprecating static ways. You can still use it, but we best use the hook instead because it will get removed. We have also some support for all browsers. We removed it, so less polyfill stuff.
We have a change in the GraphQL schema around sorting and filtering. That one is actually to optimize for resource usages. We'll use definitely less memory. Your old query will still work. It's not going to break your app, but we actually... If you look at the console, we give you the new query that you can just copy paste, or you can run a codemod that will go through all your query and change it for you. It's a very, very safe change in there. Probably, also, some changes in some plugins, but we'll see. For GA, this is going to be just a property will be renamed or something. For, I guess, the audience, I think, things would be-

Noel:
Yeah, it sounds pretty doable. Yeah, I would suspect it would be plugin compatibility. That stuff's always a little bit laborious to get through sometimes. And then, the Node version and React version, it's kind of one of those, sometimes it's a little bit of a pain but you know it's coming anyway. So, it's one has to do.

Khaled Garbaya:
Yeah. And for plugins, especially source plugins which is one of the most important ones, from Alpha, the first version we release, we communicate with especially the top of source plugins like WordPress, Contentful, and other to test the version and make sure it's working, it's fine, and everything because that's actually one of the things that... We want to have these plug-ins also already for Gatsby 5, when Gatsby 5 is out.

Noel:
Very cool. Cool. I think we've covered a lot here. I want to turn it over to you, Khaled. Is there anything you want to plug, or point listeners to?

Khaled Garbaya:
Yeah, a few things. We are currently hiring, I'm looking for a Senior Cloud Engineer. If you want to work on cool features on the Cloud, reach out to me. I think, follow me on Twitter, you'll find, I guess, my handle there. There's also a course that I worked on. It's called realworldjamstack.dev. If you go there, I work through people from starting a marketing site to having starting point for a SaaS app. And then, also, how you build your shop using Shopify and Gatsby. There's a lot of things to learn there, and it's really cool. Yeah, I guess, these are the plugs.

Noel:
Excellent, excellent. Yeah, we'll get links in the show notes as well so people can find all two or three of those. Cool. Well, thank you so much for coming online and chatting with me. It's been awesome.

Khaled Garbaya:
Yeah. Thank you. This was a lot of fun.