The Good, The Bad, and The Web Components

How's everybody doing? Got some coffee? Bruce, I guess we're old friends. Great. That's awesome to hear. Well, you couldn't really tell by that introduction, but that's fine. Bruce and I get along really good.

All right. So today we're going to talk about web components. They're good. They're bad. Hopefully, not ugly. So, yes. Web components. Animations. Gotta love it. Web components, right? I don't have to convince you all that components are good, right? Components. Yay.

All right. Here is an example of a component. Look at that. It's a button. Woo-hoo! Thank you. That's been my time. Yeah. So we have our nice JavaScript up top. We have our JSX on the bottom. This is great. And some of you might be familiar with what this example comes from. It's from Vercell.js.

So if we look at some of the other component libraries that exist right now, there's a ton of them, right? There's a ton of component abstractions that exist in the space. But today I want to talk to you about Web Components.

So Web Component is a piece of reusable UI, it's enabled by web standards. It's built into the web platform. It's provided to you for free by web browsers. And really the benefit here is you have the potential to initialize your components faster and run with less library overhead, which is great.

So as Bruce introduced, my name is Zach. I blog on zackleet.com. I built Eleventy, which is a static site generator. And I work at Netlify. And just to kind of convince you that Web Components are a thing that you should care about, I'm going to show you some examples. Hooray. This is peer pressure. This is social proof. And after these four or five slides, you all are going to be convinced that Web Components are amazing. So let's get into it.

Web Components, really the bread and butter of Web Components right now is design systems. People love the portability of Web Components. They love that they're built into the platform. And that's really where the most examples you'll see of them are in the wild. Microsoft built MSN with Web Components. VMware has a nice design system. Google has material design which exports to Web Components. IBM has one, Salesforce. My personal favorite, Nord Health built with 11-D is a really good example of that. GitHub uses Web Components. Adobe actually brought Photoshop to the Web with Web Components using Lit, which I think is great. And that's using Spectrum Web Components which is a wrapper around Lit. So are Web Components a thing? Look at all these logos, logos, logos, logos. We love logos. Does that really convince us that things are good? Yes, I think so. If you go out to Google Chrome's Web Statistics, they have as of April of this year, measured that 18, almost 19 percent of page loads in the Google Chrome Web Browser are properties using Web Components.

So pretty popular, amazing. That's convinced you all that they are good and should be used because they're popular, right? Component libraries are sort of adapting to Web Components as well. But today we're going to kind of go through how to create a Web Component from scratch so you know how it works, you can build it, you can utilize the unique power of them. But these component libraries, animations, some of them also include options to export to Web Components directly. And I think that's great too because we can reuse the existing patterns we have for our library and framework code and export to Web Components to use in the wild.

So, what are Web Components? What are they? Here is a Web Component. Woo! Just as good as that button example I showed earlier. We have the sort of a ubiquitous counter component that folks love to demo. This is called a custom element and this is what it looks like when you demo it, right? You have this lovely counter that counts up when you click the button. Incredible code. We love it.

And this is what it looks like when you add a button to the example. This is the default slot, the child component of a custom element and we just added a button here. This is called light DOM but I just call it plain HTML because we don't need fancy words for things that already exist. And this is what the JavaScript looks like for a custom element. So we have, when you use our custom element registry, we define what tag name we want to associate with that and then we pass in a class. So what happens with the custom element registry is anytime the browser encounters a my counter element on the page, it doesn't need to exist on initial page load, you can fetch it in later. Those will be enhanced or hydrated using web standards. And this is all provided to you for free by the web browser. There are some minor limitations here with custom element registries. You can't define an element name that doesn't have a dash in it. So if you have an element like this, you need to add a dash. Amazing. And the reason that limitation exists is because you don't want to overlap with existing HTML elements that exist as part of the web standard.

So to make this example a little bit more fleshed out, let's add some additional JavaScript to actually increment our button number. The number that renders on our button. That's what this looks like. So we can have any number of myCounter elements on the page, and they'll all be enhanced using this mechanism. So you click the button, and you increment the number inside of it. Amazing. So the way I like to evaluate how components load, and this really kind of dovetails with Barry's talk earlier, we really want to put as much into HTML as we can. So the thing I like to do when I'm evaluating the performance characteristics of a library or a framework, I like to look at what it can look like before JavaScript has initialized and what it looks like after JavaScript has initialized. And we kind of want to minimize the amount of layout shift that happens there. And so with this example specifically, there's no layout shift before and after because we didn't do any DOM modifications. All of the HTML that's rendered is the same as the HTML we're using in our page.

