848: Web Components Can’t Save Us with Scott Jehl

Scott and Wes talk with Scott Jehl about the benefits, challenges, and use cases of web components, particularly in design systems and performance. Show Notes 00:00 Welcome to Syntax! 00:55 Scott’s background and career Responsible Responsive Design Webpagetest.org 06:46 An overview of web components 09:06 Why should people care about web components? 13:16 Should you write your own web components? 14:39 Reactivity in web components 15:56 DOM parts 18:23 Styling web components 22:08 Brought to you by Sentry.io 22:33 CSS custom properties Mux Player Customizer 24:28 Responsive video 28:27 The polyfill use case 30:55 Shadow DOM challenges 36:04 Web components in design systems 41:58 How are people using web components? 43:25 Web components and server-side rendering 45:00 Scott’s thoughts on build tools 47:33 Sick Picks & Shameless Plugs Sick Picks Scott: Enhance Shameless Plugs Scott: Squarespace is hiring Web Components Demystified - Get 30% off with coupon code “syntax” Web Components Community Group Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax. Today, we've got an episode for you today on mostly web components. And I think we're going to title this one, "Web Components Can't Save Us," because we've got Scott Gel on. He has a pretty, pretty good background in JavaScript and web development in general. I'll let him talk a little bit about that, but I've known him for, I don't know, probably feels like 13, 14 years. I remember taking a bus to jQuery conference together many, many years ago. And it's, it's kind of fun to be able to, this often happens, we get to come back and talk to people that you've known for, for so long. So, welcome, Scott. Thanks for coming on.

• 0:37Speaker 01

  Hey, thanks, Wes. It's, it's really nice to be here. I listen to the show all the time. So, and good to see you, Scott.

• 0:43Scott Tolinski?

  Yeah, likewise.

• 0:45Wes Bos?

  Yeah, two Scots. I don't think we've ever had two Scots on, have we?

• 0:48Scott Tolinski?

  I don't know. This very well may be a first. We've never had another Wes on.

• 0:52Speaker 01

  Really?

• 0:53Scott Tolinski?

  Yeah.

• 0:55Wes Bos?

  You want to give people just a quick rundown of your background? Because like, I know from way back when, you were, you were pretty early in like the responsive design scene, and then you've had several jobs since then.

• 1:07Speaker 01

  Yeah, yeah, that's right. I guess I could, I could start from way back and, and go towards now. So, back when, when I knew you, I guess I was, I was working at Filament Group, an agency in Boston. They're still around, kicking ass. And I was there for 15 years. And we had, yeah, long, long term for, for our industry. But it was great. You know, we had just an array of amazing clients throughout that time. We got to build the, the Boston Globe's first responsive, you know, large scale website that sort of made a name for us in, in doing responsive work. We did the Lego Shops front end. We worked for Vineyard Vines for a long time.

• 1:49Speaker 01

  And, you know, a lot of that, that client work drove some of our open source work, like for the jQuery team. So, I met you through that. And yeah, I was on that team since, you know, since we were putting together the website in John Rezig's bedroom. It's way back.

• 2:07Speaker 01

  Yeah, so Filament for a long time, a lot of open source and web standards work came out of that and performance audits and things like that. So I ended up doing a lot of performance work to the point that, you know, at some point, Catchpoint, the company, had acquired Web Page Test, the product, and, you know, free webpagetest.org, performance testing tool. And I had long been a, you know, sort of a super fan of the tool and an advocate and a community member. And they were staffing up the team and it felt like, you know, sort of the right moment to, to make the jump to work on a product for a little bit. So I got to do that Catchpoint for a couple of years. And we built the first commercial addition

• 2:49Speaker 01

  to the product that they had, which was called Web Page Test Pro. And it was pretty fun, you know, it let you apply optimizations to websites live over the air using workers and sort of a reverse proxy sort of thing. And, and actually see like if optimizations, you know, move the needle without having to like, you know, do all the code to see that. And yeah, so that was pretty neat. After that, took a little time freelancing, worked with the folks at Begin, and they do Enhance.dev, the web components framework. So that was great, just to get some exposure to how people are building on these things right now that are just starting to make their way into, well, some of the biggest

• 3:33Speaker 01

  companies in the world are adopting them now. So, yeah, so that was great for exposure. And then, and now I'm at Squarespace. I've been there for three months now, pretty much. And it's fantastic. I mean, it's the first time that I've sort of been in a role where performance changes that I could make could potentially, you know, end up rippling out to millions of websites as opposed to working on one client at a time. So the scale is, is pretty inspiring to me. Yeah.

• 4:01Wes Bos?

  Yeah, that's wild. I often talk to people like, I don't want to name a competitor, but I've talked to some of the folks at Wix as well. And it's just the scale that these things are running at, you know, just a couple bytes here and there could be Serious bandwidth savage over, over the scale.

• 4:20Scott Tolinski?

  Yeah. And also, for those people who weren't around in 2011, that Boston Globe site was, I mean, you hinted at that, that was kind of monumental. In fact, the agency that I worked at used the Boston Globe site every single time we were trying to sell responsive design on our clients in 2011. It was like, no one knew what it was. And so you were, had to show everybody, yes, this is gonna take a big more effort, but look at the experience you can get. And this is, this is how good it can be. So, uh, man, that thing was huge.

• 4:52Speaker 01

  That's a great story. Um, you know, credit to their team for taking, I think, a pretty big risk at the time and adopting technology that was just like right at the right moment to, to jump on it. And also just, you know, the team that was involved, Ethan Markut worked with us in-house at Filament Group, the team at Filament, Upstatement did all the, the design work. They're just a fabulous design shop. Um, yeah. So it was, it was kind of a dream project. I don't know if we'll ever, you know, quite, quite live up to that one again.

• 5:23Wes Bos?

  Because it was like early days of

• 5:25Scott Tolinski?

  It was very early.

• 5:26Wes Bos?

  Mobile devices, right? Like we had those big, uh, mobile device walls where you would

