Writing about Jamstack with Raymond Camden and Brian Rinaldi

Episode Description

Brian Rinaldi and Raymond Camden discuss their Jamstack Book, the evolution of the Jamstack term, static site generators, and choosing the right tools.

Episode Summary

Brian Rinaldi and Raymond Camden join the show to talk about The Jamstack Book, a Manning publication that serves as a follow-up to their earlier O'Reilly book on static site generators. The conversation traces the evolution of the Jamstack concept, from its origins in static site development through the coining of the term and the recent shift from the capitalized JAM acronym to lowercase "jamstack," which both authors support because the acronym created more confusion than clarity—particularly the implication that JavaScript frameworks were required. They address Ryan Florence's public skepticism about the term, agreeing that the definition can feel muddled but arguing that Jamstack represents a legitimately distinct, static-first approach to web development. The discussion then shifts to the book's structure, which intentionally uses different tools for each chapter—Eleventy, Jekyll, Hugo, and Next.js—to demonstrate that Jamstack is not tied to any single framework and that different tools suit different use cases. Raymond highlights Eleventy's flexibility and lack of constraints, while Brian explains why he chose Next.js for the e-commerce chapter over Gatsby. The conversation wraps with a look at emerging full-stack Jamstack frameworks like Redwood and Blitz, the book's beginner-friendly audience, and its availability through Manning's early access program.

Chapters

00:00:00 - Introductions and StepZen Overview

The episode opens with host Anthony Campolo introducing guests Brian Rinaldi and Raymond Camden while disclosing that he and Brian recently became coworkers at a company called StepZen. Brian provides a brief overview of StepZen, describing it as a tool that unifies multiple data sources—REST APIs, databases, and other backends—into a single GraphQL API, noting the product is in private alpha.

Raymond Camden then introduces himself as a developer relations professional at HERE Technologies, where he works on mapping, navigation, and location services for developers. The hosts establish that Brian and Raymond have a working relationship stretching back to approximately 2000, rooted in the ColdFusion and Adobe community, and that The Jamstack Book is actually their second collaboration after an earlier O'Reilly book on static site generators.

00:03:05 - The Jamstack Term and Its Evolution

The conversation turns to the history of the Jamstack term and how both authors experienced the transition from "static sites" to "Jamstack." Raymond explains that while he wasn't initially thrilled with the name, he came to appreciate that it shed the baggage of the word "static," which led people to assume they'd be giving up dynamic capabilities. Brian notes he understood the need for a new term even if he wasn't sold on the specific word.

Both authors strongly support the recent move from the capitalized JAM acronym to lowercase "jamstack," arguing the acronym caused significant confusion. People assumed that because "J" stood for JavaScript, a JavaScript framework was mandatory, which excluded tools like Hugo. Raymond adds that a subset of the community was pushing JavaScript as the only valid approach, which he disagreed with. The group agrees that dropping the acronym better reflects the technology-agnostic nature of the approach.

00:07:01 - Debating the Jamstack Definition

Chris Burns brings up Ryan Florence's public questioning of what Jamstack actually means, sparking a broader discussion about definition clarity. Brian recounts responding to Florence's tweet thread, feeling it was somewhat dismissive of the community's work to define the approach as a static-first methodology that uses CDN-based deployment and specific tooling to distinguish itself from traditional single-page applications.

Anthony adds nuance, noting that Florence's frustration likely stems from people repeatedly asking whether Remix qualifies as Jamstack when he has no connection to it. However, Anthony pushes back on the claim that Jamstack developers ignore challenges like persistence and authentication, pointing to the FSJam community's active work on those exact problems. Raymond contextualizes the debate as growing pains typical of any young technology movement, comparing it to the early serverless backlash, and suggests the best response is simply to keep building.

00:11:35 - Static Site Generators and Eleventy

The discussion shifts to specific static site generator tools, starting with how Jamstack can be an approachable entry point for beginners through tools like Gatsby and its plugin ecosystem. Brian argues that more traditional generators like Jekyll, Hugo, and Eleventy offer an even simpler starting experience for developers who don't know a JavaScript framework. The conversation then focuses on Eleventy, which Raymond chose over Jekyll because of its npm-based installation and JavaScript customization capabilities.

Raymond praises Eleventy's flexibility, explaining that unlike more prescriptive generators, it allows developers to output any file format and use multiple templating engines like Liquid and EJS within the same project. Brian adds that JavaScript-based static site generators generally excel at integrating external APIs at build time, something traditional tools like Hugo and Jekyll handle less naturally. The group also discusses Next.js's role, agreeing it can perform static site generation but is better understood as a multi-purpose tool rather than a dedicated static site generator.

