The standard made most of it unnecessary and nobody noticed

The Selectors API gave native querySelectorAll, which covered the single most common reason to load the library. Adoption barely moved.

When the browser caught up, the library stayed

By the time the W3C's Selectors API shipped in every major browser, jQuery had already won. That timing mattered more than the technology.

The problem jQuery solved in 2006 was not a single problem — it was several layered on top of each other, and the Selectors API only ever addressed the most visible one. John Resig had built a library that abstracted browser inconsistencies across DOM traversal, event handling, Ajax, and animation, then wrapped it in a terse, chainable syntax that developers actually enjoyed writing. The dollar-sign selector — $('.nav a') — was the face of the library, but the face was not the whole building.

Still, traversal was genuinely the reason many developers reached for jQuery in the first place. Before 2009, selecting a set of elements by CSS class required either getElementsByClassName (which Internet Explorer 8 did not support and older browsers lacked entirely) or iterating manually over getElementsByTagName results and filtering by hand. The alternative was loading someone else's code to handle it for you. jQuery's selector engine, Sizzle — extracted as a standalone library and contributed to the jQuery Foundation — parsed CSS selectors and returned results that behaved consistently regardless of which browser ran the code. It was indispensable because the platform gave developers nothing comparable.

querySelectorAll and the standard that arrived late

The Selectors API was a W3C specification that gave browsers two new native methods: querySelector, returning the first matching element, and querySelectorAll, returning a static NodeList of all matches. Both accepted a CSS selector string as their argument — the same syntax Sizzle already knew. Internet Explorer 8 shipped a partial implementation in 2009. Firefox, Safari and Chrome had shipped it around the same time or earlier, and by the time Internet Explorer 9 landed in 2011, the Selectors API was effectively universal across the browsers that mattered to most production projects.

This was a genuine, substantial shift. The most common jQuery invocation — find elements by class, ID, or CSS selector, then do something with them — now had a native equivalent that required no library, no download overhead, and no Sizzle parse step. Measured in call frequency, querySelectorAll covered an enormous portion of what jQuery code actually did on a typical page. By any rational calculus, the justification for shipping thirty-something kilobytes of minified JavaScript to every visitor had shrunk considerably.

The justification also shrank on other fronts during the same period. The Fetch API eventually replaced jQuery's $.ajax. classList replaced the string manipulation jQuery used to add and remove CSS classes. addEventListener had always existed, but jQuery's cross-browser wrapper for it became unnecessary once Internet Explorer's proprietary attachEvent model finally disappeared. The closest and matches methods arrived and covered common traversal patterns. The ECMAScript specification, through TC39, was meanwhile moving faster than it had in years — ES2015 brought arrow functions, template literals, destructuring, and Promises, removing several reasons developers had leaned on utility libraries beyond jQuery. Native array methods like forEach, map, and filter, long available on modern browsers, became safe to use without shims as IE support requirements relaxed across the industry.

Adoption that did not move

None of it moved the needle the way you would expect. The numbers that web almanac surveys and HTTP Archive crawls consistently returned — throughout the mid-2010s and into the 2020s — showed jQuery present on the majority of measured websites. The share declined slowly, but the baseline remained stubbornly high. A library whose core reason to exist had been answered by the platform was still shipping on more than half the web, years after the answer arrived.

Some of that is explained by inertia that is entirely rational. A CMS like WordPress bundled jQuery, and WordPress powered somewhere around a third of the web by the early 2020s. A site that uses WordPress uses jQuery whether its developer knows it or not, whether they want it or not. Plugins assume it. Themes depend on it. The ecosystem calcified around the library in ways that had nothing to do with whether Sizzle was still necessary.

Some of it is explained by the cost structure of removing something versus adding it. When jQuery was already present — already downloaded, already parsed, already initialised — reaching for $() instead of querySelectorAll had a marginal cost of zero. The decision to remove it was not trivially free: it required auditing every piece of code that called the library, confirming each call had a native equivalent, testing across browsers, and updating any plugins that assumed jQuery's presence. For a site whose jQuery usage had long since atrophied to a few selector calls, the dependency stuck because cutting it cost more than it saved in any given sprint.

A standard lands in a browser changelog; a library is what developers are taught.

And some of it is simply how standards adoption works in practice. The Selectors API did not appear with an announcement that jQuery was now optional; it appeared quietly in browser release notes while developers were busy with everything else. The guidance ecosystem — tutorials, Stack Overflow answers, agency starter kits, bootcamp curricula — continued to reach for jQuery by default because that was what the guidance ecosystem already knew. A standard lands in a browser changelog; a library is what developers are taught.

What the gap reveals

The gap between capability and adoption is the honest record of how front-end infrastructure actually evolves. Polyfills extended old browsers' lives by backfilling standards that arrived before browser support caught up; what the jQuery story illustrates is the inverse problem, where browser support caught up but the abstraction layer didn't leave. The library had accumulated enough mass — in installed packages, in institutional knowledge, in the sheer volume of code already written — that the platform's maturation wasn't sufficient cause to dislodge it.

Resig had written jQuery in a browser landscape where quirks mode and divergent rendering engines made the DOM a genuinely hostile surface. By the time those hostilities were mostly settled — by the convergence of standards work at the W3C, by the steady pressure of MDN's documentation, by TC39's acceleration of the language itself — jQuery had become infrastructure rather than a tool. Infrastructure doesn't get evaluated the way a new tool gets evaluated. It gets inherited.

The Selectors API is, in that light, a useful case study in what "the platform caught up" actually means at scale. It means capability exists. It does not mean that capability is adopted, taught, depended on, or treated as a reasonable baseline. The web platform moves in geological time when it comes to removing anything, even when the reason for the thing has evaporated. The jQuery numbers are that observation in the data.

The library didn't survive because developers examined the alternatives and chose it.

The library didn't survive because developers examined the alternatives and chose it. It survived because removing it was work, and the web accumulates rather than audits.