Your Guide for Building a Jamstack Website

Ready to go beyond static sites and leverage Javascript, APIs and markup? In this episode, Brian Rinaldi and Ray Camden, authors of The Jamstack Book, explore the past and future of this new standard architecture for the web. They provide you with a list of their favorite tools and cover how their book can help you build your first Jamstack website, including advice on the correct framework from deployment to production.

Intro

Brian Rinaldi: Hi, I'm Brian Rinaldi. I'm a developer advocate at StepZen and one of the co-authors of "The Jamstack Book" from Manning. My other co-author, Ray Camden Camden is here with me. Ray, can you please introduce yourself?

Ray Camden: Sure. Thanks, Brian. I'm Ray Camden. I am a developer evangelist for Adobe. I wrote the good half of the book. Is that how it is, right, Brian?

What the heck is the Jamstack anyway?

Brian Rinaldi: Yes, I think that's right. Especially because I'm not done with my half yet. That's right. So, yeah, we're going to talk about our book, obviously called "The Jamstack Book." So, it's about Jamstack. For those of you who haven't heard of Jamstack before, we're going to go over a little bit of an introduction of what Jamstack is, which is actually a really, really important question when it comes to Jamstack because there's still some debate for anybody who hasn't been around the Jamstack world for a while, you know, we started, what, 5... 2015 or 2016 I think it was.

I can't remember what, 2015 I believe. We started with JavaScript APIs and markup was "the JAM." And that has evolved. Nowadays, we don't capitalize the Jam anymore. We just do it all lowercase, or I guess with a capital J. But that's partly because the definition of Jamstack has evolved quite a bit. Ray, how do you define the Jamstack?

Ray Camden: Sure. I think about its evolution. We started talking about this, as you were saying, five or six years ago, back then it was just static websites. I had presentations on the intro to static websites and stuff like that. Every time that we would talk about it, there was always this, yes, it's static, but you can do X, Y and Z to make it dynamic, to make it up to date, to make it relevant, in comparison to a traditional ad server site.

For me, the Jamstack, it's all about having the power and the flexibility of a traditional lab server but having the simplicity of a mostly static production build. Most of my website is static and just flat files as it should be. It doesn't have to be drawn from a database because the content's not changing. The parts that do need to be dynamic there, dynamic with JavaScript, are dynamic at build time. It's kind of the power of the app server without having to worry that it's actually running.

Brian Rinaldi: I think generally, I agree with your definition. When I talk about this, I give it a little bit of a different take. First of all, I tell people, like just forget the jam. Forget the jam. Because so many people started with JavaScript, APIs and markup. Part of my trouble is that doesn't really differentiate much because everybody's like, "Well my, server-side react site uses JavaScript, APIs and markup. So I'm doing Jamstack." It's like, no.

So, I focus on some of the things, the key pieces, which I mean, I think a static site generator is a critical piece of the toolset. I think that leads into the build that, kind of, CICD process that we've adopted now almost like a de-facto standard. When I started doing this stuff at Jekyll, I remember I was using a little tool that would help me FTP the results to my server. 

That was not Jamstack, that was just static sites. Now, I think part of that process is being able to check stuff into GitHub, or wherever you have a repository, have that stuff built and deployed for you is a critical piece of the process.

Then the other critical piece to me is the deployment is going to see the end. It's not going to a web server. That's the key thing that gives it security and speed and things like that. That’s a critical piece of the infrastructure of what makes Jamstack what it is. If you can deploy it to the CDN, that's, kind of, the important piece. So, yes, I agree with everything you said. And yet I would add those pieces layered on top of it: the static site generator, the CICD process and the deploying to edge servers/CDN.

Ray Camden: Which we thank God is kinda like brainless nowadays. .I don't think about the CDN, per se, like my host just does that for me, which has been in this business for a very long time, that is an incredibly simpler approach compared to what I used to do:  FTPs, sync files up and make sure you don't forget the one for a health check and stuff like that.

The history and evolution of the term Jamstack - how things are changing in 2021

Brian Rinaldi: Yes, exactly. I remember I had some command-line tool that actually would manage the deployment via FTP because it became such a pain because you were constantly overwriting the site. I think it is amazing how simple this stuff is. Because all of that sounds complicated, it's like, "Oh, the CICD to the edge servers and CDNs." And even serverless functions and all that. Then all I'm doing is just checking files into my repository, and the rest is all handled for me, right?

