A Web Component UI library for people who love HTML | Go Make Things
I’m obviously biased, but I like the sound of what Chris is doing to create a library of HTML web components.
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.
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
“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.”
How I switched to high-resolution maps on The Session without degrading performance.
Web components are supposed to extend the web, not replace it.
is=”too-hard”
Extending the wheel, instead of reinventing it.
Baldur Bjarnason has written my mind.