543: Zach Leatherman on Eleventy, Mastodon, Twitter, and is-land
Zach Leatherman talks with us about what's new with Eleventy, setting up on Mastodon, what's happened with Twitter, and is-land.
Time Jump Links
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about websites. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris. How are you doing today?
Chris Coyier: I am doing absolutely perfectly.
We have a special guest on this week! Can't wait. Been wanting to talk with Zach recently. This is almost an excuse. It'd almost be nice just to talk to Zach so I could have him explain some of the new stuff he's working on personally, but I don't think Zach takes personal video solicitations, so you have to invite him to a podcast to get it.
Zach Leatherman! How ya doin', Zach?
Zach Leatherman: Great. How are y'all?
Chris: Good. Fresh from Jamstack Conf -- probably, I think, as we're recording this -- just yesterday. We might be a few weeks out on the show. Sorry if that sounds dated to all you listeners of this. But what is time anyway?
How was it? Was it cool?
Zach: It was amazing. Yeah. Really great couple of days. It's awesome to chat with a lot of the--
Chris: Netlify throws it and you work there.
Zach: Yeah. For sure. Yeah, so I did get a free trip. I snuck onto a panel. I feel like panel speaking is the easiest of conference speaking.
Chris: Yeah. [Laughter]
Zach: Yeah.
Dave: My vibe on panels is to play the role of wildcard.
Zach: [Laughter]
Dave: Just pure wildcard.
Zach: Yeah.
Dave: Intentionally. Yeah. What's your vibe? Are you serious?
Zach: The theme of the panel was open-source software and sort of collaboration and how it's going to reduce the framework wars long-term. So, I don't know if wildcard would have been an appropriate role in that panel.
[Laughter]
Dave: No, you should have flew me out. Matt, call me. Call me next time. You can fly me out.
Zach: Yeah, I feel like it was supposed to be not spicey, but yeah, I talked a little bit about single-page applications. [Laughter]
Dave: Okay. Okay.
Zach: They couldn't stop me.
Dave: They couldn't. Yeah, you're like, "I have the mic. You can't turn it off."
[Laughter]
Dave: That's fun. I'm sure we can get into that later. Zach, what's happening? 11ty.
Chris: Yeah. I mean I guess that's your main project, isn't it? Despite the fact that you work at Netlify and probably have to show up to those standups or whatever too. They kind of pay you to work on this static site generator known as the beloved 11ty, right?
Zach: Yeah. It's the real deal. It's full-time open source. There are no standups. [Laughter] Yeah, I mean it's really just me dedicating full time to 11ty.
Chris: Yeah. Okay, so that's great. Eleven as in 11ty.dev is the URL if nobody has seen it. It's not even the new kid on the block anymore like it used to. You've entered your adolescent stage, perhaps, as 11ty. It's hit 1.0, and even 1.0 took a hot minute to get there.
Zach: Mm-hmm. For sure.
Chris: But pretty rad, right? It literally has nothing to do with JavaScript, despite that it's a Node-based thing, right? it doesn't help you. It's not a bundler for your JavaScript. There's nothing that turns your Vue components.
I know there are plugins and stuff that dabble in this, but the core 11ty just could care less about your JavaScript, right? [Laughter]
Zach: Yeah. It really kind of has its roots in Jekyll, and that was kind of the origin of it. I wanted a JavaScript alternative but very similar to a lot of the conventions that come from Jekyll.
Yeah, it's been interesting because we've kind of taken the role of low JavaScript, zero JavaScript in the JavaScript world for a while and sort of carried that torch for a very long time. It's been awesome to see some other frameworks sort of pick up that torch as well - or pitchfork, or whatever you want to call it. [Laughter]
Chris: Ah! I like mentioning the fact that it comes from this previous land where Jekyll was kind, but there were others like Hugo that got popular - and stuff - that are in this. There used to be a vibe that was like, "What an SSG is, is kind of like some templates that Markdown goes into eventually," kind of thing. [Laughter] Then that got conflated over the years with frameworks that were JavaScript-focused but maybe could output as static and maybe not.
To this day, perhaps the king of frameworks has become Next, and there was Next.js Conf recently. We've talked about that on the show. It just got wildly popular because of - for whatever reason - good DX and stuff. I'm actually kind of a fan of Next, personally. Although, there's certainly criticisms you could lobby at it.
As soon as Next 13 dropped, there was even a tweet from you that was like, "Look at the bundle of the Hello, World of Next. It has a massive amount of JavaScript."
Zach: Every time Next releases a version, I do the Hello, World and see if the bundle size has decreased, and it doesn't seem to be trending in that direction (despite some of the React server components marketing that sort of went around it in reducing the JavaScript bundle). The story isn't quite there yet, and I'm wondering if that will come. I mean it seems like the promises keep coming but the code tells a different story, unfortunately.
Chris: It seems like there could be a world where the JavaScript correlates to what is happening on the page. On a Hello, World page with absolutely no interactivity at all, it does seem reasonable that the JavaScript bundle then would be zero too.
Zach: Yeah. My primary complaint is just if you're going to have a tool that bundles a bunch of JavaScript, don't market it for low JavaScript cases. If you go to the Next docs right now, you'll see that the getting started tutorial is all how to build a blog, and that's very heavy content-focused sites. Yeah, just don't sort of lead folks down that path if you are more of an application-focused tool.
Chris: Yeah. Fair enough. But perhaps one of the reasons it gained some popularity (probably tied to the idea of React and how many people know and are comfortable in React) and that you get to kind of build things in components, passing props around, and scoping styles to them and such, and having it feel like, "Oh, components. What a nice way to build."
I personally am compelled by that as well. Not from a, like, "I love React!" thing, but "I love the conceptual model of building things with components and scope styles and how those components communicate with each other and the fact that they have their own state," blah-blah-blah. Right?
Now perhaps this next movement -- and we saw this with 11ty, too, with Ben's thing. What did you call that? Slinkity or whatever?
Zach: Slinkity, yeah.
Chris: It was kind of like, "I love 11ty and I love components. I want both." And that started to happen.
Then he popped over to Astro because I feel like they shared a similar vision - in a way.
Zach: Yeah, for sure.
Chris: Astro has that same kind of thing going on. Sorry to make you come on and talk about your competitors a bunch. We'll get to your thing in the second.
Zach: I mean the whole point of the panel too, right? Fred was on the panel.
Yeah. I don't want to harp on this too much, but I really feel like a plurality of successful frameworks is going to be the next thing. We don't need to crown a champion that has one way of doing it.
Chris: Well, that's nice.
Zach: We can have a bunch of different successful frameworks that are marginally different but are moving towards a better goal.
Chris: And perhaps building with components is part of that story, maybe, hopefully, and if you ask me. And so, they did it, and they even had the interesting... They, meaning Astro, did this thing, like bring your own framework. Kind of clever. We'll see how that goes out.
And in my mind, for a short period of time, it was almost like "Oh, poor 11th" thing because it's so nice, but the component story there isn't really a first-class thing, and I wonder what Zach is up to. That's kind of why I wanted to talk to you.
Then all of a sudden, you have the perfect answer for it.
Zach: [Laughter]
Chris: Kind of just arrived, and that's in the form of this thing called WebC. We're in the beginning of the show, and I think that's perhaps the juiciest thing that we can get into. Although, we'll see. There are probably lots of juicy moments here.
When I say WebC, that is a name that you invented.
Zach: Yes. Correct.
Chris: What is it?
Zach: WebC is a single file component format for Web components. That's where the C comes from is just an abbreviation of components.
Really, it's history is from Vue single file components, and I wanted to sort of bring that to the Web components world. A few years ago, we rewrote Netlify.com, and this is before I was working on 11ty full time at Netlify. I worked on the Netlify.com marketing team.
We built that using 11ty, and we used Vue single file components with the 11ty Vue plugin. It really took the same approach that Astro takes now (by default). The components are all built into static HTML, and there's zero JavaScript (if you don't want any).
Chris: How does that work? You can ask Vue, "Hey, here's a .vue file. Could you please turn this into HTML for me?" Then 11th can take it from there?
Zach: Yeah, it sort of runs it through Rollup in the 11ty plugin specifically. I think Astro uses Vite, which uses Rollup behind the scenes for that. Yeah, so it's a lot of the same mechanisms, but I love components in the same way.
I feel like that it's a great way to author things. it's a great way to not have a bunch of duplicated code all over your codebase. Yeah, I really lived that through the Netlify.com project for a couple of years before the sponsorship started.
Chris: You're seeing the benefits of componentry, but now you're like, "I'm using Vue almost just because I want components." It was almost like a stand in for that. I mean maybe you love Vue for other reasons, but it doesn't seem like you were leaning into all that Vue has to offer. It just was a way to make HTML components and stitch them together.
Did it feel like that? Does it feel like, "Man, I wish we didn't have to use Vue for this, but I don't know. At least it's the easiest one to use at the moment"?
Zach: Yeah, I mean I think the Vue community is more aligned with some of the values that I have in terms of trying to use more of the platform. But the Vue JavaScript library is getting a little heavy now. I mean they have Petite Vue, which I love, which is a great sort of alternative, and you can do progressive enhancements with it.
But if you want to do client-side Vue stuff, I think the baseline JavaScript is a little bit more than I would want. I don't want to get too spicy there because React's is so much bigger than Vue's.
[Laughter]
Zach: I'll take it even spicier by saying that, right?
Dave: Yeah. I think it's like 30K and 90K are the floor there, right?
Chris: Yeah. Right, and Petite Vue is not -- it's not something that has a compiler in it. You can't take Vue and get raw HTML out of it. It's just a different approach. It's more like the Alpine.js kind of thing, right?
Zach: Right. But just that they had that, I felt like, was a good vote of confidence. Yeah.
Chris: Yeah. Indeed. They keep an eye on it. They care about it. It's proof that they care about stuff - the right kind of things.
Okay, but I don't know. Maybe you never felt, "Oh, it's too bad I have to use Vue for this," but you are kind of a platform guy. [Laughter] Obviously, your love of HTML, your reputation precedes you, let's say. But you're attracted to the idea of native Web components, clearly, because you just spent a whole bunch of time working on them. But perhaps saw some shortcomings or some ways that they didn't jive with what 11ty is doing - or something.
I'm trying to dig at what was the, like, why spend so much time and energy on this WebC thing, which we haven't even really described, but we're trying to set it up perfectly. Right?
Zach: Yeah, I mean there's been a ton of very (I already feel like) fair criticism of Web components over the years. And the criticism, I think, is rooted in folks that have a ton of client-side JavaScript framework background. They really expected Web components to fill the same use cases and the same needs that the frameworks were already solving.
I mean really, I think the thing I'm trying to bring with WebC is a way to address a lot of those complaints. And I'm a big fan of Svelte, and I think one of the biggest maybe fairest criticisms I've seen of Web components has come from Rich Harris. He wrote a blog post a few years back. Really it was about having the correct progressive enhancement story or the correct authoring story for Web components really came down to you have to copy and paste a bunch of fallback content throughout your components or you need to client-side render them. There's some drawbacks to both.
Chris: Hmm...
Zach: The thing that I'm trying to do with WebC is to make it so you can use components without having to worry about the fallback content that you need to duplicate inside of your authoring experience or inside of your local files and will compile that to HTML for you.
Chris: Because you have a compiler because that's what 11ty is, right? Yeah.
Zach: Right. Yeah, I'm trying to bring the Svelte compile APIs. Yeah, my background with Vue single file components and sort of marry a bunch of those good approaches together in the Web components world.
[Banjo music starts]
Dave: Today's episode is brought to you by Sanity. The new Sanity studio has amazing features like embeddable authoring, which enables you to bundle Sanity as a React component within the Web app code itself.
The studio has been fully rewritten as modular React-based components that enable you to reduce maintenance for your content system overall. Yay! Less code. It also has full TypeScript coverage so you can customize your studio with confidence and support from within your favorite code editor.
Sanity is hosting a Sanity Product Day on December 8th to showcase the latest updates. Learn more at sanity.io/productday.
Thank you, Sanity, for sponsoring the show.
[Banjo music stops]
Dave: Setting it up -- because I don't mean to brag but I have a Frontend Masters course on Web components. You can go buy it right now.
Zach: [Laughter]
Dave: I saw this, and I was like, "This is cool," because since Palmer or since the switch from HTML imports (rest in peace), a lot of Web components have become JavaScript client side only. We got declarative Shadow DOM, which is, like you said, a fallback strategy, sort of a placeholder skelly screen [laughter] skeleton vibes. While that's okay, it's just not the same as progressive enhancement exactly.
But what excited me about WebC was, yeah, it's this Vue style component, so I think, on your docs, you have avatar image, and it can take a source file and an alt attribute and stuff like that. Right? Then it runs through your little WebC compiler, which can be used with and without 11ty, right?
Basically, I saw it as React render to string. I mean that in the nicest possible way.
Zach: Yeah.
Dave: But it just basically takes a dynamic component and says, "Cool. I can do stuff with this. I know how to make this interactive or use the JavaScript I need to create."
I guess, how does that do that with dynamic components? I don't think I understand that, like props and stuff. How does that work in WebC world?
Chris: Yeah. I was going to ask about that, too. How do you declare a WebC component?
Zach: Yeah, so there are a couple of different ways to do it. In WebC specifically, you can define a component's folder that will then parse all of the files inside of that folder.
It's sort of strange because there's some weird crossover between WebC and Web components. Just in WebC, you can have any HTML element be a WebC component. That isn't really a requirement or isn't allowed by custom elements inside of the browser.
In custom elements inside of the browser, which is part of the Web component spec, there's an umbrella of a bunch of different things that goes into Web components. Inside of custom elements, you need to have a dash and the name, right? It can't just be any element.
But I can make a paragraph WebC component and have it transform to be whatever I want. There's no limitation there because WebC runs on the server. It's a precompile step. It doesn't run on the client. Whether or not we'll do that eventually at some point is a point of discussion.
Chris: Yeah, so it's not a real Web component by the time it hits the browser. It's been juiced away.
Zach: Correct. Yeah. Yeah, it's just an HTML preprocessor.
Chris: Really?! I didn't understand that point. Then you're also not using Shadow DOM. Even though I know your offering like a scope-styled solution, it's not scoping via Shadow DOM. It's scoping via some CSS Modules-like approach.
Zach: Yeah. It's more analogous to what, again, Vue single file components do. If you put a style block inside of a WebC component, we'll parse that out or we'll take that out and put it into your CSS bundle for the page. Then we'll process that using some code we have in there to modify your selectors to scope them.
Chris: Okay, cool. A WebC component, this is almost the neatest part about them, I think, is that they're just like HTML files, right?
Zach: Yeah.
Chris: They're quite literally... They even have a doc type at the top, right? I don't know if you need that or not, but it's there if you want it.
Zach: Yeah. Well, there's... Yeah, so 11ty really tries to enforce strict mode parsing. It's not required necessarily if it's just in a component file. But if you have an HTML file, yeah, you're going to want that at the top, like a page-level HTML file.
Chris: Yeah, so you have this WebC component, and it's just an HTML file because HTML files are like single file components in that you can put CSS in them. You can put JavaScript in them. It's kind of like, "Yeah, Vue, you're so cool with your SFCs. But the OG SFC is .html, baby." That's so cool.
Zach: Yeah, and if you go out and look for HTML single file components, there are some really cool, pretty old blog posts about how to just dynamically include an HTML file and have that work for you automatically. Yeah, I think some of WebC's roots came from that idea.
Chris: Now I'm going to use one. I'm going to make a card component, and I'm going to make it a WC. Yeah, cards. Hell yeah.
I'm going to make Dave's book page, so each card is a book or something. And the way my mental model for programming this works is that I'm going to have some kind of template, and it's going to call book-book-book-book-book-book-book. It's a loop, maybe.
Then those book components are going to have some data passed to them.
Dave: Rating. Title. Author.
Chris: Title, rating, thumbnail - all that stuff. I think of those as attributes or props.
Zach: Yeah.
Chris: And so, how am I sending those to a WebC? Do I go just like as HTML attributes?
Zach: Yeah, absolutely.
Chris: Sure. Right?
Zach: There are a couple of different ways to do it. We have just raw HTML attributes, which I think you'll just be very familiar with, and those will be available inside of your component definition. Then we have dynamic attributes, so those will parse as JavaScript. You can write JavaScript inside of those. So, you can do dynamic ones.
Then we have a third thing, which is props. Props are like private attributes. They operate the same as attributes, but they just aren't rendered to the output.
Chris: Which one steamrolls the other one? [Laughter] Like can you make class a prop? Which one wins?
Zach: What's your question? I don't know that I understand.
Chris: If you name a prop the same as a normal HTML attribute, like lang or class or something.
Zach: Oh, that's absolutely allowed. Yeah. You can reuse attributes the same as anything else.
Chris: Okay. Yeah. But where I care about those things is inside the component because I'm like, "Ooh, I have thumb now," and I know that it's probably a prop because - I don't know - that's probably the appropriate thing to pass it. It's just some data that I'm passing it. Where do I pluck it out?
Zach: Yeah. You could just reference that directly inside of dynamic attribute, or what...?
Chris: I don't even have to pull them out of some props object or something. They're just magically available inside. Yeah...
Zach: Yeah, and we have a couple of different larger block-size JavaScript functions in there too that you can do, like render functions in WebC. If you wanted to use more HTML element style, like transforms, you can do that.
Chris: I see. There's a render function. Meaning, yeah, if I want to do dynamic JavaScript stuff to ultimately produce that HTML, I can do so.
Zach: Yeah.
Chris: Like a loop.
Zach: Yeah, exactly.
Dave: Love loops. It's cool, so I guess 11ty is smart enough to see whatever book, and it's like, "Oh, I know where book is. It's in my component, so I'm just going to go take all this new data and run it through my little WebC interpolator and basically just crunch it out."
Zach: Yeah, so that's kind of a thing with custom elements, too, is they're kind of global to the page, and so that is good and bad. But you can also scope them in different ways as well. We have a way to dynamically import another component inside of your WebC file. I think it's the WebC:import attribute. You can directly reference another WebC component file and it will use that component's definition too.
Dave: It's neat.
Chris: That is neat. I guess that's what I had wrong in my head is this kind of has nothing to do with the Web platforms Web components. It might share some spirituality or something but it doesn't use any of that technology in browsers, like none.
Zach: Yeah. Correct. It's mostly reusing the same conventions that are used for Web components.
Chris: It'd be ultra-weird, but you could do it. You could put a traditional Web component in a WebC component.
Zach: Yeah. I have a bunch of demos of that.
Chris: Of that?
Zach: It just doesn't generate any client-side JavaScript for you as well. If you want to have a custom dynamic component, Web component, you can definitely put that in WebC, and that's encouraged.
Chris: Yeah, right, like the classic image slider or something. Hell yeah. Chuck that in there, baby.
Zach: Yeah, and we have some good demos of image comparison components on our docs. I feel like that's maybe the really interesting and different thing about WebC is that it's very clearly delineated what is on the client and what is on the server. That really allows you to control how the progressive enhancement works. Maybe one of the coolest demos we have is I built six or seven different image comparison components using WebC using different progressive enhancement strategies.
Chris: Oh, wow! Really?! There are seven ways. That's a lot of ways. [Laughter]
Zach: Yeah. Well, I just really wanted... I mean I feel like that level of control is important because, just based on the context of where a component is used, you might want to use a different progressive enhancement strategy.
Chris: Yeah. Yeah, I get that. Control is good. Hell, yeah, it is.
Dave: I love the idea of it like HTML in, HTML out, basically. Right?
Zach: Yeah.
Dave: HTML, you write a style tag, and then that can get munged up. But it's basically HTML in, HTML out.
What about scripts inside my WebC file? I can do scripts inside of there? Then how does that--?
If I have a set time out, the countdown, counting down to the big release, how does that work? What happens to that script block?
Zach: Yeah, so just like I mentioned before, I tried really hard to stay to normal HTML conventions. So, if you put a template tag in your WebC file, it will be treated as a normal template. You have to add these extra attributes and opt into these extra things to make it operate in WebC stuff.
It's the same with script and style. If you add a script element inside of your WebC component, that will be treated just as a client-side script and that will run on the client.
Chris: It's not touched in any way. Yeah, I was going to ask about that too. Very interesting.
Zach: I mean it's bundled in the same way that a style is, so when you compile a page of WebC components, we have a bundler mode. That is if you're using it in 11ty, that bundler mode is enabled by default. So, it will take all of the styles inside of all of those components, aggregate them together, and then you get to put them in a critical CSS bundle at the top of your page.
Chris: Oh, fancy! So, it does... That's optional, though?
Zach: No, that's on by default in the 11ty plugin.
Chris: So, it moves. It moves stuff. You'd have to be kind of aware of that, like if you had a script block that was somewhere special in the DOM and you put it somewhere special because it would say "after an HTML element" and it has to be after it because it's about to query selector for it or something. But I assume what you do with the scripts is when you move it, you move it lower, not higher.
Zach: You get full control over where it goes.
Chris: Oh, you do? Okay.
Zach: And you get to decide what bucket. We call them buckets. You get to decide what bucket it goes into, so you can even specify inside (at the component level). I want a defer bucket that goes later, or I want a critical CSS bucket that I inline at the top of my page.
You do really get full control over where that stuff ends up.
Chris: That's neat, so you're inline scripts aren't necessarily... You might just write it that way knowing that I'd never write it this way on purpose, but I know that this framework has got my back and it's going to bundle it appropriately elsewhere. I'm just using this as a developer convenience.
Zach: Yeah, and I really feel like that's important because there's an interesting sort of drawback to the declarative Shadow DOM in that a lot of that stuff gets duplicated the more you have component instances on your page. And so, the bundling aspect, I think, is important because it prevents that duplication because we deduplicate all the scripts and styles before we output them in your bundle.
Dave: Yeah. I was going to say, what if I put five countdown timers? Do I have five countdown blocks in my script tag or just one?
Zach: Yeah, so when we bundle the JavaScript together, it's all deduplicated based on the content. You only get one script block in the output no matter if you have one or 100 countdown elements.
Dave: Smart.
Chris: The HTML would be duplicated but not the script.
Dave: Right. Exactly. The same with styles. Yeah.
Dave: Yeah.
Chris: Yeah, that's cool.
Dave: I tried to chime in on the declarative Shadow DOM issue a long time ago, and it was like, "Hey, what do we think of this?" I was like, "That's a lot of repeating templates."
Zach: Mm-hmm.
Dave: Ideally, I could just not send book, the book template that's going to get thrown away 100 times or, in my case, 200 times, and the comment was, "Well, no one is hand-authoring this."
I was like, "Hmm... I’m sorry. I'm that asshole. I will be at some point."
[Laughter]
Dave: But yeah, anyway, I feel like there's a chance where that gets better but maybe five years from now.
Zach: Yeah. I feel like the pain is going to be obvious when declarative Shadow DOM has a cross-browser story and folks start complaining about that. Yeah, I think that will get better with time, but it'll probably take a while.
Chris: Aren't script styles? If you put a script style in a classic Web-native Web component, it's also kind of like weirdly scoped, isn't it? You can't query selector outside of itself or anything.
Zach: Yeah, if it's in Shadow DOM, yeah.
Chris: Some people maybe would like that, and there's no Shadow DOM involved here, right? In WebC, there's no Shadow DOM.
Zach: Yeah. Yeah. We're sort of precompiling Shadow DOM-esque things because we do... You can still use--
Chris: So, you don't get that same JavaScript protection that I don't like anyway. [Laughter]
Dave: Here's marketing for you, Zach. I give it free - free. Shadowless. Shadowless.
Zach: I love it.
Dave: Chris Enns, put some echo on this. Shadowless. Yeah, there you go. That's what we want. Yeah.
Zach: I mean I did have an idea to rebrand this and my idea was Foreshadowing.
Dave: Whoa! Good. Good. Good.
Zach: But yeah, I don't know. [Laughter] I didn't end up using it.
Dave: That's good.
Chris: Oh, that is good. Okay, so that's WebP. WebP... Oh, gees.
Zach: Yeah, so that's exactly where the name came from. I tried to steal from WebP.
Chris: Is it? [Laughter]
Zach: Glad that you confused those.
Chris: WebP is now WebC.
Zach: [Laughter]
Dave: You're like, "What other...?"
Chris: Holy cow.
Dave: [Laughter] What other technologies do people love? WebP.
[Laughter]
Zach: I mean WebP has a pretty good success story, I would say.
Chris: Yeah.
Dave: I would say.
Chris: I'd say it's more successful than AVIF, I think, so far. Yeah, kind of. I feel like this came out (in the grand scheme of things) close to that enhance.dev, too, which is very much not the same but also the same. You know? It still has, you know, you can put your components in a components folder kind of thing. But I think it leans more into the--
Zach: Yeah, they released about two weeks before mine came out. [Laughter]
Chris: Oh, no!
Dave: Ah, yeah.
Zach: No, it was great. I love what they're doing over there, and they have an 11ty plugin, too. Shout out to them.
Dave: I did like how they were kind of like, "We don't actually care who builds your site." They were kind of agnostic to that part, like, "We're just handling the sort of--"
Chris: That's surprising to me because of their... They want you to use a specific folder structure for their project. Then what? You wrap another folder structure around that?
Dave: Yeah, they were just kind of like, "We build out the app, and then how you get that app out is kind of up to you." It was kind of an interesting approach.
Chris: Well, okay, let's say then you invented this technology and you wanted to share it with the world. You might have to use some kind of social media product in order to do that.
Zach: [Laughter]
Chris: You record a video, maybe. Chuck 'er on YouTube. What do you do? Do a toot? Do you toots?
Zach: Yeah, I love doing toots.
Chris: [Laughter]
Zach: I'll leave that there for the sound clipping that folks need for that.
[Laughter]
Zach: Yep.
Chris: Yeah, it was just a way to talk about that because you have a big presence on Twitter, I'd say.
Zach: Reply guy.
Chris: [Laughter]
Zach: I think that's fair to say.
Chris: Not necessarily that.
Zach: I mean, not - yeah. Hopefully, not negatively. But yeah, I do a ton of conversation on Twitter. It's my favorite thing.
Chris: Right, and it's just been weird times on Twitter lately, so I thought that was kind of unavoidable to talk about. It certainly affects you as an open-source maintainer who wants to tell people about their product. It has both social and probably business implications for you. What the heck do you do now, man?
Zach: Yeah, it's funny because I was in San Francisco this week. I never travel or really go to conferences much at all. But I walked to the venue, and I walked right by Twitter headquarters.
Yeah, it's hard, man. I really feel like I've sunk a bunch of time and energy into building a presence on this site, and it does feel like I've lost a home (in a way) because I am perpetually and habitually and terribly online. I'm extremely online because I live in Iowa.
Chris: [Laughter]
Dave: Well, yeah. Like I was going to say, in some ways that's enabled you to live your quality of life in Iowa.
Zach: Yeah.
Dave: You have a farm in your backyard. It's awesome. But you didn't have to be, like, ten years ago, you might have had to be like, whatever, a city person, like ultra city. You're close to Omaha and Council Bluffs.
Zach: Yeah.
Dave: Yeah, anyway, it's cool that we can all participate and be friends over the Internet. Then all of a sudden, [laughter] it's like-- I've described it as like a slow-moving asteroid coming to Earth.
Zach: Mm-hmm.
Dave: We're all like, "Ah, man! Guess it's different now." You know?
Zach: Yeah. Yeah, it's disheartening in a way, but I do kind of feel like folks that have been around as long as I have (and probably you all have) were around before Twitter, and we sort of remember what that was like too. I remember the days of Google Reader and everyone writing stuff on their blogs, and how awesome that was to be able to drive a ton of traffic to your website just by posting something on your blog without having to go through the intermediate step of publishing it to all of these different social media platforms.
Yeah, I think that that was amazing and we'll probably weather past this current storm to what's next. I've been having a lot of fun on Mastodon.
Chris: Yeah. Let's get to that in a minute, but it's possible. I mean I'm sure the vast majority of people listening to this show are of the similar opinion. I think it'd be hard to have an opinion at the moment that says things are going great at Twitter.
Zach: [Laughter]
Chris: That would be weird. But if you're like a super Elon fanboy, possibly. I mean I'm guilty of fanboyism. Not necessarily for Elon, but been an Apple apologist in the past, so I kind of get how that might feel.
We're almost talking as if Twitter is shutting down next week, but it probably isn't. Right?
Zach: Oh, for sure.
Chris: Is there a world in which we just kind of stay there and it's fine, or are we leaving out of more of a moral situation where they've treated literal human beings really poorly?
Zach: Yeah. I feel like it's going to be different for everybody. I've already seen a lot of very close friends sort of ditch the platform altogether. And I feel like that has been healthy. But that's not going to be viable for everybody. Everybody, their own moral values that they have are going to weigh differently based on maybe the monetary implications they have with leaving the platform.
Yeah, I don't think I'll judge anyone for staying around on Twitter. I hope that they don't feel judged in that way. But there are alternatives. Yeah, I think that I'll probably end up spending less day-to-day time and less reply-guying on Twitter. Yeah.
Chris: Well, because you've taken the time here to do the Mastodon thing -- Dave, you have too -- I'm only a couple of days into it, but if you're optimistic, that encourages me because I'm feeling pretty optimistic, too, that it's actually kind of fun. I do worry a little bit that now I have that and Twitter.
Dave: Yeah. Yeah. Now I have two addictions. Guys, this is great.
Chris: Now I have both. Yeah.
[Laughter]
Dave: I quit my diet Coke habit, but now I'm drinking regular Coke and Pepsi, so it's beautiful.
[Laughter]
Zach: Yeah, it's definitely not sustainable to have two, and that's kind of why I think that I'll just not open Twitter during the day, or at least try to not open Twitter.
Chris: Mm-hmm.
Zach: I might still syndicate things that I'm working on to there, but I don't think I'm going to have a ton of conversations over there.
Dave: My rule of thumb is log out at first sign of BS. [Laughter] If you find yourself logging back into Twitter for some reason, the first whiff of it.
It could be political. It can be from your opponent's party. It could be from your own party. It could be from owners of Twitter. It could be from anyone. Just log out. The first--
Chris: [Laughter]
Dave: The one weirdo who replies to you--
Chris: The first sniff?
Dave: Log out. Just say, "Nah, dude. I am not talking about that."
Zach: Surely, that can't be true, Dave. I've seen you on Twitter way too much for that to happen.
Dave: Oh, I am on Twitter way too much.
Zach: You aren't getting those every day? There's BS every day. [Laughter]
Dave: No, that's my new -- when you want to switch, just log out at first sign. Just say, "Later." Yeah.
Chris: I don't think it's... The bigger Mastodon gets... There's nothing preventing somebody from replying to a Mastodon toot. I mean you can mute them or whatever. That's fine. And other people can cancel them, but you can mute them on Twitter, too.
I don't know. I don't think it's necessarily perfect over on Mastodon or anything.
Dave: Yeah. It's not... Like the technology swap isn't the issue for me. It's the network effect. It's being one...
I think I said it recently, but it's the one step away from telling Ted Cruz he's a piece of shit. That's what keeps me on Twitter, baby. That is what gets me there.
Chris: Oh, and you. Yeah, you'll never be able to do that on Mastodon.
Zach: Yeah.
Dave: I think, too, what is interesting about Mastodon -- and for the people who are on it previously -- I mean it was a ghost town. It's a really dopamine-less ghost town. It's tumbleweeds tumbling in the sun.
Chris: I don't know. It's been pretty poppin' the last couple of days.
Dave: Now. But the vibe is very different now, and so I wonder if everyone is going to be used to that. But my thing is it's kind of like that old bar analogy. It's like if all my friends are going to go to another bar, I'll just follow them over. Let's go and hang out.
Zach: I think folks are sort of waiting for that last straw to break the camel's back. I still don't really understand what that is, but they were waiting for that last thing to happen, and I feel like that has. The camel's back has been broken at this point.
Dave: Does that affect you as an open-source maintainer? Let's pull it back to talk. You know. I mean do you...?
A lot of your marketing, a lot of your broadcasting is kind of through that one platform, let's say. Does that change it? Does that change the dynamic?
Zach: Yeah, I mean when Google Reader died back in the day, I should have learned the lesson better that I need to be present on a bunch of different things. It's hard to participate on a bunch of different things, especially at the level that I did on Twitter. I've definitely over-indexed on Twitter for many years, and I think it's kind of special that it lasted as long as it did. Not to say that it's gone now, but yeah. I think it's very special that it lasted as long as it did and definitely feeling the reverberations of that as I'm trying to participate on more things now.
Chris: Yep. You've got the YouTube too. There's been some split of social network stuff already, right? But you don't really... I mean, if you don't talk to people... If you don't have a conversation/argument on Twitter, you're definitely not going to do it on YouTube.
Dave: But you have the Discord, right? An 11ty Discord for support and stuff like that, so maybe you've already sort of set stuff up, in a way.
Zach: Yeah. I do have a Discord, and we have some great Discord moderators. But I am decidedly not a Discord person. There's something about private communication that I wish it was just more public. I really feel like it's more welcoming to have open communities that are completely public and all the content is public.
Chris: Interesting! That's your thing with Discord? Oh, man. I wonder if that's it for me too.
Dave: Like a URL for an answer is so powerful. I think it gets... I think we get hyped up on, "Ah, man. I'm live chatting. Getting my problems solved." It is awesome, but there is something to be like, "The URL for this answer is," stackoverflow.com. But I think that's somewhat powerful.
Zach: Yeah, and that's why I don't do support over Twitter DMs. [Laughter]
Dave: Right.
Zach: It's just not maintainable.
Dave: No one benefits except for one person.
Zach: Right. Yeah.
Dave: Yeah.
Zach: Yeah.
Chris: I love our Discord, but there's this... Maybe I'm just poisoned from Twitter for too long that sometimes I'm like, "I have a few minutes to kind of relax and hang with my online homies. I want to post something."
My brain is so used to, like, "Maybe I'll post this link that I've been reading that I'm interested in and have thoughts on." For some reason, I need to switch my brain so that it's okay to do that in a Discord-like context. It usually doesn't feel right to me, like, "I'm just going to post, in general, this link with my thoughts on it." For some reason, it just doesn't feel perfectly right. Sometimes I just do it and it's fine. But it makes more sense as a tweet or a toot, which I can't say toot anymore. That's the last time, everybody. I'll never say toot again.
Zach: [Laughter]
Chris: I can't. I hate it when words are that stupid. They need to change that.
Zach: You need a fart soundboard?
Dave: Yeah.
[Laughter]
Zach: Just play that instead.
Dave: Yeah.
Chris: I get the history is kind of fun and everything. I like a little levity in the world. But I'm like, "This is a pretty serious tech thing right now, so let's just call them posts - or something. Please."
Dave: Yeah.
Zach: Yeah. I'm down for that.
Chris: Yeah.
Dave: We need a cloud toot butt extension, or whatever. The reverse of that, right?
[Laughter]
Chris: You know what I'm actually excited about, though? Because it's so open-source and it has all these APIs, you're like, "Which iPhone thing should I have?" I happen to have an iPhone, right? Which Mastodon client should I put on there?
There are like 15 of them, and that's cool. That's good. That's encouraged and wanted by that community, I think.
There's also alternate Web clients. I think I picked one called Pinafore, or something.
Dave: Yeah. Nolan Lawson.
Chris: It's smokin' fast.
Zach: Yeah. That's Nolan. Yeah.
Dave: Nolan Lawson.
Chris: Oh, that's Nolan's?
Dave: Yeah.
Chris: What?!
Zach: Yeah.
Chris: Oh, I already like Nolan. That's even better. It's smokin' fast. I fricken' love it.
Zach: Nolan was ahead of the game in getting off of Twitter, too.
Chris: Yeah. But this is just the beginning because, as much as I think Pinafore is really fast, it's also pretty boring looking, but it doesn't have to be. Let's say Nolan -- some amazing designer hooked up on Pinafore and made it beautiful to use. At the moment, you go to Twitter, and you're like, "I know this is my weird, addicted home," kind of thing, but it was very well designed - in my opinion.
Dave: Yeah. Yeah. Yeah.
Chris: I actually really love the custom Twitter font. I thought it was just a perfect - I don't know - choice of typography they did and stuff. Now you're looking at Arial or whatever on a lot of these, and you're like, "Hmm..."
Dave: I think there's a lot of good work that went into making Twitter what it is, and I think that's why we like it. But there were also poisonous things like trending topics and stuff like that that just suck your attention for no reason.
Zach: Quote tweets.
Dave: Quote tweets, yeah. Kind of abuse vectors and stuff that Mastodon is at least trying to discourage.
Chris: Yeah.
Dave: Yeah.
Zach: Yeah. I really do feel like the federated instance thing where anybody can run their own Mastodon instance is incredible because I pay $6 a month for someone to host a Mastodon instance for me, and now I have all of my Mastodon content on URLs that I control. I think that's incredible.
If Mastodon goes away, I'll still have full control over the URLs, and I could redirect them to my own archive if I wanted to. I mean that sort of ejection mechanism I feel like is hugely valuable, and they've already planned for that upfront.
Chris: Yeah. What you wouldn't get there then is that local tab that other instances have for, like, "This instance has 82 people and, if you want it to be, you can only browse those 82 people." That's a little bit neat. A little micro thing. Whereas if you're totally alone on your instance, you wouldn't have that.
You could still follow those same 82 people if you wanted to. It'd just be a little more legwork, right?
Zach: Yeah, but that's how Twitter works today. My home feed or least the latest tweets feed on Twitter, not the algorithmic timeline or whatever.
That's how Twitter works today. I see content from the people I follow. I know that's probably changing with the new $8 verified thing, but yeah.
I saw they added a new verified notifications tab this morning. I'm like, "What is going on over there?"
Dave: It's tough.
Chris: Us blue checks have had that for a while.
Zach: Oh, really? Okay. I didn't know that. [Laughter]
Chris: If you're a blue check, you can view a tab that only shows you other blue checks' responses, which has never once been useful to me. It feels very silly (in a way).
Dave: I'm trying to think of Web people with blue checks. It's like you, Anil Dash. [Laughter]
Zach: Sara Soueidan has one.
Chris: Sarah Drasner.
Dave: Sarah Drasner, Sara Soueidan. Okay.
Chris: Yeah.
Dave: Well, that's good.
Chris: Scott Kellum has one for whatever reason. It's whatever - fine. But it's very interesting now that...
Whey would they conflate the two things to begin with? I don't understand. Why don't you just leave the blue checks the way they are? Not that I care.
You can take mine away right now. I could give a crap less about the blue check. But it was supposed to mean something. It was supposed to have verified it's you.
I remember when I got it, which was ages ago. You had to submit all kinds of stuff. Your fricken' birth certificate and all kinds of stuff to really prove that you're you - or whatever. And I did that even though it's questionable, right? Do I actually deserve my little checkmark? I don't know. That's for you to decide. That's what it meant then is that I'm really me. [Laughter]
Then to just not invent a new mechanism for this $8 a month thing but to just make it be the exact same blue checkmark and then walk it back two seconds later and be like, "Oh, there's a new little gray badge that actually means official." And then walk that back, and you're like, "What is going on?!"
Dave: [Laughter]
Zach: I mean my theory is that when you fire a ton of people, you're not going to have very much honesty in the conversations you have after that. Yeah, it's hard tell your boss no right after they fired hundreds and hundreds of people.
Dave: People are just put in a position until they find something else to just say yes to whatever dumb idea is currently active.
Chris: I saw this. I remember I worked at like a Dairy Queen kind of thing, a local version of a Dairy Queen when I was in college. They fired my buddy for something I thought was dumb. He was an honest, normal guy. He wasn't fricken' stealing ice cream or whatever. I don't know why they fired him.
I just go, "F-you. I'm out too." I walked out with him. Just like, "I don't need this ice cream job."
You've got to imagine that's going to happen a lot too, and I've been reading that... Like, you could almost assume an additional 50% arbitrage kind of thing.
Yeah, you fire 50%. You fire 75% because there's going to be a lot of people that are just like, "Whatever. Bye."
Zach: Yeah, and the new remote work change.
Chris: Mm-hmm.
Dave: Yeah. Remote work change. People like stability. This idea it can just change, that's bad.
Chris: Oh, this stuff is just too juicy. Sorry. We had to go there. It's just too fun to talk about.
Dave: We don't have time, but I wanted to talk about is-land. That's another Zach Leatherman joint.
Chris: [Laughter]
Dave: It is a--
Chris: A ZLP.
[Laughter]
Dave: Zach Leatherman...
Zach: Not to be confused with NFT. Much different.
Chris: [Laughter]
Dave: Yeah, so is-land helps your NFTs.
[Laughter]
Dave: This is good.
Zach: Incorrect. I'm going to have to... Yeah.
Dave: This is what I coined criminal... Scott Jehl. [Laughter]
Zach: I don't remember this.
Dave: That's a live show oopsie. Anyway...
Zach: Okay. [Laughter]
Dave: Yeah, so it kind of takes this island architecture and it's a Web component. Then you're kind of like saying... Web component in the traditional Web component sense. And you kind of say, "Load this whenever. Load this stuff inside here whenever this is true," like is visible, is whatever. Right?
Zach: Yeah. You can set loading conditions for your components. I do have examples of a bunch of different server-rendered framework components for is-land as well: Vue, Lit, Alpine. Yeah, a bunch of different ones.
I mean, in purist terms, it really is kind of a lazy loader, but a declarative lazy loader, so you can say anything inside of this HTML element, which is the is-land component element. It's loaded when certain conditions are met, and you have to declare what those conditions are.
Yeah, you can say, "I want it to load when the saved data preference is off," or "I want it to load when the user starts to interact with it."
Again, you get full control over the progressive enhancement and that lifecycle. Yeah, I think it works really good.
I've actually started to see some other frameworks experiment with using it as well because it's an independent of 11ty thing. Yeah, I've seen some really cool experiments come out of the Svelte community, SvelteKit using is-land for partial hydration. Yeah, it's been awesome.
Dave: No, it's cool. We talked at the beginning of the show. Netlify is now paying you to work on 11ty full time. This and WebC are kind of just some the byproducts of what happens when a maintainer goes full-time on their project.
We start getting this cool stuff that benefits 11ty directly but also just benefits anything, kind of. Right? You've made it portable enough. It's not super tied.
Zach: Yeah. Yeah. I'm really trying to make things that are not just useful in the 11ty community but decoupled from 11ty or zero-dependency things that other frameworks can use if they want. Yeah, I'm trying to demonstrate my value in that way. [Laughter] Larger than the 11ty community.
Dave: Yeah. That's great. Very cool. Well, anyway, I just like islands. I just was like, "Ooh, this is cool that it just is here. It's here."
Chris: It almost gives a little bit more meaning to the word "island" before. You know? I kind of conceptually understood what was meant by island architecture, like, "This little piece is just HTML, but this little piece has JavaScript associated to it."
You're like, "Yes, that conceptually makes sense," but that's also how my WordPress website works. So, hmm... Why does this need a fancy word?
But now it kind of does need a fancy word if it's talking about - I don't know - when a piece of interactive HTML gets loaded, when and how and all that.
Zach: Yeah, and I think a lot of that baggage comes from sort of sideroads that single-page applications took us down originally. Their architecture is all in -- you're either bought into it or you're not bought into it, like a big ol' bundle.
Yeah, I feel like we're going back to things that existed before the single-page application architecture really sort of took hold of the mindshare of so many different things. I think it's great.
Chris: Fantastic. We're at the end. It's just so fascinating. It's so cool that you get to work at Netlify, get to make this thing happen for yourself and all that. I am so curious if, like, a framework influences a host and back and forth. I know we don't have too much time to get into all that, but is that a juicy place to be because of that? Can you be like, "Hey, you know what would be amazing is if this... If where this thing... I know where the server infrastructure, where this is going. What can I do with that?"
Zach: Yeah, I mean it's hard to know what influence you have. But I've definitely had discussions with folks at Netlify and previews of things that are coming later. I definitely get to say, "Hey, why doesn't it do this?" or "Why does it do it this way?"
Yeah, I think those conversations happen two ways, too. I get a bunch of benefit out of that in terms of how I think 11ty should work. I think maybe the earliest iteration of that was when Netlify launched their on-demand builders, which is like a serverless with an extra level of cache. You can sort of generate pages on the first request and then repeat requests to that are just served as a static cache, and 11ty really benefited from that and seeing that beforehand.
We had first-parties like ODB support on day one of Netlify's launch of that feature. The same with the edge functions thing, too. Yeah, I'm getting a ton of benefit out of that. And I would assume they are too. [Laughter]
Chris: That's really such a cool architecture. I'd almost like to see more. There almost should be a Netlify-specific framework or something that leans into it super-heavily.
I mean 11ty is probably the closest thing to it, but it's like that's such a cool feature that isn't 11ty specific that would just be... It's just such an interesting architecture.
Dave: I've tried to explain on-demand builders, and people think I'm lying because I'm like, "Okay. It's a serverless function, but it's cached forever and it just exists. It's like you did it client-side - or whatever. Prebuild."
People are just like, "Nah, dude. That doesn't... No. You can't just cache an image or whatever."
I'm just like, "No, dude. It really works." Anyway...
Chris: [Laughter]
Dave: I feel dumb, but it's great.
Chris: No, but you can.
Dave: It's awesome. Yeah.
Zach: Yeah, and I mean just going back to your earlier point of a Netlify framework, I don't think that will ever happen. I think that Netlify really wants to... Like I said earlier--
Chris: They don't want that to happen, right?
Zach: Yeah, we want a plurality of successful frameworks. We don't want to crown a winner because there will be no way that we can keep up with the framework churn that exists.
Chris: No. Right. It wouldn't come from you. But I could see somebody being like, "They're the only company that offers this, exactly this API for exactly this feature, so I'm going to build one." That could happen, theoretically. But I'm not saying it will, but it could.
All right. Thanks, Zach.
Dave: Yeah. Thanks, Zach. For people who aren't following you and giving you money, how can they do that?
Zach: 11ty.dev is the framework. Yep, I'm @zachleat on Twitter. Uh-oh. Then [email protected] on Mastodon. [Laughter] But really, my website is zachleat.com, so just go to that.
Dave: Perfect. Awesome. Well, thank you. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show.
Follow us on Twitter for -- no, wait. Maybe don't. I don't know. Yikes! What a weird time.
Then join us in the D-d-d-d-discord, patreon.com/shoptalkshow.
Chris, do you got anything else you'd like to say?
Chris: [Laughter] No, I don't. Bye.
Dave: Bye.