Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave Rupert. With me is Chris Coyier. Hey, Chris. How are you?

Chris Coyier: Oh, I'm doing just fine here in Bend. I go to Reighley next week for All Things Open. It should be kind of neat.

Dave: Ooh... Nice.

Chris: It should be my last conference of the year, theoretically. It's nice to be invited to stuff. It was nice to get a couple of yes's in this year.

I fly from Seattle to Reighley. It's going to be a long one.

Dave: Okay.

Chris: I've got to charge my iPad.

Dave: That is a long one.

Chris: It's all the way across. Yeah. Going to be big.

Dave: I'll be heading up to Seattle for a work trip over to the mothership, so that should be fun.

Chris: Yeah?

Dave: Pretty soon, so get to meet my coworkers IRL. That'll be fun.

Chris: What days are you there?

Dave: Um... Well, that's private. No. [Laughter]

Chris: [Laughter] Oh, I'm just kidding. Yeah, yeah, yeah.

Dave: Yeah. Second week of November-ish.

Chris: Yeah, okay.

Dave: So, I'm just--/p>

Chris: I just thought of it because I'm like, "Oh, man. I'm going up, too, for a Seahawks game." For me it's a little hop, skip, and a jump, you know.

Dave: Oh, yeah. Okay, well, maybe we're in there at the same time. We'll coordinate.

Chris: Yeah, maybe.

Dave: Yeah.

00:01:29

Chris: All right. Life stuff. You've been blogging lately a little bit, I know.

Dave: Barely, but yeah. I've fallen off since my new employment.

Chris: I don't think so. I think you're doing great.

Dave: Okay. Well--

Chris: We both had a little parable posts and stuff, too. But for the context of this show, I think that your one, "Where Web components shine," is excellent. My only qualm is I wish it came out right during all that Web component drama off the other week.

Dave: Oh... buddy. I had it. I've had this for months. [Laughter] Then all that went up in flames, and I just was like, "I'm not going to post this yet. I'm going to let that go."

Chris: Oh, you almost... You on purpose didn't post it because you didn't want to be part of all that?

Dave: Yeah.

Chris: Yeah. Fair enough.

Dave: I don't want to... I didn't want it to be like this reaction to somebody said something so now I've got to defend Web components. Some people did that, and that was cool that they did that.

Chris: Oh, I see.

Dave: But I don't need to do that. I just think... I read a lot of blog posts about Web components, and I hear people go, "They're good at this, and they're not good at that." I'm like, "But are they? I don't know. They seem like they're okay at that."

Chris: Hmm...

Dave: Or "Web components are good for this," and so I just wrote down a list, literally just a list, of here are places I think they're good.

Chris: Yep, and a little bit of things they're not good just because that was you avoiding the drama again, right? To not just be a total cheerleader all the time.

Dave: Well, I think we need to also inject that into our discourse, like, you can say Solid is great. You can say Svelte 5 is great. But can you say one bad thing about it? You should be able to say bad things about things you like. You know what I mean? And use.

Chris: Yeah. I mean whatever. it has a compiler. It's written in Node, so there's 100% chance that if you leave it alone for a year and come back to it on your computer that it won't compile.

Dave: For sure.

Chris: Quote me on it. It won't. Something will change and it won't. That's okay. It's fixable. That's the job. You can get it to work. But that kind of thing is the case.

Dave: The migration from version 4 to 5 is going to bite your butt. On an application of significant size, it's going to take weeks or months or whatever.

I think there are questions like that. People need to kind of really... I don't know. Let's add a little bit of honesty into our propaganda is kind of what I was hoping to do.

00:03:55

Chris: Mm-hmm. You know the number one that gets me is that there are a lot of people that are building sites with JavaScript frameworks that are building one website basically for desktop.

Dave: Yeah.

Chris: There's just a lot of jobs in that still because a lot of business and money and stuff happens on building one website with the JavaScript framework.

Dave: Yeah.

Chris: I do it for a living.

Dave: Okay. Yeah.

Chris: And so, let's say I picked React, Svelte, Vue, or whatever, and I'm building some website in that, and I'm coming at all of this from that perspective. You're in this bucket where they're not that useful to you. They meaning Web components. You already have a component model and you're only building one website.

To have a framework author or whatever, people that are thinking in that category, which is an awful lot of you out there, that to be like, "These things are dumb. These things aren't giving me what I'm getting anyway from these component models." You're right! They're not!

Dave: Yeah. I'd agree. I think they probably give you a 5% or 10% gain in performance if it works in your framework. So, I don't think you need to necessarily rearchitect. But if you're at a point where you're like, "Dude, we are getting bit all the time. Should we jump?" I think now is the time to evaluate our Web components, a potential option in our sphere of choices. Not just upgrade.

Chris: Right.

Dave: Is upgrade the only path or is Juke the other path? If you have a rewrite on the table. And I don't propose rewrites lightly. Don't do a rewrite if you don't have to, man.

Chris: Right.

Dave: It's painful. It takes a long time. Everyone gets mad.

Chris: Do it if there's some bigtime value about to come.

Dave: If you can articulate the value, do it.

00:05:52

Chris: I mentioned bad places like you're building one website and you already have a JavaScript framework. Let's get into the things that are good, though. The obvious one being that if you have multiple websites, particularly if they're different frameworks, then these Web components can be the glue between them. But I don't want to steal the thunder of this blog post because there are a lot of bullet points under the good parts in your blog post. So, maybe we'll just read some of them. Maybe we'll go back and forth.

The first one being for leaf nodes. If that word soars over your head, I don't blame you. But only because - whatever - it doesn't enter my daily vernacular. But picture a tree. Leaves are the very farthest thing out of the tree, right? And the tree is your website.

There are no children of leaves. Leaves are all the way out to the end. Meaning they're something like the famous button component. There's probably not a lot of children of a button component. So, Web components shine in that particular arena.

Dave: Yeah. Another one might be a map, right? You're not futzing with the innards of Google Maps. That's the leaf. That's the final destination--

Chris: Okay.

Dave: --is just we need to render a map. Maybe we add markers to it. But that would also be in the leaf node category. Just sort of like, if you're old enough, you remember Java applets.

Chris: Mm-hmm.

Dave: Where you'd seen an image and the water would shimmer underneath. Those were awesome. We don't have those anymore.

Chris: Mm-hmm.

Dave: Because that's not secure. But I think these leaf nodes, this idea of these little applets or end... You're at the end of the DOM tree, literally.

Chris: Yeah.

Dave: You could just plop this in and it'll work.