• 5:30Speaker 01

  Totally.

• 5:30Wes Bos?

  test on every single device. And like, I, it's true. I don't, I don't know that we'll ever have that big of a shift in how we consume media.

• 5:38Speaker 01

  Yeah, it was amazing. I mean,

• 5:40Wes Bos?

  Maybe VR, but I don't know.

• 5:41Speaker 01

  Yeah. Yeah, maybe. Yeah. Filament had a physical device lab, you know, I remember Matt Marquis was, uh, or Marquis, I think it's, uh, you know, restarting all these devices every morning and, you know, keeping them on and charged. And we didn't really have browser stack and things like that.

• 5:58Scott Tolinski?

  Don't.

• 5:59Speaker 01

  Quite as commonly then. I think they were around, but yeah, just, that was wild times.

• 6:05Scott Tolinski?

  I had a device lab too. I made my own out of wood and had all the USB hubs powering. I just like went to my family, like, give me all your old phones, please. Let me just put them on a big wall here. And I forget who it was, somebody made software that like kept them all in sync a little ways into there when the device lab was still such a

• 6:23Wes Bos?

  Browser, what was it called?

• 6:26Speaker 01

  Browser sync?

• 6:28Wes Bos?

  Browser, not browser fine, not browser stack. There was a, I still have it in one of my courses.

• 6:33Speaker 01

  Browser, something.

• 6:34Wes Bos?

  It basically, it synced all the clicks across and all the scrolls and I don't know.

• 6:38Speaker 01

  Yeah.

• 6:38Wes Bos?

  That was pretty cool. I, I look back very fondly at those years.

• 6:42Speaker 01

  Really, really fun time.

• 6:44Wes Bos?

  Everything went down.

• 6:45Speaker 01

  Yeah, totally.

• 6:46Wes Bos?

  So, web components, web components are a thing in JavaScript HTML where you can essentially make your own components, right? And there's a lot, especially lately, on the Twitter sphere, there's been a couple of big framework authors come out and say like, web components is, is not it. And lots of people coming out saying web components is it. Scott and I talked to a lot of people from Shoelace or the, the Web Awesome folks.

• 7:11Speaker 01

  Yeah, right.

• 7:12Wes Bos?

  I'm pretty, pretty bullish on them as well. I'm curious to your thoughts on them. And obviously you have a course on them as well. So I'm assuming you like them?

• 7:21Speaker 01

  Yeah, well, I mean, partly I wanted to do this course to learn them more deeply, you know, especially just how different companies were using them and their design systems, because, you know, a lot of them, big companies have adopted them, you know, Adobe has Spectrum and Microsoft recently built the whole Chrome of their Edge browser, rebuilt it in, in web components and reported really, you know, big performance gains from doing that. So, yeah, so I, you know, I wanted for my own sake to understand it a little bit more deeply. And what better way than create a course? Yeah, so I, I'm a big fan. I, I feel like I've followed some, not all, of the drama

• 8:02Speaker 01

  that framework authors have been writing about recently. And, you know, I feel like a lot of people frame web components in sort of a light that, you know, brings expectations that they are similar to components as sort of like the metaphor comes from React and in other worlds. And I, I think they're, they're not necessarily the same thing, right? Like, they're not necessarily built as a replacement one to one for a lot of the concepts that you would, you know, have in your mind from, from frameworks about what a component really is. Even like very much just the fact that, you know, they're built. On HTML elements, like custom elements that don't go away when you include them into your document

• 8:42Speaker 01

  structure, much like, you know, maybe like an import sort of mindset works when you're dealing with components and other and other frameworks and languages. So yeah, I don't know. I mean, I feel like they have good points. It's sort of an interesting time to to figure out how to use these things. And I like parts of them more than others, or at least a lot more use out of parts, some parts and others.

• 9:06Wes Bos?

  So like, what are web components good at? Why? Where should people that are listening? Like, why should they care about what a web component is?

• 9:13Speaker 01

  Well, I feel like they're really good at the sort of like the leaf node portion of an app where you have like your button or your the actual little user interaction component part that might live within a broader framework or, you know, some sort of app orchestrating all of these, or they could stand alone, you know, on their own. And that's sort of the, I think, the killer feature of them is that we now have somewhat of a built in model in the browser that can allow these things to stand alone and live in many places and, you know, be compatible in a, you know, whatever kind of single page app if you need them to be. But ultimately,

• 9:54Speaker 01

  they're HTML, right? So like, anywhere you're emitting HTML elements, you could potentially be emitting a web component there instead. And maybe it carries its own, you know, sort of internal logic and behavior. And so I think, you know, that to me is a nice, you know, sort of transitional way to think about how they could start to be part of, you know, existing code bases today. And the way I've used them most, you know, in my own experiences as sort of little, you know, progressive enhancement, little patterns, like, you know, you wrap a custom element around some markup that already does something, but maybe not the whole thing

• 10:35Speaker 01

  that you want it to do. And then you've got this beautiful lifecycle that, oh, this thing just appeared in the DOM. Well, let's apply some behavior to it, you know, things that just weren't weren't quite so elegant. In the jQuery days, when we were like waiting for the whole DOM to be there.

• 10:50Wes Bos?

  I saw a really neat one the other day. I think it, I think it was from someone who, who works on Lit. And they made a number formater HTML component, which essentially is instead of like wrapping, let's say, for example, this project has 428,482 downloads, right? And if, if that's the case, or I've earned $1,300, you have, you have to put the dollar sign in front of it. You have to put the commas in the right spot, right? And usually when you do that, you have to use like the INTL dot number format APIs. And you sort of break the flow of, of HTML.

• 11:29Speaker 01

  Yeah.

• 11:29Wes Bos?

  You say, okay, now let me, now let me go over to JavaScript, select the thing, format it, and then stick it back in, into the DOM, right?

• 11:38Speaker 01

  Right, right.