00:18:13 - Book Structure and Technology Choices

Anthony asks how the authors chose which technologies to feature in each chapter. Brian explains that the first half of the book is organized around use cases rather than frameworks—they picked the best tool for each scenario to give readers a broad view of available options. Hugo was chosen for the documentation chapter because of its fast builds and strong documentation themes, while Next.js was selected for e-commerce because React's rendering model suits the dynamic elements of online stores.

Raymond notes that this approach was deliberate because readers might dislike one generator but find the next chapter's tool more appealing. Both authors emphasize that each chapter tries to acknowledge alternative tools and explain why a particular one was chosen, reinforcing the Jamstack philosophy that developers should select tools matching their own style. Brian also shares that his preference for Next over Gatsby in the e-commerce chapter was a personal choice rather than a judgment against Gatsby's capabilities.

00:24:12 - Serverless, Full-Stack Jamstack, and Stretching the Definition

Chris raises the question of whether adding custom APIs and serverless functions stretches the Jamstack concept too far. Raymond is comfortable with the expansion, valuing the escape hatch of breaking rules when practical needs demand it. Brian frames it as "static first, not static only," explaining that even server-side rendering in Next.js deploys as serverless functions on platforms like Netlify, maintaining the CDN-based architecture.

The conversation then explores emerging full-stack Jamstack frameworks like Blitz, Redwood, and Bison, which bundle databases, authorization, and code generation into the Jamstack model. Brian argues these tools aren't fundamentally changing what developers were already doing—connecting to databases like Fauna and orchestrating authentication—but rather simplifying the complex setup work. He sees frameworks like Redwood as making existing patterns more accessible rather than inventing a new category entirely.

00:29:39 - Audience, Book Timeline, and Closing

The authors discuss their target audience, with Raymond noting the book suits everyone from brand-new developers to experienced backend engineers looking for a simpler approach. Brian explains that each chapter functions as a self-contained project requiring no prior Jamstack or framework knowledge, making it accessible to anyone with basic web development experience. The group then touches on the book's timeline, with several chapters still in progress and a final batch due roughly a month out.

The episode wraps with practical details: Manning's early access program lets readers access chapters as they're written, and a 30% discount code is available. Brian mentions his bi-monthly virtual meetups covering Jamstack and general web development topics, while Raymond puts out a call for DevRel hiring opportunities on behalf of colleagues. The hosts thank both guests and joke about Chris's suggestion to subtitle the book "The Essence of Jamstack."

Transcript

00:00:10 - Anthony Campolo

Welcome to the show. We've got Brian Rinaldi and Raymond Camden with us. How are you doing, guys?

00:00:17 - Brian Rinaldi

Great. How are you? All right.

00:00:19 - Anthony Campolo

Doing very good. Just for the sake of full disclosure, it would be useful to let the listeners know that Brian and I are actually coworkers now. He works for a company, and I work for a company called StepZen. It's funny, when I was interviewing, I thought Brian was going to be my boss, but someone seems to have gotten confused, and we're kind of like peers or something. So it's really great. Why don't you tell the listeners just a little bit about what StepZen is?

00:00:44 - Brian Rinaldi

Sure. Yeah. I mean, we became colleagues as of, what, last week, right?

00:00:48 - Anthony Campolo

Yeah.

00:00:48 - Brian Rinaldi

Thursday. Officially. Yeah. Okay, so it's been a few days. You're already sick of hearing from me, I'm sure. So StepZen basically offers a way to create one API for all of your data sources. You can connect REST and databases and whatever other backends your system might have, all into one GraphQL API. We offer a whole bunch of tools for doing that, as well as things to optimize after you've created that API. We're still in private alpha, but you can sign up and get free access to the private alpha at stepzen.com.

00:01:23 - Anthony Campolo

It's always fun hearing how people describe these kinds of big, high-level things.

00:01:30 - Brian Rinaldi

It's not the easiest to describe in many ways, especially when you're talking about data.

00:01:35 - Anthony Campolo

We are not here to talk about StepZen, and we're actually here to talk about a book that both of you have written together. Is it The Jamstack Book? Is that the title?

00:01:45 - Christopher Burns

You've got to do a second introduction for Raymond.

00:01:49 - Anthony Campolo

Yeah, I was going to loop back in with him for the book. Why don't you go ahead and tell us about yourself, Raymond, and where you work and all that.

00:01:57 - Raymond Camden

Yeah, I work at a company called HERE Technologies. We're involved in mapping and navigation, essentially location for developers. I'm in DevRel for them, and I do routing, client-side maps, and much more advanced stuff as well.