Chris: Plop 'er in'ers.

Dave: Yeah.

00:07:41

Chris: Okay, so Web components are good at leaf nodes. That's a good use case for them. What's your second one here?

Dave: The next one, which was actually I saw somebody say they weren't, and I was like, "No, I think they're good." [Laughter] But I went back and forth. I think it was Rob Knight I was talking to, but for presentational components that wrap other components, like you have, I think, Brad Frost's idea of an organism or a molecule or whatever.

You have a button, an image, and a title, and now you want to make a card. Right? You can make a card component, and it's actually awesome because you can have slots and say, "This is card title. This is--"

Chris: Mm-hmm.

Dave: "This is slot name equals title. This is slot name equals image. Slot name equals actions," or something like that. You could have slots, and so you can actually rearrange those and have them... Just have the content slotted into the component almost like press fitting into a joint, like a joinery in a piece of wood.

Chris: Yeah. Okay. And this is all made possible through the angle bracket slot element.

Dave: Slot element.

Chris: It can take stuff and put it inside of itself. I like thinking about that. That's pretty neat to think about. Of course, JavaScript frameworks can do this, too. But it's doing this at the kind of raw HTML level, which can be pretty powerful.

Dave: Or you're just like spreading children, you know, kind of, or you have to declare certain children render here, here, or here in the component - or something like that. I think the slot element is actually pretty awesome. It's a feature of Shadow DOM.

Chris: Yeah.

Dave: But you can literally just use that piece of the Shadow DOM and then apply a little style, add a grid, make them lay out right. You can do that.

Chris: I see. Arguably more powerful than just a children concept because children just go blap, there they are.

Dave: Yeah.

Chris: But if you want to sprinkle something out into a template in JavaScript, typically then now you're like, "Okay, well, I can't just do children because it's not powerful enough. I need to pass all these individual parts in as data, props, or whatever you want to call it."

Dave: Yeah.

Chris: Then construct it. Whereas slot is just a different mental model for the same kind of thing. They can be named slots and it helps you sprinkle stuff out in there without having to pass them as props.

Dave: Yeah.

Chris: It's just part of the HTML attribute structure.

Dave: Yeah. It's really efficient. But I also want to say you don't need... You can just staple two Web components together with a div class grid. You don't need Web components all the time. I think that's the first rule of Web components is not everything needs to be a Web component, which is different than maybe these JavaScript frameworks where everything kind of has to fit into that component model.

00:10:31

Chris: All right. Another thing that they are good at is building a design system. I couldn't agree with you more on this one. I think that is a perfect choice for that sort of thing. Almost like if that's the deliverable, if that's the final product is a design system, you can make no better choice (if you ask me) than that.

Dave: I hear people do different... They're like, "They aren't good for it," but there are design systems out there: Spectrum, Nord, Lightning Web components. There are a lot of design systems that are design systems, and they work. They're fine. They use Shadow DOM. There are things out there that do it.

I think it's going to look and feel a little different than maybe the React version. But I think you have to also kind of understand why.

Chris: I do also think about the distribute ability. And I think that's a future point that you're going to get to.

Dave: Yeah.

Chris: But if you're building a design system to be spread to the world that you don't even know who the consumer of it is, then it's even stronger of a choice. Now if you're building one internally for one consumer (just yourself) and the reason that you're doing it is because - I don't know - you're a big company and it seemed right to structure your company to have a design system team - or whatever - but you have a lot of control. It's inward facing only. You know exactly who your consumers are. It's still a good choice, but it has a little bit of a different thing there.

But they're like - I don't know - "Anybody can use this!" That is Web components territory for sure. We're saying this as React 19 is starting to drop, which is for once that's the release that makes this all work nicely. I think it's just an RC right now. But you know it has been a long holdout for it not working particularly well. We are getting it done in React 18 at CodePen okay.

Dave: With some wrappers or something.

Chris: Yeah. I can't even remember what the problems were at the time, but they really weren't that bad. But I think, in 19, it's kind of like, "Just don't think about it," territory, which is how it works in all the other frameworks.

Dave: Well, yeah.

Chris: But they just work.

Dave: Yeah. I mean I think that the stink-up from a couple of weeks ago was kind of just like it's a lot of effort to make it seem like "it just works." And I'm sympathetic to that. I think it would be cool to find out why.

Chris: Yeah. it wasn't that they don't work. It's just that it's effort on the framework producers. It's like, where is the line then? Am I expected to snap my fingers and have a framework? No. It's work. That's the point.

Dave: Yeah.

Chris: Yeah.

Dave: I don't know. It's like if your customers ask for it, you kind of have to. You know? You're trying to make the customers happy, right? But I'm sympathetic that it takes effort, and it's not always a linear path.

Chris: You could write, if you wanted to, because this is a god-dang free world mostly.

Dave: [Laughter]

Chris: You could make a Web component hostile framework. You could have--

[Laughter]

Chris: You could write a framework that if there's a dash in a dang element that it just display none it.

Dave: Deletes.

Chris: Or it just compiles it.

Dave: No dot remove. Yeah.

Chris: Just deletes it.

Dave: Yeah. I mean you can do that.

Chris: [Laughter] That's up to you.

Dave: I'm not your dad.

Chris: Maybe people will.

Dave: Yeah, go for it.

Chris: Yeah.

Dave: [Laughter] Yeah. I think that's a big part of it. You can build a design system. It's a collection of leaf nodes, if you want to think about it like that. And they all come together nicely.

Chris: Hmm...

00:14:07

Dave: The next thing on my list was for progressively enhancing regular HTML, like Eric Meyer.

Chris: You have some perfectly valid HTML. Then as an enhancement, you wrap an angle bracket thing around them. And if that thing did absolutely nothing, so be it. Right?

Dave: Yeah.

Chris: But if everything is happy, it's a happy path situation, the JavaScript loads, it does something a little extra bonus-y to that piece of HTML. Like what?

Dave: Well, there are a lot of examples, but Eric Meyer wrote a nice post about it, and I linked it up. But the Zach Leatherman has a lot. Who'd expect progressive enhancement from Zach Leatherman? But the details utils element is a wrapper around a details element, and it has things like keyboard events, like escape to close or animations or only show it... open it automatically at 350 pixels wide - or something like that.

It adds features to the normal details element, which is operable, procedurable, operable, understandable, and robust. And it adds features to that in addition to the native features of it. And so, it's situations like that. You're just adding another layer of functionality to an element.

He could have done it with a script that you say, document query selector all details dot for each L, L dot add functionality - or something. He could have done that. That sucks.

[Laughter]

