Web Components Can’t Save Us with Scott Jehl

Welcome to Syntax. Today, we've got an episode for you today on mostly web components, and, I think we're gonna title this one, web components can't save us, because we've got Scott 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 it feels like 13, 14 years. I I remember taking a bus to jQuery conference together many, many years ago, and it's, it's kinda 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. Hey. Thanks, Wes. It's, it's really nice to be here. I listen to the show all the time. So and and good to see you, Scott.

Yeah. Likewise.

Yeah. 2 Scotts. I don't think we ever had 2 Scotts on, have we? I don't know. Yeah. This very well may be a first. We've never had another Wes on it. Really? Yeah.

You wanna give people just a quick rundown of your background? Because, like, I know from way back when, you were you're pretty early in, like, the responsive design

scene, and then you've had several jobs since then. Yeah. Yeah. That's right. I guess I could I could start from way back and, 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 some yeah. Long long term for, for our industry.

But it was great. You Node, we had, just an array of amazing clients throughout that time. We got to build the the Boston Globe's 1st 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. 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.

So it's way back.

Wow. Yeah. So 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 I ended up doing a lot of performance work to the point that, you know, at at some ESLint, catch point, the company had acquired, WebPageTest, the product Yeah. And, you know, free, WebPageTest Wes 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 catch ESLint for a couple of years, and we built the 1st commercial addition to the product that they had, which was called WebPageTest Pro. And it was pretty fun. You know? It 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.

Yeah. And, yeah. So that was pretty neat. After that, took a little time, freelancing, worked with the folks at Begin, and they do, enhanced Scott 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 companies in the world are adopting it now. So, Yeah. So that that was great for exposure. And then, and now I'm at Squarespace. I've been there for, 3 months now pretty much. Right on. It's fantastic. I mean, I 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 1 client at a time. So the scale is is pretty inspiring to me. Yeah. Yeah. That's wild. I I often talk to people, like

I don't wanna name a competitor, but I've talked to some of the folks at at Wix as Wes, And it's just a scale that these things are are running at. You know? Just a couple bytes here and there could be

serious bandwidth savage Mhmm. Over over the scale. Yeah. Savage. 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, man, that thing was huge.

That's a great story.

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 Marcotte worked with us. Mhmm. In house at Filament Group, the team at Filament, Upstatement did all the the design work. They're just a fabulous design shop.

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

it's, like, early days of It was very mobile devices. Right? Like, we had those big, mobile device walls where you would Totally. Test on every single device. And, like, I yes. Sure. I don't I don't know that we'll ever have that big of a shift

in how we consume media. Yeah. It was amazing. I mean maybe VR, but I don't know. Yeah. Yeah. Maybe. Yeah. Filament had a physical Vercel lab. You know? I remember Matt Marquis was, or Marquis, I think, is the, 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, quite quite JS, commonly then. I I think they were around, but, yeah, just that was that was wild times. I had a Vercel had too. I made my own out of wood and had all the USB,

hubs powering. I I just, like, went to my Sanity. Like, give me all your old phones, please. Let me just put them on a big wall here. Yep. And I forget who it was. Somebody made software that, like, kept them all in sync a little ways into there when the DeviceLab was still set up. Browser

what was it called? Remind in browsers.

Browser not Browserify, not BrowserStack.

There was a I still have it in one of my courses. Browser Oh, yeah. It basically it synced all the clicks across and all the scrolls and I don't know. Yeah. That was pretty cool. I I look back at the very fondly at those years. Really, really fun time of the year. Deno down. Yeah. Totally. 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 Twittersphere, 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 Wes components is it. Scott and I talked to a lot of people from Shoelace or the the Wes Awesome folks. Yeah. Right. All pretty pretty bullish on them as well. I'm curious to your thoughts on them. And, obviously, you have a a course on them as well, so I'm assuming you like them.

