A Bit on Web Component Libraries

There have been a lot of news about Web Components recently, and I will sort them out here.

I think one of the best application scenarios for Web Components is the pattern library. Instead of using it like Bootstrap<div> , or use it like Bulma<code><div> , it is better to use custom elements, e.g.<code><designsystem-tabs></designsystem-tabs> . The new Shoelace library uses the sl namespace to define its components. It is a schema library that is entirely based on Web Components, where the tags are<sl-tab-group></sl-tab-group> element.

What are the benefits of doing this? First, it introduces the component model. This means that if you are working on a component it will have a template and a stylesheet related to its location. Looking at the internal implementation of Shoelace, you can see that it's all based on Stencil.

Another benefit is that the component can use (and does use) a Shadow DOM. This provides an isolation mechanism directly from the web platform. For us CSS developers, this means that the style of the tags in the tag component is done using the .tab class (wow, it's so cool!), but it's isolated in that component. Even with such a generic name, I would not accidentally affect other components of the common class on the page, nor would there be some external CSS to interfere with the internal structure here. Shadow DOM is like a security wall that prevents styles from leaking or infiltration.

I also see the FAST framework¹ which is also a set of components. Its tag is defined as<fast-tabs></fast-tabs> . This reminds me of another advantage of Web Components as a schema library method: it feels like it's API-driven, even starting with the name of the component itself, which is actually what you use in HTML. The properties on this element can be completely customized. The emerging standard seems to be that you don't even have to add data- prefix to custom properties. So if I want to make a tag component, it might be<chris-tabs active-tab="lunch" variation="rounded"></chris-tabs> .

Perhaps the biggest player using Web Components as the schema library is Ionic. Their labels are<ion-tabs></ion-tabs> , you can use them without involving any other frameworks (although they support Angular, React, and Vue in addition to their own Stencil). Ionic has made great progress in Web Components and has recently supported Shadow Parts. Here is the explanation of Brandy Carney again explaining the packaging:

Shadow DOM helps prevent styles from leaking from components and being accidentally applied to other elements. For example, we assign .buttonclass to our<ion-button></ion-button> Components. If the Ionic Framework user sets the .button class on one of its own elements, in earlier versions of the framework it inherits the Ionic button style. because<ion-button></ion-button> It's now a Shadow Web Component, so this problem no longer exists.

However, due to this encapsulation, the style cannot penetrate into the internal elements of the Shadow component. This means that if the Shadow component renders elements in its shadow tree, the user cannot use their CSS to locate internal elements.

Encapsulation is a good thing, but it does make the styling "harder" (deliberately). There is an important CSS concept to understand: CSS custom properties can penetrate Shadow DOM . But it is not wise for people to decide—I think that’s right—to “variably” everything in a design system. Instead, they give each HTML fragment within the Shadow DOM a part, e.g.<div part="icon"> , which allows us to "access from outside" using CSS, e.g. <code>custom-component::part(icon) { } . I think part-based style hooks are mostly good and a sensible solution for a pattern library like this, but I admit that part of it bothers me. The selector works differently than you expected. For example, you cannot select content conditionally. You can also not select child elements or use cascades. In other words, it's just a one-off, or like you're going straight through the film with your hands. You can reach forward and grab something or not, but you can do nothing.

Speaking of things that make people angry, Andrea Giammarchi has a good point of view on the current situation of Web Components:

Every library that started with, including mine, suggests that we should import the library to define what is called a " portable custom element ".

Google always recommends using LitElement. Microsoft wants you to use FASTElement. Stencil has its own components. hyperHTML has its own components. No one uses only "raw" Web Components. This is very strange! The worst part I think is that Web Components should be a "native platform" thing, which means we shouldn't need to rely on a particular technology to use them. When we do this, we are locked onto it like using React or anything else.

Andrea puts forward some ideas in the article, including using some new and smaller libraries. I think what I want to see is a schema library that doesn't use any library at all.

1. FAST calls itself a "interface system" in a continuous sentence on the homepage, followed by a "UI framework". Shoelaces calls itself a "library", but I call it a "mode library". I think "design system" is the most commonly used term to describe this concept, but is often more extensive than a particular technology. FAST uses this term in the code itself to denote the wrapper element that controls the subject. I don't think the terminology surrounding all of this stuff is far from certain.