Dave: Wrap it in a Web component and it all kind of just works.

Chris: Yeah. It's almost like a vibes thing sometimes because you're right. Doesn't that remind you of the jQuery days - or whatever? You're like, "Oh, I want to enhance all my details elements, so I'll write a script that just finds all my details elements and does something to them." Hey, if it doesn't work, it doesn't work. But if it does, it does. The reason you say it sucks is because the vibes have changed.

Dave: Well--

Chris: There's a desire to encapsulate things a little better than that.

Dave: Yeah, it's vibes, but it just feels like manual work. I guess I'm getting into imperative versus declarative sort of territory here. But I got a PR this week, and it had a bunch of document.create-element span, you know, span.class-name=foo.

Chris: Okay.

Dave: I just was like, "What are we--? What's going on?" You can just use a template element in Web components, but it's stuff like that. When you see document-create-element, you use JSX, right?

Chris: Yeah.

Dave: But we have other primitives in Web component land, like HTML tag template literals, which we'll talk about. But it's just this sort of like, you're doing this very manually, and I don't think it needs to be this step-by-step operations. I think you can just say, "This is what I want it to look like. Now let's make it interactive."

Chris: I see. Yeah. When I say vibes, you say programming paradigms.

[Laughter]

Dave: Well, vibes are fine. No, but it's like... And I can't even--

Chris: Well, it depends on how you use it. If the way that you are using this, if we stay on this details example, is that you have a script tag that loads up that and then your usage of it is all you do is put some angle bracket tags around a thing. You're doing no work.

Dave: Yeah. Yeah, and it should all instantiate with the component.

Chris: Right.

Dave: And the minute you delete that off the page, it will say, "Cool. I'm not doing any of that work anymore."

Chris: Yeah, you've made this point before that I really liked is that you don't have to... In those jQuery days. Remember, we would often wrap the jQuery around a DOM ready statement.

Dave: Yeah.

Chris: That was always a little thing that could bite you if you forgot to do that and you didn't load the script at the bottom of the page or something. There was always this order of operations thing that we were like, "Gosh, I hope jQuery is ready by the time I'm querying for those things because maybe it's not." Then the thing that would continue to bite you is that if anything ever got added to the page later, which jQuery did make plenty easily, that you'd always have to be like, "Oh, yeah. I've got to circle back."

Dave: Yeah.

Chris: And find those elements again. Then paradigms, they kept rolling. It was like, "Well, if you bind all those click elements to the body and use event delegation, then you don't have to worry about that." The convolution rolled on. There's something nice about a Web component that as it drops into the DOM, this natural lifecycle of events just happen. If a Web component has this on connected callback... Is that what it's called? I forget.

Dave: Yeah. Yeah.

Chris: If there are things that need to have click handlers attached to it, you do it in there, which everybody does because that's how they're built. Nobody disagrees about that. But as soon as that Web component is dropped onto the page, it's ready to go.

Dave: Mm-hmm.

Chris: That it handles all that stuff for you. To me, that's a very great programming paradigm.

Dave: Yeah. As soon as the element, I guess, is more to say is defined, you can have the inert Web component, this no script version. Then the script runs and connects it. Now it's a live function in Web component. Then you can add the extra Shadow DOM, the extra everything, buttons, everything you need after that point.

00:19:57

Chris: Mm-hmm. Fantastic. What did we do? We just did progressive enhancing regular ... HTML. [Laughter]

Dave: Yeah.

Chris: Which for a moment everybody was calling HTML Web components. I don't know if that will continue to stick or not. It stuck in my brain, but I don't know if that will be a widely used thing or not.

Dave: I call them Light DOM components sometimes. There's this flavor where it's like you're doing mostly HTML. If you think of my-input, do you put a label and input in there so it works on browsers without JavaScript? Totally could. Or do you just have it say my-input attribute, label attribute equals foo, and then nothing inside of there? You could still render a label and an element. You could also do that.

Chris: Yeah.

Dave: And so, it's sort of up to you. There are options.

Chris: Mm-hmm.

Dave: There's probably a better choice from an access for all standpoint. But I think there's also a better choice from, is everyone going to remember to wire up the labels correctly? [Laughter] You know what I mean?

Chris: Mm-hmm.

Dave: You risk both ways. You can either do it right for somebody or let them hopefully do it right. And so, you're putting a lot of... That probably depends on how big your team is and, again, where your components go because if it's just your team, oh, that's your problem. If it's just your team on one app, that's your problem.

Chris: Mm-hmm.

Dave: Teams on a hundred different apps across an infinite landscape of global geography, yeah, then you may need to do the work for people. That was one.

The next one, when you want a view source, if you just want to view the source of a website or in your dev tools to know what's going on without source maps, my button is a little easier than div SPF50 XYZ PDQ.

Chris: Yeah, particularly these Light DOM ones. Although, you can look at the Shadow DOM, too. Yeah, I tend to agree. I work on React websites all the time, and the utility of the components panel in dev tools is limited because of that. The DOM that you're looking at bears little resemblance to the JSX that you're looking at.

Dave: Yeah, and you might... And there's probably a plugin out there, like the React dev tools.

Chris: Yeah, there is.

Dave: And that helps.

Chris: I don't know why I never use it. I'm sure some people live in that thing. But I just think it's sloppy.

Dave: But imagine if you need that. [Laughter] Just imagine if your dev tools were your dev tools.

Chris: Yeah. I just like the naming, too. I look around Google websites. Google uses them more and more. You can see these nested Web component models that are names that are not obfuscated. We're so used to looking at obfuscated code. It's refreshing sometimes now to see table header or something. Names that are just very... You know exactly what they're doing.

00:23:16

Dave: Sometimes in meetings, I just want to be like, "What's that called?" because once I know what it's called -- and we all go thumbs up, that's what it's called -- I can start coding it. You know what I mean? [Laughter] It's this opposite problem. It's like, just tell me the name of it and I'll write it for you.

Yeah, it's this weird, like, people are kind of like, "Okay, well, this card." It's like, "No, but what kind of card is it? Tell me the card name and I'll write whatever, foo-card or barf-bucket." I don't care. I'll put it there.

Chris: Yeah.

Dave: And it'll work.

Chris: I like that. There's a note here. One of them is that build tooling is not the typical starting point for a lot of Web component projects. Now, we should put a point on what type of tooling you're talking about. Build tooling is a specific type of tool, like, okay, I can't even look at my website until it's gone through this pre-processing step. And then stuff happens.

Now tons of stuff use build tooling. Web components can use build tooling, too. But typically, they don't.

