WebComponents are one of those things where we're getting toys before they're ready. In principle, they allow for excellent encapsulation and reusability. In practice, the overhead (including the amount of basic infrastructure needed to develop them) makes them tedious to work with, and the rules around them aren't really practical in many ways. Some bleed-through of CSS is often desired. Some better way of transporting state in and out of them and interacting with the current document/window natives is often desired. Some means of filling placeholders that well exceeds <template> (e.g. DOM nesting restrictions) is often desired.
It's a simple API on the surface, but to make it really applicable at scale it needs a lot more thought.
Web developer and lover of all things.
Helping developers and agencies build better websites.
Author of a short 60-ish page book about self-doubt and self-improvement.
The work that has been put in these past few years, especially by the community, has made them quite usable in many scenarios. And from what I've seen from the articles mentioned by @westbrook
just a few minutes ago, they will likely get much better in the not-so-distant future.
However, I have to agree that there is stil a lot of work to do to before they can really get widespread adoption. They will likely be much more developer-friendly, permissive and scalable in the future.
You seem to have not really used Web Components, they are offering all what you are mentioning today:
basic infra -> lit.dev and go bundleless
"bleed-through" of CSS -> either use CSS custom properties or Shadow Parts
transport all your glorious state, like you are used to know using either attributes, properties or projected content via default slots; i.e. you have everything at your hand, that the DOM offers
placeholders -> slot fallback content
DOM nesting restrictions? / template -> Huh? Use slots and / or nested slots
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
WebComponents are one of those things where we're getting toys before they're ready. In principle, they allow for excellent encapsulation and reusability. In practice, the overhead (including the amount of basic infrastructure needed to develop them) makes them tedious to work with, and the rules around them aren't really practical in many ways. Some bleed-through of CSS is often desired. Some better way of transporting state in and out of them and interacting with the current document/window natives is often desired. Some means of filling placeholders that well exceeds
<template>(e.g. DOM nesting restrictions) is often desired.It's a simple API on the surface, but to make it really applicable at scale it needs a lot more thought.
The work that has been put in these past few years, especially by the community, has made them quite usable in many scenarios. And from what I've seen from the articles mentioned by @westbrook just a few minutes ago, they will likely get much better in the not-so-distant future.
However, I have to agree that there is stil a lot of work to do to before they can really get widespread adoption. They will likely be much more developer-friendly, permissive and scalable in the future.
You seem to have not really used Web Components, they are offering all what you are mentioning today: