4 ms·

Fully agree with the author. My biggest complaint about web components is that I don’t see a lot of advantages over using React, Svelte, or some other JS libra

Fully agree with the author. My biggest complaint about web components is that I don’t see a lot of advantages over using React, Svelte, or some other JS library. The author hints at this: if I’m already committing to a big JS build process, why wouldn’t I reach for one of these more ergonomic JS tools? Warm fuzzies for trying to use open standards isn’t enough to convince most people to switch away from more popular JS solutions.

spankalee 6y ago
The benefit isn't warm fuzzies - it's interoperability: with other components, tools, the browser and devtools, other developers. If you build an app with web components, even if you're using one specific helper library to do it, it makes it possible, easy even, to incrementally migrate to other libraries. You can migrate top-down, bottom-up, or even middle-out to other helper libraries and have a continuously working app. You can import and use another web component built with another library without being constrained to just the framework you chose. You can even build an app with all web components, later decide you really don't like them and want to use only a framework and still easily incrementally migrate top down and not break the app. This makes web components the much safer choice for large and long lived projects, and more flexible for projects of all sizes.
onion2k 6y ago
One huge advantage is that you can isolate a web component in its own shadow DOM, which means it has CSS that's independent from the rest of the page. If you're making something for other people to embed in their code, even if you're on the same project, you can save them from breaking it by styling it by mistake. You can also close the shadow DOM to stop people easily inspecting it, but I must admit I haven't actually figured out a reason to do that yet.
- franciscop 6y ago
  That is the same if you use e.g. styled components with React, where every component is self-contained and doesn't leak the styles. The mechanism is different, but the end result is the same, and oh it's a game changer IMHO.
  - goatlover 6y ago
    But why should developers have to use a framework like React to do something the browser could provide for them? Not everyone is writing a JS application. Some just need to add some custom HTML, CSS and little bit of JS.
    - trufas 6y ago
      I don't think the GP was arguing against that. If you're already committed to an existing build process building new components as web components doesn't really have many advantages vs a component built in react. It's just adding needless complexity.
      - onion2k 6y ago
        Web components can be built separately to the rest of an application as standalone components and included by adding a <script> tag, and then using them is as straightforward as using an HTML tag. You need a build process for the component (or the author of the component does..) but you don't need one for the website you're using it in. You can do that with a React component as well but you don't get the benefits of things like styled components if you do. You do with web components.
  - sime2009 6y ago
    The difference is that web components provide browser supports low level APIs which frameworks can use to make isolated components. Sure, you can get the same effect in React. But that only works if everyone on your page is playing by the same rules and using React. I can drop a web component into some legacy page which is full of old school jQuery and global CSS styles and my component will be isolated and work. Try the same trick with React in that situation and it will likely conflict terribly and get stomped by the old legacy code.
  - bernawil 6y ago
    you can make your component's css "not leak" if you name all it's classes with random uuid and scope all selectors accordingly, exactly what styled components does. But "not leaking css" is a nicer way of saying that you can't customize it.
- Jasper_ 6y ago
  There used to be something similar to do this called "scoped styles", but they were removed in favor of WebComponents. We could have had this without all of the Shadow DOM baggage. Though maybe it's coming back now? https://github.com/w3c/csswg-drafts/issues/3547 https://github.com/w3c/csswg-drafts/issues/3547