00:02:13 - Anthony Campolo

Great. How did you guys get together for the book? Have you worked together previously?

00:02:19 - Raymond Camden

Yeah, we have a long, long, long history.

00:02:21 - Brian Rinaldi

Yeah, yeah. Our history goes back to around the year 2000 or so, 2000 or 2001.

00:02:31 - Raymond Camden

Long, long time. ColdFusion. Flash. Adobe community.

00:02:37 - Brian Rinaldi

So Ray and I have known each other a long time. We actually wrote a book together prior to this that was all about static site generators for O'Reilly. It came out around the same time as when the Jamstack term just kind of came around, so we didn't use the term Jamstack at the time. This is kind of a follow-up. Because so much has changed in four years, it's basically a wholesale rewrite.

00:03:05 - Anthony Campolo

Yeah, that's awesome. This was one of the things that really got me involved in the Jamstack. I'm a big history buff myself, and the transition from static sites into the Jamstack is something I thought was really cool. As a newer dev coming into this way after the term had already been coined, you kind of had to dig into the history a little bit to tease it out. You guys pretty much lived it. As you say, you were writing books about this before it was even called Jamstack. How did you guys feel when the term Jamstack was introduced?

00:03:41 - Raymond Camden

I was not terribly happy with it, but at the same time, I had given intro to static site development presentations like 200 times, and there was always a significant portion in that kind of talk where you talk about adding dynamic stuff back in and making sure people knew that they weren't giving stuff up. So I've kind of come around to this new term because it doesn't have the baggage or the assumption that, "Oh, you know, I have this full app server. I could do anything. If I go static, I could do nothing." Having the term kind of resets expectations and what people think about it.

00:04:18 - Brian Rinaldi

I understood at the time the need for the term. I quibbled on the actual term, but I didn't have anything better to offer. So I just kind of agreed. I'm like, okay, I guess that's it. I'm not sure I like the word Jamstack, but I don't have any better options.

00:04:35 - Anthony Campolo

That's a good attitude to have, because I feel like a lot of people will always complain and then not offer a better solution. You're just kind of left with, okay, so you're just going to complain then. All right. Cool. I like that. If you can't think of something better, get on board. How do you guys feel about capitalized JAM to lowercase jam, getting rid of the JAM acronym?

00:04:56 - Brian Rinaldi

So yeah. I think we both kind of were unsure of that at the beginning, and I've come around to feel like that is absolutely the right thing to do. The acronym is not useful anymore at all because it causes more confusion than it clarifies. Everybody's like, "Oh yeah, I do markup, and I use APIs, and my website uses JavaScript. So I'm doing Jamstack, right?" And it's like, well, are you using any of these tools like a static site generator, or are you doing this?

00:05:31 - Anthony Campolo

I would say CDN would be the question I would ask.

00:05:34 - Brian Rinaldi

Yeah. And it's like, okay, well, that doesn't sound like Jamstack. That sounds like just a regular single-page application kind of thing. My secondary quibble with the acronym was that, because it started with JavaScript, we trended toward a feeling that you had to use a JavaScript framework, and that it was all JavaScript framework-based development. While I think there are important things that JavaScript frameworks offer, and some of these tools, it's not a requirement. And I don't like that feeling.

00:06:07 - Anthony Campolo

Like a Hugo user, which is.

00:06:09 - Brian Rinaldi

Hugo, but even less JavaScript, not a JavaScript framework. And that's pretty popular too. I like the diversity of options. If you want to use a framework like React or whatever, we've got great options there. If you don't want to use a framework, you don't have to. It's not a requirement. But because of the J being first, people were like, "Oh, okay, so I have to use React." It's like, no, you don't. What's your feeling, Ray?

00:06:36 - Raymond Camden

Yeah, that was definitely a subgroup that was pushing very hard for JavaScript everywhere, and the final result was all JavaScript, and I didn't like that. So anything that moves away from pushing that as the one true way, I think is good.

00:06:57 - Anthony Campolo

It's not what Chris wants to hear. Chris wants to be the one true way.

00:07:01 - Christopher Burns

I prefer the term TAM. You know, TypeScript, APIs, and markup.

00:07:07 - Brian Rinaldi

Just TAMstack. Yeah.

00:07:10 - Christopher Burns

Just kidding. It's almost like we're now coming full circle. Ryan Florence, who is obviously the creator of Remix, is saying, like, what is the Jamstack? People are asking me if this is Jam, and I have no clue.

00:07:28 - Brian Rinaldi