• 11:38Wes Bos?

  And especially if you're not using like a, like a framework, that's, that's kind of annoying. So they just made a little web component that you, you pass the value as, as the body of the, the tag. And then that thing is all nice, nicely packed. And when the component loads, it will take its body and parse it out and format it and then return it.

• 11:59Speaker 01

  Yeah.

• 12:00Wes Bos?

  I thought that was kind of a, just a beautiful way to like, keep the declarative nature of HTML without having to do a whole bunch of JavaScript every single time you want it.

• 12:09Speaker 01

  Yeah, that, that sounds like a beautiful pattern. And, you know, just like you said, it starts with something that's already usable and makes it a little better.

• 12:17Wes Bos?

  Yes.

• 12:18Speaker 01

  You know, if the script happened to fail to load or had an error or whatever happens.

• 12:22Wes Bos?

  Still a number.

• 12:23Speaker 01

  That reminds me of, um, like GitHub has lots of these little patterns throughout its UI. Like the little timestamps that say how many minutes ago a commit happened, uses their relative time custom element. And if you look in there, it's got the timestamp, you know, kind of spelled out in full. And then in the shadow DOM of that same component, they've got the, the version of it that you see, which is, you know, three hours ago or whatever it is. It's pretty neat, I think. Yeah, you nailed it. That's like, that's the pattern that I think they're best at.

• 12:56Wes Bos?

  I realized that GitHub was using web components too. That I think that's the other thing about web components is no one necessarily knows. If you're not in the world, you don't think to look for it unless you're like inspecting element on every little thing.

• 13:08Speaker 01

  Yeah, they're all over GitHub's UI. I've used a lot of their examples because they've published a lot of those too, you know, open source and they're they're really good.

• 13:16Scott Tolinski?

  So when you're consuming personally web components, do you find yourself always reaching to write them from scratch? Or are there particular things that you would go to third parties or or looking, you know, whether that is like stuff like shoelace or or stuff like that?

• 13:31Speaker 01

  Yeah, I mean, I feel like, you know, a library like that fits the same use case that a lot of, you know, like, design system sort of libraries have fit for us for a long time. They're just using more modern APIs that are built into the browser. And they have, in their case, a very polished experience too. I think they've done just really beautiful work. So, yeah, I mean, if that was the sort of thing that that I was looking for, someone like like Web Austin looks pretty attractive. I also feel like a lot of, you know, a lot of our peers are just sharing great examples all the time. You know, Zach Leatherman, Dave Rupert, they keep these lists of, you know, good examples,

• 14:12Speaker 01

  whether they often built them themselves or are referencing others out there. So, yeah, I feel like there's just a lot of very good examples. Jeremy Keith is another, just posting good examples a lot, all in this sort of like HTML web components sort of pattern like like Wes was just talking about. Got something, make it a little better.

• 14:32Scott Tolinski?

  Yeah, totally.

• 14:33Wes Bos?

  What about reactivity? Because that's one thing that we don't have APIs for in the browser, at least not yet. I'm really hoping at some point we'll have the ability to just put a variable in a div. And that variable will update itself if it does. If you do need reactivity, what are you reaching for?

• 14:53Speaker 01

  I mean, currently, I feel like there are very good, small libraries that can give you that toolset. You know, I mentioned Enhance.dev, they have some nice base libraries, or base libraries, rather, that build on web components and offer that reactivity. There's WebC that works with static-generated sites, 11D sites. And then Lit, you mentioned Lit, that one's sort of like a power tool, I think, for more, like, you know, like, the real-time UI react sort of use case. So those are there. On the standards front, like, you talk about things like signals a lot on your show. I feel like that's within the web components

• 15:34Speaker 01

  community. It's signals and DOM parts, right, that are like, going to be the two standards that potentially figure out this problem. And those aren't necessarily like, part of web components, like, three tiers, or whatever. But I, you know, it's like, these are all standalone, you know, standards that can work independently or together.

• 15:56Wes Bos?

  What is DOM parts? I've not heard of this.

• 15:59Speaker 01

  Yeah, so that's, we'll have to link that up, but there's, so the Web Components Community Group has a GitHub page with lots of proposals. And one, I think that one's been discussed for at least a year, maybe more now. It's just, you know, framework authors, like the leads from Lit, have come together with ideas on how to build in markers into the DOM for being able to, you know, make updates a little more smoothly, I guess, especially if the HTML comes from the server and you want to update it with the rehydration kind of thing. I think their explainer is pretty long, and it's been a little while since I've looked at it, but I know that's, as of even today, I was, I was talking with

• 16:42Speaker 01

  someone over at the, at their group about that still being sort of where you'd, you'd point someone for that.

• 16:49Wes Bos?

  Neat. Okay, so this, this is what I was hoping for. This is

• 16:52Speaker 01

  It looked great, right?

• 16:53Wes Bos?

  In HTML, there's a declarative API and an imperative API. You put variables in things, and then when those variables updates, it will, it will render?

• 17:04Speaker 01

  Yeah, it's what we've wanted for a while, right? Something like that. Yeah. And something, frankly, that the HTML template element just hasn't really given us, right? Like, you have to do the sort of surgical updates on the DOM nodes with the template. And that's fine, but it's not, it's not what people coming from frameworks are used to.

• 17:22Scott Tolinski?

  Yeah.

• 17:23Wes Bos?

  That's exciting.

• 17:24Scott Tolinski?

  It also, I mean, it's not directly related, but have you seen the the Invokers stuff?

• 17:29Speaker 01

  Yeah, totally.

• 17:30Scott Tolinski?

  Yeah, that's kind of, I wonder if Invokers ends up becoming something more useful with web components for for people who don't know, it's basically like declarative event or like you're triggering events in HTML.

• 17:43Speaker 01

  Right, right.

• 17:44Scott Tolinski?

  Yeah, that would be, I feel like that would be a really interesting way to interact with web components right now that we don't have.

