The Jamstack Book: Begin Book Club

Transcript

[00:00:00] Simon MacDonald: Awesome. Welcome everybody to the May edition of the Begin book club. Today we have two authors for the first time ever. We have Ray Camden and Brian Rinaldi, and we’ll be talking about the Jamstack book. but before we get started, I just want to remind everybody that this activity is covered by the Architect code of conduct.

[00:00:21] So please be nice to everybody. We’re going to be enforcing that code of conduct. So just don’t be jerks is really what I’m saying. Now I have known these two gentlemen for probably over a decade now. So they don’t really need an introduction to me, but let me give you a brief one. Ray Camden is the author of multiple books on web development, and he’s been blogging and presenting for almost 20 years now.

[00:00:45] And he works for a company, you know, I might not pronounce this correctly, it’s adhobley or adobo. I don’t know something, something like that. Maybe familiar to some of the people. And of course, Brian Rinaldi has been involved in static site and Jamstack developments since the early days. So what we’re really saying is it’s all his fault.

[00:01:04] So if you have any problems, just blame him. Ray is in the clear, and Brian works for LaunchDarkly right now. So thank you guys for showing up and, you know, just chewing the fat with us for an hour or so.

[00:01:17] Brian Rinaldi: Thank you for having us. Yup. Happy to see you again.

[00:01:21] Simon MacDonald: Yeah. Good to see you guys too. As it is tradition here now, and tradition means this is the third time we’ve done this, but it’s a tradition now. We kick it over to the authors for them to do a dramatic reading from their books.

[00:01:33] So I think maybe you have something prepared for this.

[00:01:38] Raymond Camden: Want me to go first, Brian?

[00:01:40] Brian Rinaldi: You go first? Yes, absolutely. All right.

[00:01:43] Raymond Camden: So, I have been in technical robotic in some aspect or another, for a couple years now, over 20 at least. And what I have found that has worked for me is to try to put myself into my writing.

[00:01:57] not always so much in technical docs, per se, but definitely in blog posts and articles and books. Try to put the human spirit into it. You know, I’m, I’m talking about what I’m feeling about a technology of what excites me and just translating that emotion about the technical aspects of what I did.

[00:02:17] And I think that has been successful for me. This particular book has been written over the last couple of years. And as you probably have heard, there’s been a couple of things going on. So, you know, there’s the things that everybody knows about. They’re saying this personally as well, and, there’s one particular aspect of this book that I think, I really let a lot of my heart and soul into, and I think it really translates to the text on the page.

[00:02:46] And I’m going to read a short, short part of it because I can only do a short part because I really do think I’ll get a bit choked up. I’m actually feeling it a little bit now, but this world with me. And so if that. I’m going to read and hopefully we have the same PDF here. from page 2 49, section A of the index,

[00:03:13] Raymond Camden: active class on page 34, add to cart functionality in jam store pages, one 12 to one 14

[00:03:24] Brian Rinaldi: admin

[00:03:25] Raymond Camden: comma editing content as.

[00:03:29] Pages 85 to 88,

[00:03:33] Ryan Bethel: all

[00:03:33] Raymond Camden: WP post query 2 24, Amazon S3 1 25, the 1 31 API based headless CMS is that, that, that was a hard part. 2 0 8 architecture Jamstack benefits of seven dash nine. Costs eight dash 9 4 7 security, seven eight, and finally, Azure static web apps, 1 33, the 1 38. I can’t go any more. Brian, please.

[00:04:09] Brian Rinaldi: I mean,

[00:04:10] Simon MacDonald: I just, I mean, I need a minute to kind of, yeah. Brian, if you, if you got, yeah, I don’t know how

[00:04:17] Brian Rinaldi: well, I don’t know. I don’t know how to follow that. My original idea was to have him read some of mine and I read some of his. I’m going to read. cause we each wrote, each chapter was written by one of the two of us and we’d never really collaborated cause I can’t really work with Ray.

[00:04:36] He’s really difficult. so I’m going to read from Ray’s chapter entitled building a basic Jamstack site. The first site we’re going to build in the Jamstack will be what has previously been referred to as a brochure where website in the past, this was used to describe websites that were nothing more than digital versions of a marketing brochure or the web is an incredibly powerful platform and enables powerful collaboration.

[00:05:14] Lots of powerful. Sometimes simple is all you need. There are multiple examples where one or two page site is more than satisfied. So that’s it. What do you think? Amen. Amen.

[00:05:30] Simon MacDonald: Awesome guys. Well, thank you so much for doing that. And I mean, Brian, you just brought up something that I wanted to ask you about anyway.

[00:05:37] And that’s is, what is it like to collaborate on a book with two authors? I think you already alluded to you folks were trading chapters, but if you guys can comment a little bit more on the writing process, I mean, that would be interesting for me personally.

[00:05:51] Brian Rinaldi: Yeah, sure. So this was the second time we wrote together.

[00:05:54] We wrote a book before we called the Jamstack or anything from the last time. Yeah. Well, you want a story about that day? I said, no. How many times Ray to do me this one once more than once. Yes. so, I clearly didn’t learn enough, I’d say. but we did the same thing as last time, which is just kind of, it was easiest to trade off chapters, especially because Ray and I have kind of complementary knowledge on the Jamstack tools.

[00:06:27] He uses tools, I don’t use, I use tools he doesn’t use. So it was kind of easy to like trade off, topics that were a bit more versed in. Right, Ray. I mean, yeah,

[00:06:41] Raymond Camden: Like almost all of my writing experience. and I’ve done like 20 books. almost every single one of them has been multi-author things. I think I have like one or two books where it’s just me.

[00:06:55] So my default way of doing this is either I’m told what chapters I’m doing, which happens sometimes. or I work with the other authors and we split things up. I’m working on a book now for Vue.js 3 and it’s me and one other author. Going into it. We had the book split in half. I’m working on mine every now and then I have to reach out and say, Hey, when you talk about X, so I know I referenced it correctly.

[00:07:19] and outside of that, you know, as long as you follow the publisher’s rules, and they’re all particular about something, like if you have a figure, you must re reference it first, or he must reference it after. Can’t do it before, after once you do, then you could kind of write as you see fit.

