Eleventy with Ben Myers

Episode Description

Ben Myers explains Eleventy's strengths as a lightweight static site generator and explores the new serverless mode that brings on-demand rendering to the Jamstack.

Episode Summary

In this episode, Ben Myers, a web developer and accessibility advocate at Microsoft, joins the show to discuss Eleventy (11ty), a JavaScript-powered static site generator he's deeply passionate about. He explains how Eleventy takes content written in formats like Markdown and converts it into lightweight, pure HTML — making it ideal for blogs, documentation, and landing pages rather than highly interactive applications. Ben walks through key concepts like templates and the data cascade, illustrating them with a real project he built: a developer events calendar. The conversation then shifts to Eleventy Serverless, a new opt-in build mode that allows certain pages to be generated on demand rather than at build time. Ben demonstrates this with examples like a color contrast checker and a Twitch chat overlay tool, highlighting how serverless routes can handle dynamic data while still delivering plain HTML to the end user. The hosts and Ben discuss how this compares to rendering strategies in frameworks like Next.js and Gatsby, with Ben advocating for using the right tool for the job and avoiding unnecessary JavaScript overhead. The episode closes with a discussion of Eleventy's documentation needs, a call for community contributions, and excitement around Eleventy reaching version 1.0 with full-time open source funding from Netlify.

Chapters

00:00:00 - Introduction and What Is Eleventy

The episode opens with a lighthearted exchange about framework loyalty before Anthony introduces Ben Myers, a returning guest who previously discussed web accessibility. Ben is a web developer and accessibility advocate at Microsoft, and today's topic is Eleventy (11ty), a static site generator he's passionate about.

Ben describes Eleventy as essentially "Jekyll, but JavaScript," a tool that takes content in formats like Markdown and converts it into pure, lightweight HTML. He emphasizes that its Node.js foundation makes it approachable for front-end developers, while noting that Eleventy intentionally isn't designed for highly dynamic, interactive applications — and that's perfectly fine. For content that can be expressed as static HTML, Eleventy is an excellent fit.

00:03:35 - Building with Eleventy and the Data Cascade

Anthony shares how he first encountered Eleventy through a developer events calendar project he built with Ben. The calendar used Markdown files for individual events that were transformed into cards on the front end, showcasing Eleventy's strengths for content-driven sites. Ben explains why Eleventy was the right choice: the project was essentially a collection of articles that didn't need heavy interactivity, just lightweight HTML.

Ben then introduces the data cascade, which he considers one of Eleventy's most powerful and important concepts. The data cascade is an order of operations for how data is made available to templates, ranging from global data down to template-specific data, with more specific data taking higher precedence. This system allows developers to set sensible defaults at the global level while overriding them on individual pages, enabling flexible configuration that new contributors don't need to worry about.

00:08:51 - Eleventy Serverless Explained

The conversation shifts to Eleventy Serverless, a new opt-in build mode that allows certain templates to be generated on demand when requested rather than during the build step. Ben explains how traditional Eleventy sites are entirely pre-rendered, meaning they can only reflect data that was true at build time. Serverless changes this by running Eleventy inside a serverless function to create pages in real time.

Ben illustrates this with a color contrast checker that would need to pre-build trillions of possible combinations if done traditionally. With serverless, pages are only built when someone requests them, and they can optionally be cached using tools like Netlify's on-demand builders. He also describes Show My Chat, a Twitch overlay tool that uses query parameters to generate themed chat displays on demand. Crucially, the output is still plain HTML — no client-side framework rehydration required.

00:15:54 - Buzzwords, Rendering Strategies, and the Case for HTML

Chris brings up the alphabet soup of rendering acronyms — SSG, ISR, SSR, DPR — and the group works through how Eleventy Serverless maps to these concepts. Ben prefers Brian Rinaldi's term "deferred rendering" for its clarity. The conversation then turns to how Eleventy's approach compares to frameworks like Next.js and Gatsby, particularly around what gets sent to the client.

Ben makes a strong case for sending plain HTML rather than large JSON payloads that require client-side rehydration. He uses the example of restaurant QR code menus during the pandemic — sites that send entire JavaScript frameworks when users just need to read a text-heavy menu on a slow mobile connection. The discussion highlights how lightweight HTML delivery respects users' limited bandwidth and data caps, and how Eleventy's approach is fundamentally about being a responsible steward of user resources.

00:23:22 - JavaScript Responsibility and the Right Tool for the Job

Chris playfully pushes back with the argument that JavaScript can handle everything, but Ben counters with a thoughtful point about JavaScript as both an enabler and a responsibility. He uses the example of a documentation site fetching GitHub stars — a minor feature that introduces complexity around error handling, loading states, and API failures when done client-side, versus simply hard-coding the value and updating it with a nightly build.

The group discusses how Eleventy Serverless is additive rather than replacing existing functionality, citing examples from community members like Brian Robinson and Stephanie Eckles who add serverless search to otherwise static blogs. Chris notes that many modern frameworks start developers with the biggest possible engine rather than the smallest sufficient tool, and Ben agrees that Eleventy's opt-in philosophy is a healthier default.

