The Good, The Bad, and The Web Components
AI Generated Video Summary
Web Components are a piece of reusable UI enabled by web standards and built into the web platform. They offer the potential for faster component initialization and less library overhead. Web Components can be created from scratch and utilized with existing component libraries. Shadow DOM and Declarative Shadow DOM provide benefits such as scoped CSS and server-rendered components. The tradeoff between not repeating oneself and achieving full server-side rendering support is discussed. User experience is deemed more important than developer experience.
1. Introduction to 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.
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.
2. Web Components and Design Systems
Web Components are a piece of reusable UI enabled by web standards and built into the web platform. They offer the potential for faster component initialization and less library overhead. Examples of Web Components in use include MSN, material design, and Adobe Photoshop on the web. According to Google Chrome's Web Statistics, nearly 19 percent of page loads in the browser utilize 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.
3. Introduction to Creating Web Components
Today we'll learn how to create Web Components from scratch and utilize their unique power. Component libraries are adapting to Web Components, allowing us to export to them and reuse existing patterns.
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.
4. Understanding Web Components
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.
5. Web Component Patterns and ShadowDOM
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.
6. ShadowDOM and Declarative Shadow DOM
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.
7. Repeating Templates with Declarative Shadow DOM
8. Benefits of Using Shadow DOM and Web Components
9. Web Components SSR and WebC
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.
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.
Handling Collisions and Naming Conventions
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? Scoped element registries was his name? Yeah, I think so. Talking of component names, tell us briefly about the hyphen in the names. What's that about? 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. 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.
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.
Developer Experience vs User Experience
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.
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.