[00:07:39] Anyway, they’re not really hardcore about having the exact same voice, which is, which is good.

[00:07:45] Brian Rinaldi: Yeah. First one, they actually put our names on our chapters so that, because we do have slightly different voices I’d say, well, probably more than slightly. It’s pretty obvious when you switched chapters.

[00:07:59] Like if you know us, you know who wrote, which one, which, O’Reilly dealt with by like, just allowing us to put, who wrote the chapter on it. I don’t think that happened this time. So people are just going to be confused by the change of voice.

[00:08:16] Simon MacDonald: I don’t think I saw particular names on each chapter, but I was fairly certain, I knew which ones were yours and which ones were Ray’s while I was reading it.

[00:08:25] But again, I’ve known you guys for a decade, so

[00:08:28] Brian Rinaldi: exactly. Yeah. I mean the higher quality chapters are mine. Pretty easy. Yeah. It’s like, this is a really good chapter. Oh, it must be Brian.

[00:08:42] Daniel Lauzon: Were there any others involved from, from the publishing house in the editing process, other than the guidelines that Ray mentioned?

[00:08:51] Brian Rinaldi: Oh God, there was like a, I think this was reviewed by, well, I don’t know if anybody’s left to buy the book because pretty much every developer out there apparently reviewed the book.

[00:09:03] Yeah. So

[00:09:04] Raymond Camden: Yeah, every publisher will be a bit different. This publisher had a lot of hands involved. the one for the Vue JS book tends to have one main person. So

[00:09:18] Daniel Lauzon: Are they helpful?

[00:09:23] Brian Rinaldi: Yes.

[00:09:28] Simon MacDonald: Well that’s better than one book I reviewed. I gave them all the feedback and none of it ever made it into the final edit. There were all sorts of errors in it. And I’m not gonna mention that publisher by name, but they’re out there.

[00:09:43] Brian Rinaldi: I’m pretty sure I know. I’m sure you do too.

[00:09:48] Simon MacDonald: Not giving them any air time.

[00:09:49] it’s funny. One of my, one of my favorite books is called Good Omens, which got turned into an Amazon Prime series and it was Terry Pratchett and Neil Gaiman, and they were doing the same thing. They were trading chapters back and forth, but they were purposely trying to write each other into an impossible situation to get out of for each chapter as they passed it back and forth.

[00:10:10] You guys ever think of doing something like that?

[00:10:16] Brian Rinaldi: If we decide to do another book Ray, we’ll have to do that. yeah. I’ll give Ray all the chapters about React. He will love it.

[00:10:29] Raymond Camden: Oh, no.

[00:10:30] Simon MacDonald: Yeah, that would, that would be an interesting one. It’s like, get the person with the least domain knowledge to write the chapter about it and just trade it back and forth so you can equally be angry about things.

[00:10:41] Folks if you want to ask questions, just go ahead, don’t be shy. I do have some questions that I can fall back on if the, if the chat starts to malinger a little bit. Dan, is there anything that you want to bring up since you’re coming in from outside on this.

[00:11:01] Daniel Lauzon: Yeah. Um,

[00:11:08] Daniel Lauzon: no, that’s cool. and I’m just trying to think of what’s useful for, I have questions I’m curious about, but then I’m trying to think about the conversation. Well, the first obvious thing is, you have a wide selection of, you know, of, stacks let’s call them or, or technology choices. And it does have a progression because you are sort of not adding, but you know, trying to add other criteria in which.

[00:11:35] Sort of how we, we get to our choices typically, but, but was there another part of the process where you said, I need to cover these nine or these three? you know, why Eleventy, why not this? Why not that you know, how did you go about, did you just like these and wanted to have a certain representation, but didn’t really mind which ones made it down or so, yeah, just how to just like frame it for the frameworks, I guess.

[00:12:05] Raymond Camden: So this, this book is kind of a new version. Although the previous version, it was a different publisher and it was like five years or so ago

[00:12:16] Raymond Camden: and it goes to the us. So that’s why they lost a book. so I think our thinking back then was, you know, there, there there’s kind of standard types of sites that you would build with the Jamstack.

[00:12:29] so we went in with that idea as a good way to say, you know, obviously a couple of standard ideas. Brochure where a documentation site e-commerce whatever here, a good engine stat that work in there. and I think we both agreed that we wanted to show multiple engines. Like there there’s books out there that are like just Hugo, just Jekyll, etc.

[00:12:50] But we really wanted to let people see different ways of doing things. I know when I present on the Jamstack I focused on Eleventy because it’s my favorite, but I’m very, very clear to say, you know, I’m very opinionated and if you don’t like Eleventy, there’s 400 different options out there. So I think our main goal was to show different types of sites, different types of engines, to let you know that you can do more than just one type of thing with the Jamstack and you have multiple ways of doing more than one type of thing.

[00:13:18] That’s horrible.

[00:13:20] Brian Rinaldi: Yeah. And in each case, I mean, we kind of try to make the case of why. This tool for this particular site. but I think the other, the only other factor that I can recall, I mean, even the first time we discussed it, but like even this time was trying to give a range of approaches because, you know, like Hugo is a very traditional static site generator.

[00:13:48] It, it, it will not do anything really beyond generating static site, whereas like Eleventy actually kind of straddles the line between very traditional and you can do some less traditional stuff with it. Partly because it’s JavaScript based, partly because, and they’ll have things like Eleventy server lists and stuff like that to do, your SSR and things.

[00:14:16] And then, you know, and then of course Next.js because, well, I mean, it’s kind of. For better or worse, it has taken over the world, I guess. and, and I thought it was important to cover that, but also to cover, because there’re a lot of React based framework tools and I wanted to make sure recovered at least one.

[00:14:37] and I chose that one in part just because, because it’s the one you’re most likely to encounter the most likely to hear the most about.