00:29:12 - Documentation, Community, and Looking Ahead

Anthony asks about Ben's contributions to the Eleventy documentation, and Ben explains that he saw opportunities to improve onboarding for newcomers. He contributed definitions for core terms like "template" that were missing from the docs, and wrote his widely referenced blog post on the data cascade to paint a bigger picture that the existing API-focused documentation didn't provide.

Ben issues a call to the community: whether through blog posts, videos, or documentation contributions, Eleventy needs more people sharing how they build things. He celebrates Eleventy reaching version 1.0 and receiving full-time open source funding from Netlify for creator Zach Leatherman. The episode wraps with Ben sharing where listeners can find him online, including his weekly Twitch show Some Antics, and encouraging everyone to explore what they can build with a lightweight, semantic, and performant approach to the web.

Transcript

00:00:00 - Ben Myers

When I was on Learn With Jason talking about Eleventy serverless, I actually spent a fair amount of time talking about how Eleventy doesn't work for every use case. There are certain websites you have in mind that Eleventy would just not be a good fit for, and that's okay. That just means it's better suited for other kinds of sites. I think there is this instinct in Jamstack communities to try to kludge Jamstack into a fundamentally un-Jamstacky problem space.

00:00:24 - Christopher Burns

What do you mean? Gatsby is the best for everything, and we should have never moved off Gatsby. There's no need for Svelte or Solid or anything like that. Gatsby, it did everything.

00:00:43 - Anthony Campolo

Ben Myers, welcome back.

00:00:44 - Ben Myers

Hey, it's good to be back.

00:00:46 - Anthony Campolo

You were on an earlier episode of 30-something talking about web accessibility. You are a web developer and accessibility advocate at Microsoft. Today, we're going to be talking to you about Eleventy because Eleventy is a project that I know you're really passionate about. We've had others on the show talk about it a little bit, especially Ben Holmes, who is building a meta-framework on top of Eleventy called Slinkity. But today we're going to be talking about Eleventy proper, what it is, why people are excited about it, and what kind of stuff they're building with it.

00:01:17 - Ben Myers

I'm thrilled. I absolutely love Eleventy as a tool, and it's one of those things that's just been an absolute privilege to get to introduce people to. To be fair, I totally have not introduced people to it through a podcast medium, so this is going to be very interesting. Super excited to chat about it with y'all.

00:01:33 - Anthony Campolo

We'll first start with just what Eleventy is. I think if anyone has heard about it, they know that it's a static site generator. They may have heard that it's based a bit on Jekyll. So if you can just talk a little bit about what it does and what you build with it.

00:01:47 - Ben Myers

Yeah. I find that just simply saying "Jekyll, but JavaScript" is enough for some people to get it. I will say that the fact that it is powered by JavaScript makes it more approachable than other static site generators for many people, because JavaScript is kind of the language of the web. If you're doing front end development, JavaScript is something you're very likely to be very familiar with.

A static site generator that leverages JavaScript, specifically the Node.js ecosystem, is a very compelling sell for a lot of people. But I should definitely back up and explain the bigger picture. You described it as a static site generator in the vein of Jekyll. I think that's absolutely fair, but personally I don't have experience with Jekyll, so that's not something that really helps me understand what it is.

The simplest way to think of Eleventy is it is a tool that will take content, typically in a format such as Markdown, and convert it to some pure, raw, boring, fantastic HTML or other assets.

[00:02:51] That is, I think, the simplest way to think of it. You've got some content, maybe it's blog posts, maybe it's documentation pages, maybe it's a landing page for some product. It's content that is mostly static and you just want some output, typically HTML. That is what Eleventy is and what it's really, really good at.

What Eleventy isn't is a tool for building highly dynamic, interactive experiences. For those, you might still consider a client-side web application framework such as React or Vue. Eleventy simply isn't as interested in addressing those kinds of websites, and I think that's totally fair. But if you've got something that could be expressed as static HTML, Eleventy is possibly a very good project for you.

00:03:35 - Anthony Campolo

I actually first started learning about Eleventy for a big reason: because of you, Ben, because we were building out the dev calendar with it. That was a really interesting project because we were trying to create an events calendar. What we did is we had a Git repo that was building the static site, and then we had Markdown files for the individual events. The individual events would be transformed into little cards on the front end.

If you want to talk a little bit about why you picked Eleventy specifically for building that, I think, also, the reason why we kind of went with that was because you were really passionate about it and we wanted to learn more about it. So I'd be curious about the thought process behind that.

00:04:15 - Ben Myers

An event calendar like that is, if you think about it, nothing but a bunch of articles. At the time, we were not heavily invested in doing anything interactive with that calendar. We just needed a place to stick a bunch of descriptions and details of different events going on, different links that we could send people to. That is, again, something that is very well suited for that kind of static markup.

