6 ms·

Serious question: does anyone still care about Web Components? They still don't work cross platform, they have substantial limitations, and they lack many of th

Serious question: does anyone still care about Web Components? They still don't work cross platform, they have substantial limitations, and they lack many of the important features that React and others come with by default (event handling, anyone?). For real, try to build a form with React, then try to build the same form with Web Components. It's a nightmare going from controlled inputs to manual DOM fiddling. Even just telling the parent component about the form submission means creating and dispatching your own event! Is the point of Web Components to service frameworks? I really don't see who the intended audience is, because any half decent framework is infinitely simpler to work with.

macawfish 9y ago
People definitely still care about Web Components. They have evolved quite a lot over the last couple years, and there are some very nice helper libraries that have come out for them (skate.js, stencil.js) I agree that state management/binding is hard, in general, but I'm sure that these Web Components helper libraries will be more and more sophisticated as time goes by. Also, isn't it pretty much standard to use redux/mobx for state management with React? Why not use these kinds of tools with Web Components? In the past I've used slots and symbols to communicate between parents and children without exposing all the guts of my components. Aside from that, there's not really any good reason I can see that React itself couldn't/shouldn't support Web Components at some point soon.
- symlinkk 9y ago
  If Web Components are only usable with a library on top of them, what is the point of using them in the first place?
  - colordrops 9y ago
    Different libraries would then be compatible and interchangeable. You could mix and match web components using different or no frameworks on a page.
    - symlinkk 9y ago
      The guy I replied to is saying that he needs to use third party libraries just for state management and data binding. Pretty much every non-trivial component is going to need these features, and if they're using a library to get them, we're back to the same situation we were in before Web Components.
      - lomnakkus 9y ago
        Nope. The whole point of Web Components is that all of the innards of components are completely encapsulated in a component, the 'client' of a component only cares about setting its attributes and responding to the events that it emits. (And perhaps supplying external styles.) I also think your claim of having to use 3rd party libraries for anything non-trivial is false, but let's ignore that for now.
  - muthdra 9y ago
    What about processors? You need entire operating systems for them to become usable.
untog 9y ago
Any framework that's integrated into browsers with no extra runtime to parse is worth caring about. Not disagreeing that the current state of Web Components is pretty bad, but the more recent versions of React are still a 100KB runtime - that's not great either!
DougWebb 9y ago
That used to be the same argument for using jQuery instead of native JS and DOM, but now much of jQuery's goodness is native. I predict the same thing will happen with React. Like jQuery it will still be useful and will probably be somewhat cleaner, but most of its value will have gone native.
- bastawhiz 9y ago
  Most modern front end frameworks are younger than Web Components. They've rebooted the spec at least once. Even after half a decade, there's still no good way of even managing state with Web Components. Really I'm not sure what we're waiting for at this point. The only thing Web Components have really solved is component isolation, but that's not something folks really struggle with these days.
- dmitriid 9y ago
  > now much of jQuery's goodness is native Frankly, not that much. Most of the APIs are still the same imperative you-can-only-do-one-thing-at-a-time hell, often with very limited capabilities compared to jQuery. And yes, whoever made the decision to return NodeLists instead of arrays everywhere should at least re-evaluate whether they should really be doing programming.
  - sametmax 9y ago
    Yep. Fetch is very low level. Chaining is a godsend. Adding elements is way shorter with jquery. All the vanilla js project i've seen end up writting a poormy tested a'd documeted half backed jquery little brother. It's not a win.
    - vinceguidry 9y ago
      I have a open job application with a company whose code challenge has me using vanilla Javascript. I'm not enthused about finishing it.
    - sebringj 9y ago
      I like fetch except its missing xhr basic stuff like cancel and abort, etc. I don't know who makes these standards.
muthdra 9y ago
The point of Web Components is namespacing (variable and styling scope), composability (one component inside the other) and cacheing (fewer network calls). Now, frameworks can work with the browser to provide those features instead of working against the browser to emulate them.
Vinnl 9y ago
> Is the point of Web Components to service frameworks? I really don't see who the intended audience is, because any half decent framework is infinitely simpler to work with. Originally Web Components were a response to web developers waiting for years to HTML elements like date pickers and such to be added to the standard. With web components, it will be possible to create such elements once and integrate them with every front-end project just like you'd use e.g. a <select>. Using them as a framework for building web applications has mostly been propagated by e.g. Polymer, but as I and many others who have tried it can attest: that doesn't work too well. Still, for components I think Web Components will be a great addition, and should combine nicely with React.
timwis 9y ago
I don't think web components were intended to be used directly by average users; even a basic abstraction layer makes the tedious bits easier. Take this to its logical end and you have something like [skatejs](https://github.com/skatejs/skatejs https://github.com/skatejs/skatejs), an abstraction layer over web components that you'd probably find very familiar and easy to use. In that sense, web components aren't meant to compete with react and other frameworks, but to serve as an alternate, native foundational layer for frameworks.