Yeah, I saw his tweet. I'm not going to quibble with Ryan, per se, but I sent him some info on that thread. I think it's pretty clear what it is. If you start thinking, how can I put this nicely? I felt like there was maybe some effort to just kind of dismiss it. I felt his tweet was a little dismissive of Jamstack in general. A lot of people sent him info about what it was, and I don't know Ryan at all, so I felt like he was a little dismissive of even that. So I was like, okay, I think we clearly defined it. We know what it is. We all talk about it. It's like this static-first kind of way of building things, right, that distinguishes it from a single-page application.

00:08:20 - Brian Rinaldi

Right. It's mostly static. We can do server-side rendering on some frameworks, but for the most part we're going to stick to static. There are certain tools that help us achieve that. Then we deploy on places where it's all CDN-based and things like that. I think all those pieces come together to make something that is legitimately different than other types of web development. I agree with him that sometimes our definition gets muddled, so it can be hard for somebody outside to understand what it is. But I do feel like we do have a clear distinction.

00:08:58 - Anthony Campolo

Yeah. I was also following along with that tweet thread, and I responded as well to it. I got the sense that he feels that it's become an overloaded word, which I think is something that we probably agree with here. That's part of why we've been honing the terminology. He's constantly getting asked by people, like, is Remix Jamstack? Can I use Remix with the Jamstack? There's all this kind of thing, and he's constantly being asked about it, and he's like, I don't have anything to do with the Jamstack. I didn't make this as a Jamstack. I don't pay attention to Jamstack. He doesn't have anything to do with the Jamstack. So I think he's frustrated that it's the thing and people keep trying to force that thing onto his thing, and I think that's totally valid.

What I did take issue with is he was saying Jamstack has all these problems Jamstack people don't talk about, in terms of things like persistence and auth. He was saying all this stuff gets fixed by magical API fairies. That's what I really took issue with, and that's why I felt the need to send long tweet messages responding to it. We here in the FSJam community have built this entire community specifically around addressing those issues that you're bringing up. So to say that we don't know about it or that we're not addressing it, I think is just fundamentally dishonest to the work that we're doing.

00:10:12 - Raymond Camden

I've been doing static sites since like 2013, but I feel like, as a thing, we're still very, very, very young. Like any new thing in the beginning, you're super excited and you love this new way of doing things. Absolutely, sometimes you oversell, sometimes you gloss over issues. I was very big into serverless when it first came out, and there was the same reaction every time you mentioned serverless. Someone would be like, "Oh, but there's a server involved." You know, that guy. And it was always a guy. So I feel like we're probably hitting some of that with Jamstack becoming so big and so popular. There's going to be negative reactions to it and whatever. Like, I'll get crap done while you complain about the name.

00:10:57 - Brian Rinaldi

Yeah, I think we can, as you know, Anthony, refine the definition. I struggled with some of the ways the JAM acronym was used. I felt like it encompassed too much. Then it becomes easy for somebody to say, well, everything is Jamstack, right? That's Jamstack, that's Jamstack. We had arguments even in some of the communities. And I'm like, no, no, we need to be clear about what this is that's distinct from something else. Otherwise, we fall into that trap of being, it doesn't mean anything, and having it be a fair criticism at that point.

00:11:35 - Christopher Burns

One of the things I think Jamstack does do very well is work well for beginners. If you've never touched web development before, picking up a Gatsby website, for example, can be a really easy way to get something on the internet for someone who's doing their first HTML, even though it's not HTML, it's JSX.

00:11:58 - Brian Rinaldi

Absolutely. Gatsby in particular has been a popular entry point, partly because it does address a lot of those issues, even though it is React, and if you don't know React, it can be kind of complex. But because they have the built-in tooling, and particularly their plugin ecosystem, it makes it really easy to be like, "Oh, I just want to use this service." Let me find it, and then they have a plugin. It's like, okay, done, and I don't really need to get into the details of how that works. So it's really good for onboarding.

I also feel like some of the more traditional static site generator tools, like Jekyll or Hugo or Eleventy, that do just purely static site generation, are actually really easy for people to get started with without layering in. If you don't know React or you don't know Vue, because we have a lot of Vue tools, or even there's now an Angular tool in Scully, if you don't know any of those frameworks and you just want to learn and get something on the web, I really feel like those tools are actually a super easy experience to get started.

00:13:08 - Anthony Campolo

Granted, if you get into Eleventy, actually, because Eleventy, I think, is kind of what a lot of your book is using. Is that correct?

00:13:16 - Brian Rinaldi

No. One chapter.

00:13:19 - Anthony Campolo

