Chris’ Corner: Web Components

I’d never heard of a CEM before. That’s a “Custom Elements Manifest” or a custom-elements.json file in your project. It’s basically generated documentation about all the web components your project has. Dave calls them the killer feature of web components.

With a Custom Element Manifest, community plugins can use that information to generate files, populate dropdowns, add red squiggles, provide autocomplete, and automate a lot of the mundane meta-system DX work that comes with supporting a component library

I love the idea of essentially getting “free” DX just be generating this file. I particularly like the language server idea so that code editors can offer all the fancy autocomplete and linting for your bespoke elements.

Sometimes web components seem so practical and straightforward, like Eric Meyer’s recent <aside-note>. It yanks out some text into another element that gets positioned somewhere new, if a few media queries pass. And sometimes web components scare me, like when you read advice to make sure to have an asynchronous promise-resolving disconnectedCallback that is a mirror image of your connectedCallback because you can’t predict how the DOM will be changed. Maybe it’s best to roll up your sleeves and write your own define functions.

Let’s just take a quick stroll through some web components I saw people writing about recently. I do find it significant there is a low constant simmer of web component writing/sharing like this.

• Lea Verou made a <bluesky-likes> component. I gave it a whirl just for fun.
• Zach Leatherman took the Web Awesome copy button and incorporated it into the Eleventy docs in his own way, with all the thinking toward performance and progressive enhancement as you’d expect.
• Pontus Horn got all declarative with ThreeJS thanks to web components.