12 ms·

I haven’t used React in a while, what does it offer that WebComponents do not?

ajkjk 5y ago
React does a lot more than WebComponents. Primarily the reactive programming model of only updating subtrees whose props change, but also an entire parallel tree of state/context updates for propagating data that lives alongside the component hierarchy.
reidjs 5y ago
In my experience React, despite its complexity, was always far simpler to use than WebComponents because it has clearer documentation and established patterns. I'm sure WebComponents can do everything React can do, but they do not have anywhere near the ecosystem and developer support you get with React.
deleted 5y ago
[deleted]
CapitaineToinon 5y ago
There is this article (https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci...) by Rich Harris, creator of Svelte which explains pretty well why he personally doesn't use web components.
- ravenstine 5y ago
  I feel like everyone has the wrong idea about web components. Perhaps it's in the name. There's no "WebComponent" class on the window object, but there is an HTMLElement you can extend and a `window.customElement` registry for tagName invocation, a thing called a shadow root, and so forth. Those are all things that I am glad exist. If I thought of them grouped together as "Web Components" and compared that to components in frontend JavaScript frameworks then yeah, I guess I'd be disappointed. Otherwise, the people who say they "don't use" web components are being as unreasonable as it would be to say to not use the `<video>` element because it doesn't support all the things that `<canvas>` does with some 3rd party library for compositing. Custom elements are awesome for small things that don't need to appear in an SSR context (assuming you're using shadow DOMs). No, they don't support composable stylesheets, whatever those even are, but seriously, who really needs them? If what you are doing is complicated enough that the browser's native APIs are too obtuse then yeah go for something like React or Svelte. No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser. I'd use uncommon browser and language features if they made sense for a task. The `<template>` and `<slot>` elements are really dopey and hard to understand. That's where something like React or Svelte comes in. Nobody would use either of those libraries if they didn't have better templating than the browser.
  - dmitriid 5y ago
    > I feel like everyone has the wrong idea about web components. What is the idea behind Web Components? Does anyone have an idea of what they are, should be, and where they are going? They've been around for 10 years now. Google has poured literally millions of dollars into trying to make them happen. If people still "have the wrong idea about web components", it's a testament to their failure. > Otherwise, the people who say they "don't use" web components are being as unreasonable as it would be to say to not use the `<video>` element because it doesn't support all the things that `<canvas>` does with some 3rd party library for compositing. Well, no. People who say "don't use web components" are very much aware about the fact that web components: - at the core are 4 different standards. One of them is already fully deprecated (HTML Imports). The other one already has a deprecated and removed version (Custom Elements v0) - introduced so many problems by simply existing that Google (primarily Google) has been pumping out literally thousands of pages of new specs just to fix the problems that web components created. Problems: https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci... and https://news.ycombinator.com/item?id=28697664 https://news.ycombinator.com/item?id=28697664. And new specs? Oh, they are introducing their own new problems: https://news.ycombinator.com/item?id=28698563 https://news.ycombinator.com/item?id=28698563 - have an API that is both too high level and too low level to be usable. It's too low level and too verbose, so after several years of promoting them as "the be all end all components for the web" the narrative shifted to "it's just an API for library authors, you're not supposed to use them by hand". It's unusable at any significant scale. Google's own AMP has switched to using Preact to author their components because they couldn't bear it anymore. It's too high level, so in the 10 years of its existence there are hardly any libs and frameworks that have adopted Web Components as the foundation. And even the new ones tend to skip Web Components. Well, most libs and frameworks can compile to Web Components, and can consume Web Components. But hardly any framework actually uses them as a foundation. Well, I've linked to the dozens of problems that they introduce, so no wonder. - "Custom elements are awesome for small things that don't need to appear in an SSR context" that don't need an SSR context, that don't need a11y, that don't need to split SVGs, that don't need... Too many "don't needs" for a tech that has seen millions of dollars poured into it, and 10 years of development. After all that it's still "it's awesome for small things". Only for small things. Meanwhile, w3c has unveiled its own design system here: https://design-system.w3.org https://design-system.w3.org It uses SASS and it uses a third-party library to, quote, "enhance a <select> into and accessible auto-complete via JavaScript." Imagine if millions of dollars and countless man-hours poured into Web Components were instead directed to make CSS better, to enhance the crappy built-in controls etc.? Oh, you'd have a better web, and not an "awesome for small things with dozens of problems". > No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser. Ah yes. I remember someone calling jQuery "the disappearing framework". Because its eventual goal is to be fully replaced by browser APIs. It looks like Web Components' motto is "there's always someone doing stuff better in Javascript, so why bother, let's be crap". > Nobody would use either of those libraries if they didn't have better templating than the browser. Nope. People are using them not because of templating alone.