When you think about a lot of web application frameworks, a common criticism that some folks in various web dev spaces will point to is that web app frameworks can be quite large and bloated. That means that if you were building your site with those, your end user very likely will have to download all of that and construct an experience from it, whereas you could get more or less the same experience, but just very, very lightweight.

I think that lightweight websites are fundamentally good and responsible. I try to take a very conservation mindset to the web. I like to only use what I need, and I apply this to users' resources such as their data. If they're out and about on their mobile phone and they're using their data plan, chances are good that they could have a really slow connection.

[00:05:22] They could have data caps. I think that if we don't need to send them an entire web app framework, we probably shouldn't send them a web app framework. That is, I think, not being the best steward of their resources, and they're going to have a slower, chunkier experience as a result.

So why did I choose Eleventy for this project? It's because the project, at least as we were thinking of it at the time, didn't need anything more than that. We just wanted some lightweight HTML pages out there on the web that could build quickly, that anyone could add to.

Eleventy is really based around this concept of a template. A template is a content file written in a language such as Markdown or HTML, and sometimes with templating languages such as Liquid or Nunjucks that Eleventy builds into a page or pages of HTML, or sometimes other static assets. It's weird because there always feels like there needs to be some asterisks, but broadly, think of a template as a content file that gets transformed into some output pages.

[00:06:23] The nice thing is that Markdown for most developers is a fairly ergonomic experience. That meant that if people wanted to add things to that site, they didn't have to worry about the whole instrumentation and orchestration of the entire project. They could contribute simply a Markdown file, and that was really nice.

Eleventy also has built into it this concept called the data cascade, which I think is one of the most crucial things to understand about Eleventy, and also one of the things that took me the longest time to wrap my head around. When you're in a template, again, a content file, you can use templating syntax, and Eleventy allows you the opportunity to expose variables in that templating syntax that you can either print out onto the page as part of the content, or you can transform or operate on them in different ways. It's data. It's variables that you have access to.

Eleventy has this amazing order of operations for how it lets you aggregate that data. You can say, "I've got some data that will be made available to every template on my site," or "I've got data that's available to every template that uses a certain layout," or "I've got data that applies to every template in a given directory or its subdirectories," or "I have data that corresponds exactly to one template."

[00:07:43] The lovely thing about this is it exactly follows the mental model you would hope for, which is that data that applies much more specifically to an individual template will have a higher precedence over data that corresponds globally. This mental model, I think, once you start playing with it, allows for some really, really powerful configuration of your website, in a way where you can almost afford to set it and then forget it, which I think is incredibly powerful.

You can set some sensible defaults at the global level, such as maybe every blog post uses this blog post layout that I've defined. Then one blog post could override that and use a different layout, maybe to accomplish some art direction. You've got a very special blog post that you want to have a special layout, and so you can change that data as you go.

That kind of configuration, once you start wrapping your head around the order of operations, is incredibly powerful and flexible, and at the same time, magic enough that you can bring new people into the project and they just don't have to worry about any of it.

[00:08:49] And I think that is super cool.

00:08:51 - Anthony Campolo

I think that was interesting. That came up while we were working on it. We ended up in a situation where we had to rebuild certain things at certain times because of the way events work. There'll be an event upcoming, then there'll be an event that has passed. You don't want to have stale events still on the home page. So we ended up setting up a cron job type thing with a GitHub Action.

I think that this is the type of thing that now, today, if we had been building that, there would be other ways to do that, not even mentioning the new scheduled jobs functions that Netlify just added. But I was curious to get more into the serverless bit, which is that there is now Eleventy serverless and you've actually been on the forefront of this. You did a stream with Zach when this first came out, and you've been building stuff out with it this whole time. We talked with Stephanie a little bit about it, and I'm really curious to get your take on it, because we've talked about serverless a ton of times here.

[00:09:45] Redwood was built on serverless. We love serverless. Well, I love serverless. I know Chris loves serverless, but I would love to hear: what is serverless, and why was it built?

00:09:53 - Ben Myers

Eleventy serverless is an opt-in build mode for Eleventy. Typically, everything is pre-rendered. You have a build step, you run, probably npm run build, if we're being honest, and Eleventy kicks in and picks up all your templates and converts them into HTML files. Once they're built, they're built. So if data changes behind the scenes, such as data that was fetched from an API, you don't get any updates to that because there's nothing in the HTML linking that data to any sort of backend. It's just pure HTML. This meant that Eleventy could only reflect what was true at build time.

So Eleventy serverless is this new opt-in build mode for Eleventy where you can say certain templates are built whenever you request them. Again, non-Eleventy people should probably read that as either certain pages are built when you request them, or I prefer to think of it as certain routes are built when you request them. I think that framing gets really, really powerful because you can use the Eleventy data cascade, Eleventy front matter, and templating languages.