Just one chapter. Okay. I guess I shouldn't say most of the book. I only got the first four chapters, so I have a bad sense of the whole book, I should say. But that was the chapter that introduces static site generators. Yes, yes, there we go.

00:13:31 - Brian Rinaldi

That's Ray. If we're talking Eleventy, you should be talking to Ray.

00:13:37 - Anthony Campolo

Great. Yeah. I'm actually learning Eleventy right now because we're using it with this group called Lunch Dev, which is kind of a spin-off of the React Podcast Discord server. It's funny because we're not using React at all, but we're kind of building out an events calendar using 11ty. So I've been learning how to pass data around. It's actually a really powerful static site generator, I'm finding. So I'd love to hear what you enjoy about it and how you would describe it to people who have never used it before.

00:14:10 - Raymond Camden

I came from Jekyll and I like Jekyll a lot, but I hated to install Ruby on new machines, especially on Windows. It was doable, and it's gotten better since I first started using Jekyll, but Eleventy just being npm-based was enough to get me to look at it, and being able to use JavaScript to customize stuff was also a big plus. The issue I've run into with certain other generators that I won't name is that some of them are very prescriptive in terms of what you're allowed to do, and if you want to go outside of that box, you have to work hard. The generator I used before Jekyll, again, I won't name. I literally wanted to output a JSON file, and it took like a week of me fighting against a system that did not want me to do that. It was HTML or nothing at all. So I feel like Eleventy doesn't care. I want to output a dot file, it will let me output whatever I want. It doesn't hold my hand.

00:15:09 - Raymond Camden

It's very flexible. I love the fact that it has multiple engines involved with it. Coming from Jekyll, I love that I could use Liquid, but every now and then I'll have something where Liquid is not a good fit and I just slap an EJS, and EJS is ugly as hell, but it gets the job done sometimes. So I think it really comes down to flexibility and not being trapped, if that makes sense.

00:15:33 - Brian Rinaldi

In my experience, the JavaScript static site generators benefit from the ease of integrating external APIs. The other traditional static site generators often don't have an easy way to consume an API and then spit out a bunch of pages or content from that API at build time. That's something that I feel like Eleventy does really well, but also Next and Gatsby both make it really easy to say, "Oh, here's this REST API that I'm consuming, or GraphQL on StepZen," and then just pull that data in and spit out pages from it or something like that, right? Hugo can do a certain degree of that, and I think it's possible with Jekyll. I've never really been able to do it, but it's not necessarily super easy, whereas on all those tools, it really is.

00:16:24 - Christopher Burns

I think I came into the Jamstack at an interesting time where Create React App was the popular one and Gatsby was just past its 2.0. Obviously I started creating something with Create React App and then was like, oh, but it kind of needs to be static. So I went to Gatsby and I've never actually looked at any other static generator apart from Gatsby and Next. At the time, I wouldn't have classed Next as a static site generator. Even now, I still wouldn't.

00:17:01 - Anthony Campolo

I would say it can do it, but that's a subset of what it could do. Next is capable of static site generation, but it's not a tool that's designed to just do that. So there's probably other things like Eleventy. I feel like it's really optimizing to be just a static site generator. That's a good question. Raymond, can you do SSR with Eleventy?

00:17:18 - Raymond Camden

I have not looked into that at all.

00:17:21 - Anthony Campolo

I don't think so. I would definitely say I would not expect it to, and I would not think it would. That's why I say I don't think of Next as just a static site generator. I think of it as this kind of multi-purpose tool that includes static site generation as one of the things it can do. That's kind of how I think of Next and how it relates to Gatsby. I have a pretty similar story to Chris, actually, in terms of how I started with, you know, I learned React, Create React App through my bootcamp, and then kind of found Gatsby. Actually, I found Gatsby before my bootcamp. Because of how it works, you can just fire up a blank project and start writing Markdown. You don't need to write a single line of React to get a Gatsby blog set up on the internet, and then just write Markdown. So that was why it ended up being a really good entry point for me, that it generated the site for you.

00:18:13 - Anthony Campolo

You didn't have to figure out how to do any of the React internals or even the GraphQL internals. I never looked at a single GraphQL query in my Gatsby project. I'm sure they're buried in there somewhere because I was always told Gatsby was using GraphQL, but I had no idea what any of that was doing. Then I started looking into the history, and I tried Jekyll just to kind of get my hands on it. I've also played a little bit with Eleventy, and I like Nuxt. Nuxt is kind of like Next in the sense that it can do static site generation. It's not just a static site generator, as we've been saying. There's so many tools, there's so many things involved here. So I'd like to kind of get into some of the other tech that you guys have written about in the book. How did you go about choosing the technology to use in the book?