• 17:50Speaker 01

  Totally, yeah, and we're seeing just so much more of that, like Popover is sort of like a similar parallel, you know, where just a lot of wiring is happening in HTML instead of needing to reach out to to write scripts. So it's pretty exciting.

• 18:06Wes Bos?

  Let's talk about styling in web components world.

• 18:10Speaker 01

  How long is this?

• 18:11Wes Bos?

  That.

• 18:15Wes Bos?

  We go for about an hour, but that's also often a pain point in in the web component world is web components are entirely encapsulated, meaning that if you want to be able to style something inside of the web component, there's this thing called the shadow DOM, right? And your your styles don't, correct me if I'm wrong, but your styles don't inherit and they don't go, you can't select things from the parent to the child unless you explicitly surface like variables that can be passed in. Is that right?

• 18:48Speaker 01

  Yeah, for the most part.

• 18:49Wes Bos?

  Okay.

• 18:50Speaker 01

  Yeah, it's it's complicated. Yeah, for the most part, styles in the, should we say, parent page don't make their way into a shadow root, but some do. So like inheritable classes, sorry, styles, like, you know, font color, things like that are going to roll right through if they apply from a parent of the custom element right into the shadow DOM. So that's surprising to a lot of people who think it's totally, you know, encapsulated from the start and, you know, even JavaScript is sort of optionally encapsulated, right? So like you, you can have a closed shadow root, which is for.

• 19:32Speaker 01

  Most purposes inaccessible for JavaScript to get to from like, say, querying the DOM. But if you set the mode to open, then the the parent of the shadow root gains a shadow root property that you can then query deeper into the into the shadow DOM. So you kind of like, you know, you can't accidentally get into the shadow root with JavaScript, but you can make it so people can optionally get into it. CSS, open and closed doesn't matter. That doesn't really affect it. It's a JavaScript concept, but it's complicated, right? Like you mentioned, you can put styles inside the shadow DOM. You could put a link element in there and

• 20:12Speaker 01

  reference an external style sheet, reuse it across your page in many shadow DOMs. That works great now. So that's, that's like a good pattern, I think.

• 20:21Wes Bos?

  Let's stop on that for a sec, because I think that's a pretty nifty or interesting way is you can literally just link your CSS sheet in every single component. And even if it's linked in the parent, it's not going to re-download the CSS 3,000 times.

• 20:38Speaker 01

  Thankfully, that's fixed now.

• 20:42Wes Bos?

  So one of the options of if somebody has an existing CSS and they're like, I just want my website's styles to apply to my web component, they can simply just link up the same style sheet and then all of those styles will be available?

• 20:58Speaker 01

  You might want to be a little more careful about the global styles just being pulled into a web component and how that affects it. But you could certainly imagine like a component based style sheet that's used every time your, you know, menu component is used throughout the page or something like that. But for the most part, you know, styles within the shadow DOM, whether they're in a style element in line or in a external link like that, are pretty well encapsulated. There are ways to reach out. Like there's a, you've probably talked about the call and host selector where you can talk to the custom element parent. So there's like a little, a little bit of reaching out, I guess, of the shadow DOM that you can do there. But for the most part,

• 21:41Speaker 01

  Within the DOM, it's protected, but the outer page, there's a lot of exceptions that can get in. You know, CSS custom properties famously can breach the shadow DOM and it's kind of like the killer feature for allowing customization. That works just like in external SVG files too. It's kind of similar with the shadow DOM. Those custom properties pass through and you can offer up configuration like that.

• 22:08Scott Tolinski?

  And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io/syntax. You don't want a production application out there that, well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to sentry.io/syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 22:33Scott Tolinski?

  Is that how you're often seeing people offer?

• 22:36Speaker 01

  Yeah.

• 22:36Scott Tolinski?

  Sometimes I wonder like if I hit sometimes a web component and it feels like they've just like re-implemented CSS and cut like a billion custom properties to let you get control over it.

• 22:45Speaker 01

  Right.

• 22:46Wes Bos?

  Dash, dash, font, family.

• 22:49Scott Tolinski?

  Yeah. Is that the best way? Yeah.

• 22:51Speaker 01

  I mean, a good way, like for example, we mentioned like types of patterns that you'd use custom web components for. And another is like for the third-party embed sort of situation. The Apple Pay button uses web components in this way where it's just attributes. There's no content inside the Apple Pay element and then they control everything about it from an external script, right? But they do offer customization through CSS custom properties. So you can like override certain parts, but not like, you know, changing the Apple logo's shape or something like that, right? So, and I think that's like a smart use of shadow DOM in particular, where, you know,

• 23:32Speaker 01

  maybe you have a video player that goes on like Vimeo or YouTube or something like that and embeds everywhere. Maybe that's a good use case where you really need tight fidelity over UI. Don't want it conflicting with page styles.

• 23:46Wes Bos?

  Yeah, we would often just use an iframe for that.

• 23:49Speaker 01

  Exactly.

• 23:49Wes Bos?

  So that there's nothing available, right? Maybe you don't need that.

• 23:54Speaker 01

  Yeah, so this would allow you to at least piecemeal offer some configuration in the layout or whatever you want to use custom properties to do. One pattern that I didn't mention that I think is kind of an interesting one, and I haven't seen done a lot yet, is they're really good for polyfills. Like, for example, short preface here. So last fall, I did some work to help land responsive video back in Firefox. It had been taken away from us for a while in the standards and in the browser support.

• 24:28Wes Bos?

  Can you explain, before we even get into the web components, you sent me a note about that, and I was like, responsive video?

• 24:34Speaker 01

  Yeah.

• 24:35Wes Bos?

  I don't know I know what that is. Can you explain that?

• 24:37Speaker 01

  That's fair, because I kind of made up the word.

• 24:42Speaker 01

  Yeah, so if you think about responsive images, you have the picture element. This is very much a parallel with the video element. So when HTML5 first landed in web standards, we had the video element spec, which included media queries on source elements in the video element. So that was supported from the start. You could put on each of your sources inside a video, you could put @media min-width 500 pixels or whatever for one source, and then another that it would fall back to in the same order that a picture element works, right? So like, the first one that matches is used by the browser. So that worked originally. It was cross-browser. When it was, I don't know, like 2014, I guess,

