How We Built Web Awesome with 11ty (and Why It’s So Fast)

Build once, run everywhere.
In this full-nerd, front-end-leaning episode of Podcast Awesome, Matt sits down with Zach Leatherman (creator of Eleventy) and Konnor Rogers (Web Awesome developer) to chat about how a static site generator just might be the key to building some of the most powerful, performant documentation on the web.

We dig deep into Eleventy’s evolution, Web Awesome’s hybrid architecture, and how a team of devs found a way to keep docs fast, flexible, and secure — without rewriting everything from scratch or giving up on open source values. Spoiler: they didn’t go full ExpressJS for fun.

Whether you’re a seasoned dev or a newb, this one's packed with insight, edge-case explorations, and some seriously satisfying build-time nerdery.

In this episode, we explore:

⚡️ Why Eleventy’s simplicity still scales
 🧠 Making static sites feel dynamic (without a heavy JS framework)
 🔐 How Web Awesome handles auth + private docs with minimal friction
 🚫 Avoiding vendor lock-in and runtime gotchas
 📦 The future of Eleventy in browsers, edge runtimes, and beyond

Pull up your terminal. This one’s for you.

🔗 Links & Credits

• 🎵 Theme by Ronnie Martin
• 🎛️ Audio mastering by Chris Enns (Lemon Productions)
• 🎹 Interstitial music by Zach Malm
• 🎥 Video support by Isaac Chase
• 🔗 Eleventy
• 🔗 Web Awesome

Stay up to date on all the Font Awesomeness!

Transcript

[00:00:00] Welcome to Podcast Awesome. Where we chat about icons, design, tech, business, and nerdery with members of the font. Awesome team and folks within the broader awesome verse. In this episode of Podcast Awesome. We sit down with Zach Leatherman, creator of 11, and Konnor Rogers, who's a developer on the web, awesome team, to talk about how Web Awesome is using 11 to build lightning fast docs.

So whether you're deep into dev workflows or just figuring out the difference between client side and server side rendering. This episode is for you. So without further ado, let's have our chat with Zach and Konnor.

So Zach and Konnor, welcome to podcast. Awesome. It's great to get have both of you guys on. And uh, Zach is the Mastermind behind 11 and Connor is part of the web Awesome team. Um. Konnor, I was talking to your workmate, Corey, uh, who is the boss of Web Awesome. Formerly Shoelace, and Corey said that you had been, uh, talking about using Eleventy as a, uh, solution for something that you were building and a problem that you were trying to solve.

Um, before we get to that, maybe Zach, you can tell us a little bit about 11 D I'm sort of assuming folks that are tuning in. Understand what 11 D is, but maybe for those who don't, can you tell us a little bit about 11 D? Yeah. 11 is a sort of a static site generator that helps you build websites. It's been around since 2017.

[00:02:00] Um, and yeah, it's kind of grown over the years. It's sort of known for its lightweight footprint, um, in terms of build performance and. Runtime site performance. So you get super fast websites and hopefully super fast build times at the same time. Mm-hmm. So, um, yeah, I've been maintaining it for, for many years now and I joined, um, fun Awesome.

Last year as part of that continuing work. So yes, 11 D has been great. Awesome. And. A static site generator, static would just be mean. Something like, uh, maybe like a blog or a docs site. Is that right? Yeah, I think static sites are typically, uh, they typically dovetail quite nicely with content based sites.

So things that don't have a ton of dynamic pieces to them. They don't change too much over time. The content doesn't change on request. Um, and yeah, I think those are the t sort of the typical use case. The other thing that I really like about static sites is that, uh, you really only have to generate the, uh, the.

Assets once at build time, and you get a couple of nice things out of that. You can get build time, uh, errors. So if there's a problem with your, your content or your code, you sort of know before it's deployed to production, um, and end users don't see it. There's also sort of a, a site performance piece of that too.

The more you, the more work you do as part of your build, um, the more work you can take off the end user. So, um, the pages are sort of super quick and fast to load, um, assuming you don't add a ton on top of it yourself, but as part of the tool. Yeah. We try to keep it as lightweight as possible to keep the websites that you build with it as quick as possible too.

Yeah. And you've been working. On 11 for, what, 10, 10 years [00:04:00] now or so and it was fully open source like folks, or? Yeah, it's getting up there. Uh, yeah, it's, I think 2017 was the, the first year that sort of shipped our first version and yeah, now we're on major version three, so, uh, yeah, it's been seven years, eight years.

