> 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.

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.

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.

> 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.

I agree, and I prefer jQuery over native. It's still better, and does more. My point was that people say we don't need it anymore because the features it introduced are native now, and I think that's going to be said about React and Web Components too at some point. The same counter-argumemt will also be said: people will defend continued use of React because it will still be better, and will still do more. Just like jQuery.

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.

I like fetch except its missing xhr basic stuff like cancel and abort, etc. I don't know who makes these standards.

Abort/cancel has recently been added to the spec as AbortSigal (https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal). Currently only supported in Firefox 57 and Edge 16.

The major thing still missing is upload/download progress.

In remembering this issue I had, I made a frankenstein promise return object mimicking fetch's interface called "retch" but didn't publish it. It allowed progress and cancelling. It made me think would be nice to have a promise interface standard class you could inherit from where you could add sugar to it so the chain would remain consistent with your additional functionality. Anyhoo.

I have a open job application with a company whose code challenge has me using vanilla Javascript. I'm not enthused about finishing it.

>but now much of jQuery's goodness is native

Since I never really learned jQuery, I can't attest to how much of modern JavaScript is based off of it. But looking an a quick reference for jQuery, it's pretty obvious that a huge part of it did not become standard. So all of the time invested in learning those features is wasted. Any application using those features is permanently locked in to a nearly obsolete framework. And the owners of those applications is now forced to find developers who both know and admit to knowing jQuery knowing they'll be dooming themselves to supporting old legacy code.

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.

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!

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.

If Web Components are only usable with a library on top of them, what is the point of using them in the first place?

Different libraries would then be compatible and interchangeable. You could mix and match web components using different or no frameworks on a page.

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.

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.

What about processors? You need entire operating systems for them to become usable.

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), 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.