[robalfonso]

As a counterpoint, I had a similar conversation with a report of mine about jQuery. He said it was not necessary and you could just use vanilla js.

I said while yes that's true as a dev if I told you I needed you to implement a new payment provider for billing would you tightly and directly align with who we used or abstract it away via some wrapper so that if we ever had to change it wouldn't be difficult? Of course everyone builds abstractions so you aren't stuck with a single provider because it's crazy not to.

I see jQuery as that abstraction. At the end of the day each browser is an api implementer and while they've come so far, that doesn't mean the situation is stable and we'll never see implementation fracture again. It of course doesn't have to be jQuery but any direct implementation of JS seems to have that risk which is easily mitigated by wrapping the basic functionality. I don't know why you wouldn't choose to do it.

[azangru]

jQuery was a useful abstraction when browsers had inconsistent and clunky apis.

Modern browsers have apis that are about as convenient as jQuery's, are standard across browsers, consistent with the language, and guaranteed to outlive jQuery the library. Aside from dot-chaining in a monadic sort of way, jQuery offers no benefit to the developer, while costing about 30kB of javascript.

[parineum]

> guaranteed to outlive jQuery the library

There's absolutely no reason to believe that considering those APIs add new features independently of each other. A library like jQuery can serve as an intermediary if browser A implements new feature X that is possible in browser B but through excessive (and slow) DOM manipulation.

jQuery can act as a bridge between the time browser A's implementation and browser B's.

[MrJohz]

There's not much added to the browser that's particularly independent (i.e browser A adds it with browser B having no plan to implement it at all), and when there are APIs that are perhaps newer and not widespread yet, it's usually easier to pull in a specific polyfill (or ponyfill) for that specific feature, rather than rely on one library that's trying to cover everything. Especially as those libraries tend to mimic the API as it is expected to be standardised, rather than implementing a distinct API as jQuery does.

In practice, I'd much rather use the native APIs to do things in the browser than a wrapper library, because I find abstraction from these wrappers tends to get in the way as often as it helps. With modern JavaScript (for-of, the spread operator, far more array functions), it's usually only one or two lines more code to do things the native way, and I find it saves me a lot of complexity down the line.

[gkbrk]

> There's not much added to the browser that's particularly independent (i.e browser A adds it with browser B having no plan to implement it at all)

You haven't seen the privacy nightmare APIs Google is trying to push on web "standards"? The only other two browsers, Firefox and Safari, are not going to implement most of them in the foreseeable future.

[azangru]

> the privacy nightmare APIs

Unless something has changed about jQuery, it is only concerned with DOM manipulation and data fetching. Do any of the privacy nightmare apis touch those areas?

[lalaland1125]

The problem is that most of the "abstractions" provided by jQuery are no longer abstractions and can frequently be replaced with simple alternatives that are directly provided by browser APIs that have extremely wide support.

https://youmightnotneedjquery.com/ is a handy illustration of this.

[evilotto]

I fail to see how replacing 1 line of jQuery with 10 lines of plain js is simple. Sure, you don't use those 10 lines all over the place, you write a function ... but then aren't you just recreating jQuery?

[franciscop]

Yes, and if you continue long enough you end up with one of the many jQuery alternatives, like mine:

https://umbrellajs.com/

[shadofx]

Yes but only the parts you need, which means better performance and job security.

[jefftk]

That site was very helpful when it first came out, but now that most of us don't even need to support IE11 it's assumption that you at least want to support IE10 is very stale.

[Gare]

What? Web APIs are one of the most stable APIs in existence. "Don't break the web" is taken very seriously.

[damon_c]

The context for this belief has only existed for about 10 years now.

[plorkyeran]

The phrase "Don't break the web" is a bit newer, but it's basically the sentiment that lead to WHATWG forming 18 years ago, and one of the big defining goals of HTML5 was to set a foundation for expanding the web platform in a backwards-compatible way. HTML5 has been out for about as long as the invention of the web to HTML5.

[8ytecoder]

More like half of that. I did web development in 2012. We couldn't have done it without jQuery.

[anotheracctfo]

Yeah that's what I'm afraid of. IE 5.5 diverging from Netscape 4 again.

Are we really betting on Microsoft, Google, and Apple not getting into a feature fight again?

[dudus]

They do get into feature fights often. See Apple not adopting PWAs, or IE focusing on blocking 3rd party cookies. But the parts that are covered by jQuery are solved and agreed upon.