Uh, but yeah, I would love to see it go 10 years and beyond. Yeah, for sure. Before we hopped on this call, we were also discussing that, you know, folks might say, well of course Connor's gonna build something with a levity because, you know, it's part of like the AU ecosystem or whatever. And it's like, oh good, good point.

But then you guys were saying no, actually maybe as back, far back as like the shoelace days, uh, Corey was using 11 D. Is that, do I have that right? Yeah. So, um, if you go back to Shoelace, um. Originally it was using dify, which had its own set of quirks to it because Dify is a React app and everything's client and sign rendered.

And so we, we were hitting like some strange issues with link links and like anchors didn't work because it used like a, a request parameter with an ID in it instead of using normal like link hashes. So like. We were quickly hitting frustrations with Dify. It was nice because everything was client side rendered in the fact that development time meant there was no like, um, there was no, there was no wait for a page to reload.

But at the same time, we were hitting all these quirks of basically someone trying to reimplement a browser. So Corey. Um, I wanna say 2019, I, I don't know the exact dates, I'd have to look them up, but sometime around there he, um, he was poking around with levity and liked the fact that, you know, static build just H-T-M-L-C-S-S JS and JavaScript doesn't really like, do a lot for you in the sense of like, it's not injecting a bunch of JavaScript onto a page.

Mm-hmm. [00:06:00] And so I think he really vibed with that like that. And so he switched way back then. Um. We've been using 11 and shoe the whole time. Now Web, awesome. We've been using 11 D. We use it for our docs. We use it for everything. And the conversation quickly became how do we continue to use 11, continue to keep our docs the same.

Because if we, if we were to move off of 11 and change our docs, then we always run into the fact that like we introduce subtle bugs and things have changed and move around. We didn't want to mess with what we had because it was working. And so, you know, it was kind of like, how do we continue to use 11 D and add authentication in front of it so people can log in and get their pro contents and everything?

And that was the big problem that we were trying to solve was how do we make these static builds have some dynamic pieces on top of them while still keeping as much static as possible? Right. Now. Originally the idea was flow to just move everything to like a basic express app, rip out 11 d, do all that, and I was like, whoa, whoa, Corey, let's back up.

Let's see if we can figure something out first so that we don't have to go the nuclear route and just get rid of all the work we've done to get here. We have everything working, everything's there. We just need a light little request layer on top to add in authentication. Like there's gotta be something we can do here.

Gotcha. So it started largely as like an exploration into how can we do this? And then eventually it was, whoa, we did this.

Yeah, it's been great to see. I think that, uh, 11. Just as part of the, the core tool, we sort of dipped, have dipped our toes into some dynamic features over the years, and I think the one that has still sort of stuck with the project is that we do, we have added [00:08:00] a sort of an on request image optimization layer inside of 11.

So when you're using 11 D locally, um, we'll optimize your images when they are requested in the browser so we don't have to do a ton of build time work. When you're developing locally, but that build time market still still happens as part of your production build. So really has tightened the developer feedback loop in that way.

So there is like a sort of a nice overlap between the two worlds. Um, and that sort of, it has facilitated as part of owning our own dev server. Um. Yeah, it's really, it's been really cool to see what y'all have layered on top as sort of an extra on request thing, because I do kind of feel like that is a future direction for the project as well.

How do we sort of manage. Um, living in these two worlds without giving up too much of the, the original benefits that we had from the, the, uh, upfront builds.

So, I'm curious, Zach, um, with the solution that the folks at Web Awesome. We're trying to, to find, was there. Was there anything that sort of emerged for you where I was like, oh, like there's maybe some, a new feature or like something that I ought to build in order to have flexibility for folks in the future?

For, for something that you maybe hadn't thought through? Not, not that you hadn't thought through, but like this is an opportunity to build something. Yeah. I mean, we have had. Dynamic pieces in 11 core, historically, uh, we sort of dove into some hosting specific adapters in terms of like a, we had a serverless plugin and we had an edge plugin, uh, in version two.

Those were just sort of single host specific, so you couldn't really, uh, you didn't really have the same [00:10:00] portability benefits that a lot of folks would expect from an eleventy project, uh, especially if you use those plugins. So, uh, we sort of moved away from that and. Went back to our roots as just like a pure static site generator.

So there is sort of this tension, right, that exists between, especially in the JavaScript build tooling ecosystem of, there's a lot of hosts right now that are, that have like, uh, I wanna say. What's the nicest way to say this? I wanna say they have a lot of vendor lock-in when it comes to their serverless implementations.

