I'm a software engineer working as a full-stack developer using JavaScript, Node.js, and React. I write about my experiences in tech, tutorials, and share helpful hints.
I agree that the narrative definitely has shifted, the original narrative came off as combative and created this rift. It also was not abundantly clear why we should "use the platform" when tools like React were out there and were better. I think the Web Components brand suffers from criticism of the early spec and the word component coming to mean something more akin to "a React-like component with props, state, and templating." Developers who use React look at them and do not see how or why they should use them because at the surface they should be similar and do the same things, but they aren't. Many React users also may not have a reason to use them if they have a single app that will only ever be in React, the overhead wouldn't be worth it and they should just continue writing their components as React components.
From my point of view, I think the benefit is when working in a large enterprise company. There can be many disjoint applications that must be maintained. If they use no framework or different frameworks and the visual design needs to be refreshed and consistent, it may be a lot of repeated effort to achieve that. If those elements use Web Components, there can be reusability across applications. I think the way to achieve that is through Web Components that focus on the visual display but leave the state to the framework as you mentioned. I think that is where being a primitive HTML element works in their favor. It takes a little bit of a mindset shift as well. Adding a <button> element, then applying classes and styles, then event handlers. Adding a <ryan-button> should be thought of like a similar thing, only instead of the getting the browser's default gray and having to apply classes/styles, you get your default style instead. If you think of that custom element as another standard button tag, I think it makes more sense. If it is viewed as a full-featured React component, it may be harder to get on board with it.
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.
I think that's a fair assessment, well said.
I agree that the narrative definitely has shifted, the original narrative came off as combative and created this rift. It also was not abundantly clear why we should "use the platform" when tools like React were out there and were better. I think the Web Components brand suffers from criticism of the early spec and the word component coming to mean something more akin to "a React-like component with props, state, and templating." Developers who use React look at them and do not see how or why they should use them because at the surface they should be similar and do the same things, but they aren't. Many React users also may not have a reason to use them if they have a single app that will only ever be in React, the overhead wouldn't be worth it and they should just continue writing their components as React components.
From my point of view, I think the benefit is when working in a large enterprise company. There can be many disjoint applications that must be maintained. If they use no framework or different frameworks and the visual design needs to be refreshed and consistent, it may be a lot of repeated effort to achieve that. If those elements use Web Components, there can be reusability across applications. I think the way to achieve that is through Web Components that focus on the visual display but leave the state to the framework as you mentioned. I think that is where being a primitive HTML element works in their favor. It takes a little bit of a mindset shift as well. Adding a
<button>element, then applying classes and styles, then event handlers. Adding a<ryan-button>should be thought of like a similar thing, only instead of the getting the browser's default gray and having to apply classes/styles, you get your default style instead. If you think of that custom element as another standard button tag, I think it makes more sense. If it is viewed as a full-featured React component, it may be harder to get on board with it.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.