Let's talk about web components

• Updated on: 2023-09-04
• Read original article here

Web components! They’re currently at the vanguard of web development and are a reliable source of hot drama in the community. We’ve built a number of web component-powered design systems with Fortune 500 companies over the last 4 years, and it’s been a wild ride. We’ve seen a ton of success, we’ve bumped up against many rough edges, and we’re still here. We are increasingly relying on web components to help our clients establish and evolve their design system efforts. We’re enthusiastic about web components and think you should be too.

Web components are a collection of technologies that work together to deliver reusable UI components to the web. I won’t really delve into the technical details (if you want to get nitty gritty, check out Dave’s web components course), but the spirit is to be able to create and use a web component like this:

That spits out something that looks like this:

The web component abstracts away the product card’s front-end markup, styles, and any presentational JavaScript and delivers it as a nice little package. Consuming developers interact with the web component’s in order to pass in content and/or turn functionality on or off.

Because web components are native to the web, they can travel to any web-based environment. They can be plugged into a WordPress/Drupal/Contentful/whatever site, integrated into a React/Vue/Angular/Svelte/whatever app, or sent to a regular ol’ static website. That’s the theory anyways! Anyone who’s worked with web components know reality is a bit more complicated than that, and we’ll get into those things in a bit.

There are many use cases for web components, but I’m going to focus on web components as a vehicle for delivering design system component libraries. It’s increasingly common for organizations to have web stuff built in a whole slew of technologies, and at the end of the day we want to deliver high-quality, cohesive user experiences to all of them. Users don’t give a crap if the homepage is powered by Drupal and the post-login dashboard is a React app. They want to get things done and get on with their lives, and our software should help them accomplish their goals with minimum fuss and muss. Design systems are an important tool for accomplishing that.

I see it critically important to differentiate between front-of-the-front-end development and back-of-the-front-end development. Crafting solid front-of-the-front-end code — HTML, CSS, and presentational JavaScript — is critical for delivering great user experiences, and it makes sense to avoid re-creating front-of-front-end code for each (past, present, and future) tech stack under an organization’s roof. That’s why web components are an attractive solution for a big challenge! Web components can serve as a vehicle for delivering a directly consumable “source of truth” for front-of-the-front-end code that can travel to whatever tech stack needs to be supported.

“Web components versus [JS library/framework]” is a positioning that I hear a lot in my own work, and is a sentiment I see bandied about in the community. This is both a false dichotomy and a damn shame.

React! Angular! Vue! There are some massively popular JS libraries and frameworks out there, and they have proven to be incredibly capable solutions for delivering websites and apps the world over. There are giant ecosystems and communities built up around them, and a lot of collective labor has gone into getting them to the state they’re in today. People should be proud of all that hard-earned success.

There are many facets that go into creating great web experiences, which is why in our work it’s less “either/or” and more “both/and” when it comes to using web components and JS libraries/frameworks.

As mentioned above, it increasingly makes sense to deliver presentational UI components in a way that can be used across many different tech stacks. But there’s a lot more to making web experiences than the presentational UI layer. Business logic, state management, cache invalidation, et al all need to be handled, and these vast JS ecosystems are certainly up to the task. We’ve found a lot of success with a one-two punch that looks like this:

Web components are compatible with and can be consumed by JS libraries and frameworks like React, Angular, Vue, and the like. Web components handle the presentational aspects of a component, but are intentionally dumb. (Note: I’m specifically talking about design system web components; you can create very sophisticated, smart web components too). A JS library/framework can consume these dumb presentational web components and breathe life into them in order to make them work in a real product. In our work, we’ve found this split creates a clear separation of concerns and leads to a healthy division of labor.

Here’s the truth: the overwhelming majority of web components don’t need to be web components. Your run-of-the-mill, meat-and-potatoes UI components — the stuff of design systems — aren’t doing quadruple backflips or traveling to the moon. They’re more likely splatting a blue button on a web page.