[00:11:01] All the stuff that you absolutely love about Eleventy you can use, but in this on-demand, on-request way. You create a page as you request it. If you're using, for instance, Netlify's on-demand builders, you can then cache that page, and so it's as if you had built that page in the build step. This is hugely powerful for a couple of reasons.

I use this demonstration when I go on people's streams to talk about Eleventy serverless, which is a color contrast checker that takes two hex codes and displays, in this pretty format, the color contrast ratio. Well, if you have two hex codes, which are six digits long each, then that is, I want to say, 2.75 times ten to the 14th contrast ratios. I don't want to build that. I don't want my dev server building that. I don't want my Netlify build minutes building that. That's incredibly wasteful.

I love to defer building those kinds of things until they're needed because chances are the vast majority of those contrast ratios will never see the light of day.

[00:12:03] Very few of the ratios on that site will ever be explored, so why build them? Eleventy serverless is a great way to defer building a large data set that folks might not ever look at. You also don't have to cache by default. Eleventy serverless built pages don't cache. You have to use specific things like on-demand builders to cache.

But what that means is that you can have up-to-date data. During the on-request build, you can hit an API and you can get the latest, greatest up-to-date data. I think that is incredibly powerful. That's something that we haven't really had in Eleventy before.

But at the end of the day, what gets sent over the wire is still an incredibly lightweight HTML page. It's not a whole client-side page that's pulling in a large framework. You don't have to worry about things like loading spinners because all the fetching is done server-side. You don't have to worry about things like authentication because all the fetching is done server-side.

[00:13:02] So you get to take advantage of everything that you love about serverless functions and everything that you love about Eleventy. I've brought up a couple times that I really love this because you aren't turning your whole site suddenly into a quote-unquote serverless site. You first opt in by installing this serverless plugin, and then you still have to opt in on a template-by-template basis.

So the core of your website, the main pages that we guarantee people are going to hit, like your landing page and a couple of your about pages and stuff like that, those are still built during the build step, still totally cached, still available for search engines to crawl. It's just that this one subsection of your site is now served on demand. I think that is super exciting.

Another benefit of Eleventy serverless routes is that you can take advantage of arguments passed in the URL. You have parameters in the path, or you could have query parameters, for instance. This allows for some really dynamic experiences all around.

[00:14:04] Anthony, you've alluded to, I've got this project that I built that is designed really to just test what I believe is the absolute limit of serverless. This product is showmy.chat. Anyone who's been in the streaming biz will know that it's very common for Twitch streamers to use websites as part of their stream layout. A very common use case for this is showing your chat box as part of your stream, so that folks can see who's interacting with the stream. It's really exciting. Look at me, Mom, I'm famous. I'm on my favorite Twitch streamer's stream.

Doing anything like that requires some understanding of web dev and WebSockets to be able to read from the chat, which is not something I feel like people should have to worry about. So I built this site, showmy.chat, which allows you to put in your channel name, as well as set a couple of other properties and configure a couple of extra values. It will generate, using Eleventy serverless, a page that has all of the WebSocket logic and the DOM manipulation to display the chat, and all the theming set in place for you.

[00:15:12] So you get this on-demand themed chat that responds to the arguments that you've passed in through the query parameters. Do I think that Eleventy serverless was the right tool for that job? I'm not entirely sure. I've actually been kind of considering maybe looking and seeing if I could have done the same thing, but maybe more flexibly, using something like SvelteKit. But I think that it's incredibly exciting that Eleventy, which has been this kind of beloved pre-build tool, now affords you this extra flexibility where just because you wanted a page that always had dynamic stuff or the latest information, you don't have to opt into a completely different framework. Now you can still stay within the Eleventy ecosystem that you love.

00:15:54 - Christopher Burns

That was a lot. I've literally just been sitting here absorbing it all in. I feel like a mega React Chad when I say, "Yeah, but you didn't say any of the buzzwords. SSG, ISR, SSR."

00:16:06 - Anthony Campolo

I think DPR would be one of them, technically. Right? Distributed persistent rendering.

00:16:10 - Christopher Burns

Yeah.

00:16:11 - Ben Myers

The Venn diagram of all of these words is a very pretty butterfly, and also inscrutable to anyone outside of the space. For folks at home who are playing buzzword bingo, it's Eleventy's implementation of distributed persistent rendering, or sometimes not distributed persistent rendering. Brian Rinaldi calls it deferred rendering. That's the term I like. It's deferred rendering. Everyone's got their own different take depending on whether they're a framework or whether they're a CDN. It's deferred rendering. That's most similar to, I think, Gatsby now has. I forget what they're calling it now.

00:16:45 - Christopher Burns

I think they're calling it deferred incremental rendering, something like that.

00:16:49 - Ben Myers

This is exactly why I'm just using Brian's term, deferred rendering. If you're looking at this and going, "What's Eleventy's version of incremental static regeneration or something like that," the closest thing is Eleventy serverless.