00:19:02 - Brian Rinaldi

The first half of the book covers mostly tools, like static site generators, but we picked use cases. When we tried to come up with, like, what would be, if I was doing X, what would be the tool I'd want to use, so we could give you a broad view of the different tools that are available. We wanted to say, rather than come out and be prescriptive and be like, okay, this is going to be about building Jamstack sites, but everything uses Gatsby or Next or whatever, we want to give you a range of options so you can see what tools fit for you. Number one. And number two, certain tools are often better for certain use cases. The documentation one, I use Hugo because I think it's actually, particularly for large documentation sites, the fast generation is great. It's got some great themes for documentation and stuff.

00:19:55 - Brian Rinaldi

So it's really a good tool for documentation. Whereas on the e-commerce side, I'm using Next because I felt like, well, e-commerce has lots of dynamic elements going on that actually benefit from the way that React renders the UI. Whereas a tool like Hugo may not be. I've used Hugo for e-commerce stuff, but it may not be as good a fit depending on what you're trying to do.

00:20:19 - Christopher Burns

I looked through the first three chapters. The basic site is with 11ty, the blog is with Jekyll, and the documentation website is with Hugo. I think that's a really good approach because this isn't a book about Jamstack, really. It's not just Gatsby. It's trying to teach the core principles that are shared across all of these projects to really define what it is. What is Jamstack? What you're teaching is, in essence, what it is without labeling it to a framework.

00:20:59 - Raymond Camden

Yeah, I was very worried because I have such a visceral reaction to some of these generators. Some I love, some I hate. So for the book, I wanted to be really sure where, if you go into the Eleventy chapter and you hate what you see, the next chapter gives you a different example of how to build something. We try to make sure people know that they have a lot of different options. There's something there that will meet your style.

00:21:24 - Brian Rinaldi

Yeah. We try, even in some of those chapters, to go through what the different options are. This is not the only option for this use case. If you look at the documentation chapter, for instance, I'm like, you know, there are static site generators just for it. There are other tools that can work. When you talk about headless CMS, it's like, here's different options and here's why I'm choosing this one. We try to continuously give you the whole range of tools you can choose. Because that's part of the fun of Jamstack. It's not prescriptive. I can do things the way I want to do them. I can create a developer experience that fits my style. But we need to give you the range of options that are available to you so you can evaluate them.

00:22:11 - Anthony Campolo

Later on in the book, do you get to things like React and Vue and some of those React- or Vue-based frameworks, or do you not use any sort of React or Vue framework?

00:22:21 - Brian Rinaldi

No, we use Next.js. I cover that in the e-commerce.

00:22:26 - Christopher Burns

Gotcha. So you've swapped it away from Gatsby because I...

00:22:29 - Brian Rinaldi

Did swap it away from Gatsby.

00:22:31 - Christopher Burns

That's really interesting because I've built an e-commerce website with Gatsby and Shopify. We also added a CMS where Shopify wasn't good enough, and then our whole build structure was merging two different sources of data into one, and then Gatsby passing that data and then displaying it to the end user. I don't know if that could be redone in Next easily. Next is a completely different way of thinking about it, as you're not thinking of a builder that is building. It's more generated page by page.

00:23:08 - Brian Rinaldi

One of the key differences with Next is it doesn't have that plugin ecosystem. You have to build that stuff yourself. Whereas I might integrate with an e-commerce system via just a plugin that they have on Gatsby, in this case I would have to code it. There were various reasons why I ended up choosing Next, and honestly, it's a personal preference thing. I've used Gatsby a bunch before and it's a great tool. I kind of prefer Next myself for a variety of reasons. So I kind of say, okay, I'm going to choose a React one, and I swapped out for Next just because that's the one I like better. Nothing against Gatsby. Just like we said, each tool has its own style, and it's really about what you like and finding the tool that fits you.

00:23:57 - Anthony Campolo

And then, on tooling before we start, you...

00:24:00 - Christopher Burns

You know, I was going to talk about one of the next chapters that I don't know if you've written yet or have yet to write. And that was serverless, chapter eight on serverless.

00:24:12 - Brian Rinaldi

That's right.

00:24:13 - Christopher Burns

That is right.

00:24:14 - Brian Rinaldi

That's you, right?

00:24:15 - Christopher Burns

Okay.

00:24:16 - Raymond Camden

I just finished seven yesterday. I haven't started it yet.

00:24:19 - Christopher Burns