So in a way, this pattern is exclusively server rendered. We didn't do anything but add a few event listeners here. We're not using any library JavaScript, there's no library overhead, and we can have nice progressive enhancement without any layout shift which is great for a core web vitals as well.

So there are a few web components that I built in the wild that kind of reuse this pattern. There's a details utils component that I built to sort of add additional behaviors to your detailed summary elements on your page. And you can go and check that component out if you're interested in it. This one just adds a behavior to close the details element when you click outside of it.

In this example, I have a video radio star component that only plays a video element on the page when it's visible, which I think is a nice pattern, especially when you're you don't necessarily want to play all the way through before the user has even encountered them on the page. So we want autoplay, but only when the user scrolls to it. So in this way, we're enhancing existing HTML that is the child of our web component.

And another example that I have here on my Github is a is lan component. And now Astro is a very popular component framework, or a popular framework that really relies heavily on islands architecture, which is just kind of spicy, fancy, lazy loading, which I know is maybe a controversial thing to say, but I'll say it anyway. So yeah, there's an is land web component that does something very similar. So any web components that are nested inside of this is land component are only initialized when they're visible to the end user, which I think is great. And there's a bunch of different mechanisms to that, too. You can only do it when it's idle, you can do it when save data is enabled, you can do it under media queries, or only when the user has interacted with it.

Now, the problem with this pattern here is that all of the content inside of our web component is sort of repeated. So the authoring experience is not great, because we really don't want to have to nest all of this repeated HTML throughout all of our content. So my number one grievance probably with this pattern is that I do have to duplicate this HTML myself, unless I have an existing library or framework on top to do that for me. And I don't like to repeat myself. And I don't like to repeat myself. So when we have three counter instances on the page, this is kind of what the authoring experience is of what I'd expect or what I'd want to do. I want the unique things inside of the component instances. I don't want any repeated things that I have to manage myself.

So to do that, we have to graduate to a level two of Web Components and go to use ShadowDOM. So ShadowDOM is a way to have a reusable template that you can inject yourself in JavaScript. And this is what this might look like. So we have a template element on our page. We have our button inside of it. We have our slot.

And then the default slot, or the light DOM or the plain HTML, that's nested inside of our component instances, gets slotted into that content. And so I've kind of grayed out the code from the previous example. And you can see the new code that we've added just to inject the ShadowDOM template. So it's just a couple of lines. We find the template element, we attach it, and that's kind of it.

So, in that way, we get the benefits of not having to repeat our button element in every instance of our component. And the content is slotted for us automatically. But, going back to our pre-JavaScript and post-JavaScript experience, depending on where we run that custom element registry code, this could interject some layout shift because the content that was available to the component before JavaScript was initialized was just a number. And after the component is rendered using ShadowDOM, it's a button and a number inside of it. So in that way we have a client JavaScript rendered component. The benefit here is that none of the content is repeated. And we, again, don't have any library JavaScript, that's great. We're not repeating ourself in our component instances, but we do have a higher risk of layout shift happening.

So in CSS, we actually have a hook to control styles before a component registry is available or before a component is initialized in our registry, and after. So this is a great hook to say I want to render my component a certain way before and after it's initialized. Because really, I don't want any JavaScript in my critical rendering path, I want my page to be as fast as possible. And some existing component libraries that I linked to previously in this demo, and I'm not going to necessarily name names unless you find my speaker notes here, they use this mechanism to hide the component altogether. So this still has some layout shift when you're doing content or JavaScript manipulation of the DOM, excuse me. So I wouldn't recommend sort of doing this, if we can get away with it, because, again, it creates an additional JavaScript dependency on your styles. If JavaScript fails or your JavaScript doesn't run or you get an error on your page from maybe a browser extension, your page is going to be invisible, which is not great. Here's another example from another unnamed component library in the wild with Web Components. They're just toggling opacity here. So I guess this is maybe part of my brand, if people are familiar with my extensive work on social media, very relevant work too. Just JavaScript is a grievance here. We don't necessarily want to require JavaScript to have a full rendering of our Web Component. And with Shadow DOM that is a requirement. So how do we work around this? Hey, there's a new specification, level three, declarative Shadow DOM. We can actually use the template and the browser will inject that template into the Shadow DOM for us. So this completely alleviates the JavaScript dependency that we needed from the previous example and we get the full benefits of Shadow DOM. So this is what your component instance might look like.

