The Web Component Success Story

The Web Component Success Story

Table of Contents

Tom MacWright wrote a short post wondering why we don’t see prominent applications using web components.

That’s a fair question! It’s easy to see the success of frameworks like React and Rails: just look at the thousands of websites built with them. What does the web component success story look like?

Contrary to some people, I don’t see web components on their own as a huge productivity boon for individual websites. Once you’ve bought into a particular set of technologies, it makes sense to use it for as much as you can. If you have a React app, you’d be justifiably skeptical of introducing a second way to build components!

Rather, the biggest benefits I see are collective, cutting across the industry as a whole. I think web components can make the entire web more accessible. They have the potential to unify currently fragmented communities, including various JavaScript frameworks and those who avoid them.

I know that’s an audacious pitch, but bear with me.

JavaScript Framework Interop

Whenever I write about web components, I see pushback from people in the JavaScript community who seem to think that I want replace to JavaScript frameworks.

If you’re in that camp, let me assuage those fears: the web component success story emphatically does not involve rewriting every React app using web components. As I’ll continue to say, web components and JavaScript frameworks are complementary (as opposed to competing) technologies. In fact, I think JavaScript framework apps will be one of the most common places in which web components are used!

Does that mean we’ll all start writing web components in addition to React components? Not at all. When I say that web components will be used in JavaScript framework apps, I’m talking about third-party libraries.

JavaScript frameworks are tools, all tools have tradeoffs, yada yada, let’s skip the preamble. I want to talk about one specific weakness of JavaScript frameworks: interoperability, or the lack thereof. Almost without exception, each framework can only render components written for that framework specifically.

As a result, the JavaScript community tends to fragment itself along framework lines. Switching frameworks has a high cost, especially when moving to a less popular one; it means leaving most of the third-party ecosystem behind.

That switching cost stunts framework innovation by heavily favoring incumbents with large ecosystems. It’s hard to create new frameworks, because each one has to start its own ecosystem from scratch. We keep rebuilding the same set of primitives over and over and over again.

There’s a famous Joel Spolsky blog post about why capitalistic tech companies contribute to open source. Briefly: every product has substitutes (products that can replace it) and complements (products that can be used alongside it). The big takeaway is that ”smart companies try to commoditize their products’ complements”. In other words, they try to make it so that their own product has a proprietary advantage, while the products used alongside it are all cheap and interchangeable.

Back to JavaScript frameworks. React and Svelte are substitutes, while React and Radix are complements. As a library author, the way to commoditize your complement is to make it work with as many frameworks as possible.1 And unlike in Native Land — where people have collectively spent billions of dollars over decades developing write-once run-anywhere environments — the web has one built in.

Maybe you’ve heard of it? It’s called HTML, and it works with every Javascript framework. For all their warts, the fact that web components get this interoperability for free is a ridiculously powerful advantage, and libraries that don’t exploit it are leaving a lot of potential users on the table.

Here’s a concrete example. xyflow is an excellent library for making flow charts. It was originally called React Flow, but the maintainers renamed it when they added Svelte support. They had to put in a ton of work just to support that one extra framework! And if you use Vue, Angular, Solid, Qwik or Ember, you’re still out of luck.

React has enjoyed continued success because it has a moat of fantastic third-party libraries: Radix, React Aria, React Three Fiber, Framer Motion and xyflow, among many others. Web components have the potential to give us that same ecosystem — but for every framework.

Islands of Interactivity

Of course, plenty of websites don’t use JavaScript frameworks. Hypermedia-centric approaches (read: how websites were built before circa 2010) are making a resurgence, led by libraries such as htmx.

Many websites like this still incorporate highly dynamic elements. Often, these take the form of rich widgets that are missing from HTML, like menus and combo boxes. Sometimes they’re even more complicated, like interactive diagrams in articles. The modern term for these dynamic regions within an otherwise static page is “islands of interactivity”, but the pattern has existed for a long time.

Embedding these islands within the larger page has always been kinda awkward. The process remains mostly unchanged from the days of jQuery plugins, relying on a complex choreography of HTML classes, CSS selectors and JavaScript function calls. The bulk of the setup happens in a separate JavaScript file, far away from the HTML where the component will live on the page.

Web components invert that process. They allow islands to be instantiated in the same way as any other element: by writing a tag name in the page’s markup. As I wrote in The Website vs. Web App Dichotomy Doesn’t Exist, web components allow developers to declaratively add dynamic behavior to HTML itself.

What makes web components particularly good companions for hypermedia-oriented libraries is the way they interact with other parts of the page. While JavaScript framework components tend to do so by invoking callback functions, web components instead embrace one of the web’s core idioms: events. 2 Indeed, Carson Gross’s essay Hypermedia-Friendly Scripting neatly outlines this use case:

A JavaScript-based component that triggers events allows for hypermedia-oriented JavaScript libraries, such as htmx, to listen for those events and trigger hypermedia exchanges. This, in turn, makes any JavaScript library a potential hypermedia control, able to drive the Hypermedia-Driven Application via user-selected actions.

As an example, here’s a TIL I wrote on using htmx and the Shoelace web component library to load the content of a dialog when it opens. Notice how the whole process — from instantiating the dialog component, to requesting the content when the modal opens, to inserting it into the appropriate place in the DOM — is controlled declaratively via markup.

There are also HTML web components, which work by progressively enhancing existing markup rather than by rendering new DOM elements. Colocating logic in this way, sometimes called locality of behavior, is a different lens on a concept with which JavaScript developers should already be familiar.

No More Silos

These sound like separate problems, but they’re actually two sides of the same coin. With web components, the library that works in every JavaScript framework also works as an island of interactivity on a static webpage. Even HTML web components fit into both niches.

Brad Frost has called for a global design system: “a common library containing common UI components currently found in most design systems”. The proposal is to create a cohesive, unstyled, accessible and internationalizable set of components — like Radix, but for the entire web rather than for a single JavaScript framework. It’s an ambitious goal, and from where I stand web components are by far the best way to achieve it.

Web components won’t take web development by storm, or show us the One True Way to build websites. They don’t need to dethrone JavaScript frameworks. We probably won’t even all learn how to write them!

What web components will do — at least, I hope — is let us collectively build a rich ecosystem of dynamic components that work with any web stack. No more silos. That’s the web component success story.

Like what you read? Subscribe to my RSS feed ,
or follow me on Mastodon or Twitter .