macawfish 9y ago

People definitely still care about Web Components. They have evolved quite a lot over the last couple years, and there are some very nice helper libraries that have come out for them (skate.js, stencil.js) I agree that state management/binding is hard, in general, but I'm sure that these Web Components helper libraries will be more and more sophisticated as time goes by. Also, isn't it pretty much standard to use redux/mobx for state management with React? Why not use these kinds of tools with Web Components? In the past I've used slots and symbols to communicate between parents and children without exposing all the guts of my components. Aside from that, there's not really any good reason I can see that React itself couldn't/shouldn't support Web Components at some point soon.

symlinkk 9y ago
If Web Components are only usable with a library on top of them, what is the point of using them in the first place?
- colordrops 9y ago
  Different libraries would then be compatible and interchangeable. You could mix and match web components using different or no frameworks on a page.
  - symlinkk 9y ago
    The guy I replied to is saying that he needs to use third party libraries just for state management and data binding. Pretty much every non-trivial component is going to need these features, and if they're using a library to get them, we're back to the same situation we were in before Web Components.
    - lomnakkus 9y ago
      Nope. The whole point of Web Components is that all of the innards of components are completely encapsulated in a component, the 'client' of a component only cares about setting its attributes and responding to the events that it emits. (And perhaps supplying external styles.) I also think your claim of having to use 3rd party libraries for anything non-trivial is false, but let's ignore that for now.
- muthdra 9y ago
  What about processors? You need entire operating systems for them to become usable.

untog 9y ago

Any framework that's integrated into browsers with no extra runtime to parse is worth caring about. Not disagreeing that the current state of Web Components is pretty bad, but the more recent versions of React are still a 100KB runtime - that's not great either!

DougWebb 9y ago

That used to be the same argument for using jQuery instead of native JS and DOM, but now much of jQuery's goodness is native. I predict the same thing will happen with React. Like jQuery it will still be useful and will probably be somewhat cleaner, but most of its value will have gone native.

bastawhiz 9y ago
Most modern front end frameworks are younger than Web Components. They've rebooted the spec at least once. Even after half a decade, there's still no good way of even managing state with Web Components. Really I'm not sure what we're waiting for at this point. The only thing Web Components have really solved is component isolation, but that's not something folks really struggle with these days.
dmitriid 9y ago
> now much of jQuery's goodness is native Frankly, not that much. Most of the APIs are still the same imperative you-can-only-do-one-thing-at-a-time hell, often with very limited capabilities compared to jQuery. And yes, whoever made the decision to return NodeLists instead of arrays everywhere should at least re-evaluate whether they should really be doing programming.
- sametmax 9y ago
  Yep. Fetch is very low level. Chaining is a godsend. Adding elements is way shorter with jquery. All the vanilla js project i've seen end up writting a poormy tested a'd documeted half backed jquery little brother. It's not a win.
  - vinceguidry 9y ago
    I have a open job application with a company whose code challenge has me using vanilla Javascript. I'm not enthused about finishing it.
  - sebringj 9y ago
    I like fetch except its missing xhr basic stuff like cancel and abort, etc. I don't know who makes these standards.

muthdra 9y ago

The point of Web Components is namespacing (variable and styling scope), composability (one component inside the other) and cacheing (fewer network calls). Now, frameworks can work with the browser to provide those features instead of working against the browser to emulate them.

Vinnl 9y ago

> Is the point of Web Components to service frameworks? I really don't see who the intended audience is, because any half decent framework is infinitely simpler to work with. Originally Web Components were a response to web developers waiting for years to HTML elements like date pickers and such to be added to the standard. With web components, it will be possible to create such elements once and integrate them with every front-end project just like you'd use e.g. a <select>. Using them as a framework for building web applications has mostly been propagated by e.g. Polymer, but as I and many others who have tried it can attest: that doesn't work too well. Still, for components I think Web Components will be a great addition, and should combine nicely with React.

timwis 9y ago

I don't think web components were intended to be used directly by average users; even a basic abstraction layer makes the tedious bits easier. Take this to its logical end and you have something like [skatejs](https://github.com/skatejs/skatejs https://github.com/skatejs/skatejs), an abstraction layer over web components that you'd probably find very familiar and easy to use. In that sense, web components aren't meant to compete with react and other frameworks, but to serve as an alternate, native foundational layer for frameworks.