Episode 80 - Eleventy with Ben Myers [FSJam Podcast]

We need your vote to win a Jam stack Jammie! So, go to https://fsjam.org/vote.

There will also be previous guests in other categories, so make sure you vote for them too!

-------------------

In this episode we discuss the fundamentals of Eleventy, how to approach web development from a conservationist's point of view, and utilizing Eleventy Serverless for deferred, on-demand rendering.

Ben Myers

Eleventy

Links

Transcript

[Pre-show Clip]

Ben

When I was on Learn with Jason talking about Eleventy Serverless, I actually spent a fair amount of time talking about... "hey, Eleventy doesn't work for every use case." There are certain websites you have in mind that Eleventy would not be a good fit for. 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.

Chris

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

[Opening Theme Song]

Anthony

Ben Myers, welcome back.

Ben

Hey! It's good to be back.

Anthony

You were on an earlier episode, 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 cause 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.

Ben

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

Anthony

Why don't we first start with 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 talk a little bit about what it does and what you would build with it.

Ben

Yeah, so I find that simply saying, "Jekyll but JavaScript" is enough for some people to just 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 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, absolutely fair. But personally, I don't have experience with Jekyll. 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. It'll take that content, it'll just convert it to some pure, raw, boring, fantastic HTML (or other assets). 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. Some content that is mostly static and you 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 in static HTML, Eleventy is possibly a very good project for you.

Anthony

I actually first started learning about Eleventy for a big reason cause of you, Ben. We were building out the lunch.dev calendar with it. That was a really interesting project because we were trying to create like 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. Then the individual events would be transformed into little cards on the front end. If you wanna talk a little bit about why you picked Eleventy specifically for building that cause I think Chan also, the reason why we went with that was cause you were really passionate about, we wanted to learn more about it. So I'd be curious about the thought process behind that.

Ben

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 if you are building your site with those, your end user very likely will have to download all of that and construct an experience from that. Whereas, you could get more or less the same experience but 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 and 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. They're gonna 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.

The nice thing is 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. It's 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 template syntax.

Eleventy allows you the opportunity to expose variables essentially in that template 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. So you can say, "oh, I've got some data that will be made available to every template of 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 sub directories." Or, "I have data that corresponds exactly to one template."

The lovely thing about this is, it exactly follows the mental model you would hope for something like that. It is powered by co-location. Data that applies much more specifically to an individual template will have a higher precedence over data that corresponds globally. This mental model (once you start playing with it) allows for some really, really powerful configuration of your website. You can almost afford to set it and then forget it which I think is incredibly powerful. You could 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 you 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. 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. At the same time, it's magic enough that you can bring new people into the project and they don't have to worry about any of it. I think that is super cool.

Anthony

Something that was interesting that came up while we were working on it was, we ended up in a situation where we had to rebuild certain things at certain times. Because 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 homepage. We ended up setting up a cron job type thing with a GitHub Action.

But 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, what I was curious to get more into was the serverless bit. 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 Eckles a little bit about it and I'm really curious to get your take on it cause we've talked about serverless a ton of times here at Redwood it was built on serverless. We love serverless - well I love serverless, I don't know if Chris loves serverless - but I'd love to hear what is Eleventy Serverless and why was it built?

Ben

Eleventy Serverless is an opt-in build mode for Eleventy. Typically with Eleventy, everything is pre-rendered. You have a build step, you run probably `npm run build` if we're being honest. Eleventy kicks in and picks up all your templates and then converts them into HTML files. Once they're built, they're built. If data changes behind the scenes, such as data that was fueled by an API, you don't get any updates to that because there's nothing in the HTML linking that data like real data in any sort of backend. It's just pure HTML.

This meant that Eleventy has historically been very limited. Eleventy could only reflect what was true at build time. 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 Eleventy's data cascade, you can use Eleventy's front matter and templating languages.

All the stuff that you absolutely love about Eleventy, you can use but in this on-demand way, this on request way. You create a page as you request it and if you're using, for instance, Netlify's on-demand builders, you can then cache that page. 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. It's a color contrast checker. Take two Hex codes and display in this pretty format, the color contrast ratio. If you have two Hex codes, which are six digits long each, then that is - I want to say 2.75 times 10 to the 14th contrast ratio.

I don't wanna build that. I don't want my dev server building that. I don't want my Netlify high 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. 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-datest data. I think that is incredibly powerful. That is 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 holding 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.

