I think that the main reason that jQuery is looked down on (based on several blogs I’ve read) is because its so “hacky”. You’re manipulating the DOM directly, which is comparably slow.
jQuery also has no support for variable interpolation (you need to directly modify the contents of DOM elements, rather than the contents of the DOM being bound to variables in your JS code). This makes it hard to use jQuery for data-driven applications where you just want to change, for example, one word in a sentence. With jQuery you need to modify the entire contents of the tag containing that sentence. With, for example, Angular you could just change a variable in your JS and the HTML would automatically be updated.
It’s also very difficult to write a segment of HTML that can be reused over and over again. This can make your code very repetitive and thus, brittle.
Having said all that, jQuery really is a fantastic library for small scale applications/sites. If you are making something small, then including a large library could really cause a lot of overhead in your application, for absolutely no reason.
For your side note, there are two ways (that I’ve found, I’m only new to Node though) to work with jQuery. One is to create a static path that points to your
node_modules folder and then required files will be served from there (I have no idea if this is best practice, but I felt uncomfortable exposing all of the modules for the sake of two or three client side libraries) or to copy the scripts that you need into your
public directory, using a build script. That way they will get served alongside the rest of your static, client-side assets. If you’re interested, I actually just wrote a build script to do exactly that last night. It would have been easier to use Gulp or some other task runner, but I wanted to see if I could do it in pure JS.