Ray Camden: Absolutely. I know, like a totally separate discussion would be, if modern web dev is too complex. And having been in here like you like since day one, pretty much, I'd much rather be working now than how it was 20 years ago.

Brian Rinaldi: True, it's true. Otherwise, I think then the complex issue, like Jamstack is sitting in the middle of that debate in a way because we have two ends of the spectrum on tools. We have things like, "Well, I know, it's not your favorite, but Hugo or Jekyll or whatever, or even Eleventy, which are, kind of, a little more traditional static site generators. You have tools like Next, and Nuxt, and Gatsby that are much more complex. Particularly Next has been driving Jamstack in a slightly different direction with the introduction of incremental static regeneration, which now Netlify has added in with their proposal for DPR. It's distributed persistent rendering, yes. Distributed persistent rendering.

Then you also have the addition of li Next that allows you to say, "Oh, by the way, just this one route is server-side rendered." So now it's not 100% statically rendered. There's this route, or maybe a couple of routes are server-side rendered. 

One of the things that I loved about "static sites" when we started doing it was it was simple. Then things got a little bit more complex but it was still relatively simple. I was deploying some serverless functions. I'm doing some other fancy stuff.

But now things have gotten to a place where you can do a Jamstack that is incredibly complex with all kinds of complicated deployment features and server-side rendering and distributed persistent rendering. For anybody who doesn't know what .distributed persistent rendering and incremental static regeneration is - when you have a really, really large site, and the build can take a really long time. So I don't want to have to build every single page because a huge chunk of my website probably rarely gets visited.

I could then deploy a bunch of my site that's, kind of, the pages that are typically traffic... get a decent amount of traffic, and the rest are rendered on-demand. What's different from that and server-side rendering is that is basically it's still a static rendering, but it renders the first time for the first person. And then everybody else gets the static page. So it's gotten to that point is when it is a little complicated. We are, kind of, getting back to being complicated again.

Ray Camden: Well,  I don't think it was ever totally simple. I saw this in the presentation. I can't remember the guy's name. But he said it's not necessarily about removing the complexity but moving it closer. 

I've had simple sites where I've had the right, Node.js scripts to do stuff, and you talked about the script you had for FTP. There were complex things locally, like even my blog, I have some complex things going on, on my machine here locally.

But, in general, in deployment, it's pretty simple. So, there's still a certain amount of complexity, but I like having it on my machine because I feel like I could actually handle that. If a CDN goes down, there's no way I wouldn't even know how to set that up. So, to me, it's a better complexity to manage. One of the reasons I love WordPress is because I did not want to manage its caching along with PHP and Nginx. I didn't want to manage that in production. I'd much rather have something to manage on my own machine locally.

Brian Rinaldi: Yes, and I think it goes back to something Matt Billman said. I don't remember exactly where he said this but about, yes, you can do like caching on WordPress, for instance, and get a similar result to what you'd get with Jamstack in some respects from a speed perspective, maybe. But most people don't do that. Partly because it is complicated. Managing that cash isn't a simple task. I know because I tried to do it for a WordPress site that I was running. It's like, okay, well, but some of this stuff is cached and other pieces aren't cached. Then managing how it handled the caching of the blog content versus the comments and other things that were not necessarily cached was not really a simple task. So, a lot of people just end up not doing it.

I don't miss having to deal with calls where you get somebody writing you or emailing you and calling you saying, "I'm getting errors because the database connection is failing.”

I remember I used to do with that one all the time, particularly when traffic spiked, and those things are all-out gone now. Outages are rare. It happens, but it's very, very rare. If traffic spikes, I'm not worried the site is gonna go down. One of the things I find that new people to Jamstack don't realize is they think that when the site's building, if it fails, oh my god, the whole thing is going to collapse. It’s like no, no, no. I mean, that's the whole atomic builds, atomic deploys, it either all succeeds or it just doesn't deploy.

Nothing is down while it's building. If the build fails, it just stays with the old build or if something doesn't build properly and it does deploy, you can roll it back, without a problem. It’s hard to remember days when we had to deal with those kinds of issues. I remember one time years ago, I accidentally deployed via FTP something to the wrong sub-folder, and oh, my God, it was such a disaster trying to unwind that mess. But now we don't really deal with that, like all that's automatic, so.