You get to take advantage of everything that you love about serverless functions and everything that you love about Eleventy. I've also brought up a couple times that this is opt-in. 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 the serverless plugin and then you still have to opt-in on a template by template basis. The core of your website, the main pages that guaranteed people are gonna hit (like your landing page, about page, and stuff like that) are still built during the build step and are still totally cached.

They're still available for search engines to crawl and all of that. It's just that this one subsection of your site is now served on-demand. I think that 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. Anthony, you've alluded to, I've got this project that I built that is designed really to test what I believe is the absolute limit of Eleventy 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 bot 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 streamers stream." Doing anything like that requires some understanding of web development and WebSockets to be able to read from the chat. This is not something I feel like people should not have to worry about.

So, I built this site, showmy.chat. It allows you to put in your channel name as well as set a couple of other properties, configure a couple of extra values there. It will generate using Eleventy Serverless a page that has all of the WebSocket logic, the action to display the chat, and all of the theming all set in place for you. You get this on-demand themed chat that responds to the arguments that you 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 like opt into a completely different framework. Now, you can still say within the Eleventy ecosystem that you love.

Chris

That was a lot. I've literally just been sitting here just like 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..."

Anthony

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

Chris
Yeah, haha.

Ben

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.

Chris

I think they're calling it deferred... incremental deferred rendering? Something like that.

Ben Myers

This is exactly why I'm just using Brian's term of 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.

Chris

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. And this is where we talk about like functionality is obviously what really makes people understand what all these terms. Things like Next have this, Gatsby have this. For example, you build a website, let's say an e-commerce store, really easy and you add a new product. Does that product then just get rendered onto the website using like a webhook, or does that product only show if that specific URL is then entered? Because then Serverless knows to run and make that page?

Ben

Serverless is still in its infancy, but it would really depend on your implementation. I know Zach is still working on having serverless routes that have been created, but then saved can now get added to like what Eleventy calls collections (which are arrays of templates). You could be able to then display it on the rest of the site. Truthfully, I haven't done a whole lot with that. I think it would depend a lot on your implementation. It's in the moment the on request (your server function that's handling that) is looking for any arguments that you supply it 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. It would look up some known database or API and be able to render that for you.

Chris

This is actually what I've personally seen with all these different types of rendering methods is that you chuck out the complete build, they add a new product and go, "it's not in 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. Cause that means the website now knows about it. It's like, how do you explain that to someone not technical? They need to know the URL to go to the right product to then appear on the rest of the website. It's like, "I thought this was meant to save millions and time on all these things." It's still a really complicated subject. One of the really big things that I wanted to ask is, what Serverless is sending down the pipe back to the client is not rehydrated JavaScript or JavaScript JSON, it's just HTML?

Ben

Yes. Just pure boring, lovely, fantastic, delightful HTML. Which means that it's gonna 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." 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, "I go talk to a server and I ask for a page and the server builds me that page on the fly," it's that, that's what's going on. I'm waving my hands doing jazz hands - imagine sparkles around this - 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 wanna call it) that previously has been prebuilt.

You create a directory of HTML files and then that directory of HTML files is yours to do whatever you want with. You could FTP that into some server and just host that directly. You could FTP 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). 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 upload some boring old HTML to a server and host that. This provides the same lightweight end user experience where you're getting just HTML. It's not HTML that we then rehydrate 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. 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. 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 user's needs that typically fails miserably in the execution.

When I scan the QR code, it pulls up the restaurant's website and the restaurant has used some site builder or something else that sends over gobs and gobs of JavaScript. A whole framework likely or at the very least probably jQuery, 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 there. I don't have great connection there; I don't have great reception. 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. 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 rearchitecting 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, "huh, those slow websites at our own restaurant to pull up our own menu, that's an area of opportunity for improvement there." Especially considering that when people are out and about, they're often in those kind of reception dead zones, such as a restaurant. 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. Having that developer experience to make that easier is just gorgeous.

Chris

Yes, but I have two counterpoints.

Ben

I'm ready to hear them.

Chris

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."

Ben

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. Here's an example I sometimes use because I think documentation sites are a fantastic use case for Eleventy. I would like you 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. 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.

What if the GitHub API isn't down but it's 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. I think that sometimes that stuff is incredibly valuable and stuff to consider and 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's 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? Could we get away with having that be just hard coded texts in the built HTML that gets updated with a nightly built? 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." 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, but no one's gonna 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 this steak restaurant going, 'it'll load, I promise. 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.

Chris