• 25:27Speaker 01

  when we were starting to work on specing the responsive images syntax that would ultimately land in the browsers. And picture was designed... Based on this cool aspect that worked in the video elements. We were like, the video works this way. We should really, you know, picture should should have media queries like that, right? For art direction. And that's proven to be, I mean, I think, pretty successful. Like, there's no, there's no better tool that I would use to have different aspect ratios of an image across different viewport sizes, right?

• 26:02Wes Bos?

  Yeah, yeah.

• 26:03Speaker 01

  So that was what we used for inspiration. Meanwhile, some folks on the standards bodies didn't feel that that was a good model to base picture on. And throughout that conversation, they actually decided to just remove the feature from video and from the standard. So it was pulled from the HTML5 living standard for video. All the while, it was landing the same feature in picture.

• 26:29Wes Bos?

  Oh, wow.

• 26:30Speaker 01

  Yeah. So as a result, once the spec was changed, Chrome pulled their support, Firefox pulled their support, and we actually were left without support except in Safari. So this has always worked in Safari. Anyway, so I kind of made like an annoying campaign for like however many years that we really shouldn't have deleted this feature. And finally, browser vendors started to chime in last fall and say, yeah, we agree. We're interested. We want to build this back in. I just had to quickly land some C sharp and get this, get this landed back in Firefox. The Chrome team got their support back in overnight. It was kind of embarrassing.

• 27:14Speaker 01

  It ticked me. And yeah, and the standards was updated. So we have that back in browsers now. So if you want to serve.

• 27:19Wes Bos?

  We have source set on video.

• 27:21Speaker 01

  Not source set, not source set, sorry. Just media attributes on source elements. So like.

• 27:28Wes Bos?

  Oh, OK. Write a media query?

• 27:30Speaker 01

  Yeah, exactly. So like.

• 27:31Wes Bos?

  OK.

• 27:32Speaker 01

  You know, a lot of more and more video is streaming now. But say you had a blog post and you've got a local video file and you just don't want to serve the massive one to a phone. You could use this to, you know, to serve responsibly.

• 27:47Wes Bos?

  Yeah, or even like different. Aspect ratios, because whenever I do a TikTok video, I'll edit it in portrait. And then I'll make a second cut of it in square. And I just post them to different platforms, assuming most people on Twitter are going to be on their desktop. You know, TikTok, they're going to be on their phone, so they get the different one. But wouldn't it be nice if I could upload both versions of that? And it just showed the person based on the screen they're on.

• 28:15Speaker 01

  Yeah, so that's it. And this could totally pair with, you know, with streaming video too. You would just have a couple of different, you know, media queries and sources. So, so that was the preface to say the polyfill use case. So the one weird thing about responsive video is unlike picture, it only works once. So like you, you visit the page and whatever the viewport happens to be, it'll choose a source and it sticks with it. So if you resize the browser, it doesn't switch sources, right? And we decided to do that to get the feature back, just because that's how Safari's implementation worked right now. So we wanted to match that, but it's still sort of like an open issue. So yeah, I wrote a polyfill recently that just wraps a custom element around a video element and adds that behavior.

• 29:00Speaker 01

  You know, you have to sync the time code if you're switching sources on resize. But, you know, it's relatively like a small piece of JavaScript. It's not doing a whole lot, but it just gives you that, you know, that fully responsive feeling after load. And the cool thing about it, I think, is you can write, you know, customelements define in your web component. That's how you like teach the browser about a, an element. You could just do that based on a feature detect. So if the browser understands or passes this test for responsive video after page load, then don't define this element at all, like we're just, you know, fail silently. I think that's a cool use case for polyfills. I'd like to see more of it. Yeah.

• 29:46Speaker 01

  So that's, that's another one. It's kind of in the weeds.

• 29:49Wes Bos?

  But. No, I like it. I like it. We also talk a lot about Mox's implementation of their video player in web components. So they need a video player that is both highly customizable. You need to be able to change literally any part of it, but also it needs to work across all the different frameworks and in just straight up HTML. So Mox has this amazing player. They have a dedicated website for it. What is it?

• 30:15Scott Tolinski?

  Media Chrome. But most importantly, Wes, is that it supports streaming and all the, you know, HLS and all that stuff out of the box. You can use essentially a video element and pass in a M3AU and have it work like a HTML video element.

• 30:29Speaker 01

  Yeah, that's great.

• 30:30Wes Bos?

  Yeah, it just tucks all the complexity into a element. And then like you, the user, don't have to do a whole bunch of JavaScripts where you initialize the video player and, and all that. You simply just use the, the different web components and then you get things like the play button or the seek bar, the thumbnail. It's a pretty nifty implementation.

• 30:55Scott Tolinski?

  I'm curious about, what are the things that you would change about web components today that maybe is on the radar or not on the radar at all?

• 31:07Speaker 01

  Yeah, that's a great question. I think I'd, I'd like to change that people say web components instead of custom elements most of the time.

• 31:16Speaker 01

  But that, that ship has sailed. I think there are complexities with working with the shadow DOM that I find unfortunate. It would be really nice to be able to openly style a shadow DOM if, if you want to. And that's not really an option, you know, like from the parent page, just being able to select right in. Maybe there was, maybe there's some, you know, pseudo selector, special parent selector to dig into a shadow root. That would be really neat.

• 31:46Scott Tolinski?

  Yeah, totally.

• 31:47Speaker 01

  You know, Shadow DOM itself introduces a lot of more complicated scenarios like forms suddenly become complicated. You know, it's not that you can't work around these problems, but it's like you're really buying into a more, like, you know, a deeper situation. Like, if you have a form element, like an input, and it's in the Shadow DOM, it's not going to submit with your form unless you teach the browser about it, right? That's surprising. I didn't know that.