Now, even if you're choosing some framework type thing like -- what's the one you work on?

Dave: Fluent.

Chris: Lit?

Dave: Yeah.

Chris: Fluent.

Dave: Yeah, or Fast Element.

Chris: Yeah, you don't....

Dave: Fast Element.

Chris: Yeah, sure. All those things are tools but they run client-side.

Dave: Yeah.

Chris: They're not build tools.

Dave: Yeah.

Chris: That's a different type of tool, so if you're saying, "Well, you need something like that, too. Hasn't Dave told me in the past that you should be using framework like that?" Yeah, you probably should be. That is a distinctly different type of tool than a build tool.

Build tools are the things that tend to be more fragile. Your Lit component today, you're locked into some version of Lit - or whatever it is. That's just going to continue to work in the browser because browsers are amazing at not breaking stuff going forward. But your build tool will break.

Dave: Yeah. I mean somebody could come along and be like, "Here's another. I have second version of Lit in here." But there are workarounds for that.

Chris: Hmm...

Dave: Yeah. I think most people... Or the saying is, "Build tools are a production concern with Web components," like we're just writing HTML. HTML goes anywhere.

How you stitch up and build up and ship that HTML is sort of up to you. It could happen in PHP. It could happen in .net. It could happen in--

Chris: Oh, that's a nice way to think about it.

Dave: --in a Vite app. It could happen in all kinds of places. There are a lot of options.

Chris: That part is up to you. Okay. I get it. I like it.

Dave: I built off of the idea of the buildless thing. But when you're building a one-off project, like your burrito website or something like that.

Chris: Mm-hmm. Okay.

Dave: When you come back to it, you don't want to remember how the build tools work, like, "Oh, what was it? What was I using? Ope, it's broke. Oh, why?" You know?

Chris: Yeah. It's broke is one problem. But also, how does this even work again? It's not broke, but we built it and we use Node 20, but it's two years now and we're on Node 25 or something and, "Oh, should I install some Node version manager thing?"

Dave: It doesn't even run anymore. Yeah. If you reduce dependencies like a framework, again, I think frameworks are good for helping you manage it all. But reducing a big dependency on a one-off project in your company, like whatever random event dashboard.

Chris: That's the one that's the most painful. That's what you're saying. These are off. We're not talking about your absolute main number one project thing that probably does have complicated build stuff going on and that's fine. But it's like, "Oh, we also need this little side thing over here." That's when you're saying, "Don't. Don't shoot yourself in the foot." That's going to be the most annoying one to come back to when it's broken because you're like, "Oh, it's just this dumb little thing. Why did I make it so complicated?"

Dave: Yeah. Make those ones easy. Like remove all dependencies whenever you can. Yeah. I think I had the word cognitive overload in there at one point, but just that overhead of, like, God, how did this thing come together? If you're going in between project A, B, and C, and they're all different, oh God help you. That's hard. It's easier if you're just like, "Okay, I just need to look at my package.json and hopefully, the dev command does it. That's hopefully where you're at.

Chris: Yeah.

00:28:00

[Banjo music starts]

Chris: Hey. You got great ideas but no idea how to build a website? Get Bluehost with their AI design tool. You can quickly generate high quality, fast loading WordPress sites instantly. Once you've nailed the look, just hit enter and your site goes live. It's really that simple.

It doesn't matter whether you're a blogger, influencer, just starting out your side hustle, Bluehost has you covered with built-in marketing and e-commerce tools to help you grow and scale your website for the long haul. And when you upgrade to Bluehost Cloud, you get 100% uptime and 24/7 support to ensure your site stays online through heavy traffic.

Bluehost really makes building your dream website easier than ever, so what's stopping you? You already got the vision. Make it real. Visit bluehost.com/shoptalk right now and get started today.

[Banjo music stops]

00:29:00

Chris: Okay.

Dave: More buildless talk. One-off projects is one thing but prototypes, that's kind of what I've been doing the last couple of week, getting up and building real fast is huge.

Chris: Hmm...

Dave: You just don't have a build step. You just put HTML on page.

Chris: Yeah.

Dave: And you can add that stuff in and make it better.

Chris: I like to call it CodePen friendly.

Dave: CodePen friendly, for sure.

[Laughter]

Dave: Absolutely. My whole deal is if you can't run your design system in CodePen, you've got out a lot of people. I think I said it later. Designers, they need this ability to use it. Not everyone is a full stack developer with 20 years of experience Webpacking the universe.

Chris: Mm-hmm.

Dave: You need people. You need multiple entry points for your package.

Chris: Speed concerns, they just tend to be faster. They just use less RAM. They are more efficient, so that's a quick one.

Dave: Yeah.

Chris: Just so you know, people - on average.

This was the earliest one for me. I'd say this is the earliest thing that got me interested at all was that they have this... That the Shadow DOM is a unique beast in the world. It's not everybody's most excited thing lately. I think sometimes we talk about how it's kind of worth avoiding sometimes.

Dave: Yeah.

Chris: Not all the time. It really is a unique thing that absolutely no framework can do because it's too low-level of a thing. Frameworks can't operate at this level.

Web components offer Shadow DOM if you want it, and one of the things Shadow DOM does is encapsulate styles and even JavaScript selectors and all that type of stuff. It's like a little tiny iframe. It's not an iframe. It's Shadow DOM. Different.

Dave: Yeah.

Chris: But it is encapsulated. And if you need that, this is the only game in town.

Dave: Yeah. It kind of is. You can put Shadow DOM in your React components. I know people who do that. The ergonomics aren't there.

Chris: To me, that's a Web component then.

Dave: Yeah.

Chris: Yeah.

Dave: The ergonomics aren't there for you. Yeah, not necessarily the best experience.

Chris: Mm-hmm.

Dave: Yeah. I've been on the record saying I think the style encapsulation of the Shadow DOM is sometimes too much. The "I know what I'm doing" selector.

Chris: Doesn't exist yet?

Dave: Doesn't exist yet, but it should. I still feel like it should because, again, to give people pathways to do what they need to do is helpful.

00:31:48

Chris: Yeah. We've talked about this plenty. But if you have Shadow DOM and it's sitting in there, your regular CSS that styles the rest of your page has no... Well, I shouldn't say no mechanism, but it doesn't have a typical mechanism for reaching inside of that Shadow DOM and styling things. It was on purpose built that way because there's supposed to be a barrier there. It's perhaps the top purpose of the Shadow DOM. But that can be kind of a bummer because sometimes you're reaching for Shadow DOM not for that encapsulation but for other reasons; for templating reasons and distribute ability reasons - whatever it is. It's just a little unfortunate that there is no simple way to reach in there.

