Trys describes exactly the situation where you really do need to use the Shadow DOM in a web component—as opposed to just sticking to HTML web components—, and that’s when the component is going to be distributed and you have no idea where:
This component needed to be incredibly portable, looking great on any third-party website, in any position, at any viewport, with any amount of content. It had to be a “hyper-responsive” component.
“And so what we did is we started looking at, internally, all of the places where we’re using web technology — so all of our internal web UIs — and realized that they were just really unacceptably slow.”
Why were they slow? The answer: React.
“We realized that our performance, especially on low-end machines, was really terrible — and that was because we had adopted this React framework, and we had used React in probably one of the worst ways possible.”
React has become a bloated carcass of false promises, misleading claims, and unending layers of backwards compatibility – the wrong kind of backwards compatibility, as they still occasionally break your fucking code when updating.
Pretty much anything else is a better tool for pretty much any web development task.
This is an interesting thought from Scott: using Shadow DOM in HTML web components but only as a way of providing sort-of user-agent styles:
providing some default, low-specificity styles for our slotted light-dom HTML elements while allowing them to be easily overridden.
Three great examples of HTML web components:
What I hope is that you now have the same sort of epiphany that I had when reading Jeremy Keith’s post: HTML Web Components are an HTML-first feature.
So many of the problems and challenges of working with Web Components just fall away when you ditch the shadow DOM and use them as a light wrapper for progressive enhancement.
Some lovely HTML web components—perfect for progressive enhancement!
Laying out sheet music with CSS grid—sounds extreme until you see it abstracted into a web component.
We need fluid and responsive music rendering for the web!
More thoughts on naming web components.
I somehow missed this when it came out in January but Amber just pointed me to it—an interview with Chris about HTML web components, available for your huffduffing pleasure.
Here’s a nice HTML web component that uses structured data in the markup to populate a Leaflet map.
Personally I’d probably use microformats rather than microdata, but the princple is the same: progressive enhancement from plain old HTML to an interactive map.
This is a good description of the appeal of HTML web components:
WC lifecycles are crazy simple: you register the component with
customElements.defineand 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—adocument.write. The syntax looks great in markup, too: no more having to decorate withjs-somethingclasses or data attributes, you just wrap your shit in a custom element calledsomething-controllerand 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.
This is a really lovely little HTML web component from Jason. It does just one thing—wires up a trigger button to toggle-able content, taking care of all the ARIA for you behind the scenes.
Isn’t this a lovely little HTML web component? All it does is hook up a button element with an audio or video element: exactly the kind of discrete drudge work that’s good to automate away.
This looks like a handy collection of HTML web components for common interface patterns.
drab does not use the shadow DOM, so you can style content within these elements as usual with CSS.
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.
Scott has written a perfect description of HTML web components:
They are custom elements that
- are not empty, and instead contain functional HTML from the start,
- receive some amount of progressive enhancement using the Web Components JavaScript lifecycle, and
- do not rely on that JavaScript to run for their basic content or functionality.
I like how Paul has recreated his own version of This Is My Jam and I really like how he’s done it with an HTML web component.
The main reason I’m so hot on Light DOM is that I find the styling story of Web Components using Shadow DOM annoying.
Here’s an HTML web component that uses progressive enhancement for a very common use case: clicking a thumbnail image to view the full size image in an overlay. Just be sure to update the code to include an alt attribute before using this in production!