- It implements The God Object antipattern.
- Solution: there’re lots of npm modules, solving each that task separately and efficiently.
- It violates Separation of Concerns principle.
- There’s a separate solution for each jquery’s concern: polyfills for bugs, npm packages for features, browserify/component/web-components for "plugin system".
- It is excessive - where you may only need 1kb, you use 30kb.
- Use atomic point modules and you will reach theoretically possible minimum size.
- It causes extra-load - memory, traffic, performance.
- Separated modules provides theoretically best values in each aspect.
- It wraps events so that you’re unable to catch callback in debugger.
- Using native events/wrapper like emmy provides native unhindered events.
- It taints natural DOM elements/objects so that you have to discern jquery sets from native lists.
- Use dom tools like queried to query/traverse DOM.
- It lacks of modularity.
- Use CommonJS/ES6-modules with browserify to attach components.
- It is conjuncture technology, that means should be replaced with native means in some future.
- Better choose ES6/web-modules/npm for that - they are the most basic tools and won’t be replaced.
- If you have a small component, 30kb is huge for extra dependency.
- Use vanilla JS for that.
- Once you built your code with jQuery, you can’t that simply remove it.
- Use atomic modules to minimize centralization and provide high-level replaceability.
- It is obtrusive for DOM-elements.
- Using weak-map provides the most safe way to bind data to element.
- It implements promises/deferreds mistakenly, so that people once learnt jquery deferreds face troubles understanding natural promises.
- Learn native promises or q.
- Using jQuery you contribute to not developing native frontend tools.
- Using jQuery you strenghten jquery’s position as a pervert de-facto standard.
NOTE: Negative reason is not the reason for negation, but as far for each con there’s a proper solution - you really should choose it.