jQuery Is Not Dead

The Bridges Still Stand

Ancient Romans built bridges. Many of them still stand today. Many of them are still in active use. There must be a reason for it. jQuery is a JavaScript library for web coding. It can be used to implement all kinds of web-based user interfaces or just enhance static pages. jQuery was the king of web development in the 2010’s. Similarly to Roman bridges, jQuery still stands. There must be a reason for it.

The Rise of Modern Frameworks

In the late 2010’s, other types of libraries became popular. The era of ReactJS, Angular, and Vue began. The main difference between jQuery and these other kinds of libraries was that while jQuery targeted manipulating the HTML elements (DOM hierarchy) and the CSS styles of the web page, ReactJS, Angular, and Vue’s purpose was to offer a comprehensive framework for building web applications.

Building Complex Apps: A Different Approach

It appears that jQuery went out of fashion when these other kinds of libraries emerged. However, using jQuery it was possible to build very similar complex web applications very similarly to these other ones, especially when you combined it with some templating libraries like Handlebars, Mustache or EJS.

Imperative vs. Declarative: A Philosophical Divide

The difference between jQuery and these others was that you could very straightforwardly, imperatively, dynamically modify HTML elements, whereas ReactJS and others where more declarative and discouraged the JQuery kind of approach as “hacky”.

While jQuery simplified the direct manipulation of the existing real DOM hierarchy inside HTML, these libares used a virtual DOM to indirectly update the underlying real DOM.

Missing jQuery’s Flexibility

Personally, I switched from jQuery to ReactJS sometime around 2017, when it seemed like ReactJS was required in almost every project.

There was a lot of good in React, but I still felt like there was a lot of low-level stuff, timer- and native browser-event based stuff, that was really difficult and clunky to implement with React only, compared to how easily you could do tricks with jQuery.

Technically speaking you could still embed jQuery into React to complete things that would be tricky with React alone. But many people would think that’s an antipattern because then you’d be mixing two different philosophies into your code logic, imperative and declarative. So be it. That’s why I left jQuery out of my toolbox for years. Things were going well. Everything was React. If you were going to code a new application, you would do it with React.

A Modern Dilemma on a Legacy Site (Spring 2025)

Years later, in the spring of 2025 to be exact, I encountered a new kind of dilemma.

Look, I can reveal that this blog you’re reading now is built with the Jekyll static page generator on GitHub Pages. It’s really simple. It’s been doing its job for many years. Now the problem was that when I wanted to add AI-generated videos to the page and I knew that this could make the pages very heavy if I just embedded the files directly into the HTML. I wanted to modify the page so that the video would only load after it entered the viewport and the user had not scrolled for a couple of seconds. Before that, it would just show a placeholder.

Of course, you can’t do this with any static HTML. I was faced with a difficult decision. Should I really throw this easy and good Jekyll in the trash and recode the entire blog with ReactJS or possibly Blazor from scratch? It seemed like a fairly big job considering that I just wanted to get this thing working, and as a freelancer I can’t start endlessly tinkering with something like this when I have to find a project and feed my family.

Rediscovering an Old Friend: jQuery to the Rescue

Luckily, I suddenly remembered jQuery from many years ago. I could just inject a small piece of code into this Legacy blog of mine and get what I needed to move forward. And it was as easy as pie!

Just scroll through this site and you’ll notice that I’ve implemented lazy loading video clips here.

The Enduring Power of jQuery

jQuery is an amazing tool. It’s like a spider. It’s like an amoeba or an octopus. You can inject it into any legacy website and it works wonders. You can breathe new life into old creations with little effort and extend their lifespan indefinitely.

Still Relevant: The Numbers Don’t Lie

jQuery was found obsolete if not entirely dead by 2017 by the common consensus in the tech community. This once-beloved cuddly puppy was suddenly out of favor, abandoned by the cool kids of the dev neighborhood. It was doomed to fade away with the dawn of new declarative libraries like ReactJS and others.

Buying into that narrative, jQuery should be dead by now, many times over, and resting long-forgotten in its overgrown grave.

But the evidence is not adding up when we dig in to investigate jQuery’s death. We would expect to see a downward trend in jQuery’s downloads over time. But that isn’t the case. There isn’t even a single dip since 2017. Quite the opposite, jQuery’s downloads have been steadily increasing since 2017 and recently even accelerating. Looking at current download frequency on npmjs.com, we see that jQuery has been downloaded past week nearly 14 million times. Not bad for a dead library!

Embracing Tolerance: Lesson from Other Industries

This experience highlights a broader point about our industry’s relationship with “legacy” code. We need more tolerance for it, much like how legacy infrastructure is tolerated elsewhere. Think about it: IPv4 protocol hasn’t been completely ditched just because IPv6 was created; it’s still fundamental to the internet. Look at ancient Roman bridges – built with outdated technology, yet many still stand and serve their purpose today. We don’t demolish them simply because we have newer construction methods.

Just think about the insane return on investment of those bridges over the past 2,000 years!

The Maturation of Software: A Source of Strength

Software that has been actively developed for 3 or 4 years often reaches a mature state. It’s likely feature-rich and stable, hitting a tipping point where adding new features on top becomes efficient. It has been costly to write the software, but the tables are starting to turn at this point. A break-even inches closer. Your investment is about to start paying off. Everything is set for starting to make real money.

Naturally, parts of its codebase will reflect the tools and patterns available when they were written – they become partially ‘legacy’. This maturity, however, is often a strength, not a weakness demanding a complete teardown. Of course, code can and often should be partially updated or refactored over time.

The Pitfalls of Impatience: The Cost of Rewriting

Yet, sometimes there’s an impatience, a very low tolerance for anything not built with the absolute latest tools. Sometimes, fueled by the excitement of new technologies, there can be a rush to advocate for complete rewrites without fully weighing the cost of discarding years of development, testing, and accumulated business logic embedded in the existing system.

The choice isn’t always binary between “state-of-the-art” and “obsolete trash”. Often, the most pragmatic, cost-effective, and responsible path is to enhance and maintain what exists, respecting its history and proven value.

Resisting the Pressure for Constant Reinvention

Or you can succumb to the pressure to blow up everything you’ve done and rewrite it all from point 0 whenever the next ‘cool new framework’ is loudly proclaimed as the only way forward, lest we be branded dinosaurs buried in tech debt.

Conclusion

Ultimately, progress often requires tolerating some imperfection. Demanding absolute purity can prevent us from building anything great at all.