Earlier this year I spoke at An Event Apart’s Spring Summit and today I’m happy to share with you that talk called HTML with Superpowers, which is all about Web Components.
This talk had two major objectives. Firstly, In January 2021 I joined the W3C Web Components Community Group, which is hoping to advance Web Components and raise awareness. It’s a worthwhile cause to get over some of Web Components’ historical marketing problems. I also get a chance to provide feedback on nascent stage proposals. I’m a fringe member in this group, but happy to escalate any questions or feedback you have.
The second reason I wanted to talk about Web Components is that I feel there’s an education gap. I noticed that nearly all the people I know that love HTML, CSS, and Design Systems… they don’t use Web Components. It makes sense when you realize a lot of web component education targets JavaScript developers. Every How-To Web Components post on Dev.to starts with the class-based JavaScript API. That’s great… if you like JavaScript. But if I’m 100% honest, if you already have a JS framework that works for you, I don’t see much point in switching. That’s an intense amount of sunk costs and organizational entropy to overcome. I wanted to write a talk that approaches Web Components from a different angle.
Emulating Jeremy Keith’s pacing layers for the Web, which emulates Stuart Brand’s pacing layers for architecture, I start with the slower layers of the Web. The layers unlikely to change from under you and then build up to the “Jeremy Beremy” velocity of JavaScript. That means starting with HTML, then talk about CSS, then talk about JavaScript.
Part 1: How to use Web Components with HTML
Let’s start with HTML. Let’s use Web Components that someone else built. No build tools. No NPM install blah blah. Copy and paste a script tag from the web like the old days. I walk through half a dozen examples on how to use Web Components to make interactive sites, reusable components, and even 3D realms using HTML and a humble <script> tag.
My favorite is <two-up> from Google Chrome Labs which you can use in your code today to make one of those neat before/after picture sliders.
<two-up>
<div><img src="before.jpg" alt="before"></div>
<div><img src="after.jpg" alt="after"></div>
</two-up>
<script src="path/to/two-up.js"></script>
I love it because I didn’t have to code it myself. I didn’t have to fuss with absolute positioning, pointer events, nothing. It gives me a great effect with ~5 lines of HTML.
Part 2: How to style Web Components with CSS
In the second part of the talk we come face to face with the most frustrating part of Web Components… styling.
Styling Web Components is the biggest foot gun of the entire Web Component system because it involves something called “Piercing the Shadow DOM”. The Shadow DOM is a boundary inside the component where no styles bleed in and no styles bleed out… but some styles do pass through! Why??!? This is figure-outable, but it’s not intuitive and can leave you with a sour first experience.
/* This does not work */
custom-alert button {
background: pink;
}
When some styles pass through the shadow boundary and some styles don’t, it creates a bit of a frustrating developer experience. A loss of agency. As a CSS professional, I’m used to having access to style nearly everything on the page. But Web Components break that social contract and there’s not even a mechanism to say “Hey, I’m an expert, let me style this.”
I did the thing where I chucked a lot of CSS at a Web Component to see what sticks. We also walk through options like CSS Custom Properties and CSS Named Parts that you can add to your components to offer more customizable styling APIs.
Part 3: Build Web Components with JS
The final step, I sort of bring it all together and write a <custom-alert> component using Lit. It’s a hundred lines of code and I’d wager it’s half CSS. If I could redo the talk I’d probably rip out the styles and layer them in at the end.
The biggest takeaway that I hope people get is that components have a lifecycle, like a React or Vue component. And there are micro-libraries that give you different flavors of Web Components to suit your niche aesthetics. They also have a bit of reactive component state built-in and I could probably cover that more better next time around. Point being… they’re probably a little bit better than the last time you checked them out.
tl;dr
I think if you were using Web Components before 2020 you were an early adopter and you probably have some scars to show for it. But in 2021, now that all modern browsers support Web Components, I think they’re worth investigating. They have one superpower that no other JavaScript framework offers called the Shadow DOM which is both powerful but frustrating. But another superpower — the power I’m most excited about — is that you can use them standalone without any frameworks, build tools, or package managers.
And from there, if we have good, robust Web Components… I believe they can inform the Web Platform and we can get more native elements in the future.
If you have questions, want to air grievances, or would like to know more about Web Components, hit me up on Twitter. I’m also putting together a workshop on Web Components so if that interests you or your company please reach out.