What is distributed persistent rendering? It's Eleventy serverless hooked up to on-demand builders. That's what we're talking about. Hopefully that helps for people who are hoping to play buzzword bingo. The crux of it is you hit a route and Eleventy is run in the serverless function to create a page for you in basically real time.

00:17:20 - Christopher Burns

The reason I say all the buzzwords is because sometimes they help define where it sits in the market, and sometimes they really do not. This is where we talk about functionality, which is obviously what really makes people understand what all these terms are. Things like Next have this. Gatsby has this.

For example, you build a website, let's say an e-commerce store. Really easy. You add a new product. Does that product then just get rendered onto the website using a webhook, or is it more that that product would only show up if that specific URL is then entered because serverless knows to run and make that page?

00:17:57 - Ben Myers

Serverless is still kind of in its infancy, but it would really depend on your implementation. I know Zach is still kind of working on having serverless routes that have been created and then saved get added to what Eleventy calls collections, which are arrays of templates. So you could be able to then display it on the rest of the site.

Truthfully, I haven't done a whole lot with that, but I think it would depend a lot on your implementation. But yeah, in the moment, the on-request build, your serverless function that's handling that, is looking for any arguments that you supply in the URL, either through the structure of the URL itself or through query parameters. You're probably passing in a SKU or some other identifier in there, and it would look up some known database or API and be able to render that for you.

00:18:43 - Christopher Burns

This is actually what I've personally seen with all these different types of rendering methods is that you check out the complete build, they add a new product, and then go, "It's not on the store." I'm like, well, it is on the store if you know the URL, but you need to go to the URL for it to appear on the rest of the store because that means the website now knows about it. And it's like, how do you explain that to someone not technical, that they need to know the URL to go to the right product to then appear on the rest of the website? And it's like, I thought this was meant to save money and time and like all these things, and it's still a really complicated subject.

One of the really big things I wanted to ask is what serverless is sending down the pipe back to the client. It's not rehydrated JavaScript or JavaScript JSON, it's just HTML.

00:19:26 - Ben Myers

Yes, just pure boring, lovely, fantastic, delightful HTML, which means that it's going to be fairly lightweight. Really, the way to think about this is this is how the web used to work, and in many places still does. Right? This is what we now call server rendering, except you don't have to own a persistent server, and you're very likely not doing anything with sustained sessions or anything like that. But the meat of it is: I go talk to a server and I ask for a page, and that server builds me that page on the fly. That's what's going on.

It's just I'm waving my hands, doing jazz hands. Imagine sparkles around us. It's now Jamstack. That's what it is. But it's bringing that kind of server functionality into a tool, into a framework, whatever you want to call it, that previously has been pre-built, where you create a directory of HTML files and then that directory of HTML files is yours to do whatever you want with.

[00:20:24] You could FTP that into some server and just host that directly. You could put that into a CDN. Or you could do what I do, which is I have a Git-based workflow hooked up to a CDN, in this case Netlify. And so every time I push to my repo, Netlify rebuilds, but you don't have to have any of that instrumentation and orchestration. You could just be uploading some boring old HTML to a server and just hosting that.

This provides the same lightweight end user experience where you're getting just HTML. It's not, "Oh, HTML, and then we rehydrate it down the road and replace your entire page with this app behind the scenes that hopefully you won't notice." It's just HTML. It's lightweight, it's easy to cache, it's a little friendlier for search engines to optimize. When all you need is static HTML on a page and not a whole lot of dynamic, interactive stuff, it's fantastic. It's glorious. I think the performance thing is an interesting conversation.

[00:21:22] I don't know if y'all know this, but right now we are in the middle of a pandemic, and this means businesses have taken measures around this pandemic. There have been a small handful of times I have gone out to eat at a restaurant and, on the tables, instead of giving me menus, there are table tents that have QR codes I can scan to pull up their menu. This, to me, is an example of a wonderful idea to meet users' needs that typically fails miserably in the execution because when I scan the QR code, it pulls up the restaurant's website, and the restaurant has used some site builder or another that sends over gobs and gobs of JavaScript, a whole framework likely at very least, probably jQuery, and just sending over a whole lot of stuff.

I don't know if y'all have this experience, but every restaurant I seem to go to seems to have poor internet connection. I don't have great connection there, don't have great reception, and so it takes me like 20 seconds where there's just this spinner, and then I get to see a list of foods, which is mostly text.

[00:22:20] Sometimes there's pictures, but the pictures are strictly optional. That feels to me like no one quite anticipated this pandemic, restaurants least of all, and re-architecting your website is an expensive process that you can't just say, "Oh, just remake your website with faster stuff." But we are several years into this now. Folks haven't looked at this and gone, "Our website is slow. Let's fix our own restaurant menu site." That's an area of opportunity for improvement there, considering that when people are out and about, they're often in those kind of reception dead zones, such as a restaurant, and they're operating off of finite data caps. They don't need gizmos and widgets and all sorts of interactive stuff. They just want to see what kind of food they can buy at your restaurant.

