Ten years of writing a dollar sign and meaning it

A library born from browser chaos stayed atop the web long after the chaos cleared.

The problem it was built for

By 2006, writing JavaScript that worked across browsers was an exercise in conditional humiliation. Internet Explorer and Firefox disagreed on how events propagated. Safari had its own opinions about the XMLHttpRequest object. The DOM — the Document Object Model, the browser's live tree of a page's elements — was theoretically standardised, but each vendor's implementation had its own gaps, bugs and undocumented behaviours. Getting an element by something other than its ID meant writing different code for different browsers, keeping a mental map of who supported what, and accepting that the result might be wrong on a machine you didn't own.

John Resig, then a student, presented jQuery at BarCamp NYC in January 2006. Its pitch was deceptively narrow: write a CSS selector string, get back a collection of matching elements, chain methods on that collection. The dollar sign — $() — was already a valid JavaScript identifier, and Resig used it as the library's main entry point. The syntax was terse and the abstraction was almost reckless: it didn't matter whether the user was running IE 6 or Firefox 1.5, whether the event model was W3C or Microsoft's legacy attachEvent. jQuery wrote one path through the browser disagreement and exposed a single, consistent surface to developers.

The implementation did something browsers disagreed on constantly: normalised events, abstracted AJAX, and provided a unified way to traverse and manipulate the DOM. Beneath the single API, jQuery was doing the conditional branching that previously lived in every project, every developer's own utility files. It collected that tax once and paid it forward.

The decade it owned

Adoption was fast and then overwhelming. Within a few years, independent surveys of the web found jQuery running on a majority of sites that used any JavaScript at all. BuiltWith and W3Techs, organisations that crawl public sites and tabulate their technology stacks, would eventually report figures approaching or exceeding 70% of all measured websites carrying jQuery — figures the W3Techs crawl has tracked since the library's rise. That is a market share almost without precedent in a space that nobody controlled.

Several things converged to produce this. Documentation was good by the standards of the era. The plugin ecosystem grew quickly — a short $.fn extension pattern let third parties bolt almost anything onto the jQuery object, and hundreds of UI widgets, sliders, date pickers and carousels accumulated around the core. Then WordPress adopted jQuery as its bundled scripting library, and suddenly every WordPress theme and plugin author was jQuery-literate whether they had consciously chosen the library or not. WordPress's own market share among content management systems meant that adoption was no longer just a developer preference — it was infrastructure.

The jQuery Foundation was established in 2012 to steward the project, merging with the Dojo Foundation in 2016 to form the JS Foundation, which merged with the Node.js Foundation in 2019 to form the OpenJS Foundation. That institutional history is its own signal: a library grown large enough to need governance, legal entities, and formal relationship to the standards bodies it had partly been compensating for.

Meanwhile the W3C, the web standards body, was watching what developers were actually using. jQuery's selector syntax, its event model, its iteration patterns: these weren't just popular, they were empirical evidence about what developers needed. The Selectors API specification produced querySelectorAll, which gave browsers a native method that accepted a CSS selector string and returned a node list. That native API covered the single most common reason people had reached for jQuery in the first place. It landed in all major browsers by 2009, and it rendered a significant portion of jQuery's raison d'être redundant.

Array.prototype.forEach, classList, addEventListener standardised everywhere, fetch — the platform was closing the gaps one by one. MDN, the Mozilla Developer Network, became the authoritative place to check what was actually available; Can I Use mapped browser support for each feature against specific versions. The conditions that had made jQuery necessary were retreating.

And yet.

Why it stayed

The numbers did not reverse. jQuery's share of the measured web stayed stubbornly high through the 2010s, past 2013, past the arrival of ES6 in 2015, past the point where it was considered mandatory in new development. Understanding why requires separating two distinct populations: sites being built and sites already built.

The web's archive problem is severe. Sites written in 2009 with jQuery 1.3 were still running in 2016, not because their owners had assessed jQuery and found it irreplaceable, but because nothing had forced a rebuild. A CMS theme from 2011 carries its own jQuery. An internal enterprise tool written during Obama's first term might not be touched until its hosting contract expires. jQuery's installed base was partly a stratum of sediment — accumulated code that nobody had reason to disturb.

Then there is the skills pipeline. A developer who learned front-end work between 2008 and 2014 very likely learned jQuery first. The muscle memory of $(document).ready() and .ajax() was real. Training materials, Stack Overflow answers, book chapters — they all referenced jQuery. A new hire who knew jQuery was interchangeable with the existing codebase in a way that a developer who knew React but not jQuery was not, in a shop where the existing codebase was jQuery. This is not irrationality; it is continuity.