Dom7

Dom7 is a small JavaScript library for querying and manipulating the DOM using a jQuery-compatible chaining API. Rather than reinventing DOM manipulation, it reimplements the small subset of jQuery’s most-used methods — class and attribute helpers, event binding, dimension/offset queries, traversal, and simple animation/scroll helpers — as standalone functions that get mixed onto an Array subclass returned by a $() selector function.

It was extracted from and is the default DOM layer bundled inside Framework7, the mobile app UI framework, so teams that already know jQuery’s $(selector).method() style can use it without a learning curve. Because each method is exported individually, consumers who only need a couple of helpers can import just those functions and mix them onto $.fn themselves, keeping bundle size down instead of pulling in the full jQuery-equivalent surface.

What You Get

• A $(selector) factory that returns a chainable, array-like Dom7 collection (a real Array subclass) for any CSS selector, DOM node, NodeList, or HTML string
• Class, attribute, property, and dataset helpers (addClass, removeClass, toggleClass, hasClass, attr, prop, data, dataset, val)
• DOM traversal methods (find, children, parent, parents, closest, next, prev, siblings, filter, eq, index, is)
• DOM mutation helpers (append, prepend, insertBefore, insertAfter, remove, detach, empty, html, text)
• Event binding shortcuts (on, off, once, trigger, plus named shortcuts like click, focus, keydown, touchstart)
• Dimension, offset, scroll, and lightweight CSS-transition/animation helpers (width, height, offset, scrollTo, transition, animate)
• Two build targets: a full jQuery-style bundle (dom7.bundle.js, everything mixed onto $.fn) and a tree-shakeable ESM/CJS entry that exports each method as a standalone named function
• Hand-written TypeScript typings (dom7.d.ts) describing the full Dom7Array chainable interface

Common Use Cases

• Powering Framework7’s own UI components, which use Dom7 internally for all DOM reads/writes instead of raw document APIs
• Adding jQuery-style DOM manipulation to a small vanilla-JS project without pulling in jQuery’s full size or its $.ajax/deferred/animation-queue machinery
• Migrating a legacy jQuery-based codebase toward smaller bundles by swapping $ for Dom7’s compatible-but-lighter API
• Server-side-rendering setups (via ssr-window) where DOM-manipulation code needs to run without throwing on a missing window/document
• Cherry-picking a handful of DOM helper functions (e.g. just addClass/width) via the tree-shakeable named exports to keep client bundles minimal

Under The Hood

Architecture The library’s entry points sit in src/dom7.js (named-export/tree-shakeable build) and src/dom7.bundle.js (full jQuery-style build); both start from the $() factory in src/$.js, which normalizes a CSS selector, DOM node, NodeList, or HTML string into a Dom7 collection defined in src/dom7-class.js — a genuine Array subclass patched with a makeReactive __proto__ trick so native array methods coexist with mixed-in DOM helpers. Rather than defining every DOM method directly on Dom7.prototype, the actual behavior lives in separate modules (methods.js, scroll.js, animate.js, shortcuts.js) that export plain named functions; dom7.bundle.js is the only place that mixes all of them onto $.fn (Dom7.prototype) via Object.assign-style iteration, while the tree-shakeable entry leaves that wiring to the consumer. This split is the core architectural decision: one entry trades bundle size for jQuery-drop-in convenience, the other trades a manual mixing step for a minimal footprint.

Tech Stack Dom7 is plain ES2015+ JavaScript with a single runtime dependency, ssr-window, used exclusively to resolve window/document safely in non-browser (SSR) contexts instead of touching the globals directly. Build tooling is Rollup (driven by a custom scripts/build.js) with Babel’s preset-env for down-leveling and Terser for the minified output, producing CJS, ESM, and minified UMD-style bundles plus a hand-written dom7.d.ts typings file (types are authored, not generated from source). Linting uses ESLint with the Airbnb base config plus eslint-plugin-prettier, and .browserslistrc targets a broad, dated set of browsers consistent with its role as Framework7’s bundled DOM layer.

Code Quality There is no real automated test suite: scripts/test.mjs is a short manual smoke script that imports two functions from the built package/dom7.esm.js, mixes them onto $.fn, and calls addClass once — it asserts nothing and there’s no assertion library, test runner config, or CI workflow directory in the repo. Error handling is minimal to nonexistent (methods assume well-formed input and valid DOM nodes), and naming follows a consistent, low-abstraction functional style (one function per file-scoped concern, plain for loops over collections) that favors readability over defensive coding. Prettier and ESLint enforce formatting/style consistency, but there is no type-checking of the source itself (only hand-authored .d.ts output).

API Design The public API is deliberately unsurprising: every method mirrors a same-named jQuery method’s call signature (addClass(...classes), on(event, handler), attr(name, value)), so developers who know jQuery need no onboarding beyond import $ from 'dom7'. The tree-shakeable named-export style asks a bit more of consumers — they must manually assign wanted methods onto $.fn themselves (as scripts/test.mjs demonstrates) rather than getting everything by default, which is a small but real boilerplate cost traded for smaller bundles.