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.
Top comments (0)