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.