Okay. So we can talk philosophy here. Would you say that we are stretching what Jam is when you add in your own APIs?

00:24:33 - Raymond Camden

Yeah, sure. And I'm okay with that. That's fine. I mean, again, being in development for a long time, what makes me so happy about Jamstack is it gives me a great stable option, a very powerful option. So stretching it is fine. I come back to this: I hate to be constrained. I like to have an escape hatch where 90% of my code base is perfect, but I need some crap code for like 5% or whatever. I need to break the rules. Being able to break the rules when I need to is fine. I'm all about the philosophy of great development, but there's also the practical world where we have to get things done. I like having that option.

00:25:16 - Brian Rinaldi

I think the key is like we talked about earlier: it's static first. But even in modern tools like Next, static first but not static only. This is the thing I keep saying. We try to do everything static as much as we can. Where we need to integrate APIs and things like that that happen on the client side, then we do that. The definition is changing a little bit because of tools like Next, and I think others will follow suit, like Nuxt for instance. Now, as far as I understand it, you can do static site generation or server-side rendering, but you cannot do both together. But I would hazard a guess that Nuxt will be able to allow you to switch that based on route soon too, as well as maybe Gatsby and other things. But if you look at what's going on in Next underneath the covers.

00:26:09 - Brian Rinaldi

Right. And the reason you can still deploy that to Netlify is it's just serverless functions. There's no Node-based runtime going on there in terms of when you deploy to Netlify. It's still deploying to the CDNs, but it automatically creates serverless functions for you to run that server-side stuff. So the definition is we need to make it clear enough that it's distinct, as we discussed earlier, but allow for, we're just trying to solve a problem. In the end, you're trying to build a website and you need it to do X or Y. If you need to have server-side rendering to do that piece of the app, that's cool, do it. But we try and pre-render as much as we can. That's kind of the key point.

00:26:52 - Christopher Burns

The reason I bring all this up is because of new, as we would call them, FSJam frameworks, full stack Jam frameworks such as Blitz, Redwood, Bison. These are currently three projects. Two out of the three sit on top of Next, but Redwood has gone their own route. What we would define them as is basically Jamstack with a database included, authorization included, a way to generate code as templates included, and it kind of feels like its own area forming. It's kind of like, if you just want to plug in other people's APIs, well, Gatsby or something would be great. But if you want to start building an application or something deeper, that's where this new area is forming. It is tool-agnostic to a certain point, because Blitz.js is doing really well based upon Next, and Redwood is doing really well based upon nothing else, just by themselves. So it's this thing of like when we define what Redwood is, it's like, this is Jamstack, but it's also not because it's doing loads of other things.

00:28:16 - Christopher Burns

That is not typical with Gatsby or Next.

00:28:20 - Brian Rinaldi

I'd argue that that's, I mean, yes and no. I think it has a lot of the tools built in to do that stuff, but these are things we were doing. I've done, even my current dev site that I run that has auth, and that's all Hugo. It's just some of these pieces where, when you were building a complex Jamstack application, all of these pieces you had to build and orchestrate yourself. I feel like what these tools do is just give you a way to not have to do all of those pieces yourself. So a lot of people were connecting to databases, right? Fauna has been kind of popular among Jamstack developers, for instance, as a database, quote-unquote backend for Jamstack applications. They were already doing this, but they had to build it themselves and set up the orchestration within the application themselves.

00:29:15 - Brian Rinaldi

I feel like what Redwood does is just say, hey, you know what? All that stuff is complex. It's really hard for a developer to manage all these pieces. So we're just going to give you tools to make it easier to do the things you're already trying to do. And you may not need every one of the tools on the list of things that Redwood provides. You probably won't. You may need just a few, but we're going to make it really easy to do that stuff right out of the box.

00:29:39 - Anthony Campolo

Are there any other important tools that we haven't hit on that you want to get into before we move on to other topics?

00:29:45 - Brian Rinaldi

Nope.

00:29:46 - Anthony Campolo

Great. Awesome. I'd really love to know how you both think about the audience you're writing for, in terms of difficulty level and prior experience. How do you approach that? Who do you think the book is aimed at?

00:30:01 - Raymond Camden

I could see someone brand new to development being part of the audience. I came into Jamstack coming from an app server background, and so to me, I could also see that being maybe someone doing .NET, doing PHP, looking for a simpler solution as well. So I would say anyone in web development at any stage who's looking for a new way to get stuff done.

00:30:26 - Brian Rinaldi