Yeah. Well, I mean, partly, I 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 Node? 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'd 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'd I'm a big fan. I'd I feel like, I've followed some, not all, of the drama 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 in 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 1 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 structure much like, you know, maybe, like an import sort of, mindset, works when you're dealing with components in other in 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 Yeah. A lot more use out of parts, some parts than other. 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? 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 the, I think, the killer feature of them is that we now have somewhat of a a 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, 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 JS 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 that you wanted to do, and then you've got this beautiful life cycle that, oh, this thing just appeared in the DOM. Well, let's apply some behavior to it. Mhmm. You know, things that just weren't weren't quite so elegant in the jQuery days when we were, like Yeah. Waiting for the whole DOM to be there. 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 formatter HTML component, which essentially is instead of, like, wrapping let's say, for example, this project has 428 1,482 downloads. Right? Mhmm. 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 I n t l dot number format APIs, and you sort of break the flow of of HTML. Yeah. 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? Right. Right. 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. Yeah. And I thought that was kind of a just a beautiful way to, like, keep the declarative nature Mhmm. Of HTML without having to do a whole bunch of JavaScript every single time you want it. 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. Yes. You know, if the script happened to fail the Node or had an error or whatever happens. Still a number. That reminds me of, like, GitHub has lots of these little patterns throughout its UI.

Like, the little time stamps 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 time stamp, 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, 3 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. I didn't even realize 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. Yeah. They're all over GitHub's UI. I've used a lot of their examples because they they've published a lot of those too, you know, open source, and they're they're really good. 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? Yeah. I mean, I feel like, you know, a 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 in 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 it that I was looking for, some someone like, like Bos looks pretty attractive. I also feel like a lot of, you know, a 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, whether they often built them themselves or, are referencing, others out there. So, yeah, yeah, I feel like there's just a lot of very good example of Jeremy Keith JS another just posting, good examples a lot. All in this sort of, like, HTML web component sort of pattern, like, like Wes was just talking about. Scott something, make it a little better. Yeah. Totally.

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 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? I mean, currently, I feel like there are very good small libraries that can give you that toolset.

You know, I mentioned enhanced .dev. They have some nice base libraries or base classes rather that build on, on web components and offer that reactivity. There's, Wes that works with, static generated sites and Node d 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 the real time UI React sort of use case. So those are there. On the standards front, like, you you talk about things like signals a lot on your show. I feel like that that's within the web components community.

It's signals and DOM parts, right, that are, like, going to be the the 2 standards that potentially figure out this this problem. And those aren't necessarily, like, part of web components, like 3 tiers or whatever. But I you know, it's like, these are all stand alone, you know, standards that can work independently or together. What is DOM parts? I've not not heard of this. 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 Node, 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 ESLint, 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 Wes, especially if the HTML comes from the server and you wanna update it with the rehydration kind of thing. I think the their explainer is pretty long, and I'm it's been a little while since I've looked at it, but I know that's JS of even today. I was, I was talking with someone over at the at their group about that still being sort of where you'd you'd point someone, for that. Neat. Oh, okay. So this this is what I was hoping for. This is It look great. Right. 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. Yeah. It's what we've wanted

for a while. Right? Something like that. Yeah. And 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 it that's fine, but it's not it's not what people coming from frameworks are used to. Yeah. Well, that's exciting.

It also I mean, it's not directly related, but have you seen the the invokers stuff? Yeah. Totally. Yeah. That's kind of remind 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.

Right. Right. 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. Totally. Yeah. And we're seeing just so much more of that. Like, pop over is Scott 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 TypeScript. So it's pretty exciting. Let's talk about styling,

in web components world because How long is this podcast? Wes we go for about an hour, but that that's also often a pain point in in the web component world is web components are entirely encapsulated.

Mhmm. 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 Yep. 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?

Yeah. For the most part.

Okay. 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 Yeah. 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 and, you know, even JavaScript is sort of optionally encapsulated. Right? So, like, you you can have a closed shadow root, which is for 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 close 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 reference an external style sheet,

reuse it across your page in many shadow domes. That works great now. So that's that's like a a good pattern, I think. Let's stop on that for a sec because I think that's a pretty nifty or or interesting way is you can literally just link your CSS sheet in every single component.

Yeah. And even if it's linked in the parent, it's not gonna redownload the CSS

Right. 3,000 times. Thankfully, that's fixed now. Okay.

It's

You're stupid.

