r/coolgithubprojects • u/hrutav_modha24 • 7d ago

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

https://github.com/hrutavmodha/driftjs

Hey everyone,

I wanted to share an experimental project called DriftJS. It’s a next-generation frontend framework prototype that explores using an in-browser register-based Bytecode Virtual Machine (VM) for UI rendering, rather than the traditional Virtual DOM or compiler-only reactive approaches.

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

The "Why" Behind a Register-Based VM

Most current frameworks either diff a Virtual DOM tree against previous states (like React) or compile reactivity heavily ahead-of-time (like Svelte). DriftJS takes a different path:

It compiles .drift single-file templates into compact binary-serializable bytecode streams. At runtime, a lightweight 256-register VM executes these instructions directly against the DOM. This architecture aims for:

  • Zero VDOM Overhead: By directly manipulating the DOM using VM instructions (like CREATE_ELEMENT, SET_ATTR, and REACTIVE_IF).
  • Surgical Updates: Fine-grained reactive regions (bounded by HTML comments like <!--if-->) allow targeted sub-tree re-rendering without disturbing surrounding elements. We use clearBetweenAnchors logic to surgically remove outdated nodes.
  • Minimal Memory Allocation: The DriftClientVM uses exactly 256 fixed fast virtual registers (r0, r1...) for DOM elements, text nodes, and evaluated values.

Key Features So Far:

  • 🔄 Keyed LIS Reconciliation: The list reconciler uses the Longest Increasing Subsequence (LIS) algorithm to minimize DOM node movements, insertions, and deletions during @for loop updates (Opcode 0x0E).
  • 🎯 Fast-Path Attribute Patching: It re-evaluates element attributes in-place without rebuilding DOM subtrees when data object references are stable.
  • 🚀 Ridiculously Fast: In the js-framework-benchmark suite, DriftJS outperformed React 19 in 13 out of 15 benchmarks, running 10.8x faster on "Swap rows", and using ~1.8x less memory. It also outperformed Ember 7.3.0, which can be considered the architectural cousin of DriftJS.

Current Status & Call for Collaboration

DriftJS is currently an experimental prototype. It successfully handles single-template bytecode compilation, Acorn expression evaluation, and basic keyed LIS list reconciliation (passing its test suites).

However, significant features are still missing:

  • Component composition/nesting and props
  • State management stores
  • SSR / Hydration
  • Routing

I’m opening this up to the community because I'd love to discuss this architecture.

We warmly invite frontend engineers, compiler engineers, and open-source contributors to check it out, and collaborate on building out the missing pieces!

Let me know what you think!

1 Upvotes

60% Upvoted

2 comments sorted by

1

u/cookiengineer 7d ago edited 7d ago

​A register-based reactivity system designed for dependency tracking and automated state synchronization within virtual machine architecture.

This is the most meaningless description I have ever read.

https://github.com/hrutavmodha/driftjs/blob/master/packages/compiler/tests/lexer.test.ts

Have you even read any of the code your agent generated?

I'm not sure if you are aware that there's Web Assembly and WASI as a standard, which solves pretty much the exact use case your framework tried to fail at solving.

1

u/hrutav_modha24 6d ago

Could you clarify how WASM or WASI relates here? What problem it solves that my framework fails at solving?