Ray Camden: I do remember modifying a load balancer to point to like a new server. That was the way I did A/B testing or updating to a new version. I set up a whole new server, a whole new site, and then when I tested it there and I was happy, I modified my load balancer. I don't wanna do that. 

Brian Rinaldi: I do think though we are seeing quite a lot of change in the Jamstack world this year. We may even have to go and tweak some of the chapters again because things are just changing pretty fast this year, partly because it has started to gain some mainstream adoption and larger companies are trying to use it and dealing with more complex problems on their sites. Even things like distributed persistent rendering-  most sites I build are not gonna deal with having hundreds of thousands of pages. Maybe your blog. But other than that most people aren't dealing with that problem.

But if you're a big e-commerce operation, or a large enterprise company you do have hundreds of thousands of pages, and this does become an issue. You and I might be comfortable editing markdown or even some of the CMSes that the UI works, but it's not great. It doesn't have that comfort of WordPress UI, which I grant WordPress does have a great editing environment.

So then we have to start dealing with the marketing team is editing their pages, but then they're waiting on a build to happen to see and then realizing they made a mistake, and then they have to go through that whole process all over again, wait for the deploy to fix that little mistake. 

We're starting to build tools that allow inline editing and previews and stuff like that. And so things are changing quickly, I think because big companies are adopting this.

Ray Camden: Yes, some of that you touched on. Back in the old days, there was a list of things where static websites were appropriate. Like, e-commerce wasn't one of them... and we're seeing that Jamstack is just inching that bar up and up. 

I still could not say 100% of every web idea you had would be appropriate for Jamstack. But that number's a heck of a lot higher than it was when we started talking about this. Definitely, e-commerce is absolutely supported for Jamstack. So things maybe get more complex, but it's because Jamstack itself is being able to be used in more and more places, which is great.

Brian Rinaldi: So, for people who don't know, you and I wrote a book years ago, and that was actually static sites. It was just about static site generators. In the opening chapter, I did talk about what would static sites be good for? It was a list of like a handful of things. So these are the great solutions that this is perfect for. Back then it was easier to count out the things that it was good for. Now, it's like I was trying to write the equivalent chapter for this book and have a similar list of what is this good for, not good for?

I'm sitting there trying to think that I could count on my hand maybe what I wouldn't recommend doing with this as opposed to the things that I would. Even those things I wouldn't recommend now. I would say you could do it, you totally could do it, and it would work. It's just maybe a little bit more complicated doing it that way than the alternative, but you could do it. So there are very few things that won't work for Jamstack. So, it is changing very quickly.

Ray Camden: Yes, I think that's less of could I do it? I think you could almost build anything. It's not like, okay, have I done too many workarounds to make this worthwhile at this point? But I don't think there's anything I couldn’t at least try to build with Jamstack now, which is nice.

Brian Rinaldi: Yes. I mean, now people are even doing a lot of user-generated content, which at the time we couldn't really do that. So, now, if you have like, you could either write out files and have the whole thing rebuild, or you can call a serverless function and populate that way client-side or, you know, there are even more complicated solutions that rehydrate the page and rerender that page when a new comment is submitted, for instance, as an example, if there's a comment system or something. You'd only rebuild that one page that had the comment and things like that. 

We've gotten to the point where even some of that stuff, which I wouldn't have imagined four years ago like the example with user-generated content, is doable now. It can be Jamstack. 

Ray Camden: So the good news on that is yes we can we do it? We're allowing people to post on our website, what are they saying? When I talk about comments, in particular, I'm like, "Yes, you may not want comments, like ask yourself if it makes sense for  your content and your audience if you actually want people writing stuff."

What are your favorite Jamstack tools and why?

Brian Rinaldi: So, changing topics a little bit. I know we talked a little bit about Jamstack tools. Tell me, what are your favorite tools? I mean, what's your favorite static site generator? Where do you like to deploy your sites, etc.?

Ray Camden: Absolutely. I am in love with Eleventy. It has a good set of features and that good flexibility that I look out for. Other static site generators I've used in the past have had maybe great features, but were very inflexible. I feel like Eleventy hits that perfect mid-mark. It gives you some tools and what is not given I know that I could write, I know I can do anything. 

Jekyll, I really liked everything about it. But when it came to doing something custom, you had to write Ruby, and not being a Ruby person that was an issue for me. It's not an issue with Jekyll. It's this issue with me not knowing Ruby. Eleventy being based on Node.js means, you know, I can use JavaScript, and JavaScript's perfect. I could do anything with it.