This runs us right into one of the most common and valid criticisms of web components: why the hell do we need JavaScript at all in order to render web components? That’s a damn good question, and is one that my progressive enhancement-minded self has asked many times over the years. The partial answer has to do with the fact that web components were born during a different, SPA-frenzied zeitgeist. Setting that history aside, let’s dig into the nuance of web components rendering and talk about how we can successfully marry web components with progressive enhancement, server-side rendering, and the current zeitgeist.

For a (strong?) majority of UI components, we want the developer ergonomics of working with the web component abstraction, which again looks something like this:

But we want the browser to spit out something that looks like this:

That, my friends, is called HyperText Markup Language, and it’s how the web has been working since 1991. This specific component doesn’t have any JavaScript razzle-dazzle going on, so effectively we want the web components to build in the same way we’ve been doing forever with templating languages like Mustache, Twig, Nunjucks, Jade, JSP, et al.

Alas, the design of web components relies on JavaScript in order to print the component out (irrespective of whether or not the component actually contains any JS-reliant behavior). The result looks like this in the browser (the right side of the image):

Well that ain’t good. What do we do with this? Throw web components out the window? Hold yer horses there, pal. There are different solutions to this problem, so let’s first look at the design of HTML and how we can use that to our benefit.

When HTML doesn’t recognize a tag, it will proceed to render anything that happens to live inside of it:

Hey, now we’re onto something! If/when JavaScript kicks in, the web component can wipe out or transform its guts into something more interactive. Let’s look at the idea of “spicy sections“, which the OpenUI crew have been working on in order to hopefully get us native tabs/accordion behavior into HTML proper:

When the web component kicks in, the headings get converted into tabs or accordion handles, depending on the available space. Say, that’s a nice bit of progressive enhancement! Users get access to the content whether or not JS is available, but receive an optimized experience when JS kicks in. This makes my heart circa 2006 sing. We’ll talk about some of the weirdness of this pattern in a bit, but first let’s introduce another thing that builds on this feature of HTML.

Declarative Shadow DOM is a technology that’s a part of the web component spec that sprinkles a few extra elements/concepts into this nested-HTML pattern to give more control to the web component. Here’s an example taken from this article:

Declarative Shadow DOM uses the HTML tag (with accompanying attribute) in order to provide markup or styles on page load, ensuring users have access to necessary content and styles regardless of JavaScript status. When JavaScript kicks in, the component gets hydrated and becomes interactive. So alright! We have the best of both worlds: initial content that transforms into an enhanced experience. Progressive enhancement FTW!

So here’s the thing: this looks ugly as crap. And while we’re at it, the “take raw markup in a certain configuration and convert it to something interactive when JS kicks in” pattern is clever, but it’s a black box that’s ripe for abuse and you need to know how the internals work in order to wield it properly. In short, the developer experience isn’t good and I don’t think anyone’s out there promoting this as a preferred way of interacting with web components. The question then becomes: can we get the progressive enhancement benefits of declarative shadow DOM along with a great developer experience?

To reiterate, we want the following:

We can accomplish both of these goals by employing a build step. And that’s what solutions like lit-ssr, WebC, and Enhance are helping to accomplish. Developers can write this:

And it will compile into raw HTML like this:

Or a declarative shadow DOM version like this:

There’s even more nuance to all of this that I’m not going to go into here. Instead, I’d recommend checking out Zach Leatherman‘s WebC Eleventy docs, especially these videos that get into the various ways to transform a web component into the appropriate thing.

Right now, everyone’s clamoring for SSR support in web components. And since you’re a couple thousand words into this fandango, I’ll be so bold as to share one prediction and one hope:

When training our clients on web components, we see our fair share of raised eyebrows. There are certain new concepts that are fundamentally different than how other frameworks and web stuff work. A big part of that comes from this idea of the Shadow DOM.

The idea behind Shadow DOM is that a component is completely self contained, which prevents a component’s styles or JavaScript from bleeding out onto the rest of a web page and knocking over a bunch of chairs. Zach Leatherman reminded me that the design of Shadow DOM was likely taking into heavy consideration things like third-party widgets and advertisements, which have always been a source of consternation for web developers around the world.

