In this essay at Smashing Magazine, Frederik Dohr walks through some of the challenges of scaling up purely “imperative” DOM APIs inside a web component to handle complex UI state and rendering. Now I happen to think there can be a wide spectrum of approaches and third-party solutions here. Imagine vanilla JavaScript all the way on one end of the spectrum, and React all the way on the other end of the spectrum. There’s a lot of room in the middle for light-weight tools which can address low-hanging fruit.

In this addition to the corpus of critiques of “utility-first” CSS, Heydon Pickering does an excellent job of explaining the strange world we find ourselves in where the C of CSS is simply being thrown away for the sake of a convenience that doesn’t actually end up very convenient at all in the long run.

I’ve set up @font-face rules and styling for variable fonts in the past, but I recall dealing with some fiddly bits that sort of turned me off from reaching for variable fonts as a default approach.

Well, in this example of how Michelle Barker got things set up for her site in a recent redesign, it seems very straightforward and makes a lot of sense.

All right, so you got your web server emitting some HTML with declarative shadow DOM (DSD). Great! You fetch a fragment of this HTML, and use innerHTML to set an element to display this new HTML.

Uh oh.

No worries, you think to yourself. You’ll use DOMParser.parseFromString to construct a new fragment from the server-provided string, and then append that to your page. Surely that will work!

Uh oh.

Yes, I’m sorry be the bearer of bad news, but the typical DOM APIs you use to turn strings of HTML into new DOM do not parse DSD. All those <template shadowrootmode="…"> tags remain just that, template tags. No shadow DOM to be found anywhere.

Until now.