And so, our before and after JavaScript experience here is very similar to the first level when we just did a custom element and we repeated our HTML in all of our component instances. In this case, we're only repeating our template. But I'll get to that later. And this is what the polyfill is for existing browsers that do not have declarative Shadow DOM, which is currently just Firefox. This is what the polyfill looks like to add support for that. Now, of course, a polyfill is just another JavaScript dependency here, which we don't necessarily want. But this will go away over time, which is great. But the sooner Firefox can add support for declarative Shadow DOM, the better off we'll So, with Web Components, with declarative Shadow DOM, we do get server-rendered components. We aren't using any library JavaScript here. The polyfill is only a couple of lines, as you see. So even in Firefox, it's still pretty small, although it is JavaScript rendered in Firefox until they add support there. We do get full encapsulation of our components. We get progressive enhancement without layout shift. But the only problem here is that we're repeating ourself pretty badly. It's almost worse than the first example. So when you have three different instances of our counter component with declarative Shadow DOM, all of this stuff is repeated. You have to repeat the templates in every instance, and that's to enable streaming behavior, because you wouldn't necessarily want the template to be not available when the component instance is.

Now, the benefit... One of the easiest and most... The easiest communicated benefit of using Shadow DOM, either with a JavaScript dependency or declaratively, is that you have scoped CSS. So you can nest a style element inside of your Shadow DOM template, whether you do that declaratively or not. And all of that component styles are scoped to just the component, which is amazing. And this color blue assignment will only be scoped to our counter instance. And you have a few other CSS property... Or, excuse me, CSS pseudo classes that allow you access to those things as well. You can say, I want colon host, which gives you access to the tag name. You can put an additional selector on host, and you can add host context, which is almost like a parent selector. We're coming back to repeating ourselves over and over in these templates. We don't want to have to nest our scoped CSS in every component instance as well. That is so much worse. So in a way, there's almost this standoff between not repeating yourself and getting full server-side rendering support. And sort of the elephant in the room here, in this example, is JavaScript. We have a JavaScript dependency that gives us the ability to not repeat ourselves in all of our component instances, but if we want to remove that JavaScript dependency to get as fast of a loading experience as possible, we have to repeat ourselves and repeat those styles and templates in every component instance. So we're going to graduate to level 4, which is how to add server side rendering without repeating ourselves. And so if you look at this previous example where we had our declarative Shadow DOM nested in all of our component instances, you can kind of see that we want it to exist like this. We kind of want a reusable template that we can re-assign to a component definition, and have that handled for us by the web browser. Now there's some problems to solve with streaming there, but I think that that's a thing that is coming to the web platform and I've linked up with super tiny text there, a URL if you want to see the ongoing discussion of that. But the crux of the situation is that SSR is not really sufficiently solved by the platform yet. I think it's coming, I think we'll get there, but component frameworks have not solved this problem as well. They are sort of beholden to the same limitations as the platform. So I think the important thing I'd like to communicate here is that we shouldn't hold necessarily web components to a higher standard than our existing JavaScript frameworks and component libraries that we use today. And historically, it's sort of been very adversarial, right? JavaScript frameworks have been sort of against web components and maybe the most vocal critics of web components. But I think there's some very unique benefits that we can get from web components, specifically just the custom elements registry that can be leveraged very nicely by JavaScript frameworks. And so, just going through the framework libraries that we sort of talked, the logos that we looked at before and in the bottom left you can kind of see that what some of these component frameworks have SSR targets or excuse me, have compilation targets for web components. And then in the top right, there are sort of first party web components. So you author things and web components land and then SSR is sort of an added-on feature on top of that. And then the bottom right, there's a WebCE and enhanced.dev, those are sort of two existing frameworks.

I work on WebCE, enhanced.dev is another one that I've really tried to make the SSR story and web components SSR first rather than a bolted-on feature later. And if you want to sort of check out the compatibility with existing component frameworks and web standards, you can check out customelements everywhere.com with dashes in between the names. The spoiler alert, React is the only one that's being actively maintained that has failures on these tests which is unfortunate. Hopefully, it will come in React 19 but I am not holding my breath.