There are times where having tools that make it really easy and flexible to just serve some boring, static HTML is exactly what your users need, and having that developer experience to make that easier is just gorgeous.

00:23:22 - Christopher Burns

Yes, but I have two counterpoints.

00:23:24 - Ben Myers

I'm ready to hear them.

00:23:25 - Christopher Burns

One, "But JavaScript. I can write my CSS in JavaScript. I can write my HTML in JavaScript. I can just write JavaScript." And two, "Hey, you're a captive audience in a restaurant. Of course they want you to sit there a little bit longer."

00:23:37 - Ben Myers

Well, I mean, I think both of those arguments are very fair, but I think that too often we look at JavaScript as this great enabler and don't think of it as also a responsibility and a possible point of failure. An example I sometimes use, because I think documentation sites are a fantastic use case for Eleventy, is to envision we're building a documentation site for some library we've made. As is the custom, we want to show how many GitHub stars this library has. In the React ecosystem, it's fairly commonplace to set up a fetch to the GitHub API and display that.

But what if the GitHub API is down? Well, I sure hope you set up some error boundaries and stuff like that, right? What if the GitHub API is not down but really sluggish? Well, I certainly hope that you set up loading states. You have a lot of complexity around a part of the page that honestly no one cares about. You incur risk and you incur complexity over such a minor part of the page.

[00:24:38] I think that sometimes that stuff is incredibly valuable to consider. How do we do this responsibly? Of course, yes, we could work around the foot guns. We could build a robust, resilient experience. But I think it is also interesting sometimes to ask, how critical is this really? Could we get away with having the result of how many stars our GitHub project has be just hard-coded text in the built HTML that gets updated with a nightly build? Is that acceptable? In some cases, no, it won't be, but in many cases it totally could be.

You say, "Oh, we've got JavaScript," and I say, "Sure, but it might be more resilient in the backend when we don't have to worry about the costs and the risks and the complexity around doing all this stuff client-side." As for a captive audience, I mean, sure, right? But no one's going to look at that and go, "Ah, yes, this restaurant was very fancy and stuff like that, and I sure did feel very fancy waiting on my phone to pull up this menu in the middle of the steak restaurant going, it'll load, I promise."

[00:25:44] Do I need to refresh this another few times? It's all about different experiences, and there is no one-size solution that fits everything.

00:25:51 - Christopher Burns

Yeah, I would have walked out of the restaurant if the website was made in PHP. Just not for me. I don't care how rare you like your steak. This ain't for me.

All jokes aside, Eleventy serverless looks really, really cool. I think one of the things that is really cool about it is that what it's spitting out is HTML. So many times when it comes to, if you even think about Next's implementation or Gatsby's, do I even know what it's spitting out? Kinda. To what I understand, it's just JSON. It spits out a massive JSON chunk that then gets stored in the HTML file, that then gets rehydrated into the client, to what I understand.

So when you see those messages in Next.js saying, "Hey, your ISSG step is a bit too big," it's because you're literally dumping a massive JSON object into a script tag for Next.js to read later, if you didn't know.

00:26:43 - Ben Myers

I don't want to bash on those tools. I think there's absolutely a time and a place for them, but there's a time and a place for boring old HTML as well. And Eleventy, amazing.

00:26:53 - Christopher Burns

And I think one of the most amazing things about all of this is that we're still very early. It's still all very early. Even what Next.js is doing, who you could say have been doing SSG for the longest time, we're still so early when we talk about things like frameworks like Marko, who have been in the industry for like ten years. Everything is still so early in this area. The more capabilities that we have with less abstraction, I think the better.

And I think what's really interesting is what you just said about it's opt-in, not automatically there. It still works as expected, but if you want to add this, then you get it. So many times when it comes to things like Next.js or Gatsby, I use Next.js all day, every day, so I don't mind bashing it. Do I even know how much JavaScript it sends to the client by default? Well, I hope it's not a lot.

[00:27:43] What we tend to forget is when I say, "I know JavaScript, I could just write everything," is that I've made an abstraction line that is so high because it's all in JavaScript that so much performance can be potentially lost. You're technically compiling down to CSS, HTML, and JavaScript by default. What Eleventy is doing is just saying, "Look, you know HTML, you know CSS, just send that down the wire." And that is good enough for 80% of use cases like a blog or documentation.

00:28:16 - Ben Myers

And now with serverless, you complement the sites that are already built with static, like a fantastic example. I want to give a shout out to both Brian Robinson and Stephanie Eckles, who have done this kind of stuff, where you can have your blog and the meat of your blog is all built statically ahead of time during a pre-build step, right? It's great.

And then using serverless, you could add a search bar to that site. So now your search pages are generated serverless based on your search query. But the meat of your website is still that static, cached, search engine friendly version of your site. So it's all additive.

00:28:51 - Christopher Burns

And that's what makes it really good, is that so much of the ecosystem right now is taking your Ford Raptor by default. You're not starting with the smallest car you possibly can. It's like, "We got the biggest engine to do the school trip in." It's not like, "Let's start with a really small city car." It's like, "Take everything and just use it."

