jQuery to me is like riding a bike with training wheels attached after you've been riding for ten years. You don't need them, but unless you try taking them off you'll never know that.

Browser incompatibilities are basically a non-issue these days for 95% of projects. Animations etc are far better done with CSS than jQuery (particularly when it comes to hardware acceleration). The Fetch API works in every browser. So on and so forth.

I think the OP wasn't suggesting that "managing" without jQuery is difficult. Certainly, I can say that I haven't touched jQuery in years and haven't looked back once. There's nothing I miss.

> jQuery to me is like riding a bike with training wheels attached after you've been riding for ten years. You don't need them, but unless you try taking them off you'll never know that.

Why even use wheels when you can reinvent them? I'm not saying there are no reasons to go "bare metal", but satisfying your developer ego is not one of them. Unless you need every inch of performance or control, jQuery (or alternatives) is probably the more reasonable choice.

Why would it be the reasonable choice when it was created to solve a problem that largely doesn't exist any more?

jQuery wouldn't be created today in anything like its current form. It still lives on largely because of inertia. Using the APIs provided by the browser is in no way reinventing the wheel!

There is now a whole generation of FE developers for whom "JavaScript" is synonymous with "JQuery", as evidenced by endless questions on StackOverflow which use the terms interchangeable.

I agree with this sentiment wholeheartedly.

A lot of the commenters here have a very old school view of jQuery. They seem to believe that if you're using jQuery, then you must also be employing manual DOM manipulations, manual state management, etc.

You can implement modern component-ized front-end architecture while still using jQuery. My company built an in-house front-end framework heavily inspired by React and Vue. But instead of abstracting away from the DOM, we've embraced the DOM by utilizing DocumentFragments for highly performant rendering. When our components render, they return regular ole HTMLElements.

The components built using our framework work with or without jQuery. No manual DOM manipulations, one-way data binding, sane state management, templating, child components, state triggers, etc. A lot of us use jQuery simply because we prefer it's compact and expressive syntax.

Because the wheels are proprietary and full of quirks. For instance, $('.foo') returns an array of jquery objects and not HTMLElements that you can act directly upon using the standard API that was made for replacing it.

>The Fetch API works in every browser

As long as you're using recent versions. The whole point of jQuery is that you can write some code and be sure that it will run correctly in older versions of the browsers.

That's not the whole point of jQuery, it's just one advantage.

Well XMLHttpRequest has support going back to IE7.

> The Fetch API works in every browser.

No it doesn't.

> The point of JQuery is that I don't have to think about the various (slightly) incompatible implementations

Sure when jQuery was released in 2006, but browsers have had 12 years to improve their compatibility, and they have. Javascript has also had 12 years to improve and simplify its api, and it has.

Your analogy was perfect for jQuery 2006 but in 2018 its more like buying a car to drive around the city or you can just take an Uber, you don't have to walk anymore.

Tell that to those enterprise customers holding to IE 11, not allowing Chrome and doing their own timely releases of FF ESR.

Where I work we only just upgraded to IE11 - it was a decent-sized project, involving a lot of people and manhours.

I really wish we'd of just ditched it and moved to Chrome or Firefox :(

So you would have a decent sized project involving lots of people and manhours, but without support from your vendor?

If someone is developing web applications in such a way that they need support from their browser vendor to make them work properly ... they're doing it wrong.

I was assuming that the upgrade was more of an IT thing, that all the company computers are now on IE11.

Yes, that's correct.

We have a portfolio of hundreds of applications, and needed to make sure every one worked OK on IE 11 before upgrading from IE 9.

Also don't forget mobile browsers. I ran into a strange problem where Samsung's "Internet" didn't support something and could not find any online mention of this fact.

(I wish I could remember what it was. Perhaps an array method).