CHARLES MAX_WOOD: Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel, we have Steve Edwards.
STEVE_EDWARDS: Welcome Portland.
CHARLES MAX_WOOD: Dan Shapir.
DAN_SHAPPIR: Hey from Tel Aviv. Hopefully we don't lose any listeners over that.
CHARLES MAX_WOOD: Or yeah, no kidding, right? Yeah. The last episode you guys just disappeared on us. You know, it was like air raid sirens were out and yeah, but we're glad you're safe.
DAN_SHAPPIR: Yeah, yes, we are. Thank you.
CHARLES MAX_WOOD: Yeah. And there's a there is a time delay. We're like five or six episodes ahead. So people be listening to this and going what? So, yeah, just go back and look at what was going on six weeks ago. I'm Charles Maxwood from DevChat.TV. And this week we have a special guest and that is Brian Rinaldi. Brian, do you want to say hi and remind everybody how awesome you are?
BRIAN_RINALDI: Hi, everybody. Hello from Orlando, where it's it's warm and sunny.
STEVE_EDWARDS: Oh, I feel your pain.
CHARLES MAX_WOOD: Is that pain? It sounds nice. Yeah.
BRIAN_RINALDI: It is nice, actually. It's not even by Florida standards, it's not even hot. It's only in the like 80s.
STEVE_EDWARDS: Oh, that's so nice.
DAN_SHAPPIR: So I really, I have to ask, how often do you go to Disney World?
BRIAN_RINALDI: Well, over the past year, not that often, but actually I just went last weekend. So yeah, pretty, it's when you live here, it's very different. You don't, Disney World always seems like just exhausting, right? Like you wake up early and you spend your whole day running to rides to get to maximize your your ticket and when you live here, it's like, ah, let's just show up in the afternoon with my season pass and just wander around for a few hours and go home. It's not as stressed. It's not a big stressful thing, you know?
DAN_SHAPPIR: So funnily enough, when my eldest son was celebrating his bar mitzvah, we actually went on this family trip to the States and we started off with a week stay in Disney World and my kids after even after all these years, because it was a while back, still remember that as one of the best vacations ever. And my wife remembers it as hell on earth or something.
BRIAN_RINALDI: That sounds about right.
CHARLES MAX_WOOD: Yeah. It does get hot enough there.
BRIAN_RINALDI: Going with kids can be exhausting and summers here, like I probably won't be back for a few months because going in the summer is just brutal.
CHARLES MAX_WOOD: Oh yeah. I bet. Yeah. What's your mom's actually like? Going in a few weeks. So.
BRIAN_RINALDI: Who's going in a few weeks?
CHARLES MAX_WOOD: My mom is with my brother and his kids.
BRIAN_RINALDI: They don't. By then, I mean, it's surprisingly, it should be in the nineties already based on past history. So it'll be hot. Yeah. Hot muggy. It's kind of standard.
CHARLES MAX_WOOD: Good deal.
This episode of JavaScript Jabber is brought to you by DigitalOcean. DigitalOcean recently announced their new App Platform service, which is a solution to build modern cloud-native apps. With App Platform, you can build, deploy, and scale apps and static websites quickly and easily. Simply point your GitHub or GitLab repository and let the App Platform do all the heavy lifting. As it has support for Node.js, Python, Go, PHP, Ruby, static sites, Docker, and container images, DigitalOcean runs their App Platform on their own infrastructure so your costs are significantly lower than the other products platform on top of DigitalOcean Kubernetes, providing a smoother migration path so you can take more control of your infrastructure setup. As a listener of JavaScript Jabber, you can get started for free. Better than free because DigitalOcean is giving you $100 credit when you go to do.co.jabber again go to do.co.jabber to get your $100 free credit on DigitalOcean's new app platform. We want to thank DigitalOcean for sponsoring this episode of JavaScript Jabber.
CHARLES MAX_WOOD: All right, well, let's talk Jamstack.
BRIAN_RINALDI: Yeah.
DAN_SHAPPIR: You should be saying the Jamstack, or am I mistaken?
STEVE_EDWARDS: We be jammin'. Jammin'. Yeah, now it's funny. That's Bob Marley music, queued up.
CHARLES MAX_WOOD: So I remember like a zillion years ago, we had, what's his name? Douglas Rockford? No. Now I'm gonna have to go look it up, but is it Brian Douglas?
BRIAN_RINALDI: Oh, Brian Douglas, yeah, from, he works at GitHub now.
STEVE_EDWARDS: Oh yeah, he's got his own Jamstack podcast, yeah.
BRIAN_RINALDI: Yes, he does, he does.
CHARLES MAX_WOOD: Yeah, he used to work for Netlify. Right. And he got on and he was talking about Jamstack. And I was like, don't we do this anyway? Right? It's like, it's JavaScript and APIs and markups and don't we do that anyway? Right? Yeah. And it's come so far and evolved so much since then. So yeah, it's not kind of this, yeah, it's not the simple thing anymore. What are we talking about these days when we say Jamstack?
BRIAN_RINALDI: So it's funny that you bring that up because my lately, my messages, forget the jam.
STEVE_EDWARDS: Just go to peanut butter.
CHARLES MAX_WOOD: I almost said it.
BRIAN_RINALDI: Basically, you know, the JavaScript APIs and markup was, it kind of made sense. I, uh, back in the day, now I feel like it just adds more confusion to the topic than, than it clarifies just to kind of go back in time, right? The term was created by Matt Billman of Netlify for a particular reason, because we were, I had even written a book with Ray Camden a while back, like working with static sites and it was everything was about static sites and static site generators, but we weren't really building static sites. I mean, these sites actually pulled in dynamic data and build time. They pulled in dynamic data on the client via JavaScript. And so like people had this misperception that what you could build with this was just like developer blogs and, and brochure where sites and stuff. So that it was very limited. So they came up with this term to try and change the perception of what we were building. And I think that is proven successful since then, right. I mean, it's grown enormously, but what started to happen was that, that the term didn't entirely make sense. I, I I'm not advocating we dropped the term. But first of all, JavaScript APIs and markup sounds like just about anything, right? Like almost every site is going to use some degree of JavaScript APIs and markup. So we have to kind of describe that differently. And secondly, it's Jamstack is not actually a stack either because it's not a prescriptive set of technologies. It's, it's a ton of different things. There's like, I always like to say there's like a thousand ways you can get into the Jamstack and you can do it in using different languages and different tools. And hold, like depending on which path you choose, the process can be entirely different, but it's a, it's almost like an architecture set of methodologies that describe the similarities between those things. So, so even though I'm still using jam stack, obviously as a term is I say, forget the jam and yes, it's not a stack either. So, so, yeah.
DAN_SHAPPIR: Well, look, you know, this is, this is the JavaScript podcast and you know, look at JavaScript, which is, has nothing to do with Java and it's not a scripting language anymore. So you don't find a successful brand, even if it's a, doesn't actually match the, the topic or the subject that it's describing.
BRIAN_RINALDI: Exactly. And we always say what naming is one of the hardest problems in computer science, right? So this is continues to afflict us, I guess, but the name has obviously caught on. We have a whole community kind of built around it. I'd say there are some key things to describe what it actually is. And, but I would preface this by saying there is still some debate, particularly this year, because things have been changing very quickly, new technologies kind of blurring the line of what's Jamstack. So some of the stuff is still open to debate in some senses because. I'll give you an example, right? So Netlify and kind of pushed by Next.js, right? Next.js had this thing called incremental static regeneration, right? Which is basically a fancy way of saying that you didn't, you didn't necessarily like build all your pages prior to deploying it. You built whatever pages you needed to, that are kind of your, like most traffic pages, and then you could actually somebody could hit a page that you hadn't built yet. And we say, oh, I haven't built this yet. I'm gonna show you a little kind of preview thing while I go off and I load the content. Then I load the content, show you the page. And from there on, everybody else after that would receive the static version of the page.
STEVE_EDWARDS: Well, that was sort of the Holy grail for a long time was incremental builds with the Jamstack side because otherwise you're rebuilding your entire site every time you have one little change, right?
BRIAN_RINALDI: Right, so yes, and this is where like we're flooded with terminology here. Incremental builds is a slightly different because that's happening, still happening locally, right? Like so, I don't have to rebuild the entire site every time. This one, it's happening when somebody hits your site.
STEVE_EDWARDS: Oh, on demand.
BRIAN_RINALDI: Like yeah, basically on demand page builds.
STEVE_EDWARDS: So that's sort of not Jamstack anymore, then that's sort of back to where you were, where you're rebuilding, you know, if you're doing a PHP site, then you're hitting your page. Oh, I gotta go to my database and neither get it from the cache. I mean, to get from the database or from the cache. So now we're sort of, the pendulum seems to be swinging wildly back and forth all the time.
BRIAN_RINALDI: It does blur the line because I mean, so, so just to kind of finish that story, like the NetLiveRFive release this distributed persistent rendering proposal, which is essentially same kind of thing. Like you hit a page, that page doesn't exist yet. We're going to go generate that page and then serve it up to you. So that sounds like, oh, that's server-side rendering except that from that point on, right, the page is actually now built, right? Like it's built, we generated it on demand that one time, but everybody else who subsequently sees that page sees the statically built version of that page as opposed, there is not like a server-side rendering going on.
DAN_SHAPPIR: So I have to ask, and I'll explain in a second why I have to ask, but I have to ask, would you define this as JAMstack? This type of a behavior. Dynamic generation on demand, first time on demand. And by the way, I could even theoretically take it a step further and say that if there's an outdated version, I'll provide that on the first request, generate the data, the next, the updated version of the background and serve that the next time that somebody asked for that. So I could theoretically make it a step further, but without going into all these technicalities this dynamic generation on first request. Would that be, because I was reading the intro to your book, well, not exactly the intro, the chapter of what is JAMstack, what is the JAMstack. And according to the definition that was given there, this is not JAMstack.
BRIAN_RINALDI: I have to go back and look at my definition that I gave there, but I would say that this is JAMstack. We are still generating you basically, everything is still being pre-rendered as we like to say, in the case of, there's just certain pages are being on, like basically on demand pre-renders. This is a solution for like super large sites, right? Like you have hundreds of thousands of pages that build could take a long time, right? So if you have that many, most of those pages aren't necessarily traffic all the time. So I could, if it's a page that doesn't get a lot of traffic, I don't build that at the initial build time I build that when, when it gets first requested and serve that up to you, but, but it's still built. And that's why I like the Netlify made this distributed persistent rendering proposal because you still get the atomic builds and things like that, which, which means I can easily roll back and stuff like that. And I, and so you're not losing like those kinds of key benefits of, of the deploying a Jamstack site while you still allow for pages to be rendered on demand. This is a one-time on demand thing. It doesn't go back and say, Oh, this is out of date. I'm going to go rerender this. You can do that. You can build that. But I would say that's, that really starts to move towards a, a fully server-side rendered application, not a Jamstack application. That's where like my, the whole point of this is it is getting a little bit blurrier, those lines between what's. What's server-side rendered and what's Jamstack starts to get a little bit blurrier than it used to be. I think for very good reasons, these are all amazing technologies that are actually going to benefit developers enormously in the long run, but it's, it starts to blur that, that meaning.
DAN_SHAPPIR: So the reason that I said that, that this definition was so interesting for me in this particular scenario is that I actually work at Wix and interestingly enough. While Wix is not built on any of the quote unquote standard or gem stack solutions or implementations that are out there, we actually utilize exactly that flow that you just described. That means that for any page that is suitable for static rendering, which is the vast majority of our pages, of the pages of the sites that are hosted on the Wix platform, we actually do exactly what you described. It's not rendered until it's hit for the first time, but then when it is rendered, it is then pushed into the CDN so that from that point on, it's statically served from the CDN. And it's not removed from the CDN until the site owner actually, let's say publishes a new version of the site or changes that page or whatever.
BRIAN_RINALDI: You're basically doing exactly that. That's exactly the proposal.
DAN_SHAPPIR: Yeah. And to be fair, we were very much so, like I said, we are not built on top of any of the standard JAMstack platforms that are out there, but we definitely were influenced and intentionally so by the JAMstack architecture and approach because it's, it's just an approach that makes so much sense in so many scenarios.
BRIAN_RINALDI: Right. And, and I would say in many respects, it sounds like obviously, I don't know all the details, but it sounds like you are effectively doing a jam stack approach, particularly if you align it with this distributed persistent rendering or incremental static regeneration stuff. Because okay, I think in the end, my definition also includes a static site generator, but in many ways it sounds like what you've built is kind of almost like your custom static site generator. So it's not-
DAN_SHAPPIR: It's exactly that.
BRIAN_RINALDI: Yeah. In terms of my definition, I don't personally think you have to use one of the static site generators out there. Like, you don't have to use Gatsby or Next or Hugo or whatever. Many people, I mean, we have like 470 static site generators out there because everybody likes to build their own because it's something you can build on your own. So I think a custom static site generator that you built yourself still ends up falling under kind of the jam stack umbrella. But I am also I personally like to define it somewhat narrowly, but I also, like I, I, some people say like they don't care if you use a static site generator and I'm like, no, I think static site generator is part of the process. Um, I think you have to deploy to a CDN, which you're doing there, right? That's part of the process. I think that, you know, the, the CI CD workflow that we're used to, kind of like the Netlify Versaill workflow where you just push it into a repo and it gets pushed up. More or less sounds like you have something along those lines. I mean, I think those are critical pieces as well. So like, honestly, you fit my definition of jam stack based on what I know.
CHARLES MAX_WOOD: Well, there we go. Wix's jam stack. Sweet.
DAN_SHAPPIR: Yeah. Ish is the term because, because there are definitely, there are definitely pages. No, I'm on the contrary. I'm actually one of the people who was primarily pushing towards the JAMstack approach at Wix. I'm not the only one, but I was a big proponent of it because I come very much from a performance side of the technology. My role at Wix is the performance tech lead and one of the main benefits, you know, again, you listed three benefits, which I think, or three or four benefits, which are of JAMstack, which I think are worth repeating. But one of them is definitely performance because obviously serving up a static content is much faster than serving up, then creating and then serving dynamic content and also being able to serve from a CDN, which means that you're much closer to the end point also results in significant performance improvements. And we've seen it because we have, we had changed our architecture from not being as JAMstack-like as is appropriate for us. And one of those things was exactly serving content, not from our servers as much as possible, but from CDN. And for example, so I'll take a very concrete example. We have a lot of customers in Australia. Our servers, our data center in the far East is located in Japan. So if you have to go all the way to the data center, then you have to go all the way from Australia to Japan through all the relevant hops. But if you're deploying it to a CDN, well, the CDN will have its own servers or proxy servers, whatever you want to call them in Australia. So the content is served via far fewer hops and the results is a dramatic improvement in terms of the performance that you see.
BRIAN_RINALDI: Yeah, yeah, exactly, exactly that. So, so yeah, you, I guess are doing customize Jamstack version of Jamstack that suits Wix. And I think, you know what, I also feel like, like while it's important because Jamstack is more of a architecture or methodology, right? To clarify what that definition is, I don't think we need to be like so rigid. I mean, I think I've written posts about this kind of stuff. Like for instance, using Next.js today, you could actually say, okay, all of, most of my site is statically generated, but I'm gonna pick these routes because these couple of routes actually need to be server-side rendered, and those are server-side rendered, right? And you could actually do that, even deploy it on, you could obviously deploy it on Vercel, but you couldn't even now deploy it on Netlify, and like, and it will work, is that Jamstack? You now have most of the site that is pre-rendered, but a couple of, you know, a couple of routes are our server-side rendered. So again, blurring that line a little bit, I, to me that, that's still generally qualifies as Jamstack. I mean, you have a couple of server-side rendered roots, but it's, it's mostly pre-rendered. So that's why I kind of say, like, I like to call it static first, but not static only, meaning like there you're, you're not limited to like, okay, I have to pre-render everything and, and not serve up content you know, that I, you know, not have that flexibility to meet the needs of, of more complex applications. I think if we kind of start having those debates, it gets a little silly to me.
CHARLES MAX_WOOD: Yeah. What, one thing that it's kind of struck me over the years is I've looked at JAMstack is that a lot of the focus, and you can tell me if I'm totally missing the boat here, but a lot of the focus seems to be on just simplifying your technology choices, right? So and then a lot of that just boils down to not having a backend that you have to manage, right? There's always a backend, right? There's Firebase or a GraphQL server or something, right? Something that you're hitting. That's the API part of Jam. But whether you throw out Jam or not, but there's something there, right?
BRIAN_RINALDI: Yes.
CHARLES MAX_WOOD: And then where it's rendered or how it's rendered or all that stuff, you know, we can argue all day about that, but yeah, but it simplifies that choice, right? Because I don't have to go right that backend. I can go use something that's out there. And then I can I can set up the rendering pieces, you know, whether it's next JS rendering it when I hit it first or rendering it every time I hit it or, you know, doing something else or some of these other technologies working in a similar way or just pulling the information out of the database and kind of doing a lot of this on the fly.
BRIAN_RINALDI: Yeah. It Jamstack definitely Jamstack developers definitely favor using services kind of like, oh, what'd she say? Like basically using tools that are very specialized for certain things. So like, if we're doing authorization and, you know, we're gonna use tools like Auth0 or Netlify identity or whatever, right? Because like we generally favor not building those things yourself where you have to, that way you don't have the whole infrastructure in the back of the backend that I used to develop those things years ago. And I mean, I remember building them repeatedly over and over again and the difficulties of maintaining them and you know, and then, and dealing with like, like for authorization, dealing with, with all the complexities of security for something like that. And this is long before GDPR and things like it's, it's not an easy thing to do. So we tend to favor those kinds of tools for that. Like I, you know, I built sites using either Auth0 or Netlify identity for authorization, using Algolia for search, using tools like Sanity or Contentful for my content. It simplifies things in some ways, right? Because there is no backend that you're having to maintain in those cases. It complicates things in other senses because now I'm constantly kind of connecting to different APIs. And I always like to say like every API has a learning curve, right? So So you have to kind of constantly be adding that learning curve and figuring out how I use that API and then how do I use that API to like, okay, now I've got your authorization, but I want to get only get the content that you're authorized to see, so now I kind of have to mesh those two together. It adds a little bit of complexity.
DAN_SHAPPIR: Yeah, but correct me if I'm wrong, but it's, you might say that the very existence of all these APIs is what kind of what you know, kickstarted JAM stack in a way. I mean, if you're pulling API together, that's like a basic tenant of JAM stack, isn't it?
BRIAN_RINALDI: Yeah, absolutely, absolutely. That's, you're right. Because before that, before these kind of tools and services, we were doing just static sites. It really was a tool for building blogs and simple sites that really didn't have much in the way of dynamic content. And I've been doing this since 2013. And that's kind of where we we were at the time, I'd say like back then the extent of dynamic content was I might pull in like discuss, which would load, you know, like basically put a widget and it would load content that was dynamic. But it really, what didn't, it wasn't a great solution. And now you have all these APIs that really turn these sites where when I wrote the first book with Ray, it was, I had my list of things like okay, what can you not do with it? Should you not do with the jam stack? And it was a fairly extensive list. It was like, you know, I would say it was easier to describe what you should do with the jam stack than what you shouldn't because the list was relatively small. And then for this book, it flipped and the things you couldn't do with the jam stack suddenly became very, very few things that I'd say, Oh, and even those I'm like, well, you could do it. It's just, is it worthwhile to do it in the jam stack or
DAN_SHAPPIR: Yeah, exactly. I was about to ask whether it's couldn't do or shouldn't do.
BRIAN_RINALDI: Yes, exactly. That becomes the, that becomes a question now, whereas before it was like, we couldn't do it now it's like, okay, you can do it. The question is like, is that the better way to solve this problem? Cause I, while I, I love the jam stack and I'm proponent of it, it's, it's not necessarily, not every site needs to use it.
DAN_SHAPPIR: When I was thinking about it and I was trying to think to myself when I wouldn't use JAM stack. The one thing that kind of came to my mind, and I'm interested in your opinion on that, is that if the main content on the main page is highly dynamic, then it probably shouldn't be JAMstack.
CHARLES MAX_WOOD: Yeah. Hang on just a sec, because I have just a little bit of clarification on this point for Dan. Some of the applications that I built, the main content on the main page is marketing and so it probably will be static. But if I'm working on like an application where it has, it's meant to be interactive in specific ways, is that what you're talking about, Dan?
DAN_SHAPPIR: Well, not necessarily. I'm thinking potentially even along the lines of something like a CNN where the main page is full of highly dynamic breaking stories from all over that you kind of need to put pulled together and it literally potentially changes like every second. Oh yeah. Or if it's like a stock ticker or, and, and the stock, uh, and a stock graph or a real time stock graph or something like that, I don't know, it could be the gem, a gem stack. I mean, I I've seen, I've seen example where people just, just to show that they could literally build a JAM stack site that updated every second. But if the site starts getting big enough, and again, and the main page is dynamic enough, it seems that it's again, it's a question of can you do it? Well, probably you can, but should you do it? Well, probably, no, there's a good chance that you shouldn't. That's my feeling anyway.
CHARLES MAX_WOOD: Okay.
BRIAN_RINALDI: Yeah, I think in general, I would agree with you. I think, like you said, you could do it. If I was tackling something like say, like a New York Times or CNN, I mean, I'd say I'd look at, there are portions of the page that change pretty quick, pretty often, and then there are portions of the page that change with kind of throughout the day, like maybe a few times a day. So like they'll have a headline story that sits there as a headline for quite a long time, but then they'll have like other top stories that kind of cycle in. So you might be able to do that where you dynamically generate the pieces that are going to stay this, I mean, sorry, statically generate those pieces that might remain the same without changing like minute by minute. And then pulling the other pieces. So is it possible? Yes. Would I recommend it? I don't, it depends. I mean, some of these sites like you said, like CNN or New York times or whatever are changing. Just so consistently you're basically in a cycle where you never stop rebuilding, which is essentially becomes a kind of, again, blurring the line between what service I rendered when you're, when your build process is running all the time. Are you just not server-side rendering? So, or like for instance, if your site is primarily user generated content, user generated content can like, you can deal with it, but, but are you going to see the benefits of Jamstack when I'm, when I'm mostly just loading content on the client, right. And what you're getting, what my Jamstack site, you know, portion this, the pre rendered part is a shell that fit, that fills, that is filled with stuff that's pulled from the client. That's That to me is like, okay, it's, yeah, I mean, that might technically fit the definition, but you're kind of maybe not seeing the benefits because all the stuff is being pulled on the client. You might be better off going with a different architecture.
Are you ready for core web vitals? Fortunately, Raygun can help. These modern performance metrics play an important role in determining the health of your website, which is why Raygun has baked them directly into their real user monitoring tools. Now you can see your core web vital scores are trending across your entire website in real time and drill into individual pages to focus your efforts on the biggest performance gains. Unlike traditional tools, Raygun surfaces real user data, not synthetic, giving you greater insights and control. Filter your score by timeframe, browser, device, geo location, whatever matters to you most. And what makes Raygun truly unique is the level of detail it provides so you can take action. Quickly identify and resolve front end performance issues with full waterfall breakdowns, user session data instance level diagnostics of every page request, and a whole lot more. Visit raygun.com today and take control of your core web vitals. Plans start from as little as $8 per month. That's raygun.com for your free 14-day trial.
DAN_SHAPPIR: Yeah, and another thing that you might need to consider when you're really intermixing content coming down from the server and dynamic content that's retrieved from the client is how to do layout, layouting both efficiently in a way that's nice from a user experience perspective. I mean, if you need to start injecting dynamic content in between static content, you don't want things to shift all over the place as you're loading the page or updating the page or whatever. They even have a term for it now, it's a CLS, it's cumulative layout shift. It's one of the Google's core vitals, one of the things that you need to try to minimize or mitigate.
BRIAN_RINALDI: Oh yeah, I mean, but I, it's something I see not, it's not particular to jamstack sites, right? Like this is something I see constantly. Speaking of some of those new sites, I know on a daily basis, I'm like clicking, I tap my finger on, on some, on the story I want to read. And by the time it registers that tap, the window has shifted and I click on the wrong story.
DAN_SHAPPIR: Yeah. For more often than not, it has to do with the, with ads where the size of the ad is, is, is just determined like page load time. And then it shifts stuff. But what I was trying to say is you were giving the example of, let's say a CNN homepage where you, you maybe bring the, the top story and some of the other stories, you bring them from the server, but then you need to stick in between dynamic content. Then you need to think about how to leave enough space as it were so that things don't need to shift around too much. It becomes an interesting challenge. Let's put it this way.
BRIAN_RINALDI: Yeah. Yeah, none of these problems are simple.
DAN_SHAPPIR: I do have another question for you.
BRIAN_RINALDI: Sure.
DAN_SHAPPIR: So there's this whole concept of a multi-page applications and single page applications. When I build a JAMstack site, is it like orthogonal to that or does it kind of necessitate one of these approaches or is it more in line with one of these approaches? What's your take on that?
BRIAN_RINALDI: So my take is I do both, basically, depending on the type of site. So as an example, I run this site, which is run, we do a bunch of developer events and stuff like that every couple of weeks. And that has a lot of pages, but the functionality is relatively simple. It does have like login and and other kinds of dynamic pieces, but the functionality didn't, the UI functionality didn't require a front-end frame, in my opinion. So I didn't add one and I use Hugo there. And that's actually, that one is not a single page application. Hugo just generates, it's more of a traditional stack site generator where it's generating a bunch of pages. And all of that dynamic functionality is just plain old JavaScript that I wrote. Whereas like some of the work sites I do. We do have more complex UI functionality that would benefit from say react. So, so I use something like next JS is usually my alternative when I have to use a front end framework using next JS and, and it would be a single page application. Right. So I think that that was part of the confusion of the jam because I, especially the leading with the J with the JavaScript, I met so many people who tell me like, oh, well. Cause Jamstack it requires like react, right? And it's, or, you know, or view it's like, no, no, it doesn't actually like, in fact, tools like the Qgo or Jekyll or 11 is a really popular one, even though it's JavaScript, right? It is more traditional static site generator. They don't, they don't force a front end framework on you. And I think both approaches are important because a lot of, I think we and then I make a statement that might get me in trouble. I think we over rely on, on JavaScript front end frameworks in many cases and so like, you know, a lot of these problems could be solved without it. And so tools like those are important to really some of those key benefits of Jamstack is you talked about performance, but performance isn't necessarily completely baked in. You can write a Jamstack application that has way too much JavaScript going on that in the end is actually still not very perform, you know, the performance is pretty lousy for the client. And in fact, I know, cause I I've done that. So, um, uh, not intentionally, of course, but, but I've done these things where like, you know, it's loading a JavaScript bundle that's way too large. And so it's jamstack, but the performance is kind of lousy. And, and so, uh,
DAN_SHAPPIR: so a few questions, like follow up questions so if I'm using React, for example, on the backend, or be it Vue, whatever other JavaScript framework, and I'm using it statically, that means that I don't generate the site on demand. It's not SSR. It is static site generation. But then I'm adding the interactivity on the client side. Does it mean that I need to hydrate the entire page in these types of scenarios?
BRIAN_RINALDI: No.
DAN_SHAPPIR: What would be the normal architecture here? And kind of related to that, if I'm doing a single page application and I need to implement the rendering logic for page number two, three, four on the client side, because client-side navigation, because page navigations in the SBA happen on the client side, doesn't it mean that I kind of need to duplicate the page generation logic, even though I may be using react on both sides, on the server side and the client side, it's not exactly the same because here it isn't SSR exactly, it's static side generation and on the client side, it's client-side generation and I'm kind of confused on that. So it's kind of two questions but kind of rolled into one, I guess.
BRIAN_RINALDI: Okay, so let me tackle that. You don't need to hydrate the whole page entirely. Mostly if a lot of the times you're pulling content, you're only replacing out the pieces that are dynamic, but tools like say Next.js, which has like built in, like it has the link tag, which will load that stuff if, if it's, if it's pre-rendered already, it'll load it from the static files basically. So, so it's not like it's going back to the server and getting this, this data, even though it may only replace the content piece of your page, right? So you can do both. The tools are built for doing, kind of allowing you to pre-generate these things without necessarily losing the benefits of pre-rendering everything. So that would be, I guess, I don't know if that answers your question, but that would be my answer, I think, if I understood your question correctly.
DAN_SHAPPIR: Well, when you're looking at hydration, then there are two aspects. One is, like you mentioned, going potentially having to go back and retrieve the data. And you're saying, if I understand correctly, that at least some of the static side generation Next.js, for example, can actually package the data, as it were, into the HTML itself so that once you've got the HTML or you also have the data, or at least the links to the data, and you don't need to do some sort of like repeat of your database query or whatever.
BRIAN_RINALDI: Right.
DAN_SHAPPIR: But the other aspect of iteration is that you're actually having to essentially kind of re-render the entire front end in the client side in order to wire up all the interactions. Now, obviously, the fact that frameworks like React have reconciliation means that you're not actually going to update the DOM, the browser DOM itself. But if your virtual DOM is big enough, then even just plain old hydration can be a non-trivial computational task. So, so that's potentially another thing that you might want to watch out for. So if a lot of the page is actually static, and like you said, only a six, relatively small part of it is actually dynamic, then in an ideal world, I would somehow automatically want to hydrate only that dynamic part and treat the rest of the stuff as just static HTML received from the server, regardless of how it was rendered. Now, I'm not sufficiently familiar with the various technologies, so maybe they just do it for you, and everything is flowers and daisies and whatever, but I'm just curious.
BRIAN_RINALDI: Yeah, I don't know that I have a great answer because I don't know the inner workings of Next enough to know how it handles rehydrating smaller portions of the page. I do know, like I guess, I guess I don't have a particularly good answer to that question. I believe that what I've done with the tools, I'm able to basically hydrate only the portion of the page I need to and the performance has been great, but I couldn't tell you what's going on in the covers. It's, I mean, particularly think tools like, I don't claim to fully understand React honest even though
DAN_SHAPPIR: I don't think anybody does maybe Dan Abramov, more or less Dan Abramov and that's it I think.
BRIAN_RINALDI: Yeah so yeah so so it may be that that you're right and some of the some of it some of the tools may end up rehydrating more than you need to or reloading portions of the DOM that that don't need to be reloaded but I can't tell you for sure.
CHARLES MAX_WOOD: We're kind of getting toward the end of our scheduled time I do have one more question though. And this is something that you brought up before we got started. You mentioned that like Netlify had some new rendering tool engine thing.
BRIAN_RINALDI: The distributed version of the rendering, yeah.
CHARLES MAX_WOOD: Right, but I'm gonna ask a more broad question and give you like 10 minutes to answer it. And that is what big exciting things are coming with Jamstack? Cause you mentioned that it's changing a lot. And so, yeah, talk about this rendering thing with Netlify, but talk about the other kind of broader things that the Jamstack nerds that are, you know, paying attention to this area in particular are going, Oh, wow. You know, and then they see the next thing they go, Oh, wow. And then they're like, yeah. Right.
BRIAN_RINALDI: Well, I think we did touch on a lot of them. I think some of the things we've seen is, is that that particularly tools like, like the gaspys and the next day as nox are I mean, part of the problem with those tools was that they were particularly kind of slow at generating sites. So like if you had a simple site, it was great. But then as your site got more complex, they were slow. And I think it was Steve who mentioned about how the incremental builds. I think we've seen dramatic improvements on those tools and how fast that they build. Then there's then there is things like incremental static regeneration and or DPR, which is Netlify's distributed persistent rendering, which is like being able to render pages on demand, pre-render pages on demand, um, without having to build them all at once, which I think opens up Jamstack to a whole range of sites that, that it used to be kind of complicated for like, for instance, I think Jamstack is great for e-commerce and we have a lot of really great e-commerce tools and headless, um, headless e-commerce tools that are that make it a really good solution. But if you have a big product catalog, generating that at build time would have taken, could have taken like 10, 15 minutes of potential, depending on what tool you use and that this solves that problem. And now it's like, okay, we can do this. And it still works for us. So I think those things are really exciting that in you're starting to see. That all that move into more, a lot of this was driven by next JS, honestly, those that those, some of those things in particular, and, and you're seeing that now move into other tools. Like I know I've, at least I've been told that Nuxt for instance, is going to have, have things like, like the incremental stack regeneration. I don't know what they're going to call it if, if it'll be distributed person rendering or incremental stack regeneration. I'm too much terminology, honestly, but that will be coming and there's a new version of Nuxt coming that's going to have a lot of really cool features. There's, I've seen Zach Letterman talking about 11D cloud, which I don't know what he's going to call it either, but it's going to be, it's going to have a lot of those kinds of things that allow you to have the flexibility to pre-generate things that initially at build time, generate things later to start to really think about when something needs to be rendered, does it need to be rendered right when you build it? Doesn't it need to be kind of be rendered initially on demand or doesn't need to be rendered on the client. Right. And I think that's one of those key things that that's tough about moving into Jamstack is thinking about. I was used to like building server-side rendered applications and it would be, well, everything is rendered when the request is made, it gets rendered on the server and sent back. But when you get into Jamstack, it's like, especially now we're starting to say like, okay, where, at which stage do we need to render this part of the page or this page entirely? And it's...It makes it a little bit more complicated, but it makes it a much more flexible solution for a much broader set of sites on the web.
DAN_SHAPPIR: From my perspective, this complication is a sign of maturity. It means that you're growing to handle more diverse use cases.
BRIAN_RINALDI: Absolutely. 100% agree. I've made the same case.
CHARLES MAX_WOOD: Well, what's interesting too is that we've seen this with a lot of these other areas software development and with JavaScript is that we see it kind of do this, right? So think of like the framework revolution that happened, you know, and we had like knockout and then angular and then, I mean, we had like a zillion of them, right? And then things kind of came back around and kind of coalesced around a few ideas that really simplified things. And so it'll be interesting to see just where, what things we optimize for as we begin to solve some of these problems and realize, oh, there's a really elegant solution to this part of it. And now there's a really elegant solution to this piece of it. And now, okay, now if we kind of put these, this and this and this together in this framework, we come up with a really nice way to make a lot of these problems go away. Yeah, that's a really good analogy because I think, you know, there was a period in JavaScript, I remember where it felt like there was a new framework, every single every single day and things had gotten inordinately complex and you're like this, it felt like this was going to go on indefinitely. We're going to kind of constantly having to learn new frameworks and new tools. And, and I think we, things did settle and coalesce.
DAN_SHAPPIR: Actually, I think, I think it's actually going on. It's just that we're not paying as much attention anymore,
BRIAN_RINALDI: but that's possible too. But to, to, to Charles larger point is, you know, I think that that we're in kind of this period where things have for JAMstack where things have gotten a little bit complex and confusing. I will admit, I still think the benefits are worth, are worth it, but I do agree. I think we're starting to kind of coalesce around some solutions to these problems and the tooling will continue to improve and, and we will see this, this become a much easier solution. Particularly, I think one of the things we struggle with is, is. It's getting, helping people get started. So it's a tough thing to jump into because there's not easy, obvious paths. And I think that we'll see that improve. I think the whole experience, particularly for new developers will improve dramatically over the next year.
CHARLES MAX_WOOD: Yeah, that's, that's true too. I had thought as much about that, but I mean, if you're getting into front-end development, yeah, you're typically going to pick up, I mean, one of three frameworks, right, or JQuery, I guess, cause it's just kind of been around forever. But yeah, you know, you may wind up seeing the same thing with Jamstack and not just because even within like a next or a Gatsby or a Nuxt or what's the one for Angular Scully or some of these other ones that are out there that kind of take a different approach to it. There are different approaches to each of those in turn within them, depending on what you want to do. And so yeah a lot of that's going to coalesce too. Okay. Here's kind of the basic path in, and now you can go down one of these roads, depending on where you're headed.
BRIAN_RINALDI: Yep. Definitely.
CHARLES MAX_WOOD: Very cool. Well, if people want to, I don't know, pick up your book, do you have a recommendation for that?
BRIAN_RINALDI: So, yeah. So the book is out through Manning. It's, it's currently I'm finishing. I, I owe two more chapters and then I'm done. Ray for, you know, has been kind enough to actually finish his part. I'm the one who's behind Um, but it's available through Manning's early access program. So basically you can get all the chapters that we've written so far are available digitally. So you can purchase that and then you get the full book, obviously, when the full book is complete, the book itself should be out this fall. And, you know, I also do the Jamstack newsletter, which is Jamstack.email. If people are into Jamstack and want to keep up with all of these changes and everything that's going on, I would highly recommend subscribing to that.
CHARLES MAX_WOOD: Awesome. And we have a coupon code for that. I'm trying to find it. We'll make sure it winds up in the show notes. Where do people find you online if they want to just follow you on Twitter or whatever?
BRIAN_RINALDI: Yeah. So I'm on Twitter at remote synth and my DMs are open and I'm always talking not just Jamstack, but a lot of Jamstack happy to answer people's questions on the topic and we're just chat about it. So feel free to reach out.
CHARLES MAX_WOOD: Awesome. And the coupon code by the way is podjsjabber19. Guess what year we got that coupon code at? It gets you 40% off. But yeah.
BRIAN_RINALDI: Yeah. Yeah, we'll have to keep, we have to get you an updated code, I guess.
CHARLES MAX_WOOD: Yeah. Well, if we get an updated code, I bet you'll all be able to guess what it is. Anyway.
BRIAN_RINALDI: Exactly.
CHARLES MAX_WOOD: But let's go ahead and do some picks.
I remember working my tail off to become a senior developer. I read every book I could get my hands on. I went to any conference I could and watched the videos about the things that I thought I needed to learn. And eventually I got that senior developer job. And then I realized that the rest of my career looked just like where I was now. I mean, where was the rush I got from learning? What was I supposed to do to keep growing? And then I found it. I got the chance to mentor some developers. I started a podcast and helped many more developers. I did screencasts and helped even more developers. I kind of became a dev hero. And now I want to help you become one too. And if you're looking forward to something more than doing the same thing at a different job three years from now, then join the dev heroes accelerator. I'll walk you through the process of building and growing a following and finding people that you can uniquely help as you build the next stage of your career. You can learn more at devherosexcelerator.com.
CHARLES MAX_WOOD: Steve, you want to start us off with picks?
STEVE_EDWARDS: Yeah, see, so I'll start out with the usual dad jokes for the day. Thanks for the week. From my good old buddy.
CHARLES MAX_WOOD: I've been practicing my groan all week.
STEVE_EDWARDS: Oh good, be ready to pull it out. So what's the difference between a camera and a foot? Oh, oh wait. A camera has photos while a foot has five toes. And then. Oh. What's made of leather and sounds like a sneeze, a shoe. But, you know, for me, that brings back memories of anybody's ever seen the mill. Oh my gosh. I can't believe I'm Robin had men and tights. One of the great classic movies of all kind of Mel Brooks. Yeah, there we go. You know, he's got the scene with the rabbi who goes around giving circumcisions two for one. But there's a scene, Dave Chappelle's in there and his name is a sneeze and his dad's name is a shoe, you know, and so they play off that on quite a bit too.
DAN_SHAPPIR: So I have to say that my favorite Mel Brooks movie by far, there are a couple, I mean, I love Blazing Saddles and Spaceballs is obviously great, but my favorite by far-
CHARLES MAX_WOOD: You passed over Spaceballs?
DAN_SHAPPIR: No, I said, I said Blazing Saddles and Spaceballs.
CHARLES MAX_WOOD: I know, but it's not your favorite.
DAN_SHAPPIR: So my favorite is the producers.
STEVE_EDWARDS: That's one I've never seen.
DAN_SHAPPIR: The original one, not the remake.
BRIAN_RINALDI: Yeah, I will admit I haven't seen that one either. My favorite would have been Blazing Saddles.
STEVE_EDWARDS: Oh, yeah. Well, there's this one. What's funny is that my kids' school, they have a thing that they do at one week during the year called Candy Grams where you can, you know, buy a little candy thing and little ice cream. So, of course, the first thing that comes to my mind every time I hear that is Candy Gram from Mongo, Candy Gram from Mongo.
DAN_SHAPPIR: Yeah, yeah, no, no, but but yeah, no, there's also for the crazy history of the world and there are some of the world part one. Yeah. Yeah, there are a couple of great ones. But for me, it has to be the producers. And if you haven't seen it, then you owe it to yourselves. And again, I'm talking about the original one with with Gene Wilder.
STEVE_EDWARDS: I'll definitely have to go see that. Yeah, I do love some little bricks.
CHARLES MAX_WOOD: Well, Gene Wilder is amazing. Anyway, that's all I got derailed Steve.
STEVE_EDWARDS: Oh, no, no, I just think of it as an enhanced discussion more than anything.
CHARLES MAX_WOOD: So awesome. All right, Dan, what are your picks?
DAN_SHAPPIR: Well, I came in with, with essentially no picks, but I was kind of saved by the bell by Brian himself, because in preparation for our conversation today, I was actually, you know, looking through the background material and I got to the Manning site and I read the chapter in his book in the upcoming book about why JAMstack. So first thing I learned that I was, that I'm spelling JAMstack wrong. So, so thanks for that. Well, not spelling, capitalizing, I think would be the better term. So I learned that you're not supposed to capitalize the A and the M anymore. So I definitely learned something. And I still don't know if I should be saying JAMstack or the gemstack by the way. So which is it?
BRIAN_RINALDI: I'll have to, I'll have to address that. I think so. I use it I usually say the Jamfack, but I don't think there's a canonical way of saying it.
DAN_SHAPPIR: So anyway, like I said in our conversation before the show, I really enjoyed reading your book.