00:29:11 - Ben Myers

Absolutely.

00:29:12 - Anthony Campolo

One of the other things I wanted to get into is, I know that you've been working a lot on adding to the Eleventy documentation because you've written a ton of blog posts about Eleventy. I think for the most part, when people want to explain the data cascade to people, your blog post is kind of the canonical example that is usually linked to.

So I would be curious, when you're looking at the Eleventy docs, where did you see areas that you felt you could add value?

00:29:35 - Ben Myers

Yeah. One pull request that actually got merged in not long ago was I defined a bunch of terms because I was looking around for a definition of, for instance, the word "template," and the definition that I eventually ended up adding to the site was the one that I gave you: a content file, typically in a language such as HTML or Markdown, that gets processed by a templating language and gets built as output.

I had the opportunity to add that to the site because I actually couldn't find anything like that anywhere on the site. I think that the Eleventy documentation right now is fantastic at showing you the breadth of Eleventy's API, but the room for opportunity I see is onboarding new people to Eleventy. The getting started guide has you build a template and then run Eleventy to build a site using that template. And then it kind of just goes, "Ta-da!" Welcome to Eleventy.

I would love to see more resources from the ecosystem, but especially more resources in the core Eleventy documentation around how to take that getting started guide and build a fully fledged application that you could host something real on.

[00:30:43] So that's a room for growth, I think. And I think that that is going to require some more explicit step-by-step walkthroughs. I think that's also going to require a bit more tying pieces together, like painting a bigger picture of that, which is why, for instance, I wrote that data cascade post. Eleventy has some great pages about each step of the data cascade, but painting that as one big picture with the sense of when should you use one step or method versus when should you use another step or method was something that I felt like was missing.

That's something that I'm hoping to contribute more and more. I think it's a bit of a slow process. You don't want to boil the ocean. You don't want to contribute every update all at once. This is something that I'm doing in a bit of my free time, just kind of here and there. Maybe I'll add a page, or I'll add to a page that already exists, but provide a bit more context in what I hope is a beginner-friendly, newcomer-friendly way to help them really understand.

[00:31:45] Like, why does this fit into the bigger picture of an Eleventy project? This is a sentiment I've heard a couple of times in the Eleventy space, and I don't want to bash on the Eleventy docs. I do think that they are great, and again, they reflect the breadth of Eleventy's API. But this is something that right now there is a need for, and people are writing blog posts and making videos that rise to that need.

If you're listening to this and you yourself do Eleventy, or if you're learning Eleventy, I would say right now the community needs you. The community could really benefit from you writing about your experiences and the things you learned and the real, practical, step-by-step process of how you built the thing that you've built, whether that's on your own blog post or on your own YouTube channel, or maybe it's in some way contributed to the documentation. I have no official affiliation with Eleventy, but this is something that I'm seeing more and more that folks could benefit from.

[00:32:38] That is kind of the encouragement I would give. This is, I think, what we need to see. Eleventy just hit 1.0 recently, and that marks it as a mature product. I would love to see us figure out more and more ways to bring people into the fold.

I myself learned Eleventy through Andy Bell's course, Learn Eleventy From Scratch, which used to be a paid course. It's now open and free, but no longer being updated. I think more resources like that, that again take you from the docs, which can sometimes be very API-focused, to something that is instead kind of methodological in its design, is something that Eleventy could benefit from.

00:33:18 - Anthony Campolo

I would use that term explanatory.

00:33:20 - Christopher Burns

One of the favorite things that I love, something you said earlier that I wish all frameworks said, is as simple as this: we can do everything, but we are not good at everything. You should use us for X and Y type of websites, and if it's not X and Y, go look at something else. And you said documentation and blogs and homepages. That's what Eleventy is really good at. Don't go try build a dashboard in it.

00:33:44 - Ben Myers

Absolutely right. And it's like, it could be done. And I think that there is value in experimenting, like using a thing far beyond what it was meant to do. In the CSS space, I see this a lot with CSS art. Amit Sheen's work is using CSS to create hyper-realistic 3D animations. This is so far beyond the realm of what anyone ever intended for CSS, but we learn something as a community from pushing CSS to its limits, right? And we learn techniques that we can use in the day-to-day.

So that's not to say you can't build hyper-interactive dashboards with Eleventy. You can certainly learn some things from that. But if you're trying to publish, if you're trying to deploy to production, and you're trying to have a resilient app, those kinds of things, probably Eleventy isn't on the table for you, and that's okay.

But I've definitely had this moment where I'll be working with someone individually through Eleventy to rebuild their blog. They'll be coming from a React mindset.

[00:34:37] And then suddenly I show them how they could create something that looks identical to their blog, but as HTML. And there's just that moment that clicks where it's like they've been using a tool that wasn't intended for the job, and now they have a tool that was actually meant for that kind of thing, and it just unlocks something in them. That is, I think, a huge takeaway, right? There's no one size fits all, but that means that the one size that fits all that you're thinking of isn't a one size fits all.