Um, and they sort of use that to, to make money. They're sort of a, maybe a light wrapper around AWS Lambda or some other things, and they give you some nice developer experience improvements there. But, um. It becomes then more difficult to port your site to a different host, uh, which I think is a very important feature, uh, especially when, uh, you're using hosts that that may not have a ton of longevity to them, or they may be propped up by business models that don't have a ton of l longevity to them.

So I think portability is a very important part of the 11 ecosystem. And, uh. And having hosting specific adapters is not really something that I would love to include long term or a code that I would want to maintain. Um, so it's, it's, it's more of a, I think we're taking a different tact moving forward in that we're trying to make 11 as runtime independent as possible.

And not have tight integrations in terms of single host specific features. Um, and that's sort of where I, where we'll probably talk about later 11 sort of, we've been. Sort of doing what this initiative to try and make 11 run client site as well. [00:12:00] Mm-hmm. And that's sort of the same thing, right? We're trying to get 11 D to run dynamically in a, in a bunch of different JavaScript run times or even in an express app.

Um, and also client site in the browser, which is sort of maybe a strange direction I think. For, for a lot of people to see after we've, we were sort of the, the, I have like a no js, uh, thing in my background, like a very limited client side JavaScript. But, um, there is, there are use cases for it. Um, and as long as you apply those correctly, uh, they can be a great benefit to your project as well.

Um, and I think a lot of people sort of have asked for, uh, these features, like having user authentication, having sort of lockdown content. Um, and it makes sense, right? You wanna have a product that you can sell. It can't just be, it can't just exist on the public web. Um, and that's why you're seeing a lot of these extra features now.

And I think that the, the work that, that Connor has done has been great for that too. I think that the, the. Maybe the thing I'm really interested is to hear about your technical direction that you chose for the backend. Did you decide to use a serverless adapter? Did you decide to use a specific host for, or a, like a host independent thing or, or a node runtime?

Like what was your thinking in terms of the backend architecture that you, you decided to add on top of 11? Yeah, so I actually had some pretty strict requirements from people above me. Well, I don't know about above, but we have a DevOps team of a few people who had some pretty strict requirements of, we basically didn't want to introduce that runtime lock-in that Zach had talked about.

Mm-hmm. Of. You have these platform specific features that only work on, you know, various different hosts. And we did, we wanted to be largely agnostic because we do have our own in-house DevOps team that has its own in-house deployment platform and does its own in-house [00:14:00] stuff. And they wanted us to be a part of that, particularly for track, just tracking everything, having logs all in one place, having everything in one place.

So it was kind of like non-negotiable that. Serverless. We initially looked at serverless, edge, et cetera, and it, it just wouldn't work with the platform that we had. Right. It would've been too much operational complexity to make that happen. So that was like immediately off the table, despite that kind of being like at the time in Docs, like the big way to add dynamic pieces was with these edge run times, these serials run times.

So that was off the table immediately. Like that was like a hard no, and that was not part of the requirements that I had to build it. So it was like, we need a. A server that we can run, whether it's Elixir, it's Rails, it's, you know, node with express, whatever the case is, it just needs to be a simple server that I can put together in a docker image, build the docker image, and then we can run that, that container.

So that was the requirements I had. So it was very specific of how this needed to be. Um, and so after poking and prodding around. Um, we ended up going with Node and Express, partly because the team is familiar with Node, they're familiar with Express, and Corey initially built out a, a small prototype with Express but not using Eleventy at the time.

And I used that prototype to kind of poke around Eleventy and my first initial implementation with it was not that great. So initially what I was doing was what Zach was talking about with the, um, dev servers and on request we would transform and we would look for an index html from 11 and transform that index html if it had like specific short codes in it.

The problem I found is that. When you, we were running this second nun jug. We, we ended up going with nun jugs in the end. We were using EJS at the time. We went through a few different templating stuff, but settled on nun jugs when we were doing it on the [00:16:00] before request and within the dev server. It was running too late, right.

A lot of transforms already happened, and so we needed the, the second transform to be the first thing to run in our, um, post-processing in 11 D. So that everything would get it, get all the pieces it needed just in case something transformed toe looking like a nun, jux, um, variable injection. So initially we went with that before request and then over time it turned into a transform.

And then it was like, okay, we have these index HTML files, but we need a way to find them. So like I built this little pathfinder utility within node. Would then take the js ON that 11 would provide of all the input paths and what they turn into for output paths. We kind of have like a, um, I forget the word for it.

