Every conference talk this year seems to be about React or the newly released Vue 2, and for good reason — for full applications they are the right tool. But a meaningful chunk of our work is still small, self-contained widgets dropped into an existing WordPress or static site: a mobile nav toggle, a simple image carousel, a form validator, a "read more" expander on a long blog post.
Why jQuery still wins these jobs
For those jobs, pulling in a build step, a component framework, and a bundler is overkill. jQuery still lets us write a fifteen-line script, drop it in a `<script>` tag, and move on, with no npm install, no webpack config, and nothing for the client's own developers to maintain that requires a modern JavaScript toolchain to even open. A lot of our clients are small businesses whose "developer" is a marketing person who occasionally edits a WordPress template — asking them to run a build step to change a button's hover behavior is not a reasonable expectation, and would turn a five-minute fix into a support ticket back to us every time.
Where the line actually is
We draw the line roughly like this:
- A handful of interactive widgets on an otherwise static or WordPress-templated site: jQuery, every time
- A page with several independent widgets that do not need to share state or communicate with each other: still jQuery, since introducing a component tree for pieces of UI that genuinely do not relate to each other adds structure without adding value
- Anything with meaningful client-side state that needs to stay in sync across several pieces of UI: Vue or React, since jQuery's DOM-first approach makes state management its own recurring headache once you pass a certain complexity threshold
- A single-page application with routing and a real component tree: React or Vue without question, jQuery is simply the wrong tool at that scale
The cross-browser argument still holds too
It is easy to forget that jQuery's original selling point — smoothing over inconsistent browser behavior — still has some relevance for the older browsers a handful of our clients' audiences still use in meaningful numbers, particularly older versions of Internet Explorer that some corporate and government clients are stuck supporting for internal tools. jQuery's compatibility layer for event handling and DOM manipulation quietly saves us from writing our own polyfills for cases a modern framework's tooling does not always account for out of the box, and for a client whose analytics show a nontrivial slice of visitors on IE10, that compatibility is not a theoretical concern.
What we have actually retired
To be clear about what has changed rather than just what has not: we no longer reach for jQuery UI's heavier widgets — the datepicker, the accordion, the tabs component — since lighter, purpose-built vanilla JavaScript libraries or small Vue components now cover those cases with less weight and better mobile behavior. We also do not use jQuery as a dependency inside a Vue or React project just out of habit, which used to happen more than it should have on projects that started as a jQuery site and grew a framework-based feature bolted on later. Mixing jQuery's direct DOM manipulation with a framework's own virtual DOM diffing is a reliable way to create bugs where the two disagree about what the DOM currently looks like, and we treat that combination as a hard no on any new work.
The actual cost-benefit for our clients
For the smaller clients this decision mostly serves, the calculus is straightforward: a WordPress site with three or four small interactive touches does not benefit from the added build tooling, dependency management, and bundle size that a component framework would bring, and it does add real cost in the form of a slower initial page load, since even a lean framework bundle is heavier than a fifteen-line jQuery snippet plus the jQuery library itself served from a CDN with a long cache lifetime shared across half the web.
We are not building new single-page applications with it, and we would push back hard on any proposal to do so. But retiring it entirely from our toolkit would mean reaching for heavier tools on jobs that do not need them, adding build complexity to sites whose maintainers cannot reasonably be expected to deal with it, and losing a genuinely fast way to ship small, well-understood interactive pieces. jQuery earns its place in our toolkit by staying in its lane, and as long as that lane keeps showing up in client work, we expect it to stay there for a good while yet.
How we brief clients on this without it sounding like an excuse
Explaining this decision to a client who has read that "jQuery is dead" in some blog post is its own small skill. We have found the framing that lands best is cost and appropriateness rather than defending jQuery's technical merits in the abstract: a five-widget marketing site built with a full framework and build pipeline is not more impressive or more future-proof, it is more expensive to build, slower to load, and harder for a non-technical maintainer to touch later without breaking a build step they do not understand. Most clients, once the tradeoff is framed around their own maintenance costs rather than which technology sounds newest, are relieved rather than disappointed that we recommended the simpler option.
What we watch for as a signal to switch mid-project
Because client sites tend to grow features over time, we keep an eye on a specific signal that tells us a jQuery-based site has outgrown the tool: once a page's interactive widgets start needing to read or react to each other's state — a filter widget that needs to update a cart summary elsewhere on the page, say — the spaghetti of custom events and shared global variables that jQuery pushes you toward becomes a liability faster than most people expect. At that point we have a direct conversation with the client about migrating that specific page, or that specific feature, to a small Vue component rather than continuing to extend the jQuery version, since patching state-management problems with more jQuery tends to make each subsequent change slower and riskier than the last.
The maintenance reality a few years in
We have jQuery-based code from client sites that is now several years old and has needed essentially no attention beyond the occasional plugin version bump for a security patch. That kind of quiet, low-maintenance stability is easy to undervalue when comparing frameworks on a whiteboard, but it is exactly the property a lot of our smaller clients actually want from their web presence: something that keeps working without requiring an ongoing relationship with a developer just to keep the lights on. For those clients specifically, jQuery's boring reliability is not a compromise, it is the whole point.
What we tell junior developers who only know frameworks
A growing number of the developers we hire have learned web development almost entirely through React or Vue tutorials, and have genuinely never written plain jQuery, or in some cases plain vanilla JavaScript DOM manipulation, before joining us. We treat a short jQuery-based onboarding task — build a working accordion or a simple filterable list with no framework at all — as a deliberate part of ramping up new hires, not out of nostalgia, but because understanding what a framework is actually abstracting away makes someone a noticeably better framework user afterward. Developers who have only ever called `setState` and never manually manipulated a DOM node tend to have shakier intuitions about what is actually happening during a re-render, and that gap shows up in subtle performance bugs down the line.
Bundle size numbers that still surprise people
We occasionally run the numbers again just to keep our own assumptions honest, and the gap has not really closed: jQuery itself, served from a shared CDN with an extremely long cache lifetime that a meaningful fraction of visitors already have cached from another site entirely, effectively costs many client sites nothing at all to load. A minimal Vue or React setup, even a lean one, is realistically tens of kilobytes of framework code that must be downloaded, parsed, and executed before a single line of the actual application logic runs, on top of whatever the application itself weighs. For a five-widget marketing site, that difference is the entire justification, restated in numbers rather than opinion, for reaching for the lighter tool.
A specific recent example
A client asked us this year to add a simple "sticky" header that shrinks on scroll to an existing static site with no other interactivity at all. It would have been possible to justify pulling in Vue for this single feature, treating it as an investment in "modernizing" the site's stack. We built it in nine lines of jQuery instead, shipped it the same afternoon, and the client has had zero issues with it since. Every time we are tempted to reach for a heavier tool out of habit or resume-building instinct rather than actual project need, a small, boring success like that one is a useful reminder of what the job actually is.