• 32:18Scott Tolinski?

  Yeah.

• 32:19Speaker 01

  Totally, yeah.

• 32:19Wes Bos?

  Yeah, I could see, that could be a pain.

• 32:22Speaker 01

  Yeah, and there are APIs for this stuff that come with the web component specs. So it's totally workarundable. Another one's accessibility, you know, like, simple things that you would expect to work, like a label and an input being able to pair through a for attribute and an ID. They don't know about each other if they have to cross a shadow root. So accessibility is broken.

• 32:45Scott Tolinski?

  Yeah.

• 32:46Speaker 01

  If you don't properly pair them, and you can, again, there's APIs to fix these things that are standard, not just like, you know, weird workarounds. But you have to know about these things, I think, when you adopt Shadow DOM. So I think some of those, it would be nice if they, the problems weren't there in the first place to catch people.

• 33:05Wes Bos?

  Yeah, those paper cuts, especially if somebody's like, "All right, I'm gonna try it," and then they're like, "Oh, this is odd." You know, it doesn't work like they would expect it right off the bat. Those are the types of things that can give people a bad taste in their mouth.

• 33:18Speaker 01

  Yeah.

• 33:19Wes Bos?

  What is the process for exposing, like, you want to make a custom input? Because that's, that's a huge use case, is a date picker web component.

• 33:29Speaker 01

  Right.

• 33:29Wes Bos?

  How beautiful would it be if we don't have to put all this junk on our page and just have a beautiful date picker input? How do you expose that to the parent form, then?

• 33:38Speaker 01

  Yeah, so form associated is like a static property that you set to true. And that is sort of the starting point to say that you have, say, like a custom checkbox or something like that. And it's actually, it needs to be like carrying a value with the form. And that value is going to be on the custom element itself, rather than like something deep in its shadow DOM.

• 34:01Wes Bos?

  Yeah.

• 34:01Speaker 01

  So just that, like that concept alone, I mean, to me was, you know, surprising. So it's that form associated, like read the docs on MDN about that, combined with element internals, which is a whole series of properties and methods that help you, you know, connect, connect elements for accessibility purposes and for form submission.

• 34:24Wes Bos?

  Oh, yeah, validity and.

• 34:26Speaker 01

  Totally, yeah.

• 34:27Wes Bos?

  Max and min.

• 34:29Speaker 01

  Yeah.

• 34:29Wes Bos?

  If you want to be, because sometimes you don't want to pass those things down, right? And then sometimes you do.

• 34:34Speaker 01

  Right. And the validity thing is, is pretty interesting because that lets you tie into the real CSS selectors for like valid, invalid, things like that. The thing about, you know, web components and custom elements is you're really building HTML elements, you know?

• 34:51Wes Bos?

  Yeah.

• 34:52Speaker 01

  And I feel like you really feel that when you get into the shadow DOM parts of it, because there's just so much to make sure is wired up properly.

• 35:00Wes Bos?

  Yeah. Yeah, I remember inspecting element on a video player or like, I think back in the day on Firefox, if you, if you open a video straight up in a tab, then you can inspect element and you realize, oh, the video player itself is just a whole bunch of HTML, you know? These are just buttons and event listeners and whatnot, but they've, again, abstracted that away into its own component.

• 35:22Speaker 01

  Totally, yeah. The one that I kind of get a kick out of is the HTML input elements. Like if you dig into them, they, you shadow DOM, and then you look inside and it's just a div.

• 35:33Wes Bos?

  Yeah.

• 35:35Speaker 01

  And even like the number input, like input type the number, even the little buttons in there, just divs.

• 35:43Wes Bos?

  Just div.

• 35:43Speaker 01

  Yeah.

• 35:44Wes Bos?

  Didn't even use buttons?

• 35:45Speaker 01

  No.

• 35:46Wes Bos?

  No.

• 35:47Speaker 01

  No. At least not in Chrome, they've been teaching, but yeah. You know, that varies across browsers, so.

• 35:54Wes Bos?

  Yeah. Wow, that's cool. And I want to ask about design systems because one of the most popular episodes we've ever done on this show was with Brad Frost talking about design systems. And the question people always have about design systems is how do I make it work across all of these different things? You know, we got four Vue, three Angular, seven React teams inside of our organization. How do I make this look consistent across them? And his answer was, we build them out in web components. I don't know if you've done any of that or have any thoughts on it.

• 36:27Speaker 01

  You know, I'm like at Squarespace, I'm on the performance team, so I'm not necessarily building design systems day to day, but I've certainly had a lot of experience in the past doing that. I saw Brad last week and yeah, he was talking about how they've sort of standardized on web components as the, you know, the leaf node or, you know, the the small unit that you would build in a design system and then combine them together. And I think they're a great fit for that. I mean, there's, you know, really good compatibility with frameworks now. You could speak to this a little better than I could. I'm not sure where React is with the latest 19 release or whatever, but they fixed a lot to be able to work with web components. A lot of companies are finding like this makes a lot of sense,

• 37:11Speaker 01

  you know, build the, build the little units using these. IBM is one, just in the past few weeks that wrote about how they're, they brought their web component portion of their design system into the, into the main repo and sort of endorsed it as the way forward from what I could tell from the outside anyway. So, yeah, I think it makes a lot of sense. I mean, you know, have them sort of isolated and handling their own behavior and, and still being able to emit events and receive configuration through attributes.

• 37:44Wes Bos?

  Yeah, I like that a lot, especially you mentioned React because.

• 37:49Wes Bos?

  React now, React 19, works well with web components and you can use the like React reactivity and just pass your your state variables to a web component and the web component will will update itself.

• 38:02Speaker 01

  Totally.

• 38:03Wes Bos?

  Which is really cool. So like if you are working somewhere where you think, okay, I need to make this semi-complex thing, but I I don't want to build it in in React because we have also has to work in Angular or whatever. It might be worth building it in in a web component, especially like if it's if it's kind of complex, you don't feel like like you're doing lots of DOM stuff. Sometimes it might even be easier to write it in vanilla JavaScript than to have to deal with all the refs headaches that you get with with React.

