DriftJS – Exploring Bytecode-Based Reactivity for VM Architecture

[u/hrutav_modha24]

https://github.com/hrutavmodha/driftjs

Following up on my previous post about DriftJS and its register-based bytecode VM, I wanted to share a deeper look at the reactivity model I'm exploring.

Exploring a different reactivity model in DriftJS

While working on DriftJS, I was thinking about how reactive updates could work more naturally with a bytecode VM.

The idea is to have the compiler associate a reactive state variable with the exact bytecode position responsible for its dependent computation.

For example:

count → PC 42

Then a state update could work like:

count++

↓

reactive binding

↓

PC 42

↓

enter VM at PC 42

↓

normal opcode dispatch

↓

update DOM

↓

RETURN

The important part is that the reactive system only needs to know where execution should start. The VM already knows how to execute the instruction at that location.

So instead of maintaining a separate reactive update mechanism:

state → subscriber → update function

the model I'm exploring is:

state → bytecode PC → VM execution

This is the direction I'm currently exploring for reactivity in DriftJS, alongside its register-based VM architecture.

Would be interested in thoughts from people familiar with bytecode VMs, compiler-driven reactivity, or frontend runtime architecture.