Um, so like, for like native apps in Turbo, they have like an apps js O, which includes like a giant JSO list of all the possible routes, kinda like a site map essentially. So we essentially had like a site map of all the possible routes and like what their, what the input path of those was. And like. So we were able to map when a user would go to, you know, slash fu, we would have a different template file that we knew we had to transform on the server.

And so that's largely how we got there, was we were like, let's take all the possible files we have and just kind of make like a pass through copy almost, and then run a second. Nun Jux version on top. Mm-hmm. And if you, if you look into the web awesome code that will be open source, maybe by the time this podcast goes live, I don't know.

Um, you'll see that we actually fake running a server within 11 and have some like flags to turn off so that like you don't get placeholder content. Yeah. So do you run, uh, each route is a. Either dynamic all in or static, or is it more of like a [00:18:00] Yeah. How do you decide when the route is dynamic and when it isn't?

Is there any static that gets generated or all those? All the routes run through the dynamic processor, so everything goes through the dynamic processing. Except for static assets. Static assets get a different handling 'cause there's no need to run dynamic on it, but everything on the site, because everything.

Adds like a little avatar with like if you're logged in or not, or adds a login button. Everything needs to inject that little piece. So, so did you, did you make use of, just in terms of how did you denote what nex would get processed ahead of time and what nex would get processed on request? Did you use a, like a raw short code or, yeah, so, so this is like the one weird spot is like if you need something to run on the server.

But you're doing it within a a, uh, nun jux file. You need to use two raw calls to make it run on the server. 'cause the first raw call, the first raw call, uh, sorry, you'd use a single raw call to make it run on the server. And then if you needed to actually be raw in the sense that like, we don't want this ever transformed by either the first pass by 11 or the second pass by the server, then you need to use two.

Raw calls to be able to make it, um, not transformed. Yeah, so basically what what it comes down to is one raw is a server call or two raws is actually raw. Okay. Yeah. I see. Yeah, we, it sounds like we used a very similar implementation for the Edge plugin. Uh, we had sort of like a second stage of, we used liquid for that, but it was sort of a second stage of this.

This code would run dynamically on the edge and this code would just, uh, run as part of the static build. And it was really sort of a, a really cool way to, to mix and match inside of your templates. What would be. [00:20:00] On request and what wouldn't and yeah, I, I thought it was, yeah, just a very, very amazing technical architecture where you could have most of the page be static and then there would be a small portion of it that that would be interpreted dynamically.

I thought it was a great way to mix it together, so. Kudos to you for that. We actually have two pieces that run dynamically. So we have those raw calls when you're working within a, a template file. But there's also like some pieces, like we have a, um, head do nun jugs that we use for just, you know, putting all our meta tags and everything and there's no nice way.

We could have maybe gotten away with blocks, maybe. Um, but we just ended up using like a simple utility that like we pass in some extra template data with like server dot head, which is just like a string of like different script tags, linked tags, stuff that. Would only be necessary from the server, but don't need to run into static Bill.

The big challenge that we had was we also when when Cory was initially discussing moving everything into a node and express app that would be in a private repository, we would lose the ability for people to be able to edit pieces of the documentation. We would lose people being able to run the documentation as well, because.

The core of Web awesome is, is open source, well will be open source, and not having somewhere for people to run this documentation means we would have to set up something like storybook to be able to run some, mm-hmm. Some code so that they can see the components and mess around with them. And. It just felt very weird to have to introduce additional processes when we already have everything here.

We just need a little bit of extra dynamicism on top of it so it, it. It was very much a challenge in the sense that we wanted people to be able to continue to use our documentation, be able to run everything, but we did need to hide some [00:22:00] things, right? Like there's no reason that users who are, you know, cloning down the repository, forking, need to know about authentication.

They don't need to know about, you know, all the account stuff, all that. So like that did need to be hidden away in the app. So it was largely a balance of how can we keep this free open source, let people continue to use the documentation they know, but at the same time, still squirrel away the various pieces that we need for ourselves that aren't really, don't need to be part of that open domain.

Yeah. That's fascinating. It almost goes into, um, authentication is almost a progressive enhancement at the framework layer, which is amazing to me. Like what happens if you clone the repo locally? Um, and you don't have that sort of extra runtime piece. Does it just hide the auth stuff all together from the app?

Yeah, you just don't get it. It just never sends it. Um, so we kind of have like a stub of data in place that runs a second 11, uh, second, um. None jug transform within the 11. It's a post-processing transform that will add this extra data. And if there's just a environment very flag of like is web awesome server or something like that.

