jQuery in a Modern Codebase
Most of what jQuery was built to fix — inconsistent browser APIs, no fetch(), verbose DOM methods — has since been fixed by browsers themselves or absorbed into the language. That doesn't make jQuery obsolete everywhere; it makes the decision to reach for it a more deliberate one than it used to be.
Where plain JavaScript has caught up
document.querySelector()/querySelectorAll() now cover selection with the same CSS syntax jQuery uses. fetch() covers AJAX with native Promises. classList.add()/.remove()/.toggle() cover class manipulation. element.style covers inline CSS. The CSS-transition-based approach to animation (or the Web Animations API) covers most of what .fadeIn()/.slideToggle() used to be needed for. For a brand-new project, most of jQuery's original value proposition is now built into the browser for free — no 30KB library download required.
Where a framework has taken over
For anything with real interactive state — a form that re-renders as you type, a list that reorders itself, a UI with several components reacting to each other — React, Vue, and similar tools manage the relationship between data and the DOM far more reliably than hand-written jQuery ever could. jQuery has no concept of "state" at all; you're always manually keeping the DOM in sync with whatever your data currently is, which gets fragile fast as an app grows.
Where jQuery still earns its place
- Maintaining an existing codebase. Countless production sites, admin panels, and WordPress themes/plugins are built on jQuery, and rewriting working code just to remove a dependency is rarely worth the risk.
- The WordPress ecosystem. WordPress ships jQuery by default and much of its plugin ecosystem depends on it — if you're working inside that world, you're working with jQuery whether or not you'd choose it fresh.
- A quick, no-build-step page. A single CDN
<script>tag with no bundler, no compile step, and consistent cross-browser behavior is still genuinely convenient for a small internal tool or a prototype.