[00:14:49] Daniel Lauzon: Thanks. I thought that for me personally, I thought this was the most fun part of the book is the fact that you covered so many and you know, I’ve been around, I’ve been around a while, too. Done things with all of these technologies before, and, you know, by the time I’m getting up to next year. So my current favorite, I just wanted to cry and, you know, it’s just like, what kind of a mess have we gotten ourselves into where there’s almost nothing you can carry from one of these, to the other, you know, templating and styling and just, just the basic setup and the build and the deployment.

[00:15:27] It’s just. Yeah, it’s just overwhelming and just seeing it all inside, but you know, three or four day read was just like, oh my God, any way out of this, is there any way that we can, you know, let’s give ourselves like another 10 years, will we ever converge where any of this gets this sort of just blessed forever.

[00:15:50] This is how we do X.

[00:15:53] Brian Rinaldi: That chapter was by far the hardest one to write, for, for me, because distilling next JS into a chapter is difficult. and teaching basic concepts about it, you know, without having to dive too deep into react is difficult. you know, and I, I agree with you. Like I use it.

[00:16:15] and I think Next.js has been uniquely innovative. In Jamstack. I mean, it was the first to kind of give you the option to do an SSR route and a static route in the same site. and then added things like incremental static regeneration, which everybody else copied. Which they gave a different name and different acronym.

[00:16:41] and then, you know, and even added in middleware for like edge rendering stuff. they were always kind of at, at the forefront of this stuff, but, but I also feel like the. You know, one of the reasons people love next year. Yes. Early on, I think it was React as complicated and Next.js has kind of simplified some of that, I think.

[00:17:04] and then especially, yeah, especially the routing, but now it’s becoming incredibly complicated, like just deciding where you’re going to render something and like it’s just incredibly complex. So. I’m personally, I didn’t, we didn’t get to cover in the book because a lot of this is very new, but I’ve been touring with things like felt kit and Astro, which feel a lot less cumbersome.

[00:17:31] you don’t have to deal with all the, like, you don’t get all the baggage of React, but you know, love it or hate it, I guess. Like, you know, some people love it. And one, all that baggage I personally. Don’t and would prefer to kind of leave it behind so you can use components. You can, you know, you can do a lot of the same kind of things you can do in a react based application.

[00:17:54] You just don’t have to use React.

[00:18:00] Simon MacDonald: Yeah, there’s a lot of things that you said in there that I want to take the conversation in three different directions, but I mean, Dan, you’ve been around long enough to know that if we have 13 competing standards and we decide that we want to create one holistic standard for everything, then we just have 14 competing standards.

[00:18:18] In technology we’re really good at reinventing the wheel over and over and over again. but yeah, one, one thing that you just were talking about, Brian, was the incremental builds type of thing. And this is question for you and or Ray. Obviously I know that Ray has a blog has been around for what, almost 20 years now, Ray 6,000 blog posts or so, when I was doing a developer documentation site, at a previous role, we started getting into issues where the build was taking forever, because of all the content that was getting added to things.

[00:18:56] and I know that you guys addressed this a little bit in chapter 10, but like, what are your recommendations for, you know, really slow builds in a Jamstack application.

[00:19:10] Raymond Camden: So for me, there’s been multiple things I’ve done over the years. First and foremost, when you’re working locally, every engine out there will allow you to ignore stuff. So I blanket ignore like 90% of my blog posts, which speeds up things for me. I only removed that if I needed to test archives or something like that.

[00:19:33] But for my day to day, I’m working with the local copy of my blog. That’s like 1% of what’s in production. other things that I’ve done, back when I first started out using Hugo and, I noticed somebody do a build and it would up, it would update the, change pages. And every time I would do a new blog post.

[00:19:57] Mentally I was saying, okay, the homepage is going to change because I have a list of blogs, bullets there, and then the new post will change, but everything was changing. What I, what, what, what I wasn’t thinking about was the fact that my layout showed the last five blog post thing, which is a kind of a common UI widget.

[00:20:16] So if I did a new blog post, every single blog post had to update. So I began to think about things like that and the things that would impact the entire site and trying to remove those. I also did things like loading it via Ajax. So I still got that nice widget, but I loaded it progressively, like. so I do guide kind of combination of that.

[00:20:41] I also don’t think about it as much. goes incredibly fast and it’s only gotten faster. Eleventy is incredibly fast. my build now of 6,500 or so pages, are about three minutes. And with CI/CD, I’m doing it in the background. I don’t care. I mean, it could take an hour. I don’t want it to take an hour, but it could take much longer.

[00:21:07] And it just magically copies over when it’s done. the only time that I’ve really bugged me, was when I had typo and I realized, oh, crap, I have to wait for two builds to go through. but certainly locally, look at what you could do to ignore the content you don’t need to in order to be productive.

[00:21:24] And if you’re worried about. You’re built, look at things that, with change every part of your site. I also got rid of things like archives, nobody goes through the blog archive, period. No one’s going through page 500 pages of pagination on every blog post. So I just got rid of that.

[00:21:46] Brian Rinaldi: Yeah. And I mean, all of that I think is really good advice.

[00:21:49] Ray’s obviously got a massive site. I think when you’re, I’m going to guess for a docs site you were using Gatsby?

[00:22:03] Simon MacDonald: Ray had 6,500 blog posts built in three minutes. It was like, I couldn’t get 20 pages built in four minutes. So yeah,

[00:22:09] Brian Rinaldi: I mean, so Gatsby had for a long time, a lot of problems with build times. I think it’s still, like if you’re of, if you, if you’re really concerned about that, if that’s a particular issue, then, you know, I would say avoid a lot of the JavaScript framework based tools, if you can.

[00:22:34] I mean, if you need. For your site then they tend to be much, much slower. that being said, Gatsby’s made a lot of improvements on that. and their builds are much, much faster now. They do incremental builds, I think, or something that basically they try to, to not, not, they don’t, re-render every portion of the page and reuse pieces that, you know, so that way, like it doesn’t do like what Ray said.

[00:23:05] If it doesn’t affect every single page, it’s not going to re-render every single page. It’s just going to, re-render the pieces that need re rendering. so that’s enormous in terms of improving the speed, and they’ve done other, other improvements. So it’s, it’s gotten a lot better. you, you mentioned, you asked about incremental static regeneration and things like that.