When it comes to deployment, Netlify is... you know, I call it the gold standard. Not that it's perfect. They definitely have some things to work on. But they're leading the way in terms of your Jamstack. 

I think I put all of my real slides on there. I do like Vercel a lot as well. I find Vercel is a bit easier for temporary stuff or, like, I just wanna run this real quick online, and then you do a proper build. So, I'll use Vercel for everything that I'm playing with and then Netlify for my more real stuff. Not that Vercel couldn't handle real stuff either. That's just the way that I've been doing it. How about you, Brian?

Brian Rinaldi: I flip back and forth between two static site generators, depending on what I'm trying to build. So, I still love your favorite static site generator, Hugo.

Ray Camden: I haven't said anything to anybody. I just wanna say, I have said nothing about Hugo today at all.

Brian Rinaldi: Oh, I know.

Ray Camden: That's good for you.

Brian Rinaldi: It's fine. A lot of this is personal taste. So, it's okay to not like a particular static site generator because it's just a matter of like, I like the way that works. And because, as you said, it's a lot of you working locally doing stuff. So, if it doesn't work for you, it matters nothing to the user. They don't know how their site was generated. 

It matters to you and your workflow. So, it's fine. I think I like to give you a hard time, but it's ok. I mean, there are other ones that I've tried that I don't like at all, and I wouldn't use, but I think for somebody else, it may work for their workflow perfectly. So, I do like Hugo, and if I'm doing a site that doesn't require the full react or whatever, framework-based front end, I will use Hugo. That actually amounts to a lot of sites.

The great thing about Hugo is, it's blazing blazing fast. I mean, the builds are so fast, you usually don't even realize it, you think something must have gone wrong, that didn't build, but it did. 

Things like distributed persisted rendering and stuff often solve a problem that like, if you could use something like Hugo, in which you can't always, it could generate those thousands or even hundreds of thousands of pages pretty, pretty quickly.

But when I do need more complex UI interactions that a framework, JavaScript framework would offer me, I tend towards Next.js. I will say I've struggled with React in the past. Next.js helped me get to the point where I'm comfortable enough in React because I don't have to deal with the routing. It makes the routing really easy. I like the way it handles things like static props and static routes and stuff like that for pages. All that I find pretty straightforward to deal with. I think it has a lot of really cool features, it's relatively fast for building.

None of the JavaScript...Eleventy, I think, is probably the fastest one. None of the kind of, framework-based ones tend to be very fast for site builds, but Next.js is pretty good. It works for me when I need that complex front-end. I often struggle, though, with this is where you get into particularly when you're using a framework-based solution. Is that happening on the front-end, or during the build? Is this variable being generated at which point, which is something you don't generally have to think of when you're just building like a traditional server-side rendered thing? Where is this? Is this variable being created? And can I access it on the front-end and, you know, things like that?

I guess if you do in, in a server-side React app, you might have the similar, kind of, things, but you're not having like this variable only happens on my local machine because when it's being built, as opposed to,  being accessible on the client or anything like that. So, I often struggle with that. I can't figure out where this is happening and it's causing me errors. But I still like it.

Where do you see Jamstack headed to in the next years?

Ray Camden: Oh, open-ended question: where do you see things changing in the next couple of years?

Brian Rinaldi: That is a good question. There seems to be a lot of debate within the community about some people wanting to broaden what is Jamstack, kind of the definition of Jamstack to focus on things like just the edge deployments and the tooling. I worry about that because I think we've already got too broad. But then things like DPR, and server-side render routes, and I think that's going to become more popular.

Tools like Nuxt already adding it. I know Zack is still working on "Eleventy Cloud." I don't know exactly what he's gonna call it now. But basically would allow that kind of stuff for Eleventy. So, I see those things continuing to gain momentum. Some are blurring the line between what is Jamstack and what isn't Jamstack? So, I do see us struggling to define it when you have some people arguing on what's the difference between a server-side rendered, app that caches the routes versus a Jamstack app that pre-builds the routes? It's like terminology difference, really, in many ways. But I do think those things are going to continue to evolve very quickly, particularly as larger companies are dealing with complex problems that widespread adoption has brought us. What about you?