But design system work entails creating a component library often comprised of ~40-150-ish components that are all meant to hang together as one happy, interoperable family. For design systems, each web component operating as a totally island makes things clumsy or difficult at times. Making things like compound components look and behave appropriately (e.g. a data table with zebra striping, a select menu with different dropdown options) is challenging, and the hoops we’ve jumped through to get things to work don’t have us feeling great.

Moreover, Shadow DOM unlocks several different capabilities, including scoped styles and slots. So while you can turn ShadowRoot off to get around certain annoyances, you lose some of web components’ superpowers like scoped styles and slots. The good news is that there are efforts underway to treat each superpower as its own thing so we have more control over which web component features we want to lean into.

I sometimes see commentary floating around out there about how web components are “just JavaScript” and we actually don’t need frameworks or tooling to make them happen. These people would also like to talk your ears off about the merits of rolling your own cigarettes.

The fact of the matter is that the world of web development enjoys — nay, needs — abstractions, tooling, conventions, and parameters. I see tooling and frameworks as a healthy and important aspect of getting people rolling with web components. Other popular JS libraries/frameworks have built up some downright sturdy ecosystems and tooling, and I think it’s a good thing for web components to follow suit.

There are a few popular web component libraries/frameworks out there, and Lit and Stencil are two of the most popular. We’ve built design systems for some of the largest companies in the world using both of them, and they’re both good. I won’t get into a tools comparison here (you can Google it and find good articles like this), but holding my finger up to the wind (well, ducking my head into lots of companies) it seems like Lit is pulling away as the frontrunner.

But just so it’s said, the popularity of these tools have so little to do with the actual merits of the tools themselves (they all make making web components easy), and have way more to do with mindshare, branding, corporate backing, stars, monthly downloads, number of blog posts, and so on. In my consulting work, we help our clients choose the best technical solutions for the snapshot in time we’re working in, but we also help them architect things in such a way that today’s tooling doesn’t paint them into a corner when the tooling landscape inevitably changes.

I want to touch on proprietary JS libraries/frameworks for a second. jQuery was a really important and pioneering tool of its time: it smoothed out a lot of cross-browser headaches, introduced many important concepts, and made development a hell of a lot easier. Ultimately, many of those concepts and ergonomics made their way into JavaScript proper and the world is better off for it. There was an elegance and dignity to its decline and death; it’s job here was done and could ride off into the sunset.

I see proprietary libraries/frameworks like React in the same light. React pioneered many important concepts — especially introducing an elegant component model — and those concepts have now made their way into the fabric of the web. But unlike jQuery, I don’t predict or welcome a death of React, Vue, Angular, or any JS framework. After all, JavaScript “don got big” and now powers the entirety of a web apps. This will undoubtedly continue to be the case.

My proposal is for these JS library/framework ecosystems to actively support & encourage web component use for front-of-the-front-end code, while continuing to handle all the mission-critical things that go into making web sites/apps work. I think the more HTML, CSS, and presentational JavaScript is handled by the web platform, the better off we’ll be. Reading things like “Why We’re Breaking Up with CSS-in-JS” is case in point. Let’s work with the grain of web as much as we’re able; it will benefit us all.

All these years later, I still believe in the web and its power to change the world for the better (Granted I’m not nearly as bright-eyed, bushy-tailed, naive, and optimistic as I once was). I come from the Zeldman school of web standards, am a strong proponent of progressive enhancement, care deeply about accessibility, and want to do my part to make sure that the web lives up to its ideals. And I bet you feel similar.

It’s in that spirit that I want to see web components succeed. Because web components are a part of the web! Any web component shortcomings that exist today certainly aren’t insurmountable in my view; I see them more as annoying wrinkles than anything more fundamentally flawed. So let’s work together, smooth out some wrinkles, save ourselves a lot of agony, and get us all to a better place.