krono 5y ago
It doesn't drive you mad with a needlessly complex syntax/API for one. Also no browser vendors that flat out refuse to implement parts of the spec (Apple [0]), or block proposals unless implemented in a highly specific way (all, here's one example [1], ugh politics). [0] https://bugs.webkit.org/show_bug.cgi?id=182671 https://bugs.webkit.org/show_bug.cgi?id=182671 [1] https://github.com/WICG/webcomponents/issues/587#issuecomment-253993830 https://github.com/WICG/webcomponents/issues/587#issuecommen...
- dmitriid 5y ago
  is= is dead, and Safari had good reasons for it. On mobile, so can't quickly find the rationale. But it's the same rationale IIRC why built-in components are not extensible (even if this was one of the original promises): the browser has no way of knowing about the actual behavior of the object, which leads to all kinds of mess inside the engine.
  - krono 5y ago
    So many other parts had to be done in a specific manner or left out entirely to get committee consensus, yet this was written into the spec even though Apple has opposed it from the beginning. The validity of Apple's reasoning makes it even stranger.
    - dmitriid 5y ago
      Yeah, the whole thing about Web Components is weird. And is getting increasingly weirder. Quite recently Constructible Stylesheets were released in Chrome: - because lit wanted them - despite Firefox and Safari being against the state of the spec - despite Safari clearly stating they are not going to implement the spec, ever (there was a trivially reproducible race condition in the spec) The entire discussion here: https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-521096423 https://github.com/WICG/construct-stylesheets/issues/45#issu...
- singularity2001 5y ago
  It's 2021 and we still can't define custom tags in html (without js) : <template tag="test"><h1>works</h1></template> <test/>
econnors 5y ago
a coherent strategy for keeping state and having the UI respond to changes in state
- flowerlad 5y ago
  That works well... until you have stateful components and you want to send in new props. At that point the recommended approach is to replace the entire component by using the key property. For simple components, especially stateless ones, React works well. When the component needs to manage user interactions it needs state, and then if you need to update props you have to make a new instance of the component, and that point React has failed in its promise.
  - paavohtl 5y ago
    What do you expect to happen? You ultimately have to store the state somewhere. Either it lives in the component, or outside of it, or you figure out some strategy to combine the two.
    - flowerlad 5y ago
      Once you realize React doesn't work for complex components it loses its attraction. Web Components are conceptually way simpler and work well. See example: https://github.com/wisercoder/uibuilder/blob/master/WebComponentsDemo/elements/ZxListEditor.tsx https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
      - paavohtl 5y ago
        I don't really see anything here that would be massively more complex in React. And besides, I've been hurt enough times by manual DOM manipulation to never want to do it again for interactive UI. It's a maintainability nightmare.
      - crooked-v 5y ago
        Simpler? I don't see it. That looks way more verbose than a React equivalent component I would write.
throw_m239339 5y ago
what does web component offers at first place is the real question. It's a spec but beyond that, Web Component doesn't really solve any of my architectural problems as a front-end developer. Instead of web components for instance, I would have preferred a DOM diff API as a standard which would have been far more useful that web components, all things considered.
dmitriid 5y ago
Someone already pointed to Rich Harris' article on dev.to, but there are other things: - form participation without javascript hacks (they are called "an API", but it's a hack) https://web.dev/more-capable-form-controls/ https://web.dev/more-capable-form-controls/ - SSR - splitting SVGs into components https://twitter.com/Rich_Harris/status/1354165883648827401?s=20 https://twitter.com/Rich_Harris/status/1354165883648827401?s... - not breaking accessibility by default https://twitter.com/sarahmei/status/1198069119897047041?s=20 https://twitter.com/sarahmei/status/1198069119897047041?s=20 and a million other things, big and small
5e92cb50239222b 5y ago
Rich component libraries like antd and material. https://ant.design/components/overview/ https://ant.design/components/overview/ https://material-ui.com https://material-ui.com
awinter-py 5y ago
does web components have a usable templating language? last time I checked there was some kind of mysterious slot update thing that made interface code 2-3x bigger
- azangru 5y ago
  > usable templating language ES6 multiline strings? Enhanced for convenience with a library like lit-html?
