Web Components Aren’t Components

Modern web frameworks are built entirely on the concept of components. In the realm of these frameworks, a component is a reusable piece of application code. All logic is encapsulated in one place, so the component can be dropped into the application anywhere it’s needed. Components are nested within one another to compose the structure of the page.

Vitally, it must be in control of its own styling. Yes, it should be visually cohesive with the application at large, but when it comes to a reusable component, you can’t afford for unexpected styles to suddenly occur when you add the component to a new context. It’s styles need to be higher priority than the styles outside the component—including its parent components. By corollary, a component’s styles should not be overly powerful at impacting the styles of the component’s child components.

Enter “web components” ¶

We also have “web components”. These are built directly into the platform, comprising something called custom elements. Custom elements are a web primitive, a way of extending HTML itself. They are ideal for broad distribution and re-use in various frameworks/sites/apps. But to be broadly usable, they must allow for the application to have priority assigning styles.

The idea of a universally re-usable Typahead Lookup component is valiant. Nobody likes building that over and over again every time they switch JS frameworks or move to a new project. But in order for this to work, it must be completely re-stylable. It needs to be capable of visually matching whatever application it’s used in, with consistent colors, fonts, spacing, and icon styles. This means, while it should have some default styling, it must surrender full control to the outer application.

This is not a component.

At least, it’s not the same definition for component that modern frameworks use.

If I find a <typeahead-lookup> custom element that meets my application’s needs functionally, that’s great! I won’t have to roll my own autocomplete functionality! But I will still need to wrap it in a component of my own. I need to apply my application’s styling, and encapsulate the lookahead in a way that protects it from receiving unwanted styles when it’s used across my application. I probably also need to wire it into my application’s data and possibly ensure certain options are turned on or off so I don’t have to remember them every time I use the custom element.

Maybe that’s as simple as wrapping it in a div and applying a class name. But depending on the architecture of my application at large, it’s highly likely it will require wrapping it in a full component (React, Vue, or otherwise).

Now, I get that it is possible to skip this step. You can build a custom element in such a way that it’s internal parts are locked away in the shadow DOM and cannot be styled from outside. In which case, you will have to internalize your application’s styles inside the shadow DOM. But that’s tedious to do, not to mention it defeats the whole promise of “framework agnostic” web components that can be broadly distributed and re-used in various applications.

Why web components are slow to catch on ¶

I think the difficulty with web components is not that they’re bad in and of themselves. If they came along before the advent of modern JS frameworks, they would probably be the way things are done at large.

However, in the current landscape, web components live in an awkward place: They provide a lot of the same functionality as framework components, but they are not a one-for-one replacement. The two provide a lot of the same benefits to the developer, but not all the same benefits.

If you happen to work in a problem space where you need widespread distribution of custom elements, this may be enticing enough to adopt web components. But that’s not most developers.

For a developer familiar with modern web frameworks, web components don’t offer enough compelling benefits to switch — you still need the framework to componentize everything and manage the application at a high level. And if you have a framework, there’s really very little web components can offer on top of that.

Web development is a wide world ¶

I love the web. I love the promise of open standards. And I think web components serve a useful role.

My gut tells me they’re more useful toward the website end of the spectrum than they are on the web application end — but I have little data or broad enough experience to back this up.

I think we also need to be okay accepting that they aren’t the right solution for everyone. And we need to acknowledge that we’ve probably done some undue damage by trying to say they are.