[00:23:26] basically what I call deferred rendering is another option, which whereby I set a page to basically only render when it gets called the first time. and then from there on it, it just, you know, it uses the statically rendered content, or you can set it to expire, but that’s next year, certainly at the moment.

[00:23:48] But anyway, so, you know, so that way you could say, okay, would rake and say, Hey, I only need like to render a hundred blog posts. And then after a hundred, just everything else. The older blog posts get rendered only the first time somebody actually tries to access them. and that will reduce your bill times traumatically as well.

[00:24:10] but you could also, if you know, for a doc site, this is why I mentioned Hugo for doc site 11 year or Hugo is probably the best bet. There’s very few reasons I can come up with. And I, and having maintained multiple dock sites built in, frameworks like next JS or, or Gatsby still doing so in some respect, I don’t understand why we need React for it.

[00:24:40] What does React do for a docs site? It’s static content. Like I don’t need, I don’t really need React for static content.

[00:24:47] Simon MacDonald: Yeah. I agree with you. We don’t need React for every site and the particular use case that I was talking about, we had a React framework to provide all of the widgets for all of our websites, we were kind of forced to use it.

[00:25:01] So then the natural choice at that point in time became Gatsby because it was doing SSG. And I think Next.jst, at that point in time, didn’t have SSG. It was only doing server-side rendering, right? So we had done like a 40, tool evaluation and Gatsby came out on top and it worked great at the very beginning when the content was small.

[00:25:22] But as the site got more popular and the content got bigger and bigger, that’s when the build times really started to crush us so much so that we had to split it up into multiple smaller projects that were all built individually. So if you know, author A changed some stuff on their side of the site, it would not affect all the other 15 or so authors.

[00:25:42] and then it would just all get combined into one S3 bucket. So yeah, this

[00:25:47] Brian Rinaldi: is what gets me really the. Th that a story like that gets me really excited about tools like Astro. Right. Cause, cause I can actually take an Astro site that I’m on and just say, I need certain widgets from React. Hey, just drop them in it.

[00:26:04] It knows how to use rec components. So like dropping your react components and like in just, you know, And the rest of the site all around that they’re using that islands, architecture, everything else is like, not necessarily, it could still be static. That widget is, is not, you know, you tell it to hydrate it basically differently.

[00:26:27] And, and then you. You know, you can still use your React. You can actually use React. You can use Vue, you can use any framework and you can even mix and match them on the same page, which isn’t really a good idea, but you can do it. so it’s, I think, you know, there’s the, the, the ecosystem is changing very fast and accommodating those kinds of needs.

[00:26:53] I think so.

[00:26:56] Simon MacDonald: imagine things changing fast and tech, that doesn’t sound right at all. And I don’t know, Taylor, do you want to unmute and make any comments on Astro as Taylor recently released a plugin for Astro and Architect to work together, to do server-side rendering. So that was pretty cool.

[00:27:12] Brian Rinaldi: Yeah, they, you’ve probably seen, they released like a, a beta test of

[00:27:18] Taylor Beseda: server-side rendering for us. I was always interested in the file format. So cool. Just having that dynamic, content at the top and then your markup and the content below that sort of,

[00:27:31] Brian Rinaldi: I

[00:27:32] Taylor Beseda: think it’s just like a front matter divider.

[00:27:35] so it always struck me as like the perfect file

[00:27:37] Brian Rinaldi: format for,

[00:27:38] Taylor Beseda: like small cloud functions and serverless rent type rendering. so I did get to experiment a bit with shoving it into.

[00:27:49] Brian Rinaldi: like you mentioned, you can put

[00:27:51] Taylor Beseda: whatever you want in there. It’s Svelte and Vue and React all along side each other.

[00:27:55] Not like you said, not the best idea, but it is really cool in theory. so I’m definitely keeping an eye on what they’re up to.

[00:28:05] Brian Rinaldi: that’s a really smart approach. Yeah. I’ve been, I’ve been really impressed by it. I mean, in the fact that, You know, what I like is, is, well, I don’t necessarily want to use react components or I want to just use components, but they have their Astro components.

[00:28:21] I could do everything kind of what feels like straight HTML and JavaScript, obviously in their format. Right. But like, it’s not, I’m not writing the JavaScript. It’s just plain old JavaScript not having to deal with hooks and things like that. so. I really like it so far. I mean, I haven’t built anything.

[00:28:44] I’m trying to rebuild my blog, actually using it right now. and you know, but I’ve done some smaller projects with it and been, been really impressed so far. So I’m curious to see how it goes. I also like Ray, you might like the way they handle things. 'cause, you can do some stuff in markdown, which you can’t do in traditional markdown, like using variables and dropping in components without even having to do anything special, no MDX or anything.

[00:29:15] It’s just, you know, just import you can even import, you know, you can import JavaScript modules at the top and then, you know, or components at the top and you’re in your front matter and just drop them in to your market.

[00:29:29] Raymond Camden: Oh, eleventy, by default persists, marked down with liquid as well. So you can mix liquid into markdown and you could change that to whatever else you want.

[00:29:39] So that, that sounds kind of familiar.

[00:29:42] Brian Rinaldi: It’s a little bit different, cause this is like I could write a react component or, or an Astro component. And I could just drop that in and use that inside the markdown. And it’ll render where I can use a variable, like I could say. Author is Ray in the front matter.

[00:30:01] And then I can actually use that variable in the markdown and have it placed automatically, lots of, lots of interesting things like that, but it’s just, it’s, it’s a little unique in the way it handles that stuff too, I think is very cool.

[00:30:17] Simon MacDonald: Yeah. Do you know of any of these tools that offer that kind of functionality with web components so that you can embed a web component directly in your markdown or?

[00:30:27] Raymond Camden:

[00:30:29] Brian Rinaldi: I don’t know,

[00:30:30] Raymond Camden: but it sounds like you want to know ones that would help you. I will say there are definitely options that don’t get in the way. And that’s one thing I like about Eleventy. It is famous for putting no restrictions on what you do with your generator output. So if you’re using web components to build something on the front end, you could use that with Eleventy.

