I've been frustrated with querySelectorAll performance in high-frequency scenarios for a while. On large DOMs (10k+ nodes) with 50–100 queries/second — think virtual DOM diffing, live dashboards, design tools — it becomes a real bottleneck.

So I built AQE (Atomic Quantum Engine): a CSS selector engine that replaces tree traversal with flat, memory-mapped bitwise operations.

HOW IT WORKS

Every DOM node gets a 64-bit BigInt bitmask. Each CSS token (tag, .class, #id, [attr], pseudo-class) maps to a unique bit position. Matching a selector becomes a single integer AND:

(nodeMask & targetMask) === targetMask

No string parsing. No tree climbing. No attribute iteration at query time.

AQE LIGHT — free, MIT, on npm now

Synchronous bitmask pre-filter + el.matches() for complex selectors

Zero dependencies, single file, works everywhere

~3–5× faster than querySelectorAll on warm queries

Best for up to ~5,000 nodes

npm install atomic-quantum-engine

BENCHMARKS — 20,000-node DOM, .active[data-ready]

Warm query: querySelectorAll ~4–8ms / AQE Light ~1–3ms / AQE Pro ~0.1–0.4ms 100 concurrent queries: querySelectorAll ~400–800ms / AQE Light ~150–300ms / AQE Pro ~5–15ms 50k node DOM: querySelectorAll ~10–20ms / AQE Light ~8–15ms / AQE Pro ~0.5–1.5ms

Run the benchmarks yourself in the browser: https://willmartaqe.github.io/AQE/

WHEN NOT TO USE IT

If your DOM has fewer than ~1,000 nodes or you query infrequently, native APIs are faster with zero setup. AQE is for measured bottlenecks at scale.

npm: https://www.npmjs.com/package/atomic-quantum-engine
GitHub (Light): https://github.com/willmartAQE/AQE
Questions: williammartin.aqe@gmail.com

Happy to answer questions about the architecture, the Bloom index implementation, or the SharedArrayBuffer setup. Would love feedback from anyone building tools where selector performance actually matters.