In 2019, it was easy to feel like every front-end conversation had moved on from jQuery.
React, Vue, build tools and component-based interfaces were taking up most of the attention. That made sense because they were changing how more complex interfaces were built. At the same time, a lot of real client websites still had jQuery sitting at the centre of their front-end behaviour. Menus, sliders, accordions, form validation, date pickers and WordPress plugin integrations were all often built around it.
That created a practical tension. I did not want to keep using jQuery out of habit, but I also did not want to rewrite working behaviour just because the industry conversation had moved somewhere else. The question I kept coming back to was not whether jQuery was modern. The question was whether it still made sense for the project in front of me.
Starting With Existing Websites
Most of the jQuery decisions I had to make were not being made on completely new applications. They were being made on existing WordPress websites, older themes or client projects that already depended on several plugins. In those environments, jQuery was often already loaded before I wrote a single line of code.
Removing it was rarely as simple as deleting one script. A plugin might depend on it. A theme might have small behaviours scattered across several files. A custom script written years earlier might be doing something important that nobody remembered until it stopped working. That meant the decision had to be made carefully.
I started treating jQuery less like a default choice and more like part of the existing environment. If the site already used it and the feature was small, it could still be perfectly reasonable to write the interaction using jQuery. If I was building a new interface from scratch, especially one with more state and repeated components, I would usually think differently.
Where jQuery Was Still Useful
The useful part of jQuery was still speed of implementation. Selecting elements, listening for events and making small DOM changes remained simple. For small interface behaviours, that simplicity mattered. A client did not care whether a menu toggle was written in modern vanilla JavaScript or jQuery. They cared that it worked, behaved properly on mobile and did not create maintenance problems later.
$('.menu-toggle').on('click', function () {
$('.site-navigation').toggleClass('is-open');
});That kind of code was easy to understand for anyone familiar with the stack. In a WordPress theme where jQuery was already present, using it for a small behaviour could be more practical than introducing a separate build process just to prove a point.
The mistake would be using that same reasoning for every piece of JavaScript. A small toggle is one thing. A dynamic interface with complex state is something else entirely. That was where jQuery started to feel less comfortable.
Where It Started To Feel Heavy
The problem with jQuery was not the library itself. The problem was how easily projects became a collection of unrelated behaviours attached to selectors. A click handler here, a resize listener there, an Ajax call somewhere else and a few plugins all modifying the same part of the page. That kind of code can work for a long time, but it becomes harder to reason about as the interface grows.
I noticed this most on sites that had been maintained for several years. Nobody had designed a messy JavaScript layer at the beginning. It had accumulated. Each new feature looked small enough to add directly. After enough small additions, the site had a front-end system that nobody would have chosen if they were starting again.
That is where I started being more careful. If a piece of behaviour needed state, lifecycle management or repeated rendering, jQuery was probably not the right place for it. If the behaviour was simple and sat comfortably inside the existing theme, it still had a place.
Moving Gradually Rather Than Rewriting Everything
I have never liked rewrites that happen mainly because the old tool feels unfashionable. Rewrites are expensive, and they often recreate bugs that had already been solved years earlier. In 2019, the better approach for many projects was gradual replacement.
That meant isolating new code, avoiding further dependency on old patterns and moving specific pieces of behaviour when there was a practical reason. If I touched a messy area of JavaScript as part of real project work, that was a sensible moment to improve it. Rewriting the entire front end before anyone had asked for a change was much harder to justify.
This was especially true in agency work. Clients usually want outcomes, not technology migrations. The technology matters, but it has to connect to maintainability, performance or future delivery. Otherwise it risks becoming developer preference dressed up as strategy.
Retrospective Thoughts
Looking at jQuery in 2019, I think the healthiest position was somewhere in the middle. It was no longer the automatic answer to every front-end problem, but it was also not something that had to be removed from every working website immediately.
The important part was being honest about why it was being used. If jQuery made a small feature quicker to build inside a site that already depended on it, that was fine. If it was being used to hold together a growing interface that really needed a clearer structure, then it was time to think again. That distinction mattered more than the tool itself.