I coded a thingy the other day and I made it a web component because it occurred to me that was probably the correct approach. Not to mention they are on the mind a bit with the news of React 19 dropping with full support.

My component is content-heavy HTML with a smidge of dynamic data and interactivity. So: I left the semantic, accessible, content-focused HTML inside the custom element. Server-side rendered, if you will. If the JavaScript executes, the dynamic/interactive stuff boots up.

That’s a fine approach if you ask me, but I found a couple of other things kind of pleasant about the approach. One is that the JavaScript structure of the web component is confined to a class. I used LitElement for a few little niceties, but even it fairly closely mimics the native structure of a web component class. I like being nudged into how to structure code. Another is that, even though the component is “Light DOM” (e.g. style-able from the regular ol’ page) it’s still nice to have the name of the component to style under (with native CSS nesting) which acted as CSS scoping and some implied structure.

The web component approach is nice for little bits, as it were.

I mentioned I used LitElement. Should I have? On one hand, I’ve mentioned that going vanilla is what will really make a component last over time. On the other hand, there is an awful lot of boilerplate that way. A “7 KB landing pad” can deliver an awful lot of DX, and you might never need to “rip it out” when you change other technologies, like we felt like we had to with jQuery and even moreso with React. Or you could bring your own base class which could drop that size even lower and perhaps keep you a bit closer to that vanilla hometown.

I’m curious if there is a good public list of base class examples for web components. The big ones are Lit and Fast, but I’ve just seen a new one Reactive Mastro, which has a focus on using signals for dynamic state and re-rendering. That’s an interesting focus, and it makes me wonder what other base class approaches focus on. Other features? Size? Special syntaxes? This one is only one KB. You could even write your own reactivity system if you wanted a fresh crack at that.

I’m generally a fan of going Light DOM with web components and skipping all the drama of the Shadow DOM. But one of the things you give up is <slot /> which is a pretty nice feature for composing the final HTML of an element. Stencil, which is actually a compiler for web components (yet another interesting approach) makes slots work in the Light DOM which I think is great.

If you do need to go Shadow DOM, and I get it if you do, the natural encapsulation could be quite valuable for a third-party component, you’ll be pleased to know I’m 10% less annoyed with the styling story lately. You can take any CSS you have a reference to from “the outside” and provide it to the Shadow DOM as an “adopted stylesheet”. That’s a “way in” for styles that seems pretty sensible and opt-in.