People say, "Yeah, there is. There's DOM and part or part and theme." I forget what they all are.

Dave: Yeah. Yeah. Part.

Chris: That way is in there. I'm on the record saying that sucks. I wish that API didn't even exist; it's so dumb to me. A hard line on that one.

Then some of them people are like, "Well," what do you call them, "custom properties kind of pierce in there," so you can set up styling that way. Yeah, absolutely you can. It's just both of those ways are... There's some other thing. It's CSS-like, but it's not just saying, "Here's the power of CSS."

Dave: Right.

Chris: And I think that's what we deserve inside there.

Dave: I agree with you on part. To be honest, I feel like it's a complication not a solution.

I do think it's trying to emulate native pseudo elements, like ::WebKit thumb trackbar scroll - or whatever. But I feel like it's a pretty opaque surface, just like the pseudo elements are inside of an actual element.

I also think it's one of those things where it's like -- this is Web standards to a core -- what can we do? Okay, let's dream up the perfect solution but "What can we do?" is a much smaller set of realities.

Chris: Right. Yeah.

Dave: What can we do this month just to get YouTube built - or whatever? Which is not the way you should do Web components. But how do I do a smaller set of this functionality that gives you a way to style something inside a Shadow DOM? I think it's okay.

Chris: The killer to me is that you couldn't do the children. You can select something with part, and then it's like, "Oh, but I want to select a card, and then I want to select the header within it." Oh, I'll make the card a part then, and I'll select the card.

Okay. Part and then - I don't know - H3 is a child. Nope! Too bad. That's got to be a different part.

Dave: No, sir. Yeah.

Chris: That part is so dumb to me that it's like, "Why did you even do that?"

Dave: Why did you get me here but you just said, "No more"? [Laughter] Yeah, it's like you got me.

Chris: Yeah, and there are reasons for that. And I also understand that if all of a sudden platforms shipped and we were just calling the "I know what I'm doing" selector that that kind of breaks this contract that existed before. All of a sudden, authors now (from the outside) can reach inside and style something in a way that was never possible before. There are surely loads of people because Web components are much more used than you think they are -- this is not a particularly niche thing anymore -- that authors of them could be like, "Hey, I use this on purpose so users couldn't do that."

It breaks this promise that was made at one time. But it does make me think about this concept of opt-in, which is happening all the time in CSS recently.

Have you seen this animate to auto stuff?

Dave: Yeah. Yeah.

Chris: Those are opt-ins. In order to get that to work, there's some stuff that you can do at the root of the document that kind of allows that to work.

This is also true of the new select menu. By default, there's all this stuff that you can't do. But there's... I forget the exact key value thing. But there's something in CSS now that says, "Oh, this select element, I'm opting it into this new styling universe."

Dave: It's like appearance base select - or something like that.

Chris: Yeah. Yep.

Dave: Something. Yeah.

Chris: There's a variety of them, too, because you even have to alter your HTML a little bit and stuff. But it's clearly, like, nobody... You can't accidentally... A bunch of styles are actually going to accidentally apply to these selects as they ship it because the Web platform is trying to be really careful about that and not ship stuff that's going to change websites that looked the same for 15 years and, all of a sudden, look different. They really try not to do that. A way to do that is the opt-in model.

It seems to me that that could work with some kind of "I know what I'm doing" selector. If you want that to go through, you have to opt in to having it.

Dave: Mm-hmm.

Chris: So that it doesn't break that old contract with authors.

Dave: Yeah.

00:36:53

Chris: I always thought that's what shadow mode open and closed meant, but it does not. [Laughter] I don't even... To this day, I don't even totally understand what that setting does.

Dave: Yeah. It's basically ShadowRoot close... Well, ShadowRoot open is probably easier to describe from here. It means if I'm - document query selector my button - then I can go .shadowroot, and I can enter the ShadowRoot. Now I can go .shadowroot.query-selector span.

Chris: Okay. In one query selector, you can't slide right through. But you can get the parent and then keep drilling?

Dave: Right.

Chris: Okay.

Dave: I can drill into the ShadowRoot in ShadowRoot mode open, which is kind of the default now.

Chris: Uh-huh.

Dave: Well, you have to specify, but it's kind of like Lit does it by default - stuff like that.

Chris: That is an opt-in, but it's been there since the beginning.

Dave: Yeah. Closed is like don't... You're not allowed in. You can't go into Google's thing, Google Map, and say document query selector google-map.shadowroot. They won't let you do that.

Chris: Okay. So, it's a way in for query selector, but it's not a way in for CSS. It should have been. It should have been.

Dave: I agree. I agree.

Chris: Okay.

Dave: More, I think, people are starting to think about it more, but you know it's one of those things.

Chris: It's one of those things.

Dave: It's hard.

00:38:22

Chris: You had one here about demoing something, like a little tiny example - or something. You're like, "Why not package it up so people can pick it up and drop it in their project? Just a little booper, a little embeddable kind of thing?"

Dave: Yeah.

Chris: I like that. You also have this hilarious blog post about how you used Web components in Markdown, and you know how you do it. You just do it.

Dave: You just write Markdown. Yeah.

Chris: Because Markdown supports HTML in it, and Web components--custom elements, anyway--are that. So, it's a perfect way to do that.

You're like, "Do you really like MCX? Do you think MDX is hot?"

Dave: Yeah.

Chris: That's what Markdown in Web component are with no build step whatsoever. So, enjoy.

Dave: Well, how many times have you been like, "How do I make accessible tabs or a dropdown combo box, auto-complete search? How do I make an accessible one?" Then you get sent to some archaic academic website with all this jQuery 700, 900 lines of jQuery, and they're like, "Duh! Here you go."

Or it's a React component with 72 layers of nested context. And they're like, "Duh! Here you go. That's how you do it, you idiot."

You're like, "That still doesn't help me make an auto-complete myself." [Laughter] "Could you just put it in a Web component and then I can put that on my page?" because that would be sweet - because I'm not using jQuery. I would like to just use this Web component. Thank you. Bye.

Chris: Mm-hmm.

Dave: Anyway. People me.

00:40:00

Chris: Yeah. [Laughter] There's a "Where Web components shine." Again, that's what we're talking about. You can think about using them instead of an iframe for third-party content. I think that appeals to me on a performance level alone. Iframes are very useful straight up but don't have a great performance profile among other problems, so that's a possibility there.

