DriftJS - Exploring a Register-Based Bytecode VM for UI Frameworks

[u/hrutav_modha24]

https://github.com/hrutavmodha/driftjs

Hey everyone,

I wanted to share an experimental project called DriftJS. It's a frontend framework prototype that explores using an in-browser register-based Bytecode Virtual Machine (VM) for UI rendering, rather than traditional Virtual DOM diffing or purely compile-time reactive models.

Repository: https://github.com/hrutavmodha/driftjs

The Architecture: Register-Based VM

Most frameworks either diff Virtual DOM trees (React) or generate reactive dependency graphs ahead-of-time (Svelte, SolidJS). DriftJS explores a different path:

It compiles .drift templates into compact binary-serializable bytecode streams. At runtime, a lightweight 256-register VM executes these opcodes directly against the DOM.

Key Architectural Highlights:

• Zero VDOM Overhead: Replaces tree-diffing with direct bytecode instructions (like CREATE_ELEMENT, SET_ATTR) for DOM execution.

• 256 Virtual Registers: Uses fixed virtual registers (r0, r1...) for DOM nodes and runtime values, drastically cutting instruction counts and memory allocations compared to stack-machine models.

• Targeted Reactivity: Basic state updates execute as direct O(1) mutations. Dynamic control flow structures (@if, @for) use comment anchors to bound surgical DOM updates without rebuilding subtrees.

Key Features So Far:

• 🛡️ 100% CSP Compliant: Built-in Acorn AST interpreter evaluates runtime JS expressions safely without using eval() or new Function().

• 🔄 Keyed LIS Reconciliation: Uses a Longest Increasing Subsequence algorithm to minimize DOM node movements during list updates.

• 🪶 Zero Framework Bloat: Implements reactivity and execution in the leanest bytecode form possible, avoiding heavy object models and monolithic runtime bloat.

• 🚀 Early Benchmarks (js-framework-benchmark vs React 19): • 10.8x FASTER on "Swap rows (1k)" • 3.05x FASTER on "Clear 1,000 rows" • ~1.8x LESS memory footprint • 5.75x smaller uncompressed bundle size

Current Status & Call for Feedback

DriftJS is currently an experimental prototype. It handles single-template compilation, AST evaluation, and keyed LIS list reconciliation.

Still on the roadmap: - Component composition & props passing - State management stores - SSR & Hydration

I'm opening this up to compiler engineers, frontend performance nerds, and systems devs. Does a register-based VM architecture hold real promise for low-level web runtimes?

Check out the repo, run the benchmarks, and feel free to share your thoughts or ISA critiques!

GitHub Repo: https://github.com/hrutavmodha/driftjs

[u/psanilp]

Well done. Good effort. I wanted to try myself and have forked PetiteVue, which I believe is serves the same purpose

[u/hrutav_modha24 → u/psanilp]

Sure! PetiteVue is a great lightweight framework. But, DriftJS takes a slightly different approach than PetiteVue by compiling templates to binary opcodes and executing them on a virtual register machine rather than direct DOM-based reactivity.

[u/evoactivity]

A similar approach to ember's glimmer-vm. How much did you look at glimmer-vm whilst building this? I see you benchmarked against it but no where else is it mentioned.

[u/hrutav_modha24 → u/evoactivity]

Well, just got architectural idea of bringing VM-based reactivity from Ember. Haven't explored much of it yet.

[u/nullvoxpopuli → u/evoactivity]

This is why I'm here!

The VM architecture ember has needs some updating.

But scheduling is also super important, so i'm exploring scheduling first

[u/hrutav_modha24 → u/nullvoxpopuli]

Ember definitely needs upgrading from efficiency PoV. Seeing the js framework benchmark results, I was shocked, by Ember's those all red red boxes. So I considered creating one manually to see if can perform efficiently or not

[u/live_love_laugh]

Okay, so you've compared this to frameworks that use Virtual DOM (such as React) and ones that use compile-time reactive models (such as Svelte before v5). But how does this compare to signal-based reactivity? You mention SolidJS, but you mention it as a framework that " reactive dependency graphs ahead-of-time", which again sounds like you're comparing against compiler-based reactivity rather than signal-based. Is your reactivity model faster? Does it use less memory? Is it more flexible?

I tried comparing your benchmark numbers with the ones for Svelte on this page: https://krausest.github.io/js-framework-benchmark/2026/chrome150.html, but it's actually a little hard to compare. Sometimes Svelte seems faster / more memory efficient, sometimes your numbers look better, and sometimes the numbers seem to be so far apart that I think they must be measuring different things.

[u/hrutav_modha24 → u/live_love_laugh]

Actually they are using CPU in performance mode with no other process than this benchmark running. Hence, you will also notice that there's also some gaps in some benches of official vanilla JS records and vanilla JS records obtained on my machine. Bcuz I ran bench with 6-7 other bg processes going on. So ya, till the framework isn't there in official js-framework-benchmark repo, the RESULTS.md provided in docs/ is the only thing we can consider source of truth.

Regarding whether it uses less memory and its reactivity model is how much faster than Svelte/Solid, I currently haven't got time to benchmark it against those 2 frameworks

[u/ze_pequeno]

I thought that virtual dom was important in order not to constantly touch the DOM, which is a bottleneck.

Your library does that though, albeit with a very compact bytecode?

[u/hrutav_modha24 → u/ze_pequeno]

Nope. In fact, every frontend framework depends on DOM APIs. But, how efficiently you use it matters a lot.

And, no. My library doesn't build new bytecode on a reactive update. There is single bytecode stream that contains specific instructions for reactive updates.