Lived experience
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.
Shadow DOM is for hiding your shame
This is an excellent step-by-step walkthrough by Tess of creating a web component, with real thought given to what should be in the HTML (which will act as a fallback) and what’s better generated in the Shadow DOM (like buttons for interactivity).
This perfectly mirrors something Chris was saying in a recent episode of the Shop Talk Show:
I think of the image comparison one. That’s a classic example in Web component. What’s inside is just two IMG tags. That’s it. When it fails, you don’t want a weird div with little arrows on it being rendered on the page. That’s not doing anything because it has failed to load the JavaScript.
Related links
How Microsoft Edge Is Replacing React With Web Components - The New Stack
“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.”
Cameron Dutro on ruby.social
Here’s the inside scoop on why Github is making a bizarre move from working web components to a legacy React stack.
Most of what I heard in favor of React was a) it’s got a good DX, b) it’s easy to hire for, and c) we only want to use it for a couple of features, not the entire website.
It’s all depressingly familiar, but it’s very weird to come across this kind of outdated thinking in 2023.
My personal prediction is that, eventually, the company (and many other companies) will realize how bad React is for most things, and abandon it. I guess we’ll see.
Web Components Will Outlive Your JavaScript Framework | jakelazaroff.com
There’s a cost to using dependencies. New versions are released, APIs change, and it takes time and effort to make sure your own code remains compatible with them. And the cost accumulates over time.
This post is about more than web components:
If we want our work to be accessible in five or ten or even 20 years, we need to use the web with no layers in between. For all its warts, the web has become the most resilient, portable, future-proof computing platform we’ve ever created — at least, if we build with that in mind.
Using Stencil to make a live poll Web Component
Before getting into the details of the code, Matt hits the nail on the head talking about the the one thing that web components have that no framework can offer: longevity.
Quoting Stuart Brand:
Old systems break in familiar ways. New systems break in unexpected ways.
Well! The web is an old system.
Related posts
Extensibility
A difference of opinion regarding what the core features of custom elements should be.
Browser support
Here’s Clearleft’s approach to browser support. You can use it too (it’s CC-licensed).
Applying the four principles of accessibility
Here’s how I interpret the top-level guidance in the Web Content Accessibility Guidelines.
Speculation rules
A performance boost in Chrome.
Baseline progressive enhancement
If a browser feature can be used as a progressive enhancement, you don’t have to wait for all browsers to support it.