And if it's set to true, it won't run that second transform 'cause it expects a server to run it. But if you set it to to false, then it'll just inject this placeholder empty string for you and you just never see it. Hmm. Yeah. That's fascinating. So it sounds like that you have sort of added this nun jux post-processing layer.

Um, how did you, I I think you dove maybe a little bit into the piece of data sharing between, uh, sort of the build time piece and the runtime piece. How do you control what data is exposed to that? To that sort of POS post-processing NX layer. Yeah. So right now all the only data that really gets exposed is whatever 11 D gives us.

And then one additional thing is we have like an IS [00:24:00] pro front matter in our pages. Hmm. And Zach was nice enough to, uh, show me. Um, how to have 11 output that within the final JSON within 11. So 11 has like a function call that you can be like, um, 11.2 js ONI believe, something like that. And it'll give you like all the input paths, output paths, directories, everything that you could like possibly ever want to know about your build.

And then some additional front matter that you may want in there too. And that's. So basically we just stored this blob of JSON and read off of it and use that as kind of like the source of truth for the server to then know where to direct people and what pieces of information it needs to know. Yeah, that's great.

I think that to me, that just brings up this whole notion of how much of 11 d do you want to run on request? I think I really struggled with that when I was working on the Edge plugin. Uh, be because we had sort of disabled, uh, access to your global data cascade inside of the runtime piece. Um. I, the, I think the only reason I did that was for performance reasons.

You wanna have that on request, uh, layer, be as lightweight as possible. Um, and I think the feature that you were mentioning is called a data filter selector, something like that. Yeah. Lets you add more data to your j json output. But, um, yeah, I, I think that just. Sort of going back to running 11 in as many places as possible.

I think that there is a world in which you could run 11 as the post-processing step. Um, and we would sort of take control of, uh, instead of that nun Jux piece that you're sort of adding yourself, you would run 11 again on request. And there might be some interesting architectural overlap there, um, because then you'd have access to the full data cascade and all of that, as long as the.

As long as the runtime [00:26:00] performance was good enough. Um, and in some of our experiments we've been doing in running 11 in the browser where you sort of run an 11 build on every keystroke as you're, you're using the editor in browser. Uh, and it has been pretty good so far. So, uh, I think as long as we can keep that, that runtime piece as, as lightweight as possible, there, there might be some very interesting features to come in that same layer.

Yeah, I think that would be the ideal cases. We would be able to post-process with 11 D again and mm-hmm. Be able to reuse all our existing temp completing and everything and kind of have it be aware of what it's transformed, what it hasn't transformed. Um, I think that would be a huge future enhancement, like you said, given that performance isn't an issue there.

Um. Because, yeah, that, that was the big piece is we, that's why we went with Nun Jux. 'cause we're already using Nun Jux in the 11 static build. So like we wanted to keep the templating to make it feel the same within the app. In fact, there there is actually like one little edge case with the app where, because of 11 DI think this is.

Part of why we moved away from the before request, I don't think it's actually an issue anymore, but basically when 11 D would do itch, transform, um, transforming the HTML, it would have a hard time with the, um, nun jugs variables. When you do like curly braces set, um, you know, is whatever equals. Fu for example, it would have a hard time with that.

So it would like inject, particularly from markdown pages where it was a problem. It was that markdown to HDML conversion where it would mm-hmm. Like inject extra, uh, paragraph tags, paragraphs for you. Paragraphs, yeah. Yeah. And it like set your variables as like attributes of the paragraph tag and it got all messed up.

So like a lot of our server templates are nun jux extensions instead of markdown files. That was like the one edge case of like. We can't really have these live as markdown files 'cause they run into this weird processing issue. [00:28:00] But other than that, everything's been fine and a lot of our, um, data pieces on the server don't really make sense as markdown 'cause it's a lot of heavy HTML more than markdown.

Yeah, I think there are some sort of gnarly edge cases in markdown parsing generally that a lot of folks run into. Uh, and we had this for a very long time. In 11, there was the markdown convention of indented code blocks, and it was almost a universally hated feature. No one liked it. Everyone hated it. Uh, and we were able to disable that in a major release.

I think, uh, version two, we finally got rid of it. But, uh, yeah, it was just very confusing for folks that, uh, would have some indentation in their markdown code and suddenly that would become a, a formatted code block. Um, and so yeah, there's some, there's a little, there's a few gnarly quirks in markdown I think that, that catch people off guard.