00:35:03 - Christopher Burns

Very true. Building blogs with Next and Gatsby is pretty overkill when you could just send sweet, sweet HTML.

00:35:11 - Anthony Campolo

Yeah, I was really happy that you were working on the docs because I know I've struggled with the docs. I know others have as well. But as you say, just bashing the docs doesn't solve anything or make anyone feel good, especially when Zach spent so much of his own free time creating this project.

So when you see things like that, contribute back, especially if you're someone who's in a position to help with things like documentation and explanation. That's really awesome. That's very much like the spirit of open source. So happy you did that.

00:35:38 - Ben Myers

I think in general people benefit from having multiple possible explanations for things. If Zach is the only person writing documentation, then everything is going to be oriented around how Zach understands things. And Zach has a lot of great context into the inner workings of Eleventy, as well as just the inner workings of the web.

But Zach is not everyone. I'm not everyone. The two of y'all aren't everyone, right? And so bringing more people to the table, documentation-wise, means we can get a better diversity of explanations that can work better for a wider diversity of people who are coming to this project. And that is awesome.

00:36:11 - Anthony Campolo

Is there anything else about Eleventy you want to talk about before we wrap it up?

00:36:15 - Ben Myers

We've touched a bit on how it's HTML, and I think that part itself is really huge. I feel like I've become a more robust developer as a result because I can't just rely on a component to do things for me. I have to think about what is the best markup for this, and what are the scripts that I have to write to make this work robustly.

I've been very fortunate that Eleventy has improved me as a developer, and I'm super, super excited to see just how much the community is growing. It feels like it's exploded in popularity recently, I think in part due to the Learn Eleventy From Scratch course by Andy Bell. I think it's in part just due to things like The Eleventy Meetup, which has been organized by Sia Karamalegos, Stephanie Eckles, and Thomas Semmler. There's a lot more community outreach and stuff like that. I'm just incredibly excited to see this project grow. It just received full-time open source funding from Netlify, which means Zach is now paid to work on Eleventy full time.

[00:37:13] And already we've seen some long-standing pull requests get merged in that have enabled things for different teams. The more people we can get in on this project, just kind of the more cool things we can build, I think. So, yeah, absolutely. Dive into Eleventy, see what you can build, see what you can break, see how you can make something that you previously might have wanted a whole framework for. See if you can build something lightweight, robust, semantic, performant, and just see what a different way to build is like.

00:37:42 - Anthony Campolo

Yep. And if you hit any roadblocks, check out Slinkity.

00:37:44 - Ben Myers

There we go. Yes.

00:37:46 - Anthony Campolo

Go ahead and let our listeners know where they can find more about Eleventy or more about yourself.

00:37:51 - Ben Myers

Yeah. So if you want to learn about Eleventy, the documentation can be found at their website, which is 11ty.dev. Eleventy kind of has two spellings. It's a whole thing, but 11ty.dev. I'm sure the link will be in the show notes. There's multiple links on there to find the documentation. Poke around, see if you can find the Easter eggs there because it's delightful. The documentation button is incredible.

If you want to find me out and about on the web, I'm on Twitter at BenDMyers. Again, I'm sure that link will be in the show notes. I host a weekly Twitch show, which Anthony has been a part of four times now. I think he was the inaugural guest, and he's still the person who's been on the most times. It's called Some Antics. Every week I bring on a guest from around the web development and web design industry to teach me something about building a great user experience for the web in a hands-on way, with a focus on accessibility and/or core web technologies.

[00:38:47] And you can find that at twitch.tv/someanticsdev. That's S-O-M-E-A-N-T-I-C-S-D-E-V, someanticsdev. I look forward to hearing from y'all. I look forward to seeing what y'all build, what y'all make, what y'all are learning, what you're doing. My cat has just jumped off the bed in a clunky, noisy way.

00:39:08 - Anthony Campolo

Tuna wants to be on the show.

00:39:09 - Ben Myers

Yes, I think that probably means he is done with this podcast as well.

00:39:13 - Anthony Campolo

Well, thank you so much, Ben. It's always a pleasure getting to speak with you. We appreciate your time and hope to have you back soon.

00:39:20 - Ben Myers

Likewise. See y'all later.

00:39:51 - Christopher Burns

I remember back in the Gatsby days when you'd have 10,000 pages. You're like, "I just want to rebuild just that one page."

00:39:57 - Ben Myers

Yep.

00:39:57 - Christopher Burns

Finally, they're like, "Five years later."

00:40:00 - Ben Myers

Yep. Even Eleventy beat them to that punch.

00:40:03 - Christopher Burns

Wow. I should learn more about Eleventy.

00:40:06 - Ben Myers

It's almost as though we need a podcast episode about it.

00:40:11 - Anthony Campolo

Okay, that's our pre-show clip. Perfect. Okay, let's do it. Ready.