DEV Community

Cover image for jQuery Will Outlive Half of Today’s JavaScript Frameworks - Here's Why
Sylwia Laskowska
Sylwia Laskowska

Posted on

jQuery Will Outlive Half of Today’s JavaScript Frameworks - Here's Why

#javascript #discuss #webdev #programming

Everyone loves declaring jQuery dead.
And yet - 2025. It’s still here. Not starring in any conference talks, not topping npm charts…
but running quietly in production on ~78% of the top 1M sites (W3Techs) and hundreds of millions of websites total.

So maybe the real question isn’t “why is jQuery still alive?”
but rather:

Why do we expect old code to disappear just because we found a cooler way to write new code?

After a five-year break, I’m returning to the conference stage. On November 19th, I’ll be speaking at JS Poland about practical strategies for migrating legacy frontend systems to modern architectures.

To lead up to the talk, I’m publishing a short series of articles on legacy code, refactoring, and incremental migrations — this is the first one in the series.

If you’ll be there, feel free to say hi — I’m always up for a good legacy-code war story 🛠️.

jQuery is not “alive” - it’s installed.

jQuery isn’t winning the frontend race.
It already finished it years ago, shipped to production, and is now sitting in long-term maintenance mode…
exactly like COBOL in finance systems.

Nobody wants to rewrite an old COBOL banking backend - but they also can't just delete it.

jQuery is the same, just for the web.

🧠 Misconception: “Modern JS killed jQuery”

Yes - the browser finally caught up.

// jQuery
$('#btn').on('click', () => $('#box').addClass('active'));
Enter fullscreen mode Exit fullscreen mode 
// Modern JS
document.querySelector('#btn').addEventListener('click', () => {
  document.querySelector('#box').classList.add('active');
});
Enter fullscreen mode Exit fullscreen mode

Native DOM APIs finally do almost everything jQuery used to fix.

✅ Query selectors
✅ Class manipulation
✅ Event binding
✅ AJAX → fetch()
✅ Animations → CSS + Web Animations API

So why is jQuery still everywhere?

Because fixing the past is way more expensive than building the future.

🧱 The uncomfortable truth: refactoring doesn’t pay bills

Most jQuery code isn’t “bad.”
It’s just old, tangled, DOM-first, and impossible to replace safely in one go.

The real blockers:

Problem Why jQuery stays
🧩 Business logic glued to DOM no clean separation to migrate
🔌 3rd-party plugins no React/Vue/Svelte versions exist
💸 Rewrite has no ROI “Works now, don’t touch it”
🛒 WordPress, Shopify, Drupal ecosystems built on jQuery
🧨 Migration risk you break checkout → you lose money

The business perspective is brutally simple:

“Does rewriting jQuery bring new revenue?”
No. It only reduces technical debt.
And debt is only paid when it starts to hurt.

📊 Data check: frameworks die faster than legacy code

Thing Average lifespan
JavaScript frameworks ~5–7 years of relevance (React is a rare longer-lived exception)
Real commercial apps 12–20 years
WordPress share of web ~43% (jQuery in core)
Sites still using jQuery ~78% of top 1M

Frameworks come and go:
AngularJS (dead), Backbone (dead-ish), Ember (barely breathing), Meteor (remember that one?).

jQuery?
Not evolving. Not trending.
Just quietly on production servers, powering money-making code.

🧑‍🎓 Should juniors learn jQuery in 2025?

Short answer: No.
Not as a first tool. You don’t learn medicine by studying outdated procedures as your entry point.

jQuery doesn’t teach:

  • components
  • reactivity
  • state management
  • bundlers
  • SSR / hydration
  • scalable architecture

It teaches DOM scripting. And that’s not modern frontend anymore.

🧑‍💼 Should seniors understand jQuery?

Yes. Absolutely.
Not to write it - but to delete it safely.

A senior who can’t read legacy code is just a React developer, not a software engineer.