[00:30:49] It won’t stop you. I, one of the reasons I stopped using Hugo and this was a few years ago to be fair, is because it was very restrictive and like what it outputs and it stopped me from, like, for example, I’m putting JSON, whereas Eleventy will be like, you offer whatever the heck you want and whatever weird made up HTML, I will let you do whatever you want.

[00:31:11] So if your tool doesn’t get in the way, it’s not one of these JavaScript frameworks, then you’re free to output it, use whatever.

[00:31:20] Brian Rinaldi: It does let you do that by the way, just to be clear, you just have to specify in the it’s. The only pain is you have to put into configuration that you want to be able to output JSON first.

[00:31:34] Yeah. but yeah, so I, I believe Astro has an example using, If I recall for web components, I can’t see why you couldn’t use lit for instance, within the lemony project. I don’t, I don’t know that anyone is, is specifically, using, like, trying to use, like has any built-in support for any of these things.

[00:32:00] It’s just, you could use it.

[00:32:04] Simon MacDonald: Yeah, I’m just always trying to think of a way to use the platform instead of pouring more JavaScript down the pipe into people’s browsers, because that’s a real problem that we have these days.

[00:32:17] Brian Rinaldi: Although, if this is static really rendering and you’re not pouring that any JavaScript down the right leg, this is just rendering component.

[00:32:25] Simon MacDonald: Yeah, theoretically, but, I’ve definitely seen some things where it’s a static site rendered, but then it ends up being a JSON file that is fetched, on the client side. And then it’s client side rendered. So you’re getting the worst of both worlds, basically.

[00:32:45] Brian Rinaldi: Yeah, it’s problematic, yeah.

[00:32:48] That’s those are always the framework ones, you know, so because they try to not, you know, one of the interesting things that a lot of these tools, levity, it’s felt kit, and have moved to like away from that single page app model to a multi page app portal, which I think is a good. Overall direction is one that I feel is better.

[00:33:15] I know Ray does too. I think that’s basically how you like to build your apps. You don’t need a single page app.

[00:33:21] Ryan Bethel: Yeah.

[00:33:23] Simon MacDonald: Yeah. I, I feel like that the three of us probably had a, somewhat of a larger than regular sized hand and popularizing single page applications back when we used to do a lot of web mobile development.

[00:33:36] So everybody, we’re sorry. I mean, multi page apps are great. Single page apps are great too, but. You know they’re great. When you want to make a website act and feel like a mobile application, but you don’t have to make everything a single page app. I mean this all. Okay. I’ll get off my soapbox now.

[00:33:53] Brian Rinaldi: Yeah, no, I like that. Soapbox stay on it.

[00:33:57] Simon MacDonald: All right. I’m back in. I have a question

[00:34:00] Ryan Bethel: maybe along those lines, like what, what do you, what do you think about the. The criticism sometimes against Jamstack is that it, if you start with a small site that is like an obvious fit for Jamstack. So in brochure site or simple blog and it, and it evolves and grows and you want to add to it, it’s like you, it seems like the pure jam stack as it grows, it, it encourages your site to just take the full jump to a single page app in order to, to add a lot

[00:34:39] Ryan Bethel: of what you want to, and it’s, there’s, it’s like you’re crossing a big chasm. Is that, is that a valid argument?

[00:34:51] Brian Rinaldi: I think part of that perception is because a lot of what popularized Jamstack over the past couple of years has been. Tools like Gatsby, like Next.js, which were single page app models for billing applications.

[00:35:12] and so, so yeah, that, that became what it became known as I I’ve, I’ve had to fight regularly with people, like not fight, fight, but like just argue like, Hey, you know that like the J doesn’t when it stands for JavaScript, it’s not JavaScript frameworks. That’s not what it wasn’t even, it wasn’t even Gatsby was the only framework based tool that was even out.

[00:35:39] And it was super, super early days when the term came out. I was like, this was about JavaScript on the client, for doing API calls and stuff, client side, not about a full JavaScript framework. but we, it became synonymous with JavaScript frameworks and, and, you know, I think. In my opinion, kind of the short term helped popularize it, but in the long term has kind of been, holding us back a little bit.

[00:36:11] but like I said, that that’s, I’d say particularly in the past year, that’s changing a lot, a lot of new tools to kind of ditch that approach although Next.js is still insanely popular. So, yeah.

[00:36:29] Raymond Camden: I’ll say that for me in my path I have avoided all those guys. all those options. I should say.

[00:36:36] I went from harp and JS to Hugo, to Jekyll to 11, eight. I used nuts a little bit, pretty much just for, a presentation, but in terms of my Jamstack things I’ve gone through, I’ve avoided the ones that are JS framework. So I get that they’re popular, but it’s, that’s not the way I Jamstack. and it’s, to me, I, I’m just turned off by the idea of outputting a spa for what should be a multi page site.

[00:37:06] I’m not saying you shouldn’t have to say it just turns me off as like a, it doesn’t feel right

[00:37:12] Brian Rinaldi: there, there are cases where I feel like, like, I, that’s why I chose it for the e-commerce one, because there’s a lot of functionality in an e-commerce app. It is not necessarily as easy to build in a static multi-page application.

[00:37:30] That probably makes sense to build it as a single page application. So you can kind of more easily keep things like, you know, your, your shopping cart and yours, other, you know, kind of, sort of like dynamic pieces, like recommendations and things like that. Can, can easily kind of. Be componentized and move to cry.

[00:37:52] Like the state can remain, without a lot of complications. but, but then, you know, a lot of, I think what we do a lot of, okay, I’m gonna, I’m gonna, I don’t know how well widely this is going to be seen, but I put my son with terrible, but get myself in a little bit of trouble, but I’d say, you know, As Jamstack became more popular and particularly as certain tools, which I don’t, I’m not dissing those tools.

[00:38:24] They’re great tools, but I guess they became kind of the ubiquitous Jamstack solutions. and bad effect of that was that we made a lot of people build things as SPA’s, that should never have been SPA’s in the first place. Like, I think there’s, there’s a good argument that like probably 75% of what people were building with, the Jamstack should not have been a single page application, but probably it was like Simon docs process.

