This comes with the big disadvantage of jQuery, everyone and their dog knows it and dogs are not great coders.

Did you mean "hire" or where you intentionally trying to make it sound like you're abducting programmers off the street and hiding them in your basement?

tldr; jQuery's success was not innovation or unification, it was an easy to pick up syntax. From there it was all inertia.

The last two products I've worked at has had an audience that includes individuals who either cannot or will not upgrade their web browser. They are stuck on whatever their IT department froze their browser version to year(s) ago. This could be internet explorer 9 or some ancient version of Firefox or Chrome.

The individuals in this circumstance always amount to what some might consider to be a negligible amount of people (Probably less than 2%), however, I've always been unable to construct a good argument for why we should be unwilling to support 2% of our customer base when using a good cross-browser compatible library like jQuery from the start can save the argument from even taking place.

I suspect this is more the nature of working on B2B apps than B2C, although I do wonder how many people are actually looking at the browser analytics of their audience when they are so willing to forsake jQuery for "vanilla javascript".

https://www.w3counter.com/globalstats.php

Sure, okay, I'll tell my CEO that 2% of our customers just don't matter, becuase - yanno, the progress of the internet needs to happen.

Or I could just use jQuery from the start and not think about this problem again.

At the moment, I get the feeling that if I start with vanilla JS, at some point I'll need features that only jQuery provide, so I'll either have to reimplement them in my project, or backpedal and add jQuery.

Edit: another reason: slideUp() / slideDown() are very useful and not easy to implement with native code.

- unhandled errors silently swallowed [1] (this is the case for the most popular polyfill [1] too - the one recommended by fetch polyfills, BEWARE [3])

- no 'finally' method, despite pretty much everything in a UI needing some common 'cleanup' after e.g. a fetch()

- not cancellable

Right now you're better off with `$.ajax` (maybe make a custom build of jQuery) or a promise-like library like reqwest [2], rather than fighting with fetch.

[1] https://github.com/stefanpenner/es6-promise/issues/70#issuec...

[2] https://github.com/ded/reqwest

[3] http://requirebin.com/?gist=8f13d5147c1c252ab1691115bfa8b7c5

I think that's the thing. Unless you write your own utility library or use someone else's it's often more verbose, more fragile and less intuitive.

And if you do use a library, probably one for each feature, why is it better to have a handful of dependencies than one?

In a year I will be able to reach out to the community for support on jQuery. Will I for all of these small tools?

Cross browser compatibility and legacy IE support.

I disagree that jquery's API is convoluted.

And what is wrong with sugar syntax? One can argue that most of es7 is sugar syntax, but we are happy to use it since it makes your code more terse while remaining readable

https://github.com/github/fetch

Among countless others. Please don't bring in all of jQuery if you're just going to use one function from it.

http://youmightnotneedjquery.com/

var request = new XMLHttpRequest(); request.open('GET', '/my/url', true);

request.onload = function() { if (request.status >= 200 && request.status < 400) { // Success! var data = JSON.parse(request.responseText); } else { // We reached our target server, but it returned an error

  }

request.onerror = function() { // There was a connection error of some sort };

request.send();

OR

Even better, you should just use a reactive front end framework. https://vuejs.org/ combined with https://github.com/vuejs/vue-resource is currently my fave.

Just use jQuery. Please.

vue.min.js is 75k. vue-resource.min.js is 13k.

So jquery is smaller.