Yeah, I'd say each of the chapters is written almost as a complete project, particularly the first ones that are like build the documentation, build e-commerce. They're written almost as a complete end-to-end, like I finish a project by the end of that. Other than general web development experience, I don't write them assuming any other prior knowledge. You don't have to have used Jamstack before. Even the Next.js chapter, I don't assume you necessarily know React. So I don't dig deep into React concepts, but I will show you how you can actually get the job done in Next without even necessarily having to understand all of those pieces. I think it's really for anybody with some web development experience. I don't even know if that's necessarily required, but it probably would help.

00:31:19 - Christopher Burns

When do you expect the book to be fully finished?

00:31:23 - Raymond Camden

Tomorrow?

00:31:24 - Brian Rinaldi

Did Manning pay you to ask us that? Just kidding. We just turned in. We're, well, I think Ray's finishing another chapter, and I finished chapter five. So basically that will get us through the second third of the book. The last third I think is due in like another month or so. I don't know the exact timing.

00:31:50 - Raymond Camden

I've got one more left. That's all I know.

00:31:53 - Brian Rinaldi

But I will tell you that you can get access now. Thankfully they have their early access program. So if you want access to the chapters as they're being written, you can get them. If you get the book now, you'll get the next batch of chapters, which will be coming out shortly, very soon.

00:32:13 - Christopher Burns

Manning have provided a discount code for the book. I can't remember how much it is. I should have revised this. Do you have it, Anthony? We're still new to this.

00:32:24 - Anthony Campolo

Yeah. Yeah, you're supposed to ask.

00:32:26 - Brian Rinaldi

You can always ask. No, it's fine.

00:32:32 - Anthony Campolo

When is Ever Fund going to be finished, Chris?

00:32:35 - Christopher Burns

Ever Fund finished? It's just not fully working yet. Yeah.

00:32:41 - Brian Rinaldi

We're finished. We're just not done.

00:32:44 - Christopher Burns

That's it. You mentioned it about the price. You can pre-read the book before it's finished. That was what I was trying to allude to.

00:32:53 - Anthony Campolo

We've got a discount code for you guys. It's a 30% discount code at pod21, and we'll have a link for that in the description in the show notes.

00:33:07 - Christopher Burns

I'm still waiting for the Purple mattress. I can't wait to get a free mattress.

00:33:12 - Anthony Campolo

Cool. Just to open it up to both of you, is there anything else you'd like to talk about? Other projects that you're working on that you're excited about, or things you want to get out into the world?

00:33:21 - Brian Rinaldi

The only thing I'd love to share is I run these bi-monthly virtual meetups on dev on a whole range of topics. We run a lot of Jamstack ones, but a lot of general web development and just a range of topics. They're all free, so just go to dev and you can join those.

00:33:45 - Raymond Camden

The only thing I would throw out there is if anyone's hiring for DevRel, I know some people who are looking, some very top-notch people. So feel free to reach out to me and I can connect you.

00:33:56 - Christopher Burns

Thank you for the time that you give us today. It's always interesting to take things back to the basics, as you are doing with a book about teaching the essence of Jamstack, and I really did enjoy reading the first three chapters.

00:34:13 - Brian Rinaldi

Thanks. Yeah. The essence of Jamstack. I think that's like a new cologne.

00:34:18 - Raymond Camden

Yeah.

00:34:21 - Brian Rinaldi

The essence of Jamstack.

00:34:22 - Anthony Campolo

So is that the subtitle of the book?

00:34:25 - Christopher Burns

Don't worry. I'm already pitching it to O'Reilly. Essence of Jamstack.

00:34:30 - Anthony Campolo

Does it have a subtitle, or is it just the Jamstack book, like the entire title?

00:34:35 - [unclear speaker]

It is The Jamstack Book.

00:34:37 - Brian Rinaldi

I don't know. I don't think it has a subtitle. It's like, you know. Yeah, yeah, it says The Jamstack Book. Brian's chapters are better than Ray's, I think is what it says.

00:34:47 - Raymond Camden

Yeah, yeah, yeah, whatever, dude.

00:34:49 - Christopher Burns

Well, there are comments where people can say things, so I expect to see on there: The Essence of Jamstack, Chris Burns.

00:34:58 - Brian Rinaldi

Okay, I'll look for it. Then I'm sure Manning will contact us and be like, we need to use this.

00:35:04 - Christopher Burns

Maybe that's the follow-up.

00:35:06 - Brian Rinaldi

Yeah. They'll give you royalties for it.

00:35:09 - Raymond Camden

Yeah.

00:35:10 - Christopher Burns

Thank you for your time.

00:35:12 - Raymond Camden

Yeah.

00:35:12 - Brian Rinaldi

You're welcome. You're welcome.