Container Queries in Web Components | Max Böck

Churn

This is a good description of the appeal of HTML web components:

WC lifecycles are crazy simple: you register the component with customElements.define and it’s off to the races. Just write a class and the browser will take care of elements appearing and disappearing for you, regardless of whether they came from a full reload, a fetch request, or—god forbid—a document.write. The syntax looks great in markup, too: no more having to decorate with js-something classes or data attributes, you just wrap your shit in a custom element called something-controller and everyone can see what you’re up to. Since I’m firmly in camp “progressively enhance or go home” this fits me like a glove, and I also have great hopes for Web Components improving the poor state of pulling in epic dependencies like date pickers or text editors.

The Web Component Success Story | jakelazaroff.com

The power of interoperability:

Web components won’t take web development by storm, or show us the One True Way to build websites. They don’t need to dethrone JavaScript frameworks. We probably won’t even all learn how to write them!

What web components will do — at least, I hope — is let us collectively build a rich ecosystem of dynamic components that work with any web stack. No more silos. That’s the web component success story.

HTML with Superpowers - daverupert.com

A great talk from Dave on web components:

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.

The talk makes a callback to my talk Building from a few years back. I like that. It feels like a long thoughtful converstation.

Using the platform

Elise Hein documents what it was like to build a website (or web app, if you prefer) the stackless way:

• use custom elements (for modular HTML without frameworks)
• use the in-browser package manager (for JavaScript packages without build tools)
• match pages with files (to avoid routing and simplify architecture)
• stick to standards (to avoid obsolescence and framework fatigue)

Her conclusions are similar to my own: ES6 modules mean you can kiss your bundler goodbye; web components are a mixed bag—it’s frustrating that Apple are refusing to allow native elements to be extended. Interestingly, Elise feels that a CSS preprocessor is still needed for her because she wants to be able to nest selectors …but even that’s on its way now!

Perhaps we might get to the stage where it isn’t an automatic default to assume you’ll need bundling, concatenation, transpiling, preprocessing, and all those other tasks that we’ve become dependent on build tools for.

I have a special disdain for beginner JavaScript tutorials that have you run create-react-app as the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.

Custom Elements: an ecosystem still being worked out - Tales of a Developer Advocate

Really, really smart thinking from Paul here, musing on the power relationship between the creators of custom elements and the users of custom elements.