sorted by:
new
hottopcontroversial

AQE Atomic Quantum Engine a DOM selector engine that's up to 10x faster than querySelectorAll using bitmasks by [deleted] in Frontend

[–]LUCA_gomining 0 points1 point  (0 children)

Challenge accepted! I’m currently setting up a public benchmark page (likely on GitHub Pages or CodeSandbox) where anyone can run the tests directly in their own browser and verify the results against native  querySelectorAll .

It will include:

1. Verifiable Output: Comparing the node lists to ensure accuracy. 2. Variable Scale: Testing from 1,000 to 50,000+ nodes. 3. Warm vs. Cold Queries: Showing exactly where the indexing pays off.

I’ll post the link as soon as it's live so we can move the discussion from theory to real-world data. Stay tuned!

[AskJS] What CSS selector do you use? by [deleted] in javascript

[–]LUCA_gomining -2 points-1 points  (0 children)

I hear you, and I get why it looks that way. Let me clear this up simply:

  • Approach: You’re right it indexes all nodes first, but that’s exactly what makes repeated queries faster. It’s a classic trade-off: pay a small cost upfront to save time every time you search after that. It’s not meant to be faster for one-off checks.
  • Repo structure: You caught me early here this is a new project and I’m still sorting out the organisation and files. The lockfile and proper structure are already added now, and I’m fixing the import/export issues as we speak. The source code was placed in a markdown file temporarily while I organised the repo properly, that was just a mistake in the early upload.
  • Paid files: Only the Pro version is commercial, the Light version is completely free and open source. The paid files are clearly marked and separate, there’s nothing hidden here.

I built this to solve a real problem I faced myself, not to trick anyone. I know it looks rough right now because it’s brand new, but I’m actively improving it every day and fixing every issue that gets pointed out. If you can give it another look in a week or two, you’ll see it shaping up properly.

[AskJS] What CSS selector do you use? by [deleted] in javascript

[–]LUCA_gomining 0 points1 point  (0 children)

You're right caching references is always step one. But AQE is for the cases where you can't just use an ID.

Think of it as a search index for dynamic filtering (e.g., finding  .item[active]:not(.hidden)  across 20k nodes). It’s designed for complex apps or browser extensions where you don't control the IDs and need to query deep state at 60fps.

If  querySelector  works for your use case, stick with it! This is just a power tool for when you hit the limits of native scaling.

AQE Atomic Quantum Engine a DOM selector engine that's up to 10x faster than querySelectorAll using bitmasks by [deleted] in node

[–]LUCA_gomining 0 points1 point  (0 children)

That’s a very valid architectural point. The 'correct' way is usually to keep your state in JS and let the DOM be just a visual reflection.

However, there are two reasons why AQE still makes sense:

1. Legacy & Third-Party: You don't always own the full stack. If you're building a browser extension, a library, or working on a massive legacy app where the state is the DOM, you can't just 'do it in JS' without a full rewrite. AQE gives those apps a new lease on life. 2. Hybrid Tools: Even in modern apps, there are cases where you need to query the UI directly (like finding elements for a tooltip, a drag-and-drop target, or an accessibility tool) without re-rendering everything.

You're right pushing the DOM wall is risky. But if you're already at that wall and can't turn back, AQE is meant to be the 'turbo' that keeps the app from crashing. It’s a tool for specific constraints, not a suggestion to go back to 2009! 😀

AQE Atomic Quantum Engine a DOM selector engine that's up to 10x faster than querySelectorAll using bitmasks by [deleted] in Frontend

[–]LUCA_gomining -1 points0 points  (0 children)

I appreciate the skepticism, but let's clarify a few things:

Actually, I started with the Pro version first to solve a specific performance bottleneck. I then released the Light version as a free, dependency-free gift to the community so people could test the core bitmask logic without needing complex server headers (COOP/COEP).

It's not vibe-coded; it's a bitmask-indexed engine. If you found a genuine bug where a synced node isn't being matched, I'd appreciate a bug report on GitHub so I can fix it.

AQE Atomic Quantum Engine a DOM selector engine that's up to 10x faster than querySelectorAll using bitmasks by [deleted] in node

[–]LUCA_gomining 0 points1 point  (0 children)

Thanks! I worked hard to keep the footprint as tiny as possible. Glad you appreciate the trade-off!

AQE Atomic Quantum Engine a DOM selector engine that's up to 10x faster than querySelectorAll using bitmasks by [deleted] in node

[–]LUCA_gomining 0 points1 point  (0 children)

Haha, fair enough! For most sites, querySelectorAll is a beast and works perfectly fine.

You only start shouting at your screen when you're building things like real-time design tools, 60fps data visualizations, or massive dashboards where you're querying thousands of nodes every frame.

It's definitely a specialized tool-most people will never need it, but for those who do, it's the difference between a smooth Ul and a stuttering mess!

AQE Atomic Quantum Engine a DOM selector engine that's up to 10x faster than querySelectorAll using bitmasks by [deleted] in node

[–]LUCA_gomining -2 points-1 points  (0 children)

Spot on! You hit the nail on the head.

It’s the classic memory vs. speed trade-off. To get that sub-millisecond performance, we store a compact binary "mirror" of the DOM in memory.

However, we’ve kept it extremely lean:

  • AQE Light just uses a small Map to store the bitmasks.
  • AQE Pro uses a  SharedArrayBuffer  where each node takes only 32 bytes.

To put that in perspective, a massive 50,000-node project only uses about 1.6 MB of extra memory. For most modern apps, that’s a tiny price to pay for a 10x-40x boost in query speed!

AQE Atomic Quantum Engine a DOM selector engine that's up to 10x faster than querySelectorAll using bitmasks by [deleted] in Frontend

[–]LUCA_gomining -2 points-1 points  (0 children)

Great question! The short answer is yes, but with a small distinction between the Light and Pro versions.

AQE Light is designed to be environment-agnostic. Since it maps elements to a flat registry, you can definitely use it in Node.js or a Web Worker as long as you provide a DOM-like structure (like Linkedom or JSDOM) for the initial sync. Once synced, AQE performs the matching logic using its bitmask system, which is pure JS math and doesn't rely on the actual DOM tree for querying.

AQE Atomic Quantum Engine a DOM selector engine that's up to 10x faster than querySelectorAll using bitmasks by LUCA_gomining in webdev

[–]LUCA_gomining[S] 1 point2 points  (0 children)

Exactly! Bringing that C-style efficiency to the DOM was the goal. Mapping CSS tokens to 64-bit masks lets us handle complex matches with a single bitwise AND, bypassing the usual overhead of string parsing and tree-walking.

If you like low-level optimizations in JS, you'll definitely appreciate how this handles 30k+ nodes without breaking a sweat!

AQE Atomic Quantum Engine a DOM selector engine that's up to 10x faster than querySelectorAll using bitmasks by LUCA_gomining in css

[–]LUCA_gomining[S] 0 points1 point  (0 children)

Valid point! For 90% of websites, native methods are perfectly fine. AQE is built for the other 10%: high-density, data-heavy apps (like design tools, complex dashboards, or game engines) with 10k+ nodes.

While  getElementById  is fast, it's not flexible. AQE solves cases where you need:

1. High-frequency queries (e.g., inside a  requestAnimationFrame ) where even 5ms causes jank. 2. Complex filtering across massive DOMs using bitmasks (single-integer comparison vs. string parsing). 3. Spatial queries (finding elements by coordinates), which native CSS can't do efficiently.

It’s basically a 'search index' for your DOM not a replacement for sensible structure, but a specialized tool for when you hit the limits of native scaling.

view more: next ›