Last night, I was working on a side project. For the front-end, I'm using React, React-Route, and I'm working on figuring out Fluxible. superagent to wrap XmlHttpRequest. browserify to compile what I serve to the front-end. I don't run a reverse-proxy with a node backend since the API is in PHP, I just served the minified JS files.
Honestly, it's a huge pain. And every module I toss in there seems to limit compatibility with the next one. The barrier of entry to doing things right is HUGE. Also, if you disable JS the site would be useless, 100%.
If I were to go with angular it would be even worse. I honestly may go back to jQuery on this project yet. I don't expect it to be huge, and since most Foundation plugins use jQuery anyway it should work. I honestly loathe how much crap I'm loading for two pages: sign-up / register.
I've had a very hard time getting things like react+react-router+reflux to all work together as expected. It's not been super fun as a way of working.
And I dunno if your situation is the same as mine, but all the "contemporary" JS stuff I work with (react, etc) is for side work, that is, stuff that I am building explicitly because I want to play with the stack.
So the reaction that "you don't need all that" is probably missing the point (at least if your situation is like mine): I do things like that because I want to see how stuff works, and it's better than doing it on my $$$ projects.
But at this rate it seems like it needs to mature a bit and settle down before I should use it.
Sorry, but this is entirely your fault. You don't need any of what you mentioned to do this. You can just use jQuery if that works for you. No one except really bad junior devs on here or Reddit will say you are doing things "wrong".
PS: Use fetch instead of superagent.
Blog post - https://jakearchibald.com/2015/thats-so-fetch/
Also sinon.js couldn't mock it, and dealing with error cases is inelegant (it doesn't look like much extra code, but is hard to justify if you're just writing a small component that hits one endpoint, in terms of weird new code to explain to your teammates that is).
I have gone back to $.ajax for now, though I do mean to try out qwest  when I get the chance. Seems to be both tiny and also have a sane promise-y API.
The (promises) spec is lacking w.r.t. this use-case, and most ajax libraries (and a lot or promise libraries) recognise this by implementing a 'finally' equivalent.
Never used axios but I've heard good things about it and its creator is awesome. I just use fetch because it does what I want.
he needs most of the libraries only on two pages: login and register. i sincerely doubt his site only has these two.
.load, .unload, and .error, deprecated since jQuery 1.8, are no more. Use .on() to register listeners.
jQuery.Deferred is now Promises/A+ compatible
Error cases don’t silently fail
Animations now use requestAnimationFrame
Massive speedups for some jQuery custom selectors
Finally. Our old codebase is using quite a lot of jQuery deferreds and, well, Promises/A+ clearly improved a lot of things API-wise.
Using this selector heavily can have performance implications, as it may force the browser to re-render the page before it can determine visibility. Tracking the visibility of elements via other methods, using a class for example, can provide better performance.
What always impresses me with jQuery is the amount of features they're able to pack in 250 Mb of uncompressed code. They've got browser events, ajax and a crapload of selectors. Compatible with most browsers. Oh and performance is nice as well. Kudos to the jQuery developers!
we use jquery in an angular code base and have long wanted a build without Ajax which is huge and that is useless in angular
1. A few other libraries still depend on jQuery in turn, so I find that I still usually have it available in every app I work on anyway, so I might as well use it.
2. It "just works" and I already know it, and since it's already there, anyway (see (1) above) it just makes sense to use it. IOW, I don't feel enough pain from using jQuery to justify going off and learning what combination of new ecmascript (es6? es7? es9037253223252??? ???) features and/or libraries du jour that I would need to do everything jQuery does for me now.
Plus, wouldn't actually using Vanilla JS be faster?
Right now it looks like people use JQuery for legacy code. But, they give no reason to use it for new projects, except if they need it for other libraries they're going to use. (based on legacy code anyways...)
So jQuery is still wonderful at what it does, but there isn't much reason to be directly manipulating the DOM now that there are alternatives.
It's a bit like the perl of web page JS for me. I wouldn't recommend writing a full complex application in it - although that is possible and by people who know what they're doing can be done cleanly and organised... but for super quick hackery, it's hard to beat.
You can check the documentations here:
Those methods are quite powerful.
And it's the default choice for any complex web data visualization project.
In D3 you can do selection.classed('active', false). This is equivalent to toggleClass().
According to jQuery's API, show() "... is roughly equivalent to calling .css( "display", "block"), except that the display property is restored to whatever it was initially." Instead of show, you can just do selection.transition().duration(300).style(display, 'block').
"jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application.
"If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with."