purple_ferret 5y ago
employment opportunities
paavohtl 5y ago
What does WebComponents offer that also React offers, other than some form of components?
javitury 5y ago
Webcomponents are a huge mess, caused partially because it requires to do (some) composition in html. React is much simpler, it uses basic html elements (div, input, ...) and event apis to compose an application in javascript. These are some disadvantages of webcomponents that I can think of. - Can't register multiple versions of a webcomponent. Let's say you are using "x-dropdown"@2.0.0 which depends on " x-icon"@2.0.0 and "x-menu"@3.0.0 which depends on " x-icon"@1.0.0. Your app will crash because html tags can't have multiple versions ("x-icon" 2.0.0 and 1.0.0). It makes handling big projects a nightmare. And there are name collisions too. - Not all properties can be serialized into attributes as strings, so you end up just binding properties. Boolean attributes have special are weird when used in the javascript side (an empty string is treated as a boolean) - The shadow dom can be too restrictive and inflexible. Implementing portals for instance, requires using ugly hacks that depend on your webcomponent framework. - Some complex webcomponents are not interoperable among different frameworks. - Static analysis on webcomponents is poor and fragile. Compare declaring types of events in webcomponents, to declaring types of event handlers in react.
- azangru 5y ago
  Youtube's website is built with web components (used to be Polymer, but I wonder if they haven't migrated to lit by now). Seems to be working fine for a large-scale project like theirs. Chrome Dev Tools are also, at least in part, built with web components.
  - dmitriid 5y ago
    > Seems to be working fine for a large-scale project like theirs. It's not web components that were working for them at scale, but Polymer. They would've probably nebver completed anything with Web Components alone due to how horrendously bad their API is. You can compare Web Components API and Polymer API here: https://twitter.com/dmitriid/status/865518972380237825 https://twitter.com/dmitriid/status/865518972380237825 It still took them over two years to switch from Custom Elements v0 to Custom Elements v1.

React does a lot more than WebComponents. Primarily the reactive programming model of only updating subtrees whose props change, but also an entire parallel tree of state/context updates for propagating data that lives alongside the component hierarchy.

reidjs 5y ago

In my experience React, despite its complexity, was always far simpler to use than WebComponents because it has clearer documentation and established patterns. I'm sure WebComponents can do everything React can do, but they do not have anywhere near the ecosystem and developer support you get with React.

deleted 5y ago

[deleted]

CapitaineToinon 5y ago

There is this article (https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci...) by Rich Harris, creator of Svelte which explains pretty well why he personally doesn't use web components.