Dave: Well, even just ... They have bad performance, yeah, generally. But you think about an intercom chat widget or whatever. Man, wouldn't it be great?

They're probably doing a lot of work to make sure that their styles ever conflict with anybody else's styles. You know what I mean?

Chris: Uh-huh.

Dave: They're doing a lot of work to make that happen. What if that was default? What if it just worked by default?

Chris: Yeah, right.

Dave: You'd probably save a couple hundred hours of development on that.

Chris: Yeah. Yeah.

Dave: Just throwing that out there.

One thing I was going to say, we talked about the tech stacks thing. But one other point that occurred to me after the post was like, you know, it works across your Angular, your WordPress blog, your other thing. There are a lot of different places Web components can go. But even if you're stuck in a version jump, like Angular 2 to Angular 19 - or whatever is the latest - 18? - that's a big jump for you and your components.

Chris: Yeah.

Dave: Having Web components as part of your UI, those pieces that can exist on both platforms, might save you a lot of headaches, so you can start using new tech or rolling out new tech in little places without crashing everything.

There are a lot of people who are on... I guess React 19 supports Web components natively, right? But not a lot of people are on 19, Chris.

Chris: Yeah.

Dave: Not a lot of people are on 18.

Chris: No.

Dave: Most people are on 16.

Chris: We looked at it, and I was like, "I forbid us to look at 19." It's not stable yet. I do not have time for this. No.

Dave: No. No. You know the upgrade numbers for 18 are bad, too. But it's just all to say if you have to wholesale upgrade every single bit of UI before you can make the jump, that's hard. But if your UI kind of existed outside of the framework, it might actually be beneficial.

Chris: Right.

Dave: Who knows?

00:42:36

Chris: Yeah. You made the point earlier about the design thing or designers.

Dave: Mm-hmm.

Chris: I've found this to be true. I'm just one man, of course. But I find that there are plenty of Web designers who know their medium well and thus are capable in HTML and CSS and maybe some JavaScript as well but don't go incredibly deep. They know the raw materials of their craft but aren't framework heroes or whatever. They don't know whatever Svelte stuff deeply. And that a Web component like setup might help them go a little farther than they did before because Web components are just HTML and CSS and JavaScript - or whatever - that you might bring them a little farther in the process using Web components than you would with a framework.

Dave: Yeah. I mean I think--

Chris: No build process.

Dave: Yeah. You can point them at a CodePen. I don't want comparisons but pointing somebody at a CodePen and pointing somebody at a StackBlitz are two different things. One is super easy and one is like, "Oh, God! What did I get myself into?" That one is StackBlitz. I love you, StackBlitz. Thank you for sponsoring the show. Are you sponsoring the show? I don't know. [Laughter]

[Laughter]

Dave: But it's so much overhead, Chris. The first thing it does is you open it and it's like, "NPM installing the Earth." And you're just like, "Dude, I don't know where I type."

CodePen is much more like, "Here's what we're doing. Here's what you've got. Here's how it works. Ta-da!" Very, very easy to comprehend. Yeah. I'm saying that about all versions of CodePen. Yes.

Chris: Right on. That's a lot of stuff. If that was too much, just read Dave's post. I think it makes the point a lot clearer and quicker than we did here, but it's just fun to talk about, too. Isn't it? They clearly do shine in lots of ways.

Dave: I think your list is going to be different than mine. Some people go all in on things and they're like, "I can build everything with this," or "I hate this. This is stupid. It can't do anything." It's like, "Oh, okay. Well, I just wanted to broaden the conversation about here's all the stuff they do. They don't just do one thing. They don't just build "hobby websites," somebody on the Apple team. They don't do that. They do other things. Yeah.

Chris: Lots of examples of them building really big, really powerful things, notoriously, that... There's all kinds of stuff, but it is easy to point to that Photoshop example from Adobe because, wow! They really did just write Photoshop in Web components, and that's something else.

Dave: Yeah.

Chris: Pretty wild.

Dave: When you're like, "It's for baby apps."

Chris: What did they do for state? That stuff blows my mind a little bit.

Dave: I mean they can do--

Chris: Something.

Dave: You can do whatever you want. I don't know. They probably have something.

Chris: What did they do?

Dave: Yeah, I don't know. I could get that answer for you probably, but it was probably some Reactive context would be... Based on the generation, I think that they wrote that. I think, yeah, reactive context would probably be the right answer there.

00:46:00

Chris: Okay. What I don't want to hear from is anybody who... If you have some strong, weird opinion about Web components but the only context you've ever thought about using them in is one desktop website that already uses a JavaScript framework, then I don't care what your opinion is.

Dave: Yeah. Yeah.

Chris: Because it's not the right context.

Dave: Yeah, it's probably not been... You're bolting on, I guess. You're starting a new thing, or you're trying to put in new technology inside another technology, and your first experience with that is never going to be good. That was the point I tried to make is everyone's first test drive with Shadow DOM sucks. Take that when you use Web components for the first time. It sucks because you're just like, "What the hell is going on? Why can't I style this button?"

Chris: Mm-hmm.

Dave: Slowly, you start to understand the limitations and what it does and what it's good at. I can't say it's... We still encounter gotchas and stuff like that. But it's like that'll be an upcoming post, probably. But it's just kind of this, "Oh, okay. So, you don't--"

Like Vue transitions. Found out this week Vue transitions inside Shadow DOM, shadow children doesn't work. And so, you're just like, "Dang it! That would be useful."

Chris: Cross-page ones or the other, the one page ones?

Dave: I think the JS ones.

Chris: Oh, yeah. You'd expect those would work.

Dave: Yeah, so it's just stuff like that. It's just like, "Oh, okay." I don't know. I need to whip up examples for that and then file complaints to browsers and make it happen.

Chris: Yeah.

Dave: You know it's just kind of hard.

00:47:38

Chris: Well, there are a couple of related questions just because we're this far into it, I think that maybe trying to hit these two would be good because then we can make this the Web components shine.

We have one here from Andrew Scofield. Thanks for writing in, Andrew, who basically ask what would it take to make the Next.js of Web components. To me, this is a fascinating question because it doesn't really exist yet. Next.js is the Next.js of React. You have no choice. You have to use React with it, and it really helps make React shine in good ways, like it or not. It's very popular, very good framework that does a lot for people.

What does it do? Can we picture a world in which this is ready? I think it makes sense that it's not here yet because Web components had their little journey of their own and evolve independently and stuff. It's not surprising to me that it doesn't exist yet, particularly because I think a big one from my perspective is the declarative Shadow DOM.

Dave: Yeah. Yeah.