• 38:35Speaker 01

  And you know, there's there's some at least small degree of reactivity that you can get through web components APIs, like there's the attribute change callback. So you can sort of build on top of that to update, you know, make your own DOM DOM updates internally and maybe not rely on the outer framework to do that part. But the tools are there. I think it makes a lot of sense more and more, especially as you, you know, at some point, the framework of choice will change, you know, in the future. And these are built on standards. They're not going away, right? So they can go into the next, you know, next framework build. So exciting that they're finally starting to work.

• 39:15Wes Bos?

  Totally. That's the beauty of standards. I think like, like I've been watching web components for a long time and my I've sort of changed from like, I don't understand it to why is it not more popular? And now you're starting to see a bit more momentum to it. And I think if we land signals in the browser as like a way to do in the DOM parts, you said, as a way to do reactive UI, like that's a major part, especially if the performance of it is potentially better than like what a virtual DOM would be because the browser is is doing it, not necessarily just in JavaScript.

• 39:52Speaker 01

  Yeah. Yeah, I'm excited about that part because you know now like you know a lot of my work is in performance, right? And like for the last decade, we've been pretty focused on there is a lot of JavaScript in the way of rendering, right? Like we're we're generating too much content after delivery. And finally, you know, frameworks and everyone are starting to agree like that was that was a mistake. We're now we're delivering HTML popularly, right? And so the new sort of JavaScript centric problem becomes that that HTML that's being delivered, it's great, is now

• 40:30Speaker 01

  being chased by 2 to 10 megabytes of JavaScript for rehydration. And what happens is you see a very different experience across devices in how they handle that, you know, parsing that massive payload when it lands. The average, you know, Android device off the shelf these days is like five times slower than the nicest iPhone that we can buy. And I'm seeing UIs that, you know, are delayed by 10 seconds for interactivity after it looks, it looks ready to use, but it's not, it's not able to, you know, you're not able to interact with it for that long. And

• 41:12Speaker 01

  that's, that's just with like 2 megabytes of JavaScript. That's, and that's transfer size. I mean, that's a lot, but we're seeing a lot more than that, too. Like on very popular sites we all use every day. So I feel like that's the new problem, you know, like we got it out of the rendering path, but it's still there. And maybe these APIs are going to help us start to slim that down a little bit, you know?

• 41:34Scott Tolinski?

  Yeah. How are people really using web components, though, in their full site builds today? Like, are people, are you finding them that they're building them into component or framework based sites? Because I think one of the big things that a lot of people, you know, they they see their framework based sites and now you have, you get page changes without full page reloads, history API, all that stuff, right? But in in web components, right? Without a framework behind it, you're still getting full-page reloads, you're still getting these things. How are people building like sites today?

• 42:09Speaker 01

  Well, I think like you could look to GitHub as an example of a really complicated sort of app that is using web components and also quite a bit of, I think, React. And maybe more so, they're moving back towards React. But it's certainly they're orchestrating lots of little web components throughout the page. So that's one popular way that we're seeing them used. You know, I think a lot of ordinary websites are getting by without any, you know, single-page app orchestration of their web components too, right? Like a lot of, ideally, a lot of websites are using these in the same ways that we would have used any progressive enhancement sort of scripting in the past.

• 42:54Speaker 01

  Which I hope, you know, with better and better tools that are letting us deliver HTML from the server, that'll more and more become popular again, right? Because it is how browsers are designed to receive a website, right? Like they've got the preload scanner, they get this HTML and they're already busy like finding image references to go fetch and things like that. And anytime there's something in the way of generating that HTML so soon, it's, you know, that's a performance bottleneck, so.

• 43:26Wes Bos?

  So would you say that you're like a fan of the React server component approach? Where you simply just do it all on the server by default? And then sort of opt-in, make islands as you need interactivity, rather than the whole, just rehydrate the whole website?

• 43:42Speaker 01

  Yeah, absolutely. I mean, especially, you know, just conceptually. Like it's so, it's so good to see the React community coming around to this idea. But also many other frameworks are thinking similarly. And, you know, I mentioned like Enhance.dev, they have this great concept of, you know, being able to compose large-scale apps using custom elements on the server side. And you sort of like, you know, each file is a custom element. That might have some scripting or whatever associated, but you're you're composing with them. And ultimately you get a flat HTML file at the end, you know? I think in a lot of ways that's similar where you that the client side scripting is something you opt into. Right? And yeah, I'm thrilled to see that with React sites.

• 44:27Speaker 01

  And I think like, we could totally see a world where we're using web components to take the handoff from React server components and extend them when you need to, right? It wouldn't necessarily have to be React on the client, you know, it could

• 44:42Wes Bos?

  Yeah.

• 44:43Speaker 01

  custom elements.

• 44:44Wes Bos?

  We have Brian on all the time because we love to hear his opinions on things.

• 44:50Wes Bos?

  He's he's one of these people that's like very opinionated, but not in like a jerky way. Like, I appreciate his opinions, even if I don't necessarily agree with them. I always like to hear what he has to say.

• 44:59Speaker 01

  Totally.

• 45:00Wes Bos?

  And in one of his opinions is that you don't need a build tool. You just ship ESM straight to the browser. And I'm curious what your thoughts are on that, especially around like performance and waterfalls.

• 45:12Speaker 01

  Hmm, yeah, I don't know. I mean, this is stepping a little outside of like my day to day expertise.

• 45:18Wes Bos?

  Yeah.

• 45:18Speaker 01

  I don't know if I'd want to speak to it. I do think it's really interesting. And gosh, like when I was working on webpage tests, that is a PHP app and I would hit save and hit refresh and it was ready. And like the the speed at which we could move.

• 45:33Wes Bos?

  Yeah.