ravenstine 5y ago
I feel like everyone has the wrong idea about web components. Perhaps it's in the name. There's no "WebComponent" class on the window object, but there is an HTMLElement you can extend and a `window.customElement` registry for tagName invocation, a thing called a shadow root, and so forth. Those are all things that I am glad exist. If I thought of them grouped together as "Web Components" and compared that to components in frontend JavaScript frameworks then yeah, I guess I'd be disappointed. Otherwise, the people who say they "don't use" web components are being as unreasonable as it would be to say to not use the `<video>` element because it doesn't support all the things that `<canvas>` does with some 3rd party library for compositing. Custom elements are awesome for small things that don't need to appear in an SSR context (assuming you're using shadow DOMs). No, they don't support composable stylesheets, whatever those even are, but seriously, who really needs them? If what you are doing is complicated enough that the browser's native APIs are too obtuse then yeah go for something like React or Svelte. No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser. I'd use uncommon browser and language features if they made sense for a task. The `<template>` and `<slot>` elements are really dopey and hard to understand. That's where something like React or Svelte comes in. Nobody would use either of those libraries if they didn't have better templating than the browser.
- dmitriid 5y ago
  > I feel like everyone has the wrong idea about web components. What is the idea behind Web Components? Does anyone have an idea of what they are, should be, and where they are going? They've been around for 10 years now. Google has poured literally millions of dollars into trying to make them happen. If people still "have the wrong idea about web components", it's a testament to their failure. > Otherwise, the people who say they "don't use" web components are being as unreasonable as it would be to say to not use the `<video>` element because it doesn't support all the things that `<canvas>` does with some 3rd party library for compositing. Well, no. People who say "don't use web components" are very much aware about the fact that web components: - at the core are 4 different standards. One of them is already fully deprecated (HTML Imports). The other one already has a deprecated and removed version (Custom Elements v0) - introduced so many problems by simply existing that Google (primarily Google) has been pumping out literally thousands of pages of new specs just to fix the problems that web components created. Problems: https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci... and https://news.ycombinator.com/item?id=28697664 https://news.ycombinator.com/item?id=28697664. And new specs? Oh, they are introducing their own new problems: https://news.ycombinator.com/item?id=28698563 https://news.ycombinator.com/item?id=28698563 - have an API that is both too high level and too low level to be usable. It's too low level and too verbose, so after several years of promoting them as "the be all end all components for the web" the narrative shifted to "it's just an API for library authors, you're not supposed to use them by hand". It's unusable at any significant scale. Google's own AMP has switched to using Preact to author their components because they couldn't bear it anymore. It's too high level, so in the 10 years of its existence there are hardly any libs and frameworks that have adopted Web Components as the foundation. And even the new ones tend to skip Web Components. Well, most libs and frameworks can compile to Web Components, and can consume Web Components. But hardly any framework actually uses them as a foundation. Well, I've linked to the dozens of problems that they introduce, so no wonder. - "Custom elements are awesome for small things that don't need to appear in an SSR context" that don't need an SSR context, that don't need a11y, that don't need to split SVGs, that don't need... Too many "don't needs" for a tech that has seen millions of dollars poured into it, and 10 years of development. After all that it's still "it's awesome for small things". Only for small things. Meanwhile, w3c has unveiled its own design system here: https://design-system.w3.org https://design-system.w3.org It uses SASS and it uses a third-party library to, quote, "enhance a <select> into and accessible auto-complete via JavaScript." Imagine if millions of dollars and countless man-hours poured into Web Components were instead directed to make CSS better, to enhance the crappy built-in controls etc.? Oh, you'd have a better web, and not an "awesome for small things with dozens of problems". > No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser. Ah yes. I remember someone calling jQuery "the disappearing framework". Because its eventual goal is to be fully replaced by browser APIs. It looks like Web Components' motto is "there's always someone doing stuff better in Javascript, so why bother, let's be crap". > Nobody would use either of those libraries if they didn't have better templating than the browser. Nope. People are using them not because of templating alone.

krono 5y ago

It doesn't drive you mad with a needlessly complex syntax/API for one. Also no browser vendors that flat out refuse to implement parts of the spec (Apple [0]), or block proposals unless implemented in a highly specific way (all, here's one example [1], ugh politics). [0] https://bugs.webkit.org/show_bug.cgi?id=182671 https://bugs.webkit.org/show_bug.cgi?id=182671 [1] https://github.com/WICG/webcomponents/issues/587#issuecomment-253993830 https://github.com/WICG/webcomponents/issues/587#issuecommen...

dmitriid 5y ago
is= is dead, and Safari had good reasons for it. On mobile, so can't quickly find the rationale. But it's the same rationale IIRC why built-in components are not extensible (even if this was one of the original promises): the browser has no way of knowing about the actual behavior of the object, which leads to all kinds of mess inside the engine.
- krono 5y ago
  So many other parts had to be done in a specific manner or left out entirely to get committee consensus, yet this was written into the spec even though Apple has opposed it from the beginning. The validity of Apple's reasoning makes it even stranger.
  - dmitriid 5y ago
    Yeah, the whole thing about Web Components is weird. And is getting increasingly weirder. Quite recently Constructible Stylesheets were released in Chrome: - because lit wanted them - despite Firefox and Safari being against the state of the spec - despite Safari clearly stating they are not going to implement the spec, ever (there was a trivially reproducible race condition in the spec) The entire discussion here: https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-521096423 https://github.com/WICG/construct-stylesheets/issues/45#issu...
singularity2001 5y ago
It's 2021 and we still can't define custom tags in html (without js) : <template tag="test"><h1>works</h1></template> <test/>

econnors 5y ago

a coherent strategy for keeping state and having the UI respond to changes in state

