Dave explains how Jekyll Includes are starting to convert him to web components. The encapsulation is nice and neat. And he answers the inevitable “but why not use React?” question:
Writing HTML that contains JavaScript, not JavaScript that contains HTML, feels good to me.
The key feature for me is that this approach doesn’t have to depend on JavaScript in the browser:
I like that Web Components are an entirely client-side technology but can be rendered server-side in existing tech stacks whether it’s Jekyll, Rails, or even some Enterprise Java system.
Eric Meyer and Brian Kardell chat with Jay Hoffmann and Jeremy Keith about Shadow DOM’s backstory and long origins
I enjoyed this chat, and it wasn’t just about Shadow DOM; it was about the history of chasing the dream of encapsulation on the web.
I’m obviously biased, but I like the sound of what Chris is doing to create a library of HTML web components.
This is very nice HTML web component by Miriam, progressively enhancing an ordered list of audio elements.
I hold this truth to be self-evident: the larger the abstraction layer a web developer uses on top of web standards, the shorter the shelf life of their codebase becomes, and the more they will feel the churn.
So what are the advantages of the Custom Elements API if you’re not going to use the Shadow DOM alongside it?
- Obvious Markup
- Instantiation is More Consistent
- They’re Progressive Enhancement Friendly
How I switched to high-resolution maps on The Session without degrading performance.
Or, more precisely, why use React *in the browser*?
In which I find a tagline for Web Day Out and a tagline for React.
The enshittification of React …which was already pretty shitty for users.
Responses to my thoughts on why developers would trust third-party code more than a native browser feature.