[00:39:00] Simon MacDonald: Yeah, I kind of got forced into that, knowing what I know now, I wouldn’t have picked that approach, certainly. but I don’t think what you said was controversial at all. In fact, I think it goes back to the age-old advice as you pick the right tool for the right job. Unfortunately, sometimes there are outside requirements that kind of make you pick the wrong tool.

[00:39:22] Raymond Camden: arc on that a bit too, because I know like, wow, you and I both were talking about PWA alive. And what bugged me so much about that area of discussion was it was always single page applications. And I get beat, you know, A is in PWA, but so much of the PWA stack was so useful to the web as a whole.

[00:39:42] And I felt that we were limiting the conversation by saying, you can only build this if you’re building an application versus if it was useful. And I think everyone and I tried like, heck, like when I, when I did talk about it to let people know it, you don’t have to build a spa with this, so you can build regular applications and use offline cash and you can still do that without having a stock.

[00:40:04] so yes, this all sounds like anti SPA. It’s more anti everything has to be a SPA

[00:40:12] Simon MacDonald: Yeah, again, right tool for the right job and yeah, service workers are amazing. And we just, we don’t really use them enough or talk about them enough outside of the PWA sphere. Taylor remind us to add a service worker to our code so that we can cache documentation for people.

[00:40:32] All right, cool. but yeah, on the right tool for the right job, topic, when it comes to. Building applications with the Jamstack like, what would you say are some of the best use cases and what would you say are some of the worst use cases for Jamstack.

[00:40:51] Raymond Camden: Easy blogs and docs, definitely. for sure where, which has a negative connotation, but works at a lot of places still. If you’re launching a new mobile app, a lot of times we’ll put up a one-page. Or a whole page just to talk about the application, restaurants, anything that is not necessarily changing.

[00:41:12] I had a lot of content sites that were built in cold fusion, running on SQL server, where I realized the data had not changed in a year. And you can use a Jamstack and still have SQL server and just have a process to suck that crap out, generate a static site, and update once every, you know, a year or so when you change the data.

[00:41:32] so certainly, everything I just said, that’s, concluding that, which is a dump, sorry.

[00:41:41] Brian Rinaldi: Yeah. I mean, I think my answer to that is going to be super. Vague in a way, because I think Ray’s right. If you think that Jamstack is purely about aesthetic stuff or not purely, but mostly, and it is kind of right.

[00:42:03] I think I take an aesthetic first approach, right? Like, so if you can statically render a page, do statically render that page. But then again, I also think like, okay, I don’t, I don’t think it’s, there’s no, I’m not a purist about it. If you want to do server-side rendering and you want to do, you know, deferred rendering or you want to do edge rendering or whatever, like, I think there’s a place to mix and match those as needed.

[00:42:32] In which case, what can you not build? I mean, if I could server-side renders stuff I can, or, you know, you know, use edge rendering or deferred rendering and all those other things like. What kind of site can I build with Jamstack? It’s to me that’s more of, since Jamstack is not really like a stack. Jamstack is a methodology or an architecture or whatever you want to call it.

[00:42:57] Right. I could take, I don’t have to take everything verbatim. It can be like, I take. I think a lot of, even things like Remix use a lot of Jamstack like kind of, ways of doing things like a, an approach that’s very similar. Like it takes a lot of, of what Jamstack is and, and kind of says, okay, we’re going to do that, but everything’s going to be server-side rendered.

[00:43:25] you know, so, But it’s very similar in many respects and I’m, I’m, I’m totally cool with that too. It depends on the needs of your application. If, if it makes sense to server-side render everything, then Hey, go for it, do it. And, you know, it’s, it’s cool that you’ve taken lessons from what we tried to do with Jamstack I think, and applied them how you need to, and that’s totally cool.

[00:43:53] Yeah,

[00:43:55] Raymond Camden: it doesn’t have to be the solution like for, for my team at Adobe, like we have Gatsby for docs and crap and that’s fine there. And then we have something running or dev console and something writing, a REST APIs. So our complete solution jam is a portion of, it’s definitely not the complete thing.

[00:44:13] And it would’ve been silly to try to build everything via just one Jamstack solution.

[00:44:20] Simon MacDonald: That’s why I love talking to you guys. Cause you’re not dogmatic about that approach. You know, you’re not like everything has to be a Jamstack because you talked to some other folks at other companies that have a vested interest in that, you know, all things have to be done with their technology or else you’re just stupid.

[00:44:34] And. Yeah, I’m not going to say which companies those are, but you know, if I sneeze and the name comes out, then maybe I do feel like I’m monopolizing the conversation a little bit. So I’m just going to throw it out there to everybody on the call. And anybody want to jump in with a question? Yeah.

[00:44:49] Daniel Lauzon: Yeah. Just going to say listening to, to, to all of your comments and especially something you said Simon made me think, you know, the right tool for the job. It sounds really cool. Except my job is to sort of perform a lot of jobs. And I think that’s the demo. The dilemma actually comes from some of the overwhelmingness I talked about before.

[00:45:08] I’m always trying all these new things, but really I’m trying to gather like, this is a Swiss army knife. It’s not going to shoot me in the foot when it’s a brochure, but at least I don’t have to learn another damn thing. And it has reasonable, you know, deployment cycle and build times and all that, but it’s like it’s contained and, I think that’s part of the criteria that’s sort of missing because yeah, sure.

[00:45:32] Maybe you’ve been given the ownership of this new doc site, but you know, in four months now you’re doing this other intro brochure in front of that, and now you gotta like switch your entire stack and get good at it and remember why you picked it and all of that. So that’s, that’s what I think is part of the, that’s the criteria that’s missing for us to all converge to a thing that has.

[00:45:53] Not just a single purpose. It’s really good for that. It’s like, what’s the thing, that’s good for most things, you know? And I think that’s why, Next and Remix and things are getting slick. Cause they’re oh, flexible, but they need a really, really easy on ramp and, and make you not shoot yourself in the foot.

