There is a recurring genre of blog post that announces the death of jQuery. The genre runs about once a year, attracts a predictable amount of attention, and is usually wrong. The library that John Resig presented at BarCamp NYC in August 2006 still ships on roughly three-quarters of the public web in 2026, and the surface that displaced it on new projects (querySelector, fetch, ES6 modules) is a near-direct lineage from the APIs jQuery normalised twenty years ago.
This retrospective is an attempt to be honest about both ends. jQuery is no longer the default choice for new work, and the reasons are clear. It is also one of the most consequential pieces of software the open web ever shipped, and the reasons for that are clear too. The interesting question is which jQuery patterns survived, which were absorbed into the platform, and which quietly died.
Pre-jQuery web 2003 to 2005
To understand why jQuery captured the front-end developer market in 2006 it is worth remembering the alternatives. The 2003-2005 web was a confrontation between four roughly competing libraries, each with strong opinions and a small but devoted community.
Prototype.js, written by Sam Stephenson and shipped as part of Ruby on Rails in 2005, was the most influential. Prototype extended core JavaScript objects with helper methods, took an Object-Oriented approach to DOM manipulation, and pioneered the Selector API that jQuery would later refine. It was the default JavaScript library for Rails developers and was widely used outside Rails as well.
Mootools, started by Valerio Proietti in 2006, was Prototype’s more aggressive cousin. It extended even more of the JavaScript prototype chain and offered a more class-based programming model. Mootools was particularly popular in Europe and held a meaningful share of the JavaScript library market through 2009.
MochiKit, written by Bob Ippolito, was the smallest of the four but had the cleanest design. It was inspired by Python and emphasised functional composition over DOM extension. Reddit was famously built with MochiKit in its early years. The library never crossed into mainstream use but was admired by developers who took JavaScript seriously as a language.
Dojo, an enterprise-oriented JavaScript framework from the Dojo Foundation, focused on widgets and large-application patterns. It was used by IBM, Sun and several major enterprise software vendors. Dojo’s widget library was the most complete of the era and presaged what jQuery UI would later popularise.
The four libraries shared a problem. Internet Explorer 6, the dominant browser, had inconsistent DOM APIs that did not match Mozilla, Opera or Safari. Every library spent a substantial portion of its codebase normalising the differences. Every developer who built against any of them had to learn the library’s idioms in addition to JavaScript itself.
The state of the practice in 2005 was that “DOM scripting” was its own skill. Jeremy Keith’s book “DOM Scripting” (2005) was a standard reference. Peter-Paul Koch’s quirksmode.org documented hundreds of browser inconsistencies. Picking a JavaScript library was a serious architectural decision, and the libraries did not interoperate.
John Resig and jQuery 1.0 launch August 2006 at BarCamp NYC
John Resig was 22 years old in 2006 and was working on a master’s in computer science at Rochester Institute of Technology. He had a personal blog at johnresig.com, was active on the early JavaScript community mailing lists, and had started thinking through what a smaller, less invasive JavaScript library might look like.
The early development work on what became jQuery started in late 2005. The first public release, on Resig’s blog in January 2006, was named “jQuery” and exposed a single global function ($) that took a CSS selector and returned a wrapped collection of DOM elements. The wrapped collection had methods (.css(), .html(), .click()) that could be chained together. The library was a few hundred lines of code.
Resig presented jQuery 1.0 at BarCamp NYC on 26 August 2006. The talk’s premise was modest: jQuery was not a framework, it was a small utility library that made DOM manipulation pleasant. The presentation slides circulated; the library got picked up by early adopters; and within a year it was on the shortlist of every front-end developer.
The technical achievement was that the dollar-sign function, the chained methods and the $(document).ready() lifecycle hook combined into an idiom that was easy to teach, easy to read in code reviews, and forgiving of the inconsistent DOM behaviours of the browsers of the day. The cultural achievement was that Resig wrote and presented in a self-deprecating, community-oriented register that contrasted with the more dogmatic tone of the Prototype and Mootools maintainers.
The library was MIT-licensed, which made it trivially adoptable in commercial projects. The first major commercial validation was Microsoft’s September 2008 announcement that jQuery would ship with ASP.NET Ajax, with full support from Microsoft. Three months later Nokia announced that jQuery would ship with the Web Runtime on Nokia phones. By the end of 2009 jQuery was the dominant JavaScript library on the open web.
The dollar operator and chained methods
The technical reason jQuery captured developer mindshare in 2007-2010 is worth dwelling on because the design choices are still teachable in 2026.
The dollar-sign function ($()) was the universal entry point. It accepted a CSS selector, a DOM node, an array of nodes or a function. It returned a jQuery object, which behaved like an array but exposed a substantial method API. The conceptual unification (one function, many input types, one output type) collapsed the cognitive load of working with the DOM in a way that no previous library had achieved.
The chained methods ($('h1').css('color', 'red').addClass('important').fadeIn()) gave developers a fluent interface that read like English. Chaining was not new; jQuery’s contribution was making it the canonical idiom. The pattern was widely imitated (in Lodash, in D3, in the JavaScript Array methods that became standard in ES5 and ES6) and is the source of the modern functional-programming idiom that dominates client-side JavaScript in 2026.
The selector engine (Sizzle, extracted as a separate library in 2009 and contributed back by Resig) was state-of-the-art for its time. Sizzle implemented CSS3 selectors before native browser support was complete, including pseudo-selectors like :contains() and :has() that the platform later adopted (or rejected). The performance work that went into Sizzle was substantial and informed the implementation of querySelectorAll in the browsers themselves.
The plugin pattern was the ecosystem multiplier. Any function added to jQuery.fn became a method on every jQuery object. The pattern was trivial to teach, which produced an explosion of third-party plugins (see the official API documentation for the canonical reference): jQuery Validate, jQuery DataTables, jQuery Slick, jQuery Lazyload, and thousands of others. The plugin economy is the closest analogue to what the WordPress plugins ecosystem did for content management.
jQuery UI and jQuery Mobile, the plugin empire 2007 to 2012
jQuery UI launched in September 2007 as a separate library built on top of jQuery, providing widgets (datepickers, dialogs, sliders, accordions, tabs), interactions (draggable, droppable, sortable, resizable, selectable) and a theming system (ThemeRoller, which let developers customise the visual style without editing CSS by hand).
The widget library was the closest thing the open web had to a comprehensive UI kit. Bootstrap, which would eventually replace it for most projects, did not launch until August 2011. Through 2007-2011 jQuery UI was the default choice for enterprise dashboards, admin panels and any project that needed datepickers and modals without reinventing them.
jQuery Mobile, launched in October 2010, was the more ambitious bet. It was a framework rather than a library, with a declarative HTML-based markup model, a touch-optimised event system, transitions between pages, and a theming system aimed at mobile-first design. The project anticipated the rise of mobile web traffic and was an early attempt at responsive UI patterns.
The mobile bet was both prescient and unfortunate. Prescient because mobile web traffic did indeed surge through the 2010s and the responsive-design patterns jQuery Mobile pioneered were absorbed into the wider community. Unfortunate because the implementation lagged native mobile performance, and because the rise of React Native (2015) and Flutter (2017) took the mobile-first UI conversation in a different direction. jQuery Mobile was officially deprecated in 2021 and removed from the jQuery Foundation’s active project list.
The jQuery Foundation, formed in 2012 to consolidate governance of jQuery, jQuery UI, jQuery Mobile, Sizzle and QUnit, was an early example of corporate-stewardship governance for an open-source JavaScript project. The Foundation merged with the Node.js Foundation in 2019 to form the OpenJS Foundation, which continues to host jQuery in 2026.
React in 2013, Vue in 2014, and the displacement
The displacement narrative is more nuanced than the typical retelling. jQuery did not lose to React in a single moment. It lost to a combination of forces that converged between 2013 and 2017.
React, released by Facebook in May 2013, was initially treated as a curiosity. The JSX syntax was controversial. The virtual DOM was unfamiliar. The component-based architecture was a substantial conceptual shift. Through 2014 the consensus was that React was an interesting experiment for large applications but overkill for most jQuery-style projects.
Vue, released by Evan You (formerly of Google) in February 2014, was the more jQuery-compatible alternative. Vue 1.x could be added to an existing page with a script tag, used template syntax that read like HTML, and was learnable in a weekend. Vue captured a substantial share of the “we want components without rewriting everything” market that jQuery had previously owned.
Angular 2 (September 2016) and the wider TypeScript-first ecosystem reframed JavaScript development around static typing, dependency injection, observables and module-driven architecture. The jQuery idiom of “load a page, run a function on DOMContentLoaded, manipulate the DOM in event handlers” no longer matched how serious front-end teams were building.
The single-page-application pattern was the deeper shift. jQuery was designed for server-rendered HTML with progressive enhancement. The SPA model rendered the entire UI client-side from JSON, which made jQuery’s DOM-centric idioms structurally inappropriate. React, Vue and Angular were native to the SPA pattern; jQuery was retrofitted to it through plugins like Backbone.js (2010) and never fully adapted.
By 2017 the centre of gravity in greenfield front-end development had moved decisively to React, with Vue as the runner-up. jQuery’s share of new projects collapsed. But jQuery’s share of existing projects (WordPress sites, Drupal sites, Bootstrap 4 sites, enterprise admin panels, legacy CMSs) stayed where it was. The library went from being the default to being the substrate that defaults had been built on, and never went away.
What jQuery still does well in 2026
The honest assessment in 2026 is that jQuery is still on roughly three-quarters of the public web. The HTTP Archive and BuiltWith surveys put the figure at 73 to 75 percent, although the methodology counts any page that ships jQuery for any reason, including pages where the library is loaded by a single plugin and otherwise unused.
The places where jQuery is still actively useful in 2026 are narrow but real.
WordPress core ships jQuery (currently jQuery 3.7) and uses it in the admin UI and in many legacy themes. Plugins that target the wp-admin surface still write jQuery code, partly because that is what the admin surface expects and partly because the WordPress core team has been deliberate about not breaking the existing plugin ecosystem.
Legacy enterprise admin panels that were built between 2008 and 2016 are still in production. Rewriting them in React is rarely worth the cost, and adding new features in jQuery is rarely worth the friction. The maintenance pattern is jQuery for now, with a multi-year plan to migrate that may or may not execute.
Microsite needs where a single page needs to do five things (validation, a modal, a slideshow, a sticky header, a smooth scroll) and the team does not want a build pipeline are often still served best by jQuery plus four plugins. The argument against this in 2026 is that the modern DOM APIs cover the same ground without a 28 KB minified dependency, and the argument is correct.
Drupal 9 and Drupal 10 ship jQuery for the same reasons WordPress does. The Drupal core team has been more aggressive about reducing the dependency, with the Olivero default theme (Drupal 9.1, 2020) using vanilla JS, but jQuery is still in the project’s npm dependencies and many contributed modules rely on it.
The pattern across these cases is that jQuery is the substrate for a long tail of existing software, and that long tail is too valuable to migrate aggressively. The library will quietly run on production websites well into the 2030s.
The native web platform made the dollar operator obsolete
The technical explanation for why jQuery stopped being the default is that the web platform absorbed the patterns jQuery normalised. The list is worth being explicit about.
document.querySelector and document.querySelectorAll, standardised across browsers by 2010, replaced jQuery’s $() selector. The native APIs accept the same CSS-selector syntax and return native DOM nodes. The performance is comparable.
element.classList.add(), .remove(), .toggle() and .contains(), standardised by 2013, replaced jQuery’s .addClass(), .removeClass(), .toggleClass() and .hasClass(). The native APIs are more verbose by a few characters and not chainable, but they work without a library.
fetch(), standardised in 2015 and widely available by 2017, replaced jQuery’s .ajax(), .get(), .post() and .getJSON(). The native API is promise-based, which fits modern async/await idioms better than jQuery’s callback or deferred patterns.
DOMContentLoaded and document.readyState, available in every browser since 2010, replaced jQuery’s $(document).ready(). The native event is two extra lines of code; the conceptual model is identical.
ES6 modules, standardised in 2015 and broadly usable in browsers by 2018, replaced the global-namespace idiom that jQuery plugins depended on. Modules let developers import and compose functionality without polluting the global object.
The cumulative effect is that the dollar-sign operator no longer earns its 28 KB. A modern developer who learns vanilla DOM APIs is more productive in 2026 than a developer who learns jQuery first, because the platform now exposes what the library used to wrap.
The mapping from jQuery patterns to their 2026 native equivalents, laid out as a table, makes the absorption explicit:
| Use case | jQuery pattern | Modern alternative 2026 | Verdict |
|---|---|---|---|
| DOM selection | $('.item') | document.querySelectorAll('.item') | Native API wins, same syntax |
| AJAX | $.ajax({...}) or $.getJSON() | fetch() with async/await | Native API wins, promise-based ergonomics |
| Animation | .fadeIn(), .slideDown() | CSS transitions and Web Animations API | Native API wins, GPU-accelerated |
| Event delegation | $(parent).on('click', '.child', fn) | parent.addEventListener('click', e => e.target.closest('.child') && fn(e)) | jQuery still terser, but native works |
| Plugin pattern | $.fn.myPlugin = function() {...} | ES6 modules with named exports | Native modules win on bundling and tree-shaking |
| Chained methods | $('h1').css('color','red').addClass('important') | No direct equivalent in vanilla DOM | jQuery still wins on ergonomics for one-off scripts |
The lasting legacy is that the platform exposes those APIs at all. The standards conversations that produced querySelectorAll and fetch were directly informed by what jQuery had proven to be useful. The library taught the web platform what its surface should look like. For more on the standards work that came out of this era, see the web-standards topic page, and for context on how the broader front-end ecosystem evolved, see the jQuery topic archive.
FAQ
When was jQuery created?
jQuery 1.0 launched on 26 August 2006 at BarCamp NYC, presented by John Resig. The first development work had started in late 2005 and the first usable releases circulated on Resig’s blog at johnresig.com over the spring of 2006.
Who made jQuery?
John Resig, a young JavaScript developer who was then working at Mozilla, created jQuery. The project later became a community effort under the jQuery Foundation (formed 2012), which merged into the OpenJS Foundation in 2019. Resig went on to work at Khan Academy and continues to maintain a personal blog at johnresig.com.
Is jQuery dead in 2026?
jQuery is not dead, but it is no longer the default. As of 2026, public web-crawl surveys (HTTP Archive, BuiltWith) put jQuery on roughly 73 to 75 percent of websites, largely because of its inclusion in WordPress core, Drupal, Joomla, Bootstrap 4-and-earlier sites and long-tail enterprise applications. It is rarely chosen for new greenfield projects.
Should I learn jQuery today?
For new projects, no. The modern DOM APIs (querySelector, fetch, classList, addEventListener, ES6 modules) cover the same use cases without the dependency. For maintenance work on existing WordPress sites, legacy admin tools, Bootstrap 4 applications or enterprise codebases, a working knowledge of jQuery selectors, chained methods and $.ajax is still useful.
FAQ
- When was jQuery created?
- jQuery 1.0 launched on 26 August 2006 at BarCamp NYC, presented by John Resig. The first development work had started in late 2005 and the first usable releases circulated on Resig's blog at johnresig.com over the spring of 2006.
- Who made jQuery?
- John Resig, a young JavaScript developer who was then working at Mozilla, created jQuery. The project later became a community effort under the jQuery Foundation (formed 2012), which merged into the OpenJS Foundation in 2019. Resig went on to work at Khan Academy and continues to maintain a personal blog at johnresig.com.
- Is jQuery dead in 2026?
- jQuery is not dead, but it is no longer the default. As of 2026, public web-crawl surveys (HTTP Archive, BuiltWith) put jQuery on roughly 73 to 75 percent of websites, largely because of its inclusion in WordPress core, Drupal, Joomla, Bootstrap 4-and-earlier sites and long-tail enterprise applications. It is rarely chosen for new greenfield projects.
- Should I learn jQuery today?
- For new projects, no. The modern DOM APIs (querySelector, fetch, classList, addEventListener, ES6 modules) cover the same use cases without the dependency. For maintenance work on existing WordPress sites, legacy admin tools, Bootstrap 4 applications or enterprise codebases, a working knowledge of jQuery selectors, chained methods and $.ajax is still useful.