You-Dont-Need-jQuery: a method-by-method map from jQuery to plain JavaScript

What You-Dont-Need-jQuery actually is, and who it is written for

This is a documentation repository. The package.json marks it as private, there is no main entry, no dist folder and no published module, so nothing here installs into an application as a dependency. What you get is a README that walks through jQuery's API area by area (query selectors, CSS and style, DOM manipulation, Ajax, events, utilities, promises, animation) and shows the native JavaScript that does the same job.

The audience is narrow and specific. It is for a developer who inherited a page or a plugin written with jQuery and wants to know what the equivalent plain JavaScript looks like, one call at a time. It assumes you already know what $('.class') does. It does not teach the DOM from zero, and it does not argue that jQuery is bad. The README states plainly that jQuery is still a great library with many valid use cases and tells readers not to migrate away if they do not want to.

The framing in the README is that modern browsers have implemented enough DOM and BOM APIs for production use, and that direct DOM manipulation has become an anti-pattern in React, Angular and Vue codebases. Those two claims set the scope: evergreen browsers only, and applications where the framework already owns the DOM.

How the snippets are structured, and what the test suite checks

Every entry follows the same shape: a jQuery line marked with a comment, then a native line marked with a comment. Query by class becomes document.querySelectorAll('.class'), or document.getElementsByClassName('class') if you prefer the older call. Query by id becomes document.querySelector('#id') or document.getElementById('id'). The README notes the difference in return types: querySelectorAll gives a static NodeList that supports forEach and can be converted with Array.from, while querySelector returns null when nothing matches, where jQuery would have returned an empty jQuery object.

The repository has a test directory and a vitest.config.js, and package.json wires vitest run to npm test. The devDependencies are jquery ^4.0.0, jsdom ^30.1.0 and vitest ^5.0.1, with engines set to node ^22.12.0 || >=24.0.0. The presence of jQuery as a dev dependency, alongside jsdom, indicates the suite exercises the jQuery side and the native side in the same simulated DOM rather than only checking that the native snippets parse. That is the strongest signal in the repository that the pairs are meant to be behaviourally comparable, though the README does not describe what each test asserts.

Some entries are not one-liners. Sibling traversal needs a helper: all previous siblings is written as a while loop over previousElementSibling with an optional filter function, and parentsUntil is a function that walks parentElement upward until el.matches(selector) is true. These are the places where the mapping stops being a translation and becomes code you have to maintain.

Installing it and running the test suite

There is nothing to install for use in a project, because the package is private and unpublished. The only installable thing is the development setup for the repository itself, which is what the package.json scripts describe.

Clone the repository and install the dev dependencies:

git clone https://github.com/camsong/You-Dont-Need-jQuery.git
cd You-Dont-Need-jQuery
npm install

Then run the suite once, or in watch mode with the tdd script:

npm test
npm run tdd

Node 22.12.0 or newer is required by the engines field, so an older runtime will fail before the tests start. The suite runs under Vitest with jsdom, which means it validates DOM behaviour in a simulated environment, not in a real browser. For a first real use, open the README section that matches the jQuery call you are replacing, copy the native line, and run it against your own markup. If you want to confirm a pair behaves the same, the test directory is the place to see how the two sides are set up.

Where the native equivalents are not equivalent

The README carries its own warning: the alternatives are not completely equivalent in all scenarios and it is recommended that you test before using them. That sentence is doing a lot of work, and it is the most important line on the page.

Two gaps are visible. First, browser support. The snippets target current evergreen browsers, and the README states that IE-specific fallbacks have been removed because Microsoft no longer supports Internet Explorer. If your support matrix includes IE, this branch is not for you, and the README points to the last IE-compatible version at commit c4e00b3. Second, the traversal helpers. jQuery's prevAll and nextAll accept an optional selector filter and return a jQuery collection with chaining; the native versions here are hand-written functions that accept a filter function and return an array. The return type changed, and so did the filtering contract. Any code that chains further off the result will need rewriting, not substitution.

There is also a performance note that cuts against the obvious instinct. The README says getElementById, getElementsByClassName and getElementsByTagName are slightly faster than querySelector, but that the getElementsBy* family returns a live HTMLCollection which changes as the DOM changes. The advice is to prefer querySelector unless you have measured a bottleneck. A live collection is a real source of bugs when you mutate while iterating, and the guide steers you away from the faster call for that reason.

You-Dont-Need-jQuery compared with Alpine.js and Umbrella JS

The alternatives people search for alongside this project fall into two different categories, and the distinction matters more than the names.

Alpine.js is a small reactive framework. It keeps HTML as the source of truth and attaches behaviour through attributes in the markup, so state and rendering are handled by the library. You-Dont-Need-jQuery does the opposite: it removes a library and leaves you with direct DOM calls in your own code. If your problem is that you have scattered imperative DOM updates and want declarative bindings, Alpine.js addresses that and this guide does not. If your problem is that you have a jQuery dependency you want to delete, Alpine.js is not a drop-in answer because it changes how the markup is written.

Umbrella JS is closer in spirit: it is a small jQuery-like library, so it keeps the $ function and the chaining style while dropping the size. Choosing it means you still depend on a DOM utility layer, just a lighter one. Choosing You-Dont-Need-jQuery means you depend on nothing and write the loops yourself. That trade is explicit in the repository: helper functions like getPreviousSiblings and parentsUntil exist precisely because the browser does not provide them, and they become your code to test and maintain.

Maintenance, licence and what a migration costs

The repository is not archived, and the last push was on 2026-09-17. The only listed release is v2.0 from 2016-01-13, so the version number has not moved in a decade even though the working tree has. Treat the README as the current state and the release tag as historical.

The licence is MIT, declared in package.json and present as a LICENSE file at the top level. That permits use, modification and redistribution with the licence and copyright notice retained. It covers the text and snippets in this repository; it says nothing about the licence of jQuery itself, which is a separate project with its own terms, and nothing about the code you write based on the examples. That is a description of what the licence file says, not legal advice.

The upgrade cost is the part people underestimate. There is no codemod here, no build plugin and no runtime shim, so nothing automates the change. The work is reading each call site, finding the matching section, and rewriting by hand, including the traversal helpers that have no direct native counterpart. The test suite lowers the risk of the snippets themselves being wrong, but it does not test your application. Budget the migration as a code review exercise, not a dependency swap.

Editorial conclusion

Adopt this as a lookup table when you are converting a jQuery codebase that only runs in evergreen browsers, and read the test directory before trusting any single snippet, because the README itself warns the alternatives are not equivalent in all scenarios. Do not use it as a migration tool: there is no codemod, no build plugin and no runtime. If you still support Internet Explorer, this branch is the wrong one, and the README points to the last IE-compatible version at commit c4e00b3. Verify two things first: that your target browsers match the evergreen list, and that each replacement you copy behaves the same as the jQuery call it replaces, since the project recommends testing before use.

Frequently asked questions

Official sources

1. camsong/You-Dont-Need-jQuery on GitHub
2. Issues
3. License: MIT
4. README
5. Releases