[00:46:10] Like the one thing that I love about next is how flexible it is, but then you go to their, you know, the, the next examples, as part of their, the repo and there’s literally 150 starters. And a lot of them probably haven’t been built in the last year and a half. And haven’t been tested with, you know, whatever it is then the next 14 or 13 or whatever, where they’re at.

[00:46:30] Cause that’s what I find with my own little experiments that I, oh, I tried this and I tried that and like, God knows if I can get a Gatsby site that was built with a, you know, version 1.7, two years ago or whatever it is, it’s just, it’s just really hard to, to carry this stuff forward anyway. So I just wanted to interject that it’s not so much the fitness for purpose.

[00:46:51] I don’t want to have to redo the, you know, compare five tools every time I start something and learned everything. I just, invented in the last iteration. And I wish there’s some more of that, but, you know, it’s the price of having a lot of cool innovation going on, I guess.

[00:47:08] Brian Rinaldi: Yeah. I completely agree with you and hear you.

[00:47:13] It’s like, you know, part of the nice thing about having a job like mine, and I think Ray too. Part of our job is just a mess around with this stuff, but we don’t have to maintain something for a super long time. It was like, oh yeah, that demo over three years ago. Yeah. No, I haven’t touched that framework since then.

[00:47:30] so, you know, but, but yes, if you’re having to maintain these things and you definitely don’t have to choose every time we come around to a new project, that’s kind of, it’s, it’s kinda crazy. and I do feel like we have gotten to a point where. It’s it, you know, if there’s a feeling like you have to know it all, otherwise you’re falling behind.

[00:47:53] I, you know, like for me, I’d say, my solution for this is I have this. I tend to have like, Hey, tool I use for like, I might use next JS, for like, for when I have to do more. Interactive like dynamic sites in the night drop to Hugo, if I’m doing more aesthetically based stuff. so I guess the right tool for the job, isn’t it doesn’t require that to me, that you have to reevaluate everything every time.

[00:48:29] It’s just, you have more than one tool in your toolbox. So you’re not like, Hey, all I know is Gatsby. So like everything’s got to fit somehow into using Gatsby. whereas like, if you. You know, at least if you have at hand a few of these, at least I can pick from those the best fit. They may not be the perfect fit, but as we know, having developed stuff for like, you ever been in a call for a long time, it’s like, you know, you’ll regret it three years from now.

[00:48:59] Anyway, it doesn’t matter what you picked.

[00:49:03] Ryan Bethel: Exactly.

[00:49:07] Simon MacDonald: We’re not

[00:49:08] Raymond Camden: all programs to run a government computer for 20 years. So I think it’s okay. I think it’s okay.

[00:49:14] Brian Rinaldi: Yeah. It still runs. Who cares?

[00:49:17] Simon MacDonald: I don’t even want to tell you. I think the security clearance is okay, but I wrote some code for the Canadian military at the department of defense and meteorology division back in the late nineties.

[00:49:32] And it was running for a really long time, like two too long for a co-op work term for that code to live on, but it works so they’d never, they’d ever changed that it was, it was pretty hilarious that, I wrote code that was providing weather data to, Canadian ships at sea. So.

[00:49:51] Brian Rinaldi: Sometimes

[00:49:51] Daniel Lauzon: It’s amazing.

[00:49:52] It is amazing when it works. I have a personal sites been on app engine since whatever, when it launched 2007 or eight or something, and now it is a full static site, it feels very gem. He actually hasn’t broken. It’s

[00:50:04] Brian Rinaldi: awesome.

[00:50:06] Simon MacDonald: And I think that’s the Swiss army knife is going back to the platform and just trying to leverage the platform’s capabilities as much as possible.

[00:50:14] I think over the past five years while we’re all so very busy, learning React and becoming React experts, the platform got really good underneath our feet and we didn’t even notice it. So there’s a lot of amazing things that you can do. We’re getting close to the end of the hour, but I just wanted to interject with like one more quick question.

[00:50:34] one of the things I really enjoyed about the book was the kind of the no code, low code, solutions for things. Here in my local neighborhood, we have our community association and we maintain a WordPress site. They found out that I work in high tech. So I guess who gets to do all that stuff now.

[00:50:53] And sure, I could run it in cloud functions on edge computing and it would be a great little project for me. but then when I have to pass it to the next person, They won’t have a clue what’s going on. so having that section where you talk about headless WordPress, using Google forms and getting data from that, that was like,chef’s kiss for me because it’s like, Those were things I can actually use and pass it on to the community association and not have to worry about maintaining it long term, which is a key thing for me, because I don’t want to be doing this in two years when I’m no longer on the community association.

[00:51:31] but then on the other hand, When you get into building like more, detailed Jamstack sites and you’re needing to pull in some dynamic content, and you’re making API calls. One of the things I always struggled with was how to protect your API keys, because,if it’s, if it’s statically rendered, those API keys could end up in the HTML or JavaScript that you’re delivering to the client.

[00:51:53] So what are, what is like the best practice for kind of getting away from that situation?

[00:52:05] Raymond Camden: for me it’s so it disbanded a serverless function. and initially, literally just a wrapper. So you call a serverless function from this function, which calls the API. I would also do things like if I knew I didn’t need the full API result, I would reduce it.

[00:52:18] So that would mean less traffic for the client. So I was giving them a better shaped response and hiding the API key, some hosts like Netlify, that actually allow you to do a redirect file. To an API with a key and on the front end, all you’d see is slash API slash weather, but behind the scenes, they’re redirecting to so-and-so API with key blah, blah, blah.

[00:52:43] So there there’s multiple ways, but typically something on the server has to handle that.

[00:52:49] Brian Rinaldi: Yep. Another Netlify thing was that I can’t remember the name right now, but they have that new offering where they’re integrating specific API APIs that you could just hookup on the backend. Not again. The only trouble is you’re then hooked into their platform, which is obviously what they want.

[00:53:06] but as simplifies that, but typically, yeah, exactly what Ray said. A serverless function that handles the API calls. and then passes that back. So nobody sees the key, a lot of tools. That’s pretty, pretty simple. Now. Like I didn’t even have to write a separate batch of code and deploy it.

