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.