Yeah, I would've walked out 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! Um... no, all jokes aside, Eleventy Serverless looks really, really cool. I think one of the things that is really cool about it is, what it's spitting out is HTML. So many times when it comes to like, if you even think about Next's implementation or Gatsby, do I even know what it's spitting out? Kind of... 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! When you see those messages in Next.js saying, "Hey, your ISSG step is a bit too big," it's because you are literally dumping a massive JSON object into a script tag for Next.js to read later. If you didn't know.

Ben Myers

I don't want 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.

Chris

And I think what's the most amazing thing about all 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 10 years. Everything is still so early in this area. The more capabilities that we have with less abstraction, I think the better. 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 say Next.js or Gatsby, I use next 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. What we tend to forget is when I say about the question, "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 are technically compiling down CSS, HTML, 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."

Ben

And now with Serverless, you compliment the sites that are already built with static. A fantastic example, and I wanna give a shout out to both Brian Robinson and Stephanie Eckles who have done this kind of stuff. You can have your blog and the meat of your blog is all built statically ahead of time during a pre-build step. Great, using serverless you could add a search bar to that site. 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.

Chris

That's what makes it really good. So much of the ecosystem right now is taking, like, your Ford Rapture 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."

Ben

Absolutely.

Anthony

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. 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. I would be curious, when you were looking at the Eleventy docs, where did you see areas that you felt you could add value?

Ben

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." The definition that I eventually ended up adding to the site was the one that I gave y'all. "A content file, typically in a language such as HTML and Markdown that gets processed by a template 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 a room for opportunity I see is, onboarding new people to Eleventy. As it stands, the getting started guide as you build a template and then run Eleventy to build a site using that template, and then it kind of just goes, "Tada! 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 pro on. So that's a room for growth, I think. I think that is going to require kind of 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 - that was something that I felt 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 wanna 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 here and there. Maybe I'll add a page or I'll add to a page that already exists but provide a bit more of the context in (what I hope is) a beginner, newcomer, friendly way to help them really understand why does this fit into the bigger picture of an Eleventy project.

This is a sentiment I've heard a couple times in the Eleventy space and I don't wanna 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. 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. 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 should benefit from. That is the encouragement I would give. I think this is 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, which take you from the docs (which can sometimes be very API focused) to something that is instead methodological in its design. I think it's something that Eleventy could benefit from.

Anthony

I would use the term explanatory.

Chris

One of the favorite things that I love, something you said earlier that I wish all frameworks said is as simply this. We can do everything, but we are not good at everything. You should use this for X and Y type of websites and if it's not X or 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.

Ben

Absolutely and it's like, it could be done and I think that there is value in experimenting. Using a thing far beyond what it was meant to do is something I see a lot with the CSS space. 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 of CSS. But we learned something as a community from pushing CSS to its limits. We learned techniques that we can use in the day to day. So it'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 someone individually through Eleventy to rebuild their blog. They'll be coming from like a React mindset. Suddenly I show them how they could create something that looks identical to their blog but as HTML. There's that moment that clicks where they've been using a tool that wasn't intended for the. Now, they have a tool that was actually meant for that kind of thing, and it unlocks something in them. That is, I think, a huge takeaway. 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.

Chris

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

Ben

Mm-hmm.

Anthony

Yeah. I was really happy that you were working on the docs cause I know I've struggled with the docs and I know others have as well. But as you said, 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. 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 the spirit of open source, so I'm happy you did that.

Ben
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. Zach has a lot of great context into the inner workings of Eleventy, as well as the inner workings of the web. But Zach is not everyone. I'm not everyone. The two of y'all aren't everyone, right? 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. That is awesome.

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

Ben
We 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 how much the community is growing. It feels like it's exploded in popularity recently, I think in part to the Learn Eleventy from Scratch Course by Andy Bell and I think in part due to things like The Eleventy meetup that have 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. Already we've seen some longstanding pull requests get merged in that have enabled different things. The more people we could get in on this project, the more cool things we can build. Absolutely dive into Eleventy. See what you can build and 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.

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

Ben

There we go. Yes.

Anthony

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

Ben

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. 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 wanna 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. And 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. 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.

Anthony

Tuna wants to be on the show.

Ben

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

Anthony

Thank you so much, Ben. It's always a pleasure getting to speak with you.

Ben
Likewise!

Anthony
We appreciate your time and hope to have you back soon.

Ben

See y'all later.

[Post-show Clip]

Chris

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

Ben

Yep. Even Eleventy beat them to that punch.

Chris

Wow, I should learn more about Eleventy.

Ben

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

Anthony

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

Ben

Yes sir.

Audio Player