Chris: That's relatively new. And without that, what's the point of a framework - kind of thing. That feature to me feels like the purpose of it is so that a framework can do it.

Dave: Mm-hmm.

Chris: Declarative Shadow DOM is probably not for you to write by hand. Maybe sometimes.

Dave: They literally said that in the issue where they propose it. They're like, "No one is going to hand author it," and I was like, "Uh, actually, I'm that asshole. I would. But I see the point."

Chris: Yeah, point taken.

Dave: Yeah. Yeah, yeah.

Chris: This is for a framework to do, in my opinion, especially because components aren't just used once on a page. The point of them is that they're sprinkled all over your app. And if they're sprinkled all over your app, you need some kind of abstraction to help you author that. You're not going to hand-write the Shadow DOM 15 times in the 15 times that component is used.

That's it. To me, it's, "What would it take to make the Next.js of Web components?" It's thinking about that. Can you make a declarative Shadow DOM sprinkle machine that does all that for you?

Then the next thing is, don't underestimate this. The point of these frameworks, the reason people reach for them and like them, I think, is the routing.

Dave: Yeah.

Chris: It's all about routing. Whatever that framework is, it needs to have a router. Invent one. Use one. Be opinionated about it. Get something in there that deals with URLs.

A framework isn't Next.js unless it has a router in it. That's what--

Think of the Remix journey. At one point they made Remix, and then they were like, "This is basically just a router," so the next Remix is just React Router 6 or 5 or whatever it was.

Dave: Yeah. Yeah, yeah.

Chris: Because they realized that that's mostly what a framework is doing is serving pages at URLs at routes. Whatever you make, the Next.js of Web components (in my opinion) it's got to have a router or even just be router-based.

00:50:37

Dave: Yeah. I think file-based routing would be huge. That gets into the bracket ID bracket dot - or whatever - post/bracket-id.html.

Chris: Yeah.

Dave: I think that's some killer convenience. I think you're right on the declarative Shadow DOM. I think the machine would hopefully do that. I think I'm going to go out on a limb. I don't think it has to do it to full fidelity, like full static fidelity.

Chris: Okay.

Dave: I feel like if you got ... six.

Chris: ...skeleton-y.

Dave: Skeleton-y.

Chris: Okay. Yeah.

Dave: Maybe that gets into where this gets hard is because every framework is going to do its dynamic template parts differently. But maybe there's a way to be like, this is what a template... the shadow or the DSD template should look like. You provide that via your components - or something - or generate those.

Chris: Well, that's important. That is another strength of Next.js that's worth talking about is that it has these three rendering modes that make it rather effortlessly to think about. I shouldn't say effortless because it actually could be effortful. But think of the three. They are entirely client-side. They are entirely pre-rendered. Then the middle one, which is on-demand rendered by a Node server. It really can do either three of those really nicely, I think. I think that would be nice, too, to see that in a Web component framework.

To your point, Dave, that could be the statically rendered version of it could be skeleton-y and have some way to indicate that this component is ready for that type of treatment but doesn't need full fidelity. Imagine an attribute that just said how it wants to behave within the framework.

Dave: Yeah.

Chris: Could say, "Oh, this one. Don't even bother rendering if you're not client-side."

Dave: No SSR. Yeah.

Chris: It's just a client-side beast.

Dave: Client, yeah.

Chris: This one, it's just HTML, so you might as well just do it full fidelity because there's nothing... there's no reason why you shouldn't.

Dave: Yeah.

Chris: Then those middle ground ones that are like, "Meh, that one is kind of--" you know.

Dave: Yeah.

Chris: One like a photo grid or something that clearly could use some squares up in there.

Dave: Mm-hmm.

Chris: But you don't need to get every single image first. That's too much work. Let that happen client side, but the server-side version should have little squares. Fair enough.

00:53:12

Dave: Yeah. Yeah. No, I mean I think that's a piece. The other piece I think you have to consider is React helmet style stuff. If you have all these routes and they're changing pages, how do you update the title in the metadata, the Twitter cards, summary card? How do you update those chunks in the head, I think, is a problem you have to solve.

Chris: Sure, which is a great problem for a framework to solve.

Dave: Yeah. I don't want to do that stuff. Could you generate the cards for me, too? That'd be sweet.

Chris: Yeah. Sure. And it could be a custom element. It could be a framework-helmet element. What it does is propagate its guts to the.... It probably wouldn't even be that hard to write, honestly.

Dave: Yeah. What's funny is it's a lot of work to make layouts, like a folder of layouts, /layouts, and you have default. Then you have whatever, your document, and then you do mustache mustache content mustache mustache, or something like that. Guess what, Chris? Web components have slots, so they can wrap.

Chris: Yeah.

Dave: Your app shell can be just a Web component layout.

Chris: Cool.

Dave: But you still have to figure out the head part. That's kind of the piece you still have to have.

Chris: Yeah. You're going to have to make some decisions. It's going to be opinionated. It's not going to... There might be... You'll probably want to make it work with any Web component that gets thrown at it. But you're going to want specific features of the framework to require certain stuff, naming things and particular attributes.

Dave: Any time you are like, "I'm going to code the website for you," you're going to get people who raise an eyebrow and say, "I don't think that's right." That's fair. But all this to say, I think you have... I think there's a chance to look at it.

I think enhance gets really close from begin, who is now part of the Sanity crew as of this week. Congrats to them.

Chris: Hmm...

Dave: But enhance gets really close. 11ty with WebC is kind of the flavor of that. I would even put Astro components in there even though they're kind of trying to dodge a framework - or not a framework. You don't know. [Laughter]

Dave: Yeah.

Dave: We support React for everybody's best friend, which is good. But I think those apps or those sort of server-side generators get you pretty close to what it would probably look like for the Next.js of Web components. I don't know, man. Zach Leatherman is at fricken' Web Awesome now, so maybe they're working on that. I don't know. I haven't heard that, but--

Chris: I just saw him the other week, and I literally... He didn't really say, because... I don't know. We're not journalists.

Dave: Not journalists. Vibes only.

Chris: Yeah.

Dave: [Laughter]

Chris: But the vibe I got was that they're talking about that kind of thing. I don't think they have... they're about to lift the curtain on the Next.js of Web components, but certainly, if they could be the Next.js of Web components, they would be first in line to. Certainly, the desire is there. They've just got to--

Dave: Yeah.

Chris: --I assume, make it work with their business realities and stuff because they're a functional business that now has employees to pay and stuff. You can't just... Not everything is pie in the sky.