[00:53:30] Like I just dump it in a functions folder and all that. Or even like, you know, I think in the next share sprints, it’s, it’s just like an API folder and all that stuff gets automatically deployed as serverless functions for me. So like all the keys are hidden,

[00:53:46] Daniel Lauzon: environment variables can or can be public or not, so they can make it, you know, just to the builder, just to the backend API or all the way to your client, depending on how the variables name I think is how they do it.

[00:54:00] Sometimes it needs to live in the CI/CD. You don’t get the keys to build. Sometimes it needs to be in the SSR. Sometimes I’ll

[00:54:08] Brian Rinaldi: wait.

[00:54:09] Simon MacDonald: Yeah. I just want to make sure that we got on record that, you know, people know do not put your API keys and your front end that’s bad. Don’t ever do that. so yeah, we’re coming up to the end of our hour here.

[00:54:21] I just, I really want to thank both of you for coming in and chatting with us. I really enjoyed the book. in fact, you know, right now, anybody who’s interested in this book it’s available on the Manning site and digitally. I’m still waiting for my paperback copy to arrive.

[00:54:41] I got an email yesterday. It got delayed another month. So I don’t know. Yeah. It’s, it’s not, I think my new delivery date is June 21st, so, yeah, I’m glad I got a digital copy to be able to read before this meetup as well. but yeah,

[00:55:00] Brian Rinaldi: that’s the first I heard that they hadn’t even told us right Canada

[00:55:04] Raymond Camden: popular.

[00:55:05] That’s why his is pushed off.

[00:55:08] Brian Rinaldi: Yeah.

[00:55:09] Simon MacDonald: I mean, sometimes that happens. Like sometimes somebody orders a Lego land speeder on star wars day and it doesn’t show up, you know, anyway, that’s a whole other topic, but I just want to throw it to you guys, you know, you know, w tell me what’s up next for you folks? What do you want to promote?

[00:55:24] Brian, why don’t you go ahead.

[00:55:27] Brian Rinaldi: Sure. If you’re, obviously, if you’re interested in Jamstack, I’ve got my Jamstacked newsletter, which you can go to at Jamstack.email, which comes out tomorrow, just finish writing it. and then the other, the only other thing I want to I mentioned is, I run a community called cfe.dev that has, meetups and other, like we interviewed.

[00:55:51] Yeah, we interviewed Ray and stuff like that. We have a podcast, we have all kinds of stuff going on. Like basically every Thursday we’ve got either a session from somebody in the community or in an interview with a prominent member of the developer community or something. Tons of content there as well.

[00:56:11] Simon MacDonald: And CFE stands for certified fresh events. It’s not, it has nothing to do with cold fusion. That would be Ray’s side of the world.

[00:56:20] Raymond Camden: the only thing I will promote is my blog. if you want random thoughts. I have applied and I never blogged about the same thing twice in a row. https://www.raymondcamden.com/ you could follow me for something new every couple of days. And I will end with one very quick piece of advice. If you are having a hard time and struggling consider therapy, just life-changing incredibly helpful.

[00:56:49] Simon MacDonald: Yeah, that is, that is very good advice. Right? there’s definitely a stigma when it comes to talking about mental health. And I will admit right here on this call, I have gone to therapy. It was critical for me and I am very glad that I did that. I will never regret that decision. So thank you for bringing that up.

[00:57:06] so that’s about it for today. so please, you know, come on back in June, we’re in, we’ll be talking to Dave Farley about his book, Modern Software Engineering. so that should be a good time as well. And then in July we have Mariana Bellotti and her book is Kill It with Fire, which is dealing with legacy systems and how to upgrade them.

[00:57:27] that was another great read that I just recently finished. So, thank you guys so much for calling in and we’ll hopefully see you at a conference sometime soon. That would be amazing to see folks in real life again. Absolutely. I think the last conference I was in, in real life was in Orlando, Florida in 2020, about a month before COVID hit.

[00:57:50] So yeah, good to me. Brian’s fault. That’s basically it. Yeah.

[00:57:56] Brian Rinaldi: I mean, you know, I’m going to some conferences now. I’m now three and a half weeks out from having caught COVID at one. And despite being triple Vaxxed, I still have symptoms, all that coughing you see, you know,

[00:58:13] Simon MacDonald: Don’t tell me that we’re, we’re going to, Remix Conference at the end of May and, yeah.

[00:58:19] triple vaxxed as well. And I just bought N95 masks and I’m going to be that weird Canadian guy that looks a little bit like a storm trooper in the corner. I’m sure.

[00:58:29] Brian Rinaldi: Yeah. So, you know, anyway, it’s part of life now, but I will be at actually Ray and I will both be at That conference. I don’t know if any, if you’re going to be there, but we’re going to be at the one in Wisconsin.

[00:58:45] Simon MacDonald: No, I did not get into that one, but, yeah, I’ve always wanted to go to one of the, That conferences, whether it’s in Wisconsin or in Texas, that seems like a really great time.

[00:58:55] Brian Rinaldi: Yeah. It’s interesting to be at a water park with your colleagues and other developers.

[00:59:05] Simon MacDonald: That would be fun.

[00:59:06] All right. Thanks everyone. Thanks

[00:59:09] Daniel Lauzon: very much, Brian and Raymond, I know it’s really, really hard to write one of these books and, you know, we always nitpick on this and that and would have like this and that, but like, it must be an insane amount of work and I really, really appreciate the, that you keep coming back for more pain for the benefit of assaults.

[00:59:25] So thank you very much and thanks Simon for organizing. Awesome.

[00:59:30] Raymond Camden: Thanks everyone.

[00:59:31] Brian Rinaldi: Thank you.

Don’t miss the next book club meeting

Stay in touch by:

1. Joining the Architect Discord, where we will be hosting the book club video chat.
2. Follow the @begin Twitter account, where we will send out polls for future book club selections.

Or if you prefer emails join the book club newsletter. We promise that we will only use this mailing list for book club purposes like meet-up reminders and book club selections. We do not sell your personal data.