So what are the options of if somebody has an existing CSS, and they're like, I just want my website styles to apply to my web component, they can simply just link up the same style sheet, and then all of those will, styles will be available? 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 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 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 you've probably talked about the colon host selector Wes 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, within the DOM, it 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 Yeah. Customization.

You Node, that works just like in Vercel SVG files too. Like, it it's kinda similar with the Shadow DOM. Those custom pop properties pass through, and you can offer up configuration like that. And if you want to see all of the errors in your application,

you'll want to check out Sanity at sentry.i0forward/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 to reduce entry Scott I o forward slash syntax. Again, we've been using this tool for a long time, and it totally rolls. Alright.

Is that how you're often seeing people, offer? Like Yeah. Sometimes I wonder, like, if I hit it, sometimes a web component, and it feels like they've just, like, reimplemented CSS and cut, like, a 1000000000 custom properties to let you Yeah. Get control over it. You're right. But it, like Dash dash font family.

Yeah. Is that the best way, yeah, to build, like, a interface there? Good way. Like, for example, we mentioned, like,

TypeScript 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 that 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 shape or something like that. Right? So and I think that's like a smart use of Shadow DOM in particular Wes, you know, maybe you have a video player that goes on, like like, Vimeo or 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.

Yeah. That's we would often just use an iframe for that. Exactly. Yeah. I mean There's there's nothing available. Right? Maybe you don't need that.

Yeah. So this would, you know, allow you to at least, you know, piecemeal offer some configuration, in the layout or, you know, whatever you wanna use custom properties to do. Node pattern that I didn't mention that I think is kind of an interesting one, 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 Yes. Taken away from us for a while in the standards and in the browser support. Can you explain before we even get into the web components, you sent me a note about that, and I was like, responsive video? Yeah. I don't know I know what that is. Can you explain that? That's fair because I kind of made up the word.

Yeah. So, you know, if you think about responsive images, you have the picture element.

This is very much a parallel in in with the video ESLint. So when HTML 5 first landed in, web standards, we had the video element pnpm, which included media queries on source elements ESLint the video element.

So that was supported from the start. You could put on each of your sources inside a video. You could put at media, you know, min width 500 pixels or whatever, for 1 source, and then, and then another that would it would fall back Tolinski 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. And when it was, you know, I don't know, like, 2014, I guess, when we were starting to work on, specking the, responsive images, you know, syntax that would ultimately land in the browsers. And picture was designed based on this cool aspect that worked in the video elements. We warp like, the video works this way. We should really Oh. You know, picture should should should have media queries like that, right, for our direction. Mhmm. Mhmm. 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?

Yeah. Yeah.

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 the feature from video and from the standard. So it was pulled from the HTML 5 flipping standard, for video, and all the while it was landing in the same feature and picture.

Oh, wow. Okay. 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 wanna build this back in. I just had to quickly learn some c sharp and get this, get this landed back in Firefox.

The Chrome team got their support back in overnight. It Wes kind of embarrassing.

Man. The market ticked me. And yeah. And and the standards Wes updated. So we have that back in browsers now. So if you wanna serve We have source set on video. I I set. Not source set. Sorry. Source set. Just, media attributes on on source elements. So, like Media attributes. Yeah. Write a media query? Yeah. Exactly. So, like Okay. You know, a lot of more and more video is streaming now. But say you had a a blog post and you've got a local video file and you just don't wanna serve the massive one to a phone, you could use this to, you know, to serve responsibly.

Yeah. Or or even, like, different aspect ratios because whenever I do do a TikTok video, I'll edit it in portrait. Yeah. And then I'll in this make a second cut of it in square.

And I just post them to different platforms assuming most people on Twitter are gonna be on their desktop. You Node? TikTok, they're gonna 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 Node the person based on The right one. Screen they're on. Yeah. So that's it. And then 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 Yeah. 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. You know? You have to sync the time code if you're switching sources on resize, but, you know, it's relatively like, it's 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, custom elements dot 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 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 Yeah. You know, fail silently.

I think that's a cool use case for polyfills.

I'd like to see more of it. But Yeah.

Yeah.

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

