Is It Time to Drop jQuery for Vanilla JavaScript

I still remember the moment I realized jQuery had become a crutch. A client in Zagreb had a simple request: a dropdown menu that closed when you clicked outside it. I instinctively reached for $(document).click(), wrote three lines of code, and called it a day. Then I looked at the page weight. That one interaction came bundled with an entire library I barely used anymore. The question isn't whether jQuery works — it always has. The real question is whether it still earns its place in your stack when vanilla JavaScript now does the same job with less overhead.

The Weight of Legacy

jQuery was revolutionary when it launched in 2006. It gave developers a consistent API across browsers that fought each other over standards. Internet Explorer 6 was still king, and writing cross-browser code meant hours of debugging. jQuery abstracted that pain away. But the web has changed, and so have browsers.

The shrinking gap

Modern browsers implement DOM APIs that directly mirror what jQuery offered. document.querySelector and document.querySelectorAll replace $() with native speed. The classList API handles add, remove, and toggle without plugins. Fetch API replaces $.ajax with a promise-based interface that doesn't require a library.

Consider this: Chrome, Firefox, Safari, and Edge all support ES6 and beyond. Even Internet Explorer, the last holdout, has been officially retired by Microsoft. The compatibility gap that jQuery bridged has narrowed to nearly zero for most projects. If you're building for modern browsers, you're paying for a bridge you no longer need to cross.

Real-world performance

A minified and gzipped jQuery 3.x weighs around 30 KB. That doesn't sound like much until you multiply it by every page load on your site. For a Croatian e-commerce store serving thousands of visitors daily, that 30 KB adds up in bandwidth costs and load time. More importantly, it delays the critical rendering path.

Vanilla JavaScript executes faster because there's no abstraction layer between your code and the browser's native methods. jQuery has to parse your selector, run its own matching logic, and then call the native API anyway. You're paying for an interpreter that interprets your code before the browser gets to run it. That overhead matters on mobile devices, where your Croatian audience is likely browsing on variable connection speeds.

What Vanilla JavaScript Now Handles Natively

The most common arguments for keeping jQuery revolve around convenience. Developers claim vanilla code is more verbose. But that verbosity often disappears when you use modern JavaScript features that didn't exist ten years ago.

DOM traversal and manipulation

jQuery made DOM traversal feel effortless with methods like .parent(), .children(), and .closest(). Vanilla JavaScript now offers Element.closest(), ParentNode.children, and Element.nextElementSibling. The syntax is slightly different, but the logic is identical.

// jQuery
$('.item').parent().addClass('active');

// Vanilla
document.querySelector('.item').parentElement.classList.add('active');

The vanilla version is one line longer. But it's also faster, more explicit, and doesn't require loading a library. Once you internalize the native methods, you stop missing the shorthand.

Event handling

jQuery's .on() and .off() provided a unified event model. Vanilla JavaScript now has addEventListener and removeEventListener with the same flexibility. Event delegation works natively by checking the target property.

// jQuery
$('.list').on('click', '.item', function() { ... });

// Vanilla
document.querySelector('.list').addEventListener('click', function(e) {
  if (e.target.closest('.item')) { ... }
});

The vanilla version requires a manual check for delegation, but that check is pure JavaScript — no library overhead, no magic strings, no hidden performance cost.

AJAX and data fetching

This is where the gap has closed most dramatically. jQuery's $.ajax was a lifesaver when XMLHttpRequest was the only native option. Now fetch provides a cleaner, promise-based API that integrates directly with async/await.

// jQuery
$.getJSON('/api/data', function(data) { ... });

// Vanilla
const data = await fetch('/api/data').then(res => res.json());

fetch also handles streaming, which jQuery never could. For a Croatian startup building real-time features, that opens possibilities without additional libraries.

When jQuery Still Makes Sense

I'm not advocating for a blanket purge of jQuery from every project. There are scenarios where it remains a pragmatic choice. The key is recognizing those scenarios and making an intentional decision rather than defaulting to a habit.

Legacy projects and maintenance

If you're maintaining a site that already uses jQuery extensively, rewriting everything in vanilla JavaScript is rarely worth the effort. The risk of introducing bugs, the time investment, and the opportunity cost of not building new features usually outweigh the performance gains. jQuery doesn't rot. It will continue to work for years.

Plugin ecosystems

Some jQuery plugins have no direct vanilla equivalent. If your site depends on a specific jQuery plugin for a carousel, date picker, or complex animation, removing jQuery means replacing that plugin too. Evaluate whether the plugin is still maintained and whether a vanilla alternative exists before making the switch.

Rapid prototyping

For quick internal tools or proof-of-concept demos, jQuery's concise syntax can speed up development. The same applies to small personal projects where performance isn't critical. The rule of thumb: if you're building something that will never see production traffic, use whatever makes you fastest.

Making the Transition Smooth

If you've decided to move away from jQuery, the transition doesn't have to be painful. A gradual approach reduces risk and lets you build confidence in vanilla methods.

Audit your jQuery usage

Run a search through your codebase for $( and jQuery. Count how many times you use core jQuery features versus simple selectors. Many projects use jQuery for 10% of its capabilities while paying 100% of the cost. Identify the patterns you use most and learn their vanilla equivalents first.

Create a utility library

One common objection is that vanilla JavaScript lacks jQuery's helper methods like $.each or $.extend. You can create a small utility file with the functions you actually need. This gives you the convenience without the full library weight.

// Your own tiny utility
const $ = (selector, context) => (context || document).querySelectorAll(selector);
const each = (list, callback) => Array.from(list).forEach(callback);

This approach also makes your code more readable for team members who still think in jQuery terms. Over time, you can phase out the utility as everyone becomes comfortable with native APIs.

Use feature detection

Not all browsers are equal. If you need to support older browsers for a specific client, use feature detection to conditionally load jQuery only when necessary. This keeps the page lean for most users while maintaining compatibility for edge cases.

if (!Element.prototype.closest) {
  // Load jQuery polyfill only for older browsers
}

This is a pragmatic middle ground that respects both performance and compatibility.

The Practical Takeaway

Start by removing jQuery from your next new project. Build it entirely with vanilla JavaScript and see how it feels. You'll likely find that the code is more explicit, easier to debug, and faster to load. The initial discomfort of typing document.querySelector instead of $ fades quickly when you realize you've eliminated an entire dependency from your stack.

For existing projects, set a target: reduce jQuery usage by 50% over the next three months. Replace the most common patterns first — selectors, class toggling, and simple AJAX calls. By the end of that period, you'll have a clear picture of whether jQuery still serves your project or whether it's just a habit waiting to be broken.

The web platform has matured. It's time to trust it.