domenicd 6y ago
(Disclaimer: author and editor of the modern custom elements spec here.) The specific "failed promise" that I see is largely this positioning of web components vs. frameworks. How web components was originally envisioned was as leaf-node or light-DOM-using components, of the sort HTML already has. For example, <dialog>, <details>, <input type=range>, etc. Web components was supposed to give you the tools to create your own components of this sort, such as <tabpanel->, <toast->, <carousel->, <switch->, etc. In particular: * Custom elements gives you the ability to just drop in tags, like you do with vanilla HTML, and those tags can react to lifecycle events like being added/moved/attributes changed, automatically. The browser mediates between those occurrences and the web component's code. * Shadow DOM lets you encapsulate the inner details of your component, while using slots to reproject content into it. So e.g. <switch-> could have its innards entirely in shadow DOM, just like <input type=range>. While <tabpanel-> would be given children by the web developer using it, with some of those children being special (like <summary> is special for <details>), but some parts hidden in the shadow DOM and not provided by the web developer (like the disclosure triangle and behavior for <details>). More on this in https://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ https://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ From this perspective, the lack of data-binding (cited in a sibling thread) is not a big deal. There's no data binding for <input>, or <details>, etc. You just use normal DOM children and attributes to supply the data, perhaps with a framework to do that via binding or React-style re-rendering or whatever. Instead, we've seen people use web components as a React competitor. They want to write their whole app in web components, starting from a <my-app> component on down. It turns out the system is flexible enough to do this, but it wasn't designed that way from the beginning, and doing this doesn't play to its strengths. You end up just creating new frameworks, which are slightly smaller and potentially a bit faster than other frameworks because they can rely on native code for some of their lower-level building blocks like style encapsulation. But you're not living up to the promise of reusable components which behave like built-in elements. Edited to add: I do understand where developers are coming from in this regard. Using web components for leaf/reusable components and React/Vue/whatever for app-specific components is probably twice as many component models as most app developers want to deal with. I'm not sure how to deal with that tension.
- pkukkapalli 6y ago
isochronous 6y ago
Because then you don't have to pass a huge framework library down the wire along with all of your custom code? Look at it the other way, if you don't get a big advantage over web components by using React, Svelte, etc then why would you use them? Web components are natively supported by modern browsers. Using a fairly simple base class like Lit-Element to provide some template niceties and lifecycle hooks gives us all the extras we need. We've figured out a really nice top-down functional state pattern for data that eliminates the need for two-way binding and requires very little "framework" level code - it's probably like 100 lines if you take out whitespace and comments.
- hunterloftis 6y ago
  > Using a fairly simple base class like Lit-Element to provide some template niceties and lifecycle hooks gives us all the extras we need. We've figured out a really nice top-down functional state pattern for data that eliminates the need for two-way binding and requires very little "framework" level code - it's probably like 100 lines if you take out whitespace and comments. I'm also a fan of LE, which I'm using to build my current side-project. However, the data doesn't back up this claim. A component built with LitElement gets about 19 KB added to it when bundled: https://webcomponents.dev/blog/all-the-ways-to-make-a-web-component/ https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co...

spankalee 6y ago

The benefit isn't warm fuzzies - it's interoperability: with other components, tools, the browser and devtools, other developers. If you build an app with web components, even if you're using one specific helper library to do it, it makes it possible, easy even, to incrementally migrate to other libraries. You can migrate top-down, bottom-up, or even middle-out to other helper libraries and have a continuously working app. You can import and use another web component built with another library without being constrained to just the framework you chose. You can even build an app with all web components, later decide you really don't like them and want to use only a framework and still easily incrementally migrate top down and not break the app. This makes web components the much safer choice for large and long lived projects, and more flexible for projects of all sizes.

onion2k 6y ago

One huge advantage is that you can isolate a web component in its own shadow DOM, which means it has CSS that's independent from the rest of the page. If you're making something for other people to embed in their code, even if you're on the same project, you can save them from breaking it by styling it by mistake. You can also close the shadow DOM to stop people easily inspecting it, but I must admit I haven't actually figured out a reason to do that yet.

franciscop 6y ago
That is the same if you use e.g. styled components with React, where every component is self-contained and doesn't leak the styles. The mechanism is different, but the end result is the same, and oh it's a game changer IMHO.
- goatlover 6y ago
  But why should developers have to use a framework like React to do something the browser could provide for them? Not everyone is writing a JS application. Some just need to add some custom HTML, CSS and little bit of JS.
  - trufas 6y ago
    I don't think the GP was arguing against that. If you're already committed to an existing build process building new components as web components doesn't really have many advantages vs a component built in react. It's just adding needless complexity.
    - onion2k 6y ago
      Web components can be built separately to the rest of an application as standalone components and included by adding a <script> tag, and then using them is as straightforward as using an HTML tag. You need a build process for the component (or the author of the component does..) but you don't need one for the website you're using it in. You can do that with a React component as well but you don't get the benefits of things like styled components if you do. You do with web components.