But No. I like it. That's I like it. Also talk a lot about Max's implementation of their video player and 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 Max has this amazing player. They have a Well dedicated website for it. What is it? Mediacrome. But most importantly, Wes, is that it supports streaming and all the, you know, HLS and all that stuff out of the box. So you can Wes, essentially, a video element and pass pnpm m three a u and have it work like a HTML video element.

Yeah. That's great. Yeah. Just tucks all the complexity into a element.

And then, like, you, the user, don't have to do a whole bunch of JavaScript Wes 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 or the thumbnail.

Mhmm. It's a pretty nifty implementation.

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?

Mhmm. 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, 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, 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. Yeah. Totally. You Node, 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 it's like you're really buying into a more you know, like, you know, a deeper situation. Like, if you have a 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. Yeah. Oh, yeah. Yeah. Yeah. I could see. That could be a pain. Yeah. And there are APIs for this stuff, that come with the web component pnpm. So it's totally workaroundsable.

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 four attribute and an ID.

They don't know about each other if they have to cross a shadow root. So accessibility JS broken if Yeah. 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 Wes you adopt shadow dom. So I think some of those, it would be nice if they the problems weren't there in the 1st place to to get people. Yeah. Those paper Scott, especially if somebody's like, alright. I'm gonna try it. And then they're like, this this is odd. You know? It's 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. Yeah. What what is the process for exposing? Like, you wanna make a custom pnpm, because that's that's a huge use case JS a date picker, web component. Right. 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? Yeah. So form associated

is like a 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. Yeah. So just that, like, that concept alone, I mean, to me, it was, you know, surprising.

So it's that form associated, like, read the docs on Npm 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.

Oh, yeah. Like, validity and, Totally. Yeah. Max and min and, yeah, if you wanna be because sometimes you don't wanna pass those things down. Right? And and then sometimes you do. Right. And the, 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? And 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 JS wired up properly.

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. Totally. Yeah. The one that I kinda get a kick out of is, the HTML input elements. Like, if you dig into them, they Wes Datodom, and then you look inside, and it's just a div. Yeah.

And even, like, the number input, like, input type of number.

Even the little buttons in there, Just divs.

Just divs. Yeah. Didn't even use buttons? No.

No? No. At least not in film, film will be teaching. But yeah.

You know, that varies across browsers. So Yeah. Wow. That's cool. And Yeah. I wanna 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, how do I make it work across all of these different things? You know, we got 4 Vue, 3 Angular, 7 React teams inside of our organization.

How do I make this look consistent across them? And his answer Wes, we build them out on web components. Yeah. I don't know if you've done any of that or have any thoughts on it. 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 the latest 19 release or whatever, but they fixed a lot to to be able to work with web components.

A lot of companies are finding, like, this makes a lot of sense. You know? Build the build the little units, using these. IBM is 1, just in the past few weeks that wrote about how their, they brought their web component portion of their design system into the into the main, repo and and sort of, endorsed it as the way forward, from what I could tell from the outside anyway. So That's cool. I 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.

Yeah. Yeah. I I like that a Scott, especially you mentioned React because React now and React nineteen 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 Totally.

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 wanna build it in in React because we have it 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 kinda complex, you don't feel like like you're doing lots of DOM stuff. Mhmm. 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.

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, the, you know, next framework build. So exciting that they're finally starting to work. Totally.

That's the the beauty of standards. I think, like like, I've been watching Wes components for a long time, and my I've I've sort of changed from, like, I don't understand it to why is it nor not more popular.

Yeah. And 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 a way to do in the DOM parts you said JS a way to do reactive UI, that's a major part, especially if the performance of it is potentially better than, like, a what a virtual DOM would be because the browser is is doing it, not necessarily just in JavaScript.

Yeah. So

we'll see. 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 Mhmm. We're generating too much content after delivery.

And finally, you know, frameworks and everyone are are starting to agree, like, that was that was a mistake. We're 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, that's great, is now 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, 5 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 Really? After it looks it it looks ready to use, but Yeah. It's not Yeah. It's not able to you know, you're not able to interact with it for penetration. For that long. And 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. Yeah. Like, I'm very popular sites Wes 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 gonna help us start to slim that down a little bit. You know?

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? Mhmm. 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?

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, you know, that's one popular way that we're we're seeing them used.