Ray Camden: You touched on being too broad, or maybe becoming too broad. I know in the decade I did working in ColdFusion, if somebody was building a site, it was an app server, whether it was PHP, .Net or ColdFusion. It was an app server, like that was the assumption was that you'd have a web server plus an app server. Requests would come in, they work together to generate, but there wasn't really a question. That was just how you did it. 

I think we may get to a point where Jamstack solutions, and there are so many of them, so that may become the norm. When somebody comes in and says, we are building, you know, soandso.com...Don't go to soandso.com. I have no idea what it is.

But you're building some website. So, just the assumption, they said, it's gonna be Jamstack, it's gonna be statically rendered, we will be enhancing it with JavaScript. We will just have to figure out what solution makes sense for that. I think Jamstack will be the default way to build things. Whereas ad server will be, oh, you know what? We're the 1% very weird. We really need that dynamic thing for every single result out there. That'll be the outlier.

Brian Rinaldi: Yes, it will be interesting. I know there's been some pushback to where people are like, "Oh, you know, maybe it's better if we just render everything on the server, kind of, thing." But you and I have been around this industry long enough to know we shift back and forth. There's not a straight path to moving things forward. But  I think you're right. That's even the debate I got into:  if you define this more broadly, it's just web development, then. I guess some people like, "Yeah, that's fine with me." 

Ray Camden: I'm fine with that. Yes, it's good. It keeps us employed.

The Jamstack Book

Brian Rinaldi: So, for anybody who's interested in our book, it is already available. I don't know when this recording will be out. But it definitely is available in what they call Manning Early Access Program, which they call MEAP, which basically gives you the chapters as they're written. There are only two chapters that aren't out. I take full blame for that. That's totally my fault because that's all on me. Those two chapters are mine. But that means that they're gonna be really, really good, unlike some of the...But yeah, so it's definitely available that way.

The actual physical book, which, I mean, we're lucky enough to have a physical book because so many things aren't published that way anymore. The physical book will be out I think sometime in the fall, early fall like September, but I'm not sure of the exact dates. Please go ahead and buy it and share any feedback you may have with me or Ray, particularly if it's bad feedback, send it Ray's way. I'll let him sift through over there. So we'd love to hear what you think of the book.

There are a lot of other books that said we're gonna just teach you Jamstack by teaching you Gatsby or teaching you Next or whatever. For Ray and I, one of the things we love about Jamstack is there are like 100 different ways to do this. So, we try to, give you a taste of a number of different ones and building different types of solutions. 

For example, building a documentation site with Hugo and a blog with Eleventy and an e-commerce site with Next.js etc. So you kind of get a taste of all of them and all the potential solutions so that you can find what works for you. As we said, this is very much like a what works for you kind of thing. All of these tools have a very different feel. That's what the book's like. Any anything additional to share about the book on your end, Ray?

Ray Camden: No, I think you covered it well. Definitely buy one for you, buy one for your loved ones. Buy a second e-copy for you in case the first copy gets destroyed by a virus. Buy as many copies as you can, so I can keep buying more Legos.

Brian Rinaldi: Yes, we're gonna need a lot of books sold for more of those Death Stars.

Ray Camden: Just a few more copies.

Brian Rinaldi: Legos are expensive. All right. Well, Ray, it was good meeting you.

Ray Camden: It was good talking to you as well.

Brian Rinaldi: All right. Thanks, everybody.

About the speakers

Brian Rinaldi is a developer advocate at StepZen. Brian has been a developer for nearly 20 years, working with front-end and back-end technologies mostly focused on the web. Brian serves as the co-editor of Mobile Web Weekly, authored a report on Static Site Generators for O'Reilly and is co-author of a book for O'Reilly, also on static site generators. You can follow Brian via @remotesynth on Twitter.

Raymond Camden founded many community websites, including CFLib.org, ColdFusionPortal.org, and is the author of open-source applications, including the popular BlogCFC blogging application. He is currently a developer evangelist at Adobe. He is the happily married, proud father of three kids and is somewhat of a Star Wars nut. You can follow Ray via @raymondcamden on Twitter.

Recommended talks: Explosive Velocity with a Modern Stack • Tejas Kumar • GOTO 2021

Emulating a 6502 system in JavaScript • Matt Godbolt • GOTO 2016

You Really Don't Need All That JavaScript, I Promise • Stuart Langridge • GOTO 2020