Exploring the Bounds of Jamstack on What the Jam
Welcome to a new episode of "What the Jam," the show that dives deep into the fascinating realm of Jamstack, bringing you face-to-face with its most influential figures. In this episode, we're excited to feature Zach Leatherman, the creative mind behind Eleventy and a key figure in the Jamstack community. Zach takes us through his journey with Eleventy, discussing the inspirations and challenges behind creating one of the most popular static site generators. He shares his insights on the evolution of Jamstack, its role in reshaping the landscape of web development, and a path forward. Have your say at https://thefutureofjamstack.org
Searchable Transcript
And I think that if Jamstack can succeed, it needs to have a clear definition of whatit is and what it isn't. And if it's just going to be this vague,all encompassing umbrella term, then Jamstack will. Fall and there's no useto keeping it around it has no educational purpose It will have no technical purpose.
It won't mean anything, so if you want Jamstack to succeed it needs to havea clear definition it needs to take hard stances on things and draw some hard linesbecause that's The unique benefits of JAMstack have those hard lines. This is What The JAM,an interview series where we're finding out what's next for JAMstack.
Find out more at thefutureofJAMstack. org. I'm really excited to have the creator of Eleventyand. Handed many pies and Jamstack, Zach Leatherman here today. Welcome Zach. Yeah.Thanks. Thanks for having me. I'm excited to be here. Zach, what does Jamstack meanto you? Oh my goodness. Yeah. Yeah. There's been a lot of definitions over the years.
Um, for me, it's build time rendering. It's been sort of build time rendering from the beginning.You're pretty generating all of your markup and source files and you have a folder of,uh, content. That you can, and assets that you can upload to your web server. Um, and I think maybeover the years, I've also sort of included the, uh, continuous integration server piece of it.
So the get workflow where you commit to get, and it automatically triggers a new bill. Um,I think that that can also, that's. Maybe another piece of it that I really like,but maybe that's not baseline Jamstack, that's an enhancement off, off the, uh,the sort of, yeah, the baseline experience of just having static
HTML files that you can upload to a web server and host very easily.And it's very portable. Yeah, it's, it's a good question of there's different lines here of,of what is core Jamstack. What's a best practice and then what are things that work well with aJamstack? But aren't necessarily Jamstack and I think those three things Often get blended
into a soup and it's hard to pull them apart Like there I think yeah, you're saying the theCICD get kind of workflows of best practices What would you put in those other categories?Uh, what do you mean by other categories? So there's like core JAMstack, um, best practices,and then not JAMstack, but works well with JAMstack. Yeah, I think that, uh,
yeah, what I mentioned is, uh, just core JAMstack has A folder full of files, um,sort of Jamstack enhancements or Jamstack adjacent things, um,is the sort of the workflow process of having an automatic deploy, which I think is great.I love that feature. I think serverless is maybe something where it gets into. Um, more Jamstack
distant, but Jamstack, still Jamstack adjacent. Um, but if a host didn't have a serverless, um,uh, feature built in, I wouldn't consider that not to be a Jamstack host. I mean,it really comes down to if you are a static host, you are a Jamstack host.I mean, it's, it's very interesting because I remember from my personal
website. Sort of back in the day, as I made a transition from WordPress to Jekyll many,many years ago, um, I was still hosting static files on a PHP application serverand I was paying for PHP application server prices, but just hosting static files.And, uh, and I, and I could see my host start to differentiate between the two.
I was using nearly free speech at the time and I still have some things on them, but,um, But yeah, they sort of went through this, this milestone of divorcing the PHPaspect from the static hosting asset aspect, and actually had different pricing models for each.And so it became easier and cheaper for both the host and the person paying the host bills me, um,
to Use a static site and I had to worry about so many, so like less architecture pieces. Um,WordPress went through a very, very hard time for a while. Um, where,yeah, I mean, WordPress instances were getting hacked all the time and therewas a lot of vulnerabilities and you had to keep your WordPress instance.
Updated. You had to watch those updates too, because if you weren't good about updating yourinstance, then your website could get hacked. And I think at one point my website did get hacked,um, when I was on WordPress. Um, I mean, it wasn't like a big deal because they just injected justsome. I don't remember what it was, but, uh, yeah, some extra JavaScript onto my pages.
And this was probably 15 years ago, but, um, yeah, I think at that point I was like, I need to getoff of this and get to something where I don't need to worry about it at all, and that is. Yeah,really what the static, uh, Jamstack experience gives you. Interesting. Was that your journeyinto static and Jamstack, that experience of getting hacked and the pricing model changed?
That, that, that was the push. Yeah. I mean, it wasn't a huge price difference,but it did sort of indicate to me that from a hosting perspective,they were thinking about it much differently. Yeah. Um, and. It was cheaper, yes, but itwas still less than 5 a month or something. It wasn't like a, a huge, huge price difference,
but it did to me indicate that there is an at scale difference between the hosting companypaying for application servers and PHP to run, um, versus just, uh, having a web server by itself.Yeah. Yeah, totally. Like their cost structure, like I mentioned, they hadVPSs set up and. They have to have a certain amount of resource allocated to each PHP site,
which isn't necessarily true with a static site. You can do more of a shared pool. Um,and that's not necessarily a bad thing either. Um, in the way that it would be with a PHP site.Yeah, absolutely. And, and you can kind of see that in what GitHub offers on their free tier too,which is kind of funny. Um, and I think that's how a lot of people got into Jekyll is through. Uh,
GitHub pages and being able to host a website for free, uh,on GitHub pages using Jekyll because Jekyll is built in and that sort ofcatapulted Jekyll's success in the static site generator space too.I mean, GitHub wouldn't have done GitHub pages if it were PHP based things. They just could not have
scaled things at that level, um, or would not have wanted to with the free tier. Um, and so,yeah, I think Jamstack really. In my mind really provides a,uh, an extremely nice on ramp for people, uh, wanting to build a website.It's like, it's great for beginners and experts because it's just fewer things you need to
worry about. And I really love when you can find something that works for all experience levels,um, for maybe different reasons, but yeah, they, everyone likes it for, for,for similar reasons as well. It's like the bell curve with the, the beginner.The intermediate and the master and you become full circle at the end,
where it's like actually simplicity and not having to worry about all this stuffis pretty good. Then you can just focus on making the experience really good ratherthan having to get all these tools to work together. Yeah. Yeah. And I think that, uh,certain people really like getting tools to work together, but I don't necessarily like that.
I mean, I, I. built a tool because, uh, at least in part, I didn't want to have to, uh,configure someone else's tool chain. And that may be part of how it started, but,um, yeah, I mean, yeah, I think it can work for everybody. So let's go to the genesis of,of Eleventy. What were you seeing at the time? Um, and in the like Jamstack space,
um, and why do you feel like Eleventy was, was necessary?Yeah, I mean, it's, it's hard to know if my perspective now has beenclouded by all of the things that have happened since, but, uh, in my mind,I really remember Eleventy sort of coming around the same time as Gatsby did. Uh,
originally, and I remember sort of a lot of discussions around single page applications andclient side rendering and whether or not you need heavy javascript bundles to build static sites.Um, and I really think that Jamstack in a way was. Parts of Jamstack's success werebuilt on single page application models, which I didn't agree with. I didn't think
that that was a necessary condition for, for a Jamstack site to exist because I came from,uh, experiences where. It didn't. I mean, that's how the web has been built for many, many years.I think the original sort of bake don't fry article from Aaron Swartz was like2003 or something. It's, uh, so the ideas behind it have been around for 20 years. Um,
but I think the branding piece of it was, was a little different. And it did sort of ride the,the same marketing wave of. single page application frameworks, um, originally.And I think that's where it got maybe some, some good marketing bumps from, um, and I think it's,I think it's important to acknowledge that too. Um, because things are a little bit
different now. Uh, And yeah, I think that, uh, that's okay. Jamstack doesn't need to be,uh, a silver bullet. And we've kind of talked about this before.Um, it doesn't need to be everything to everyone. And I think if we try to makeJamstack everything for everyone, um, then it loses meaning. A hundred percent. And yeah,
I think. It just makes it hard to, to talk about it as well, if it's so broad,because it's like, well, which part of the JAMstack are you talking about?Are you talking about applications or are you talking about static websites or something inbetween? Um, I think that's, that's been one issue with expanding the definition and the,
the kind of trajectory of a lot of JavaScript frameworks. It's normalized a lot of things that,that is really against at least the, the initial ideas behind the JAMstack.Like now we're okay shipping huge JavaScript files. We're okay doing server side renderingon what essentially should be a static website. Uh, we're okay not using HTML
and CSS and using JavaScript to do those things instead. And it just It's sad,I think, that that has been normalized so much. Yeah, and I think, I think it's a, I mean,web development and front end web development specifically tends to act like a pendulum.Um, and it swings sort of back and forth and I've been around, I think I've been a,
I've been a paid front end web developer for 17 years, 18 years now. And so I've been around longenough to sort of see some of those trends, repeat them, repeat themselves over and over again. Um,and I think that I'm hopeful for the next wave, which seems to bethe pendulum swinging back towards, um, less JavaScript and, and better performing websites.
Um, Yeah, away from sort of the default of single page applications for everything,um, which I don't think is a good default choice. I'm fine with it as a choice. Idon't think it's a good default choice. What do you think the default choice should be? I mean,it really depends on what style of application and what style of website that you're building.
But it's really hard to get away from the basics of HTML and CSS as the starting points. Um,and whether or not you're even using a site generator at all, I think, is a,is an extra layer on top of that question. You could just have, uh, an HTML file that existson your web server, and that's a website. Um, I don't know why I mean, people get so tied up in,
in building all of these sort of Rube Goldberg style machines to build websites, but I reallythink that if you look at what you need to share content on the web, it's just an HTML file.You can add some CSS to even make it look pretty. And at that point,the user experience is imperceptibly different. than if you had introduced a JavaScript first
tool. So what I mean to say is, you can, with CSS and HTML, with just those two things,you can make a website a very, very super modern, very great looking website, um,that will be so much better than anything that a JavaScript toolchain will introduce.And I say that as someone that has currently maintaining a tool that is
a JavaScript toolchain tool. Um Yeah, I think it's really important for people to understandthe minimum viable things that you need to build a website. And really, I think a modern websiteonly needs HTML and CSS now. Um, I don't think you can get away with HTML only at this point.You've got to make it look a little bit better, but, um, CSS will get you
a hundred percent of the way, um, for a lot of use cases. Yeah. It's easy to forget that,you know, these are the technologies that. The platform is understanding and it's,it's a question of how you get there, whether you just write the thing thatthe browser is going to interpret, or whether you have a whole tool chain
behind generating that and both are useful, but for, for completely different use cases.And the former probably isn't used enough. It's just a lot of overengineering. Yeah,and I mean, I think that's maybe the secret to Eleventy's longevity has been that we reallytry and stay right above that reusability layer of you're building something with the
bare minimum, you suddenly need some reusable templating, um, and maybe some data injection.Um, and. We really don't exist. We try to stay as close to that minimum as possible. Um, we don'thave a bundler by default. We do have a bunch of plugins that you can add on top of Eleventy. Um,but really the baseline core experience of Eleventy tries to stick as close to that
as possible. Um, that step right after you sort of get to the reusability question andyour site needs a little bit more needs to be a little bit more maintenance friendly.Um, and yeah, I think sticking to that and having sort of a web standards basedapproach can you can have a website that last 10 years, 15 years, um,
which is maybe. Not how a lot of, uh, folks think about having websites, but that's whatI want for my websites. I don't want to have to rewrite my tech stack every two years,which is, seems like it's a very common thing in the JavaScript ecosystem world.Um, I want some longevity. Yeah. Yeah, totally. Um, what, um,
I want to throw some names at you for, for what we could call this community and this approach,um, and get, get your feedback on it. So one, we have Jamstack,keep it the same. Jamstack is, uh, it's a term that's used throughout the industry and is.Somewhat understood, but also, there's a lot of conversations like this one,
just trying to understand what it is. Um, then we have Jamstack Plus,which recognizes that Jamstack kind of has this, these um, ambiguous edges, and it would be anattempt to tighten that up. Static first, which is going back to what you were saying earlier.It's, it's really trying to emphasize that the choice should be static first
and then use something else. If that doesn't fit the case,or, um, the final one is a new term that is, I don't have a word, but is like aninteresting cool word that doesn't have any meaning about the static, the stack itself,but it would be a community and an umbrella that this community could, could fall under.
What do you think about those ideas and what are you drawn to there? I mean,I am a fan of JAMstack as a term. I like the JAMstack term. I like whatit did for static site generation. Um, I feel like it has been transformed in away that has been damaging to it. Um, But I do also feel like it still has value.
Um, I think that it has an incredible amount of community knowledge of sort of Jamstackas an architectural model. Um, that I do not think is, uh, I do not think it's somethingthat should be thrown away. Um, so I, I am a fan of Jamstack. I. I think that it has had a hardtime in the last year or two, um, just with the introduction or the, maybe the popularization of,
uh, uh, non Jamstack tools sort of trying to fit non Jamstack tools under the umbrella.Um, and yeah, I don't think that that's a necessary. thing that JAMstack needs to do.It needs to be a laser focused definition of what it is and what it isn't. Um,so that it can be a valuable discussion point and a valuable educational thing. Um,
so I, I am a fan of JAMstack. I do like the term JAMstack. Um,I, I don't even necessarily think that Jamstack plus needs to exist.I think that we can just have technologies that are sort of Jamstack adjacent. And if we need a,a new term for that, that's, that's fine. Um, but I don't, I don't know if I'm a fan of,
of having a, a second term that acts as like a, an umbrella for the things that,um, I think cheapened the, the original definition of Jamstack.Um, Because I think it's better. And I think people respect the intellectualhonesty of being able to say, this is what it is. This is what is it. This is what it
isn't. This is what you use it for. And this is what you wouldn't use it for. Um, so yeah,that's kind of where I'm at on that. Yeah. Wait, just diving into that one.Where do you think was too, where do you think Jamstack went too far? Cause like I've rewatchedMatt's announcement of JAMstack at Smashing Conf 2016 recently. And there was a, there was a big
emphasis on the reason for needing a new term was because static is like a loaded term that peoplethink that it means simple and there's no interaction on the page and it's like lesser and.And if you're trying to sell that to someone, maybe non technical it's,it's tough to just that alone, even though there are so many benefits and
so many websites would be served better if they were static. Um, but over the years it,that definition has expanded to the point where now I believe it includes server side rendering.Um, it's unclear what it doesn't include to me. Like where, where do you think that was pushed toofar? Yeah. I mean, it's interesting to look back on it because, uh, I think that in many respects,
the, the Jamstack 2. 0 pivot was an interesting milestone. And that was sort of when at the sametime it was renamed from J A M stack and JavaScript, uh, APIs and markup.To, um, sort of the title case version, uh, just like a standalone word. And I'm,I liked the, the branding change. I was in favor of that. I didn't think that JavaScript APIs
and markup was particularly, a particularly useful descriptor. Um, but at that same time,you could see the industry, um, also sort of giving rise to frameworks that were.Not statically generated, so your remix and, uh, certain aspects of Next. js,I think, really pivoted away from Jamstack core principles. And at the same time,
Jamstack tried to include those, um, in a way that I just don't think that it makes senseto include those. Um, especially looking back on it, it doesn't make sense to include those.Um, they're not static frameworks. They're not, um, JAMstack frameworks. And I don't even thinkthe authors of those frameworks would disagree. Um, so it, it felt like a, an overreach in many
respects to, to try and include those under the umbrella, um, in a way that it just didn't,it didn't make sense to, uh, to the definition of JAMstack as most people understood it, I think.Yeah, agreed. Cause like, I think Jamstack, the movement,everyone has a WordPress story like you did before of security or performance, ouch,
static websites. Nice. And I think Jamstack was the antithesis of, of WordPress in 2016.And a lot of people came on that journey from WordPress. Everyone has that story.But now, it's hard, it, like, I find myself asking, like, is WordPress jam stick? And it,like, if it's not, then why not, it, it kind of, it meets the definition, uh,
you know, if, if server side rendering can be included in the definition,then why not WordPress? Oh, with the modern definition. Yeah. I think thatthat is a very good point that under the modern definition, it's hard to.Discount, uh, PHP style things as non Jamstack. But I mean, as we've said in this discussion,
I, I don't think that WordPress is a Jamstack framework. Um,and I don't think anything that sort of does that runtime processing in PHP is a Jamstackframework. I don't, uh, yeah, I don't think it makes sense to include that.But it's also just sort of fascinating to, to look back on the history of that Jamstack
pivot as well, because, uh, I used to work for Netlify. So, uh, I sort of saw some ofthat decision making behind the scenes. And, um, I remember sort of the very. WordPress focused,uh, mission of the company. Um, and I was really on board with that.I thought that, uh, Jamstack was a great alternative to WordPress and WordPress was
this huge comp competitor, um, and they power a ton of the web. And so I reallythought that Jamstack was going to be a great alternative to WordPress. Um,and it didn't dethrone WordPress like, like maybe I had hoped, but,um, I think at the same time you saw sort of like Vercel coming in and competing in the same space.
And, um, I really think that that was a huge, huge influence on the, on the pivot as well. Um, yeah,I think that that's the primary reason that the pivot happened. Yeah. Yeah. It's like,just, I guess WordPress is saying is legacy weird and, and. Um, Next. js is like the hot new thing,but it's easy to forget that I don't have the stat on hand,
but it's something like 60 percent of the web is WordPress, right?That's the elephant in everyone's room. Yeah. WordPress is dominated. All of the JavaScriptframeworks, I mean, it's just, it's making so much money and it's this big, huge success story. And,but yet it has all of these very obvious flaws. So, I mean, that's sort of maybe getting into,
uh, the Netlify pivot, but, um, yeah, I really think that WordPress should be a thing that is.Competed with more directly. Yeah, agreed. So what do you think needs to happen inthe Jamstack community for it to remain relevant, um, in the web ecosystem? Yeah,I mean, that's a, that's a very interesting question. Will Jamstack be able to stand on
its own as a, a well established and well documented architecture pattern?Or will it be seen as sort of this legacy thing that people are moving past? And Ithink that if Jamstack can succeed, uh, it needs to have a clear definition ofwhat it is and what it isn't. Um, and if it's just going to be this vague,
all encompassing umbrella term, uh, then. Jamstack will fall and there's no use to keeping it around.Um, it has no educational purpose. It will have no, uh,technical purpose. It won't mean anything. So if you want Jamstack to succeed, um,it needs to have a clear definition. It needs to, um, yeah, take hard stances on things, um,
and draw some hard lines because that's, um. The unique benefits of JAMstack have those hard lines.Um, and that's, that's it. And that's all I guess. Nice. Those are the greatconversations that so much, thank you so much for joining today. Yeah, I reallyenjoyed it. That's it for today's interview. Find out more at the future of JAMstack. org.