You Node, 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, which I hope, you know, with 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 it is how browsers are designed to receive a website.

Right? Like, the 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 So would you say that you're, like, a fan of the the React server component approach Wes 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.

Yeah.

Absolutely. I mean fan. 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 are thinking similarly, and, you know, I mentioned, like, enhanced dot dev. They have this great concept of, you know, being able to compose large scale apps using custom elements on the server Node. And you sorta 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 the the client side scripting is something you opt into. Right? And, yeah, I'm thrilled to see that with React sites. And I think, like, we could totally see a world where we're using web components to take the handoff from React Vercel components and extend them when you need to. Right? It wouldn't necessarily have to be

React on the client. You know? It could Yeah. Custom elements. We have Brian on all the time because we love to hear his opinions on things.

He's he's he's one of those 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. Yeah. Totally. And in one of his opinions is that you don't need a build tool. You just ship Wes straight to the browser. And I'm curious what your thoughts are on that, especially around, like, performance and waterfalls.

Yeah. I don't know. I mean, this is stepping a little outside of, like, my day to day expertise. Yeah. I don't know if I'd wanna speak to it. I do think it's really interesting and gosh. Like, when I was working on web page test, 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, you know, 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, alright. Let's set up webpack. I'm I'm making a blog. You know? Like, that Scott 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 warp and more. It's really nice.

DHH, the the guy who created Rails, kinda said this the other week as well. It's like, just they don't run a build tool or anything. They just ship Wes m right to the browser Mhmm. And and it works great. And, obviously, there I 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 it feels like the old web, which I very much appreciate.

Yeah. I miss a lot of that.

But a lot of the new web is kinda 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. Scott it's, yeah, it's a fun time.

Especially all the the new CSS stuff as well. You know? I'm 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. It's incredible. Yeah. View transitions that all Node. I mean, a lot of people adopt

single page apps to get transitions. Right? Like, that's all. Yeah. Yeah. Yeah. Right? So, yeah. I mean, there's so much in CSS right now. It's it's wild.

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?

I did, but I kinda telegraphed it a lot already. I'm gonna say it again now.

Yeah. Enhanced dot dev, I'm a big fan. You Node, 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,

check them out. The showcase is really fun to go through because you can especially, you look at 1 like enhanced movies. They kinda built, like, a Netflix style thing. Them. Yeah. Like, you think, oh, yeah. This is this is Mhmm. It's not gonna be a good experience, or you you open up dev tools and be like, they gotta be bundling this. It's not. Yeah. It's not. Look up dev tools and and and watch it. It's it's wild. 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, it you know, you can run it on Ruby. You can run it on Pnpm DB. Oh. It's yeah. That was kind of a game changer, and they were just releasing that as I I Wes, finishing up I don't think I saw you. Yeah. It's pretty pretty cool.

The benefit there would be you can do all your templating, create all your custom elements, and still Vercel render even if you're using PHP. Like, it doesn't have to be a node environment. Right? Yeah. And if you go to the the GitHub repos for each

Scott of flavor of it, pretty concise. And it it's cool to see, like, you know, spaghetti ish PHP, and then, oop, there's a custom element.

Yeah. That's cool. I didn't realize they had done that. WASM is so cool, man. It's It is. Unreal. You can just bundle. And talk about bundling things up and sticking it in a nice package.

WASM is the custom element of the server.

Yeah. Yeah. So check them out.

Sweet. High praise. Talented team.

And, shameless plug. You can plug as many things as you like. Yeah. Well, we're hiring at at Squarespace on the accessibility

and performance teams, so, I would advise checking those out. Couple of, senior engineer positions.

So, yeah, that's Wes. Also, you know, Wes mentioned it, but I have a course.

It's very new still. Web components demystified.

It's 8 hours of talking about web components all Nice.

Very deep. So, also, there's a there's a coupon syntax.

You can get 30% off. So Oh, sweet. Yeah. The word syntax.

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. Moving so, so fast. Yeah. 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, web components don't do that. I like that part of the framework. They're probably thinking about that for that feature. So,

yeah, definitely check it out. The web component community group Yep. Discord? Okay. I'm 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. Yeah. Thank you both so much. Alright.