Uh. I think the other one that is, that comes to mind immediately is, uh, the difference between, so when you embed HTML inside of a markdown file, it actually tries to distinguish between a. Block element and inline elements. And so if it's a, if you do an inline element, it will wrap it in a paragraph. Um, which is, I think, very surprising to people.

They expect that if I start a line with HTML. And this is especially important if you're using custom elements, uh, web components. Uh, because if, if it's an unknown tag to the markdown par parser, it, it doesn't assume it's a block tag by default. It's not a block tag. So, uh, yeah, that can create some interesting wrinkles for folks as well.

There's some, just a little. A few weird things about markdown. Yeah, I think we could do a whole nother podcast on markdown parsing because like even some markdown, parsers, when you have like. If you have, if you end a line with a, [00:30:00] a, um, closing tag of a diviv, you have a, and then you put a new line between your next element, some, some pars will inject a a paragraph tag.

In between that, others will continue. HTMO. Processing and you're like, why am I getting this difference here? And like there is, I mean, even when we used Astro, their markdown, parer, we used a custom element and we set a value attribute on it and something about their markdown. Parer didn't like that, and it would strip away the the value attribute.

And it was like a core issue that they had no control over. Something about like the A ST that got, that got created and it was like markdown parsing is cursed is all I've come to learn. Yeah, I mean I think it, a lot of it's just historical problems with their, for a very long time, not being an official standard for markdown.

I don't think there is one still. There's just sort of a couple of different ones. I think there's loose specs is what it is at this point, right? Nothing, yeah. There's a common marks. Spec and Yeah. Yeah, I don't, maybe there's a couple of other ones, but yeah, there's not really a formal agreement on how markdown should be parsed, which is a problem.

So, Connor, I am curious now, what's the one thing that you wish somebody had told you before you got started on your project? Um, I wish, I wish somebody had told me how hard it would be to mix both. Public and private repositories together. Mm-hmm. And get those bills to talk to each other. And the amount of headache that it was going to introduce in my life.

Um, I wish, I wish I had known just how bad that was going to be. I had an idea, but not until you're in the weeds, you realize just how bad it is. So Zach, is there anything on the horizon for 11 that you're excited about that you like to tell folks? Yeah, I mean, we're sort of heading this future direction of trying to get 11 to run in as many, uh, JavaScript run times and as [00:32:00] many environments as possible.

Um, we've sort of added, uh. An 11 D code editor and some of our demos on the documentation. And that's sort of a working example of 11 D running in browser. It runs an 11 build every time you hit a keystroke on the keyboard to edit in your 11 D project. And um, you can kind of see in your browser how fast it runs, how fast it builds.

Um, so I think that has been very powerful. But there's also just some future work, I think, where we will get sort of a single file. Bundle of 11 that you can run in a bunch of different rot, uh, run times. You can run on the server, you could run it in node, you could run it in Dino, you could run it in an edge, uh, environment, in a serverless environment and on the client.

So there'll be a lot of very interesting. Uh, dynamic use cases that come, that come out of that, uh, that I think will be really great for the future of the project. And, uh, getting 11 t to run in as many places as possible will help developers as well. Yep. It's all about having those options, baby.

Absolutely. Zach and Konnor, uh, thanks for taking some time today to come on podcast. Awesome. And to cock shop a little bit. And is there any other like, bit of content we could, uh, suggest for folks to check out or any resource on either web Awesome. Or Yeah, so Web. Awesome. I believe the date is by end of June.

We hope to have it open source. Um, you can still back web. Awesome. And we can get you set up with an account to check out the Pro features. We hope to have an MPM package out soon as well, so people can do that and not have to run off the CDN. Um. I think those are the big three things for web. Awesome.

That's great. Looking forward to all the awesome stuff we're gonna be building. Thanks fellows for coming on today. Thanks for having us. Thanks for having me. Yeah, for sure. A big thanks to Zach and Konnor for coming on the podcast today [00:34:00] to chat with me about how to balance the elegance of static builds with the complexity of modern app needs.

Without losing the benefits of speed performance and that oh so important. Open source spirit that we love so much here at fa. Awesome. If you want to keep up with everything that 11 and Web Awesome are up to these days, you can check out eleven@eleven.dev, like the number 11 tty.dev, and sign up for early access to Web.

Awesome at Web. Awesome. Dot com podcast. Awesome. Was produced and edited by this guy right here, Matt Johnson. The podcast awesome theme song was composed by Ronnie Martin and the music interstitials. Were done by Zach Malm. These video episodes, we get some extra editing help from Isaac Chase. Okay, until next time.