• 45:34Speaker 01

  Building new features was amazing. So I did not miss a build process there. But of course, there's, you know, there's some benefits to it. I feel like it just, you know, varies by your needs. Like, I think if you could have a mindset of not defaulting to like, all right, let's set up Webpack. I'm making a blog, you know, like that sort of mindset and and sort of like getting instead to a point where you're like, okay, this has reached a level of complexity where we need to build. That's a healthier way to approach it. They're certainly popular. People are using them for different reasons, but I do like the idea of, you know, trying to, especially like trying to run code, write code that's actually the code that you're running in the browser more and more.

• 46:19Speaker 01

  It's really nice.

• 46:20Wes Bos?

  DHH, the the guy who created Rails, kind of. Said this the other week as well is like just they don't run a build to or anything. They just ship ESM right to the browser and it works great. And obviously there's probably some downsides there, but because they're doing most things server side, they don't need a ton of JavaScript on there and you can, you can literally go to hey and whatever and view source on their JavaScript, see all the comments and it feels like the old web, which I very much appreciate.

• 46:52Speaker 01

  Yeah, I miss a lot of that. But a lot of the new web is kind of coming around to feel like the old web, you know, like a lot of these new standards just feel in that same spirit to me. It's, yeah, it's a fun time.

• 47:07Wes Bos?

  Especially all the, the new CSS stuff as well, you know, I'm sure you, you're happy about taking all the, all that stuff off the main thread, all the new CSS, like rendering the scroll animations, things like that.

• 47:18Speaker 01

  It's incredible. Yeah. View transitions that, I mean, a lot of people adopt single page apps to get transitions, right?

• 47:27Wes Bos?

  Yeah, right.

• 47:28Speaker 01

  So, uh, yeah, I mean, there's so much in CSS right now. It's, it's wild.

• 47:34Scott Tolinski?

  Cool. Well, now is the part of the show where we get into sick picks and shameless plugs. Scott, did you come prepared with a sick pick today?

• 47:42Speaker 01

  I did, but I kind of telegraphed it a lot already. I'm going to say it again. Yeah. Enhance.dev, I'm a big fan, you know, I got to collaborate with, with that team a little bit over the winter. I'm no longer affiliated, but I'm still like, I really think they've, they've come across some great patterns that even if it's not their toolkit that you end up using, just this idea of like thinking about composing with, with custom elements through the whole stack is super slick. So, uh, check them out.

• 48:13Wes Bos?

  The showcase is really fun to go through because you can, especially you look at one like Enhanced Movies, they kind of built like a Netflix style.

• 48:20Speaker 01

  Really well done. Yeah.

• 48:21Wes Bos?

  Like you think, ah, yeah, this is, this is, it's not going to be a good experience. Or you, you open up DevTools and be like, they gotta be bundling this. It's not.

• 48:29Speaker 01

  Yeah.

• 48:29Wes Bos?

  It's not. Look up DevTools and, and, and watch it. It's, it's wild.

• 48:33Speaker 01

  Yeah. And they have a Wasm build that lets you run Enhance on basically any platform. So if you go in their docs and check that out, you know, you can run it on Ruby, you can run it on PHP.

• 48:46Wes Bos?

  Oh.

• 48:47Speaker 01

  It's, yeah, that was kind of a game changer. And they were just releasing that as I, I was finishing up.

• 48:53Wes Bos?

  I don't think I saw this.

• 48:54Speaker 01

  Yeah, it's pretty, pretty cool.

• 48:56Wes Bos?

  The benefit there would be you can do all your templating, create all your custom elements and still server render, even if you're using PHP. Like it doesn't have to be a node environment, right?

• 49:07Speaker 01

  Yeah. And if you go to the, the GitHub repos for each kind of sort of flavor of it. It's pretty concise and it's cool to see like, you know, spaghetti-ish PHP and then, oh, there's a custom element.

• 49:22Speaker 01

  Yeah.

• 49:23Wes Bos?

  That's cool. I didn't realize they had done that. Wasm is so cool, man.

• 49:26Speaker 01

  It is.

• 49:27Wes Bos?

  It's unreal. You can just bundle it. Talk about bundling things up, sticking it in a nice package. Wasm is the custom element of the server.

• 49:36Speaker 01

  Yeah. Yeah. So check them out. High praise. Talented team.

• 49:43Wes Bos?

  And shameless plug. You can plug as many things as you like.

• 49:46Speaker 01

  Yeah. Well, we're hiring at Squarespace on the accessibility and performance team. So I would advise checking those out. Couple of senior engineer positions. So yeah, that's one. Also, you know, Wes mentioned it, but I have a course. It's very new still. Web Components Demystified. It's eight hours of talking about web components. All very deep. So also there's a, there's a coupon, Syntax. You can get 30% off. So.

• 50:17Wes Bos?

  Oh, sweet.

• 50:17Speaker 01

  Yeah. The word syntaxed.

• 50:20Wes Bos?

  Beautiful. Yeah. Thank you so much for coming on and, and sharing your, all your thoughts. It's good to catch up as well as learn a little bit about, I feel like every time we have somebody on about web components, I. Oh, I had no idea that was a thing. I had no idea that was a thing.

• 50:32Speaker 01

  It's moving so fast. Yeah. The community group is a great resource. They have a Discord. They're always looking for feedback. There's lots of proposals that are being discussed. Any feature that you're thinking, "Ah, web components don't do that. I like that part of the framework." They're probably thinking about that feature. So, yeah, definitely check it out.

• 50:54Wes Bos?

  That's the Web Component Community Group?

• 50:56Speaker 01

  Yep.

• 50:57Wes Bos?

  Discord?

• 50:57Speaker 01

  Yep.

• 50:58Wes Bos?

  Okay. Just making sure we don't link the wrong one up. Beautiful. Awesome. Well, thanks again for coming on. I appreciate your time and have a good one.

• 51:05Speaker 01

  Yeah, thank you both so much. All right.

• 51:07Wes Bos?

  Thank you, God.