jQuery: The COBOL of the Frontend

It's a popular sport on tech Twitter and Hackernews to declare jQuery dead. And yet, here we are. It's not headlining any conferences, and it's not topping npm charts, but it's quietly running in production on an estimated 78% of the top 1 million websites.

So, the real question isn't "why is jQuery still alive?"

The real question is: Why do we, as engineers, expect working code to just vanish because we found a better way to write new code?

This isn't another "jQuery vs. React" post. This is a post about economics, risk, and the code you actually get paid to manage. The core idea is simple: jQuery isn't "alive" because it's good. It's "alive" because it's embedded.

Why We Think It's Dead (And Why We're Right)

Let's be clear: for any greenfield project, jQuery is obsolete. The original problems it solved are now handled by the browser itself.

• Query Selectors: $ is just a wrapper for document.querySelectorAll().
• Class/Event Binding: element.classList.add() and element.addEventListener() are standard.
• AJAX: fetch() is a modern, promise-based standard.
• Animations: CSS transitions and the Web Animations API are more performant.

The browser caught up. Technically, you don't need jQuery. So why is it everywhere?

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

The Real Blocker: Economics, Not Tech

Most jQuery code isn't "bad" in the sense that it's broken. It's "bad" in the sense that it's old, tangled, and was written with a completely different paradigm: direct DOM manipulation instead of declarative, state-driven UI.

That old code is a minefield. And here are the real reasons it never gets rewritten.

1. Refactoring Has No Business ROI

From a product manager's perspective, the logic is simple:

PM: "What does this task accomplish?" Dev: "It replaces our old, working jQuery checkout form with a new, working React checkout form." PM: "Will it bring in new revenue? Or add a new feature?" Dev: "No. But it reduces technical debt." PM: "We'll pay that debt when it starts costing us money. Backlog."

Technical debt is only paid when the "interest" (in the form of bugs or slow feature development) becomes unbearable. Until then, "if it works, don't touch it" is the law.

2. Logic Glued to the DOM

This is the real technical nightmare. Old jQuery code doesn't have a clean separation of concerns. The business logic is the view logic.

Take a look at this snippet. This is the kind of code holding up a million e-commerce sites.

// This code is in a 2,000-line global.js file
// and it works. Don't touch it.
$('#submit-order-btn').on('click', function() {
  var total = 0;
  
  // 1. Business logic tied directly to DOM structure
  $('.cart-item').each(function() {
    var price = parseFloat($(this).find('.item-price').text());
    var qty = parseInt($(this).find('.item-qty').val());
    total += price * qty;
  });

  if (total > 50) {
    // 2. More direct DOM mutation as a side-effect
    $('#shipping-cost').text('0.00');
  } else {
    $('#shipping-cost').text('5.00');
    total += 5.00;
  }
  
  var discountCode = $('#discount-code').val(); // 3. Reading "state" from the DOM

  // 4. API call embedded right in the handler
  $.ajax({
    url: '/api/submit-order',
    method: 'POST',
    data: { total: total, code: discountCode },
    success: function(response) {
      $('#order-status').text('Success! ID: 'J + response.orderId);
    },
    error: function() {
      $('#order-status').text('Error, please try again.');
    }
  });
});        

How do you refactor this? You can't just "replace it with a React component." You have to first excavate the business logic. You have to trace every .find(), .parent(), and .val() to understand what the intent of the code was, all while having zero test coverage.

The risk of breaking the checkout button is too high. And if you break checkout, you lose money.

3. The Ecosystem Elephant: WordPress

Let's talk about the 800-pound gorilla.

• WordPress runs ~43% of the entire web.
• WordPress core still ships with and requires jQuery.
• Tens of thousands of themes and plugins depend on jQuery being globally available.

Even if every single frontend developer on earth agreed to stop using jQuery today, the WordPress ecosystem alone would keep it alive for another decade.

Frameworks Die. Production Code Doesn't.

We have a massive blind spot as an industry: we mistake "relevance" for "longevity."

Frameworks are ephemeral. AngularJS, Backbone, Ember, Meteor... they all had their moment.

jQuery is different. It's not a framework, it's a dependency. It finished its race years ago, shipped to production, and is now in long-term maintenance mode. Just like COBOL in a banking system. Nobody wants to rewrite the COBOL, and they can't just delete it.

What This Means for You

Should Juniors Learn jQuery?

No. Not as a first tool. It teaches the wrong patterns for modern development (DOM scripting vs. state management). Learning it first is like learning medicine by studying 1950s procedures.

Should Seniors Understand jQuery?

Absolutely. Yes.

Not so you can write it. So you can safely delete it.

A developer who can only build greenfield apps is a React developer. A developer who can step into a 10-year-old codebase, read tangled jQuery, and incrementally migrate a feature to a modern stack without breaking production... that's a Software Engineer.

Your job isn't just to build shiny new things. It's to keep the existing, money-making things alive.

This "strangler" pattern is the real work. You don't "remove jQuery." You build a new React component for the new feature. You run it in parallel. You quarantine the old code. And one day, 5 years later, you realize the last 3 jQuery widgets are gone, and you can finally uninstall the dependency

That's not failure. That's economic reality.

The 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.

It's the COBOL of the frontend: old, uncool, and irreplaceable in millions of systems. As senior engineers, we have two jobs:

1. Build the new stuff right.
2. Understand the old stuff well enough not to break it.

A Few Questions for You:

• Have you ever tried to remove jQuery from a critical production app? How did it really go?
• What's the oldest piece of tech you're still maintaining, and why haven't you replaced it?
• Will we still be seeing jQuery in 2035? (I'll bet yes.)

#JavaScript #jQuery #LegacyCode #TechDebt #Frontend #WebDevelopment #SoftwareEngineering #React #Refactoring #EngineeringCulture #TechLeadership