- sime2009 6y ago
  The difference is that web components provide browser supports low level APIs which frameworks can use to make isolated components. Sure, you can get the same effect in React. But that only works if everyone on your page is playing by the same rules and using React. I can drop a web component into some legacy page which is full of old school jQuery and global CSS styles and my component will be isolated and work. Try the same trick with React in that situation and it will likely conflict terribly and get stomped by the old legacy code.
- bernawil 6y ago
  you can make your component's css "not leak" if you name all it's classes with random uuid and scope all selectors accordingly, exactly what styled components does. But "not leaking css" is a nicer way of saying that you can't customize it.
Jasper_ 6y ago
There used to be something similar to do this called "scoped styles", but they were removed in favor of WebComponents. We could have had this without all of the Shadow DOM baggage. Though maybe it's coming back now? https://github.com/w3c/csswg-drafts/issues/3547 https://github.com/w3c/csswg-drafts/issues/3547

domenicd 6y ago

(Disclaimer: author and editor of the modern custom elements spec here.) The specific "failed promise" that I see is largely this positioning of web components vs. frameworks. How web components was originally envisioned was as leaf-node or light-DOM-using components, of the sort HTML already has. For example, <dialog>, <details>, <input type=range>, etc. Web components was supposed to give you the tools to create your own components of this sort, such as <tabpanel->, <toast->, <carousel->, <switch->, etc. In particular: * Custom elements gives you the ability to just drop in tags, like you do with vanilla HTML, and those tags can react to lifecycle events like being added/moved/attributes changed, automatically. The browser mediates between those occurrences and the web component's code. * Shadow DOM lets you encapsulate the inner details of your component, while using slots to reproject content into it. So e.g. <switch-> could have its innards entirely in shadow DOM, just like <input type=range>. While <tabpanel-> would be given children by the web developer using it, with some of those children being special (like <summary> is special for <details>), but some parts hidden in the shadow DOM and not provided by the web developer (like the disclosure triangle and behavior for <details>). More on this in https://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ https://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ From this perspective, the lack of data-binding (cited in a sibling thread) is not a big deal. There's no data binding for <input>, or <details>, etc. You just use normal DOM children and attributes to supply the data, perhaps with a framework to do that via binding or React-style re-rendering or whatever. Instead, we've seen people use web components as a React competitor. They want to write their whole app in web components, starting from a <my-app> component on down. It turns out the system is flexible enough to do this, but it wasn't designed that way from the beginning, and doing this doesn't play to its strengths. You end up just creating new frameworks, which are slightly smaller and potentially a bit faster than other frameworks because they can rely on native code for some of their lower-level building blocks like style encapsulation. But you're not living up to the promise of reusable components which behave like built-in elements. Edited to add: I do understand where developers are coming from in this regard. Using web components for leaf/reusable components and React/Vue/whatever for app-specific components is probably twice as many component models as most app developers want to deal with. I'm not sure how to deal with that tension.

pkukkapalli 6y ago

isochronous 6y ago

Because then you don't have to pass a huge framework library down the wire along with all of your custom code? Look at it the other way, if you don't get a big advantage over web components by using React, Svelte, etc then why would you use them? Web components are natively supported by modern browsers. Using a fairly simple base class like Lit-Element to provide some template niceties and lifecycle hooks gives us all the extras we need. We've figured out a really nice top-down functional state pattern for data that eliminates the need for two-way binding and requires very little "framework" level code - it's probably like 100 lines if you take out whitespace and comments.

hunterloftis 6y ago
> Using a fairly simple base class like Lit-Element to provide some template niceties and lifecycle hooks gives us all the extras we need. We've figured out a really nice top-down functional state pattern for data that eliminates the need for two-way binding and requires very little "framework" level code - it's probably like 100 lines if you take out whitespace and comments. I'm also a fan of LE, which I'm using to build my current side-project. However, the data doesn't back up this claim. A component built with LitElement gets about 19 KB added to it when bundled: https://webcomponents.dev/blog/all-the-ways-to-make-a-web-component/ https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co...