Yeah exactly as I said in the conclusion I see 3 uses:
simple element extensions which are the unfortunate "is" syntax like <button is="ryan-button" />. Only awkward thing about this is you don't get isolated styles. At which point why didn't I just make <button class="ryan-button" />. You can go the other way and just add properties to HTMLElement ie <ryan-button /> but then you have to manually add all the functionality of button. Like accessibility, or like handling form submission. Implementing form validation api, and being recognized by the parent form. Forms are actually surprisingly awkward with the Shadow DOM. They are working on it but if you look at Polymer etc they had to make their own form Web Components to handle this correctly. CSS duplication is a bit of a mess with the Shadow DOM right now as well. This is really my only issue with them as a design system. The platform doesn't serve them well enough, but it would be their most natural fit. Unfortunately they kind of fail here today too.
3rd Party Widgets.. like a zendesk help widget. Sure it draws an iFrame, but telling the dev to just include this script and drop this tag on the page is infinitely easier. I think companies like Salesforce have gone this way. Makes a ton of sense. This is the single best use for them right now I think.
Micro-Frontends.. This is the enterprise solution. Companies like Zolando have rolled out their own complicated setups for this but Web Components can do the job quite nicely. Have each front end team build into components with its own js bundle and then dynamically load based on the pages being rendered. Break up the monolithic front-end.
I guess the challenge is the first point should be the use case but they still fall a bit short there so even with cross browser support they aren't quite compelling enough yet. Which has forced people to find other solutions like CSS Modules. So unless you work at a scale where your frontend is being written in multiple technologies these won't be great. And even then I'm not sure if the current problems are worth it compared to other CSS systems. It's debatable. I did seriously consider using them for a design system. I think if that is possible it would be really great.
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.
Yeah exactly as I said in the conclusion I see 3 uses:
<button is="ryan-button" />. Only awkward thing about this is you don't get isolated styles. At which point why didn't I just make<button class="ryan-button" />. You can go the other way and just add properties to HTMLElement ie<ryan-button />but then you have to manually add all the functionality of button. Like accessibility, or like handling form submission. Implementing form validation api, and being recognized by the parent form. Forms are actually surprisingly awkward with the Shadow DOM. They are working on it but if you look at Polymer etc they had to make their own form Web Components to handle this correctly. CSS duplication is a bit of a mess with the Shadow DOM right now as well. This is really my only issue with them as a design system. The platform doesn't serve them well enough, but it would be their most natural fit. Unfortunately they kind of fail here today too.I guess the challenge is the first point should be the use case but they still fall a bit short there so even with cross browser support they aren't quite compelling enough yet. Which has forced people to find other solutions like CSS Modules. So unless you work at a scale where your frontend is being written in multiple technologies these won't be great. And even then I'm not sure if the current problems are worth it compared to other CSS systems. It's debatable. I did seriously consider using them for a design system. I think if that is possible it would be really great.