Dave: But the nice thing about Web components is you build your stuff on the Next.js of Web components. You have a folder full of components. Then that person goes wild and starts shutting people out and going nuclear. You can just take that folder full of components, hopefully, and just move it to a different project. I think that's sort of like the shadow requirement that I would put on this, too, is hopefully, your components aren't overly tied to the framework. That they are just elements. They're not special flavor elements that I have to code that only work in your system because then I think they stop being the universal Web components, if that makes sense.

00:57:40

Chris: Indeed. Well, there's one more that I thought would be interesting to relate to all this, especially while we're talking about the framework stuff. Alex Hinton writes in, "How long until we just don't need any frameworks and JavaScript can do framework-y stuff out of the box? Or what will be the next framework type thing to come to front-end land?" If that happens, then what do frameworks do in that world?

What are those kind of things? What are things that frameworks do that need to be done by a build tool or something and could the Web platform step in and just start doing the type of thing that frameworks do? Recently, there's talk about letting frameworks do more instead of less, so that's kind of weird timing for the question.

Because I made such a big deal about routing, I will bring that up. It was a couple of years ago. There was a JavaScript feature called URL pattern.

Dave: Mm-hmm. Mm-hmm.

Chris: The blog post was called "URL pattern brings routing to the Web platform." I don't know where that went, so bad podcast journalism here. But the point of it was React Router is huge and the way that routing happens in JavaScript Web apps is folder-based or whatever. That will probably always have to be framework-y to some degree. But it also can be these... If you're doing it client-side, it can be a component, and the component's job is the routing. If you can picture what React Router looks like. There's a router element. There are children of it called Route. Routes have an attribute which matches URL patterns. Then if it matches, it renders the components within that component. It's like a declarative-y way of doing client-side routing.

Dave: Mm-hmm.

Chris: That could come to the native platform.

Dave: Yeah.

Chris: It could be like, "A URL matches, so I should render X." And what X could be is a Web component.

Dave: Yeah.

Chris: That's a thing that the framework or the Web platform could swallow up from frameworks should that go well. Did it go well? I don't know.

Dave: Yeah.

Chris: Have you heard of this? Do you remember URL pattern?

00:59:57

Dave: Well, I actually don't remember this. But it actually looks cool because I was thinking about writing a parser kind of like this, so this is cool.

[Laughter]

Dave: It seems like it kind of... You kind of sort of give it some URL patterns and say, "Is this real?" and it'll say, "Yep, that works. That's a real URL," which you need to preflight that, right?

Chris: Mm-hmm.

Dave: You can test the URL and otherwise go to a 404. But then you can execute the URL, but I don't know ... the URL of it. I don't know what that does. It returns an object but maybe... I don't know. That would be cool for your getting now all the params in there through :id is now id=123 in a JavaScript object.

I was going to say the navigation API is kind of in the talk now, which is a sort of router, navigation API just kind of coming out. I think it's kind of like something to consider. You can kind of get that history sort of... It's like a buffed up history API or push state API. I think that's kind of cool. I would consider that. That's, I think, a piece of technology that has to be there.

I think schedulers - or whatever - need to show up. We have that idea, I think, now. But that would be more helpful to have more tech around that.

Chris: Yeah.

Dave: I think Signal's API is going to be huge. I think game-changing, to be honest, if it ever lands in JavaScript because then we kind of have a native global state solution - if that makes sense.

Chris: Mm-hmm. Mm-hmm.

Dave: I think that's what people will need. I think we've been chasing that for a long time. I think that would be huge.

Chris: We're getting there. I don't think frameworks are going away, but I feel like it's kind of the job of the Web platform is to be watching what people are doing and making those things better and whatever. Almost every time it happens, it's good for everybody.

Dave: Yeah.

Chris: Chances are they do it more performantly and they do it more accessibly than can be done any other way.

Dave: Yep. Hopefully. Hopefully.

Chris: Hopefully. Right. It's not like there's a perfect track record, but generally that's the case.

I was just looking at a bunch of those scrolly telling sites today. I'm like, "Man, people still--" When you see a really good one, you can almost be sure that it's not using the new stuff.

Dave: Yeah.

Chris: It's still going to be Greensock under the hood. Like, "Hmm... How can we move the needle on that?"

Dave: Well, we were talking to Adam Argyle, I think, a bit. But stuff like I think we need new HTML or standard lib or something for data grid stuff, like all apps or whatever. I'm always going to say we need more HTML to do stuff. Stuff like popover eliminates a huge need for a UI library because now you can just add a popover with an HTML attribute and an anchor in the position sort of thing. You can anchor it without a framework. That's pretty cool.

Chris: Yeah.

Dave: What if we did that for tables, like a data grid, sorting, like click to sort the headers and stuff like that? That could be huge, man. I think you have to think outside of the box here, but I think why did we choose the framework? Well, it's because it had a cool table. Sometimes that's the answer, and that's fine. But that's a lot of JavaScript for a table.

Notion. I'm talking to Notion.

Chris: [Laughter]

Dave: Thank you for sponsoring this show.

Chris: [Laughter]

Dave: That's my new thing.

Chris: Assume that it's a sponsor.

Dave: I'm just going to shit talk people and then say, "Thank you for sponsoring this show."

[Laughter]

Chris: Sponsorship is amazing.

Dave: It's good.

Chris: This one is sponsored by Automattic. Thank you.

Dave: Thank you. Thank you for sponsoring the show.

All right> Chris, do you got anything else, or should we wrap this guy up? j

Chris: Nah.

Dave: Yeah. All right.

Chris: We could talk for days. We'll be done.

Dave: All right. We'll cut. We won't do the two-hour episode. [Laughter]

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... Oh, shart it up. Shart it up big time.

Then follow us on Mastodon. I deleted my Twitter account, so whoopsie-daisy. It's a goner.

Chris: Yeah, it's gone.

Dave: Yeah.

Chris: See, that's a whole show right there.

Dave: Yeah. Anyway--

Chris: I know you felt bad about it, kind of like it was just one big waste of time. You don't have to feel that way. It's the friends we made along the way. We learned a lot. You shared a lot. You built your network. Now it can go away. Everything changes.

Dave: Yeah.

Chris: It's just another change.

Dave: There's like 8% remorse, but it's also just like, "Dude, my life is now less complicated without that website in my life." And everyone is moving to Bluesky anyway. But anyway, yeah, follow... Join us in the D-d-d-d-discord. That's also a good place with nice people, patreon.com/shoptalkshow. Chris, do you got anything else you'd like to say?

Chris: Hey! ShopTalkShow.com. Bye.

Dave: Bye.