flowerlad 5y ago
That works well... until you have stateful components and you want to send in new props. At that point the recommended approach is to replace the entire component by using the key property. For simple components, especially stateless ones, React works well. When the component needs to manage user interactions it needs state, and then if you need to update props you have to make a new instance of the component, and that point React has failed in its promise.
- paavohtl 5y ago
  What do you expect to happen? You ultimately have to store the state somewhere. Either it lives in the component, or outside of it, or you figure out some strategy to combine the two.
  - flowerlad 5y ago
    Once you realize React doesn't work for complex components it loses its attraction. Web Components are conceptually way simpler and work well. See example: https://github.com/wisercoder/uibuilder/blob/master/WebComponentsDemo/elements/ZxListEditor.tsx https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
    - paavohtl 5y ago
      I don't really see anything here that would be massively more complex in React. And besides, I've been hurt enough times by manual DOM manipulation to never want to do it again for interactive UI. It's a maintainability nightmare.
    - crooked-v 5y ago
      Simpler? I don't see it. That looks way more verbose than a React equivalent component I would write.

throw_m239339 5y ago

what does web component offers at first place is the real question. It's a spec but beyond that, Web Component doesn't really solve any of my architectural problems as a front-end developer. Instead of web components for instance, I would have preferred a DOM diff API as a standard which would have been far more useful that web components, all things considered.

dmitriid 5y ago

Someone already pointed to Rich Harris' article on dev.to, but there are other things: - form participation without javascript hacks (they are called "an API", but it's a hack) https://web.dev/more-capable-form-controls/ https://web.dev/more-capable-form-controls/ - SSR - splitting SVGs into components https://twitter.com/Rich_Harris/status/1354165883648827401?s=20 https://twitter.com/Rich_Harris/status/1354165883648827401?s... - not breaking accessibility by default https://twitter.com/sarahmei/status/1198069119897047041?s=20 https://twitter.com/sarahmei/status/1198069119897047041?s=20 and a million other things, big and small

5e92cb50239222b 5y ago

Rich component libraries like antd and material. https://ant.design/components/overview/ https://ant.design/components/overview/ https://material-ui.com https://material-ui.com

awinter-py 5y ago

does web components have a usable templating language? last time I checked there was some kind of mysterious slot update thing that made interface code 2-3x bigger

azangru 5y ago
> usable templating language ES6 multiline strings? Enhanced for convenience with a library like lit-html?

purple_ferret 5y ago

employment opportunities

paavohtl 5y ago

What does WebComponents offer that also React offers, other than some form of components?

javitury 5y ago

Webcomponents are a huge mess, caused partially because it requires to do (some) composition in html. React is much simpler, it uses basic html elements (div, input, ...) and event apis to compose an application in javascript. These are some disadvantages of webcomponents that I can think of. - Can't register multiple versions of a webcomponent. Let's say you are using "x-dropdown"@2.0.0 which depends on " x-icon"@2.0.0 and "x-menu"@3.0.0 which depends on " x-icon"@1.0.0. Your app will crash because html tags can't have multiple versions ("x-icon" 2.0.0 and 1.0.0). It makes handling big projects a nightmare. And there are name collisions too. - Not all properties can be serialized into attributes as strings, so you end up just binding properties. Boolean attributes have special are weird when used in the javascript side (an empty string is treated as a boolean) - The shadow dom can be too restrictive and inflexible. Implementing portals for instance, requires using ugly hacks that depend on your webcomponent framework. - Some complex webcomponents are not interoperable among different frameworks. - Static analysis on webcomponents is poor and fragile. Compare declaring types of events in webcomponents, to declaring types of event handlers in react.

azangru 5y ago
Youtube's website is built with web components (used to be Polymer, but I wonder if they haven't migrated to lit by now). Seems to be working fine for a large-scale project like theirs. Chrome Dev Tools are also, at least in part, built with web components.
- dmitriid 5y ago
  > Seems to be working fine for a large-scale project like theirs. It's not web components that were working for them at scale, but Polymer. They would've probably nebver completed anything with Web Components alone due to how horrendously bad their API is. You can compare Web Components API and Polymer API here: https://twitter.com/dmitriid/status/865518972380237825 https://twitter.com/dmitriid/status/865518972380237825 It still took them over two years to switch from Custom Elements v0 to Custom Elements v1.