Okay. So, again, SSR sort of supported for web components with these component frameworks that have web components first, your authoring and web components, Lit and Stencil are two examples of that. And Enhance and WebC are sort of taking a different approach. We want the SSR experience to happen first. So I am just going to go through a super quick example of WebC component. This is what the authoring experience looks like in your template. And then you have a component definition on the right. And so we don't have to repeat ourselves but we still get the full benefit of declarative shadow DOM and it will render the output to you. We'll repeat it in this way, but you don't necessarily have to do that in your authoring experience. You still get a nice authoring experience. And there's another way to do it in WebC as well. You can sort of compile to regular HTML. So you can sort of compile to level one of the examples that we showed today. And this is the output you'll get from that example. So in this demo it's very svelte-esque in the compiler output. So using ssrfirst component libraries, we do get the benefit of server-rendered, streaming-friendly HTML. We don't have any library JavaScript. There's no sort of extra JavaScript library overhead there. We can encapsulation, we don't repeat ourselves, and we get good progress enhancement. If you want to try out WebC, there's a good starter project on my GitHub, on the 11 GitHub to do that. But really, the main thing that I think Barry really drove home today is that if you can do it in HTML, it will be faster than JavaScript. And I think that has really proven itself true if you've tried to use CSS and JavaScript libraries in the last couple of years. So thanks for listening.

Firstly, because you said that you're feeling bad because nobody at this conference has a framed photograph of you, anonymous said, no question, just wanted to say the presentation is top-notch. Thanks, Zach. Wow, okay.

So, yeah. Ten out of ten. We'll do business again. Yeah. A round of applause to Mrs. Leatherman for submitting that.

Dip asked, how do you deal with collisions in handling multiple versions of a web component the same page? Yeah, I mean, there is a coming specification that's scoped element registries and so that will be a sort of way to handle same component name on your page registered multiple times, so that is coming. Those component tag names are sort of global right now, but that's a problem that will be solved in the future. Scoped element registries was his name? Yeah, I think so. Blimey. I suspect that I haven't heard of this increasing amounts of them now.

Talking of component names, tell us briefly about the hyphen in the names. What's that about? Yeah, so you need to add a hyphen in your tag names so that it doesn't conflict with current and future additions to the HTML specification. So I think that's an important limitation because we don't necessarily want our custom elements to collide with HTML elements they add later. But I mean, additions to HTML seem to be happening pretty slowly. I think CSS right now is just incredible how things have sort of ramped up and how they're shipping things very quickly in CSS land. So hopefully more things will come to HTML as well. So basically the dash in the name is because the W3C and WOTWG have said that they will never invent a core HTML tag with a hyphen in its name and therefore, it won't collide.

What about the attributes? What about them? Do they have hyphens in them? Oh no. You can name them whatever you want. Yeah. And I don't even think they need to, if they're on a custom element, I don't think they even need to have the data prefix that is common in existing HTML patterns. So go wild on attribute names, woohoo. Go wild on attribute names, you heard it here first party people.

There's an interesting question that might have actually disappeared. But it was simply, why do developers spend so much time worrying about things that are not important? I don't really have the context of this. Now, what? There's two different ways I can take that question. The first way is that the entire talk I just gave is something that's not important and we shouldn't worry about it. So I'm going to ignore that one. And assume that developers are caring a lot about things outside of the scope of my talk that aren't relevant.

I don't know. I think that's a hard question to answer. I feel like developers really get on hype trains very easily. We're social creatures and we sort of take cues from what other people are doing. And so if someone that you admire and follow is telling you to care about a certain thing, then you start to care about it as well. And so I think, yeah, I think this conference is great because we need to get more people in front of people talking about things like web performance and accessibility and, yeah, the things that maybe have been marginalized a little bit, but things that are very important nonetheless.

Although there was no context to that question, I included it because it was a genuine question from an audience member, but it did, it does gel with something that I was thinking about. Like you mentioned often about, don't repeat yourself. I get that, but we work in an industry in which people fret about not repeating themselves and yet are more than happy to squirt 48 kilotons of JavaScript down the wire rather than just write some HTML, so what's that about? That gets into the whole developer experience versus user experience question.

OK, I'll ask the question. I don't know if we have time for that, since we have thirty seconds left, but that's maybe a whole hour. I'll ask the question which you can answer in twenty-six seconds. What's more important, developer experience or end user experience? I think user experience is so much more important than developer experience. And you heard it here, folks. Thought leader, Zach Leatherman said user experience is more important than developer experience. Yep.