You don’t get paid to build shiny new things.
You get paid to keep existing things alive without breaking production.

Real senior skill today:

“I can refactor a jQuery-heavy feature into modern code without breaking the checkout button.”

🏗️ Why full jQuery removal rarely happens

Because real migrations look like this:

  1. Ship new UI in a framework
  2. Leave old jQuery modules running in parallel (strangler)
  3. Promise “we’ll clean it up later”
  4. Later never comes

You don’t “remove jQuery.”
You encapsulate it, shrink it, quarantine it.
And one day, after 5+ years, you realize only 3 old widgets still depend on it… and that’s good enough.

That’s not laziness.
That’s economic reality.

🧩 WordPress: the elephant in the room

  • ~43% of websites run on WordPress
  • WordPress core still ships jQuery (updated, but still required)
  • Tens of thousands of themes/plugins depend on it
  • Most won’t ever be rewritten

Even if every frontend dev stopped using jQuery today, WordPress alone would keep it alive for another decade.

🧨 The real punchline

jQuery isn’t “alive” because it’s good.
It’s alive because the cost of deleting it is higher than the cost of keeping it.

That’s not a technical decision.
That’s economics + risk management + legacy entropy.

🔚 Final verdict

Is jQuery the future? No.
Is it “dead”? Also no.
It’s the COBOL of the frontend - old, uncool, irreplaceable in millions of systems.

Modern frontend dev means two skills:

✅ Build the new stuff right
✅ Understand the old stuff well enough not to break it

🤔 Your turn

  • Have you ever tried to remove jQuery from a production app? How did that go?
  • Do you think companies should budget for refactoring - even without direct ROI?
  • Will we still see jQuery in 2035? (I’ll bet yes.)

📬 Like content about legacy, migrations and real-world frontend?

I share more on my Substack:

👉 sylwialask.substack.com

No hype. No frameworks of the week.
Just real software reality.

Top comments (3)

Collapse
 
dariomannu profile image
Dario Mannu •

Tried once, with the "one component at a time" approach.

One of the best aspects of jQuery many people don't realise is that it's a library and not an obtrusive opinionated framework, so it's easy to sneak in some other similarly inobtrusive libraries that can coexist with it, or potentially enhance it.

Here's a little example of how we added rxjs and rimmel.js inside some existing jQuery code to add various pieces of advanced interactive functionality:

const counter = new BehaviorSubject(0).pipe(
  map(n=>n+1)
);

$('#some-element').html(() => rml`
  <button onclick="${counter}">click counter be like</button>
`);

$('#some-other-element').html(() => rml`
  <div>
    Count: <span>${counter}"</span>
  </div>
`);
Enter fullscreen mode Exit fullscreen mode

this way we only enhance existing jQuery code where it's convenient, leaving the rest untouched.

The benefits of reactive components and various stream-oriented patterns become quickly apparent: very few lines of code, just as powerful as rxjs can take you.

Most of this would have been much less straightforward (or outright impossible) in an Angular or React application, so kudos to jQuery for being so unobtrusive and easy to work with.

Collapse
 
junothreadborne profile image
Juno Threadborne •

I love this:

fixing the past is way more expensive than building the future.

So true. And you're right. This is the same reason WordPress will never go away. There are a million new (and often better) ways of building a site with CRM-like features, but WordPress does it in one package. Similar story with jQuery. It got the job done well. Should you use it today? Almost certainly not. Does it still get the job done if you do? Of course. And that's the beauty of it.

Collapse
 
sylwia-lask profile image
Sylwia Laskowska •

Exactly! I remember building WordPress sites a few years back, and honestly — it just didn’t make sense to use anything else. WordPress had everything in one box, and it worked.

Suggesting something like “let’s build a headless React frontend” for a simple website felt less like good engineering and more like upselling the client for no real benefit 😅

(As long as we’re talking about a straightforward marketing site, not a complex app.)