DEV Community: Hrutav Modha

[Boost]

Hrutav Modha — Sun, 30 Aug 2026 04:13:46 +0000

Hrutav Modha

Aug 29

How DriftJS Updates DOM Without Diffing or Signals?

#architecture #frontend #programming

4 min read

How DriftJS Updates DOM Without Diffing or Signals?

Hrutav Modha — Sat, 29 Aug 2026 16:36:37 +0000

In my last post, I introduced DriftJS — a frontend framework built around a register-based bytecode VM instead of Virtual DOM diffing or a compile-only reactive model. This post is the natural follow-up: how does the reactivity actually work under the hood?

I've been calling the mechanism Jump-Based Reactivity in my own notes — that's just the name I've given it for now, not an established or official term, so take it as a working label rather than a claim of industry terminology. Here's the actual model behind it.

The two established approaches, and where they spend their time

Virtual DOM diffing (React, and Vue's core diffing engine) answers "what changed?" at runtime, by comparing two trees. Even a single-character update walks a comparison algorithm over the affected subtree before a single DOM node gets touched. The cost is proportional to how much UI you're describing, not how much of it actually changed.

Signals (Solid, Svelte 5, Angular signals) answer "what changed?" by building a live subscription graph at runtime — a reactive value tracks every computation that reads it, and writing to it directly notifies exactly those subscribers. No tree, no diff, but there's a graph of subscription objects that has to be built, maintained, and torn down as your app runs.

This model takes a third position: answer "what changed, and where" entirely at compile time, so that at runtime there's no tree to walk and no graph to traverse — just a direct address to jump to.

How it actually works

When your template is compiled, every place a piece of state gets rendered — an interpolated value, a dynamic attribute — has a precise, fixed location in the compiled instruction stream. The compiler doesn't just generate that instruction stream; it builds an index while doing so: for every variable your component declares, it records exactly which instruction addresses depend on it.

Think of it as a table of contents built at compile time: "if count changes, the instructions that care about it live at these exact addresses." This table is static — built once, when the component is compiled, and reused for every instance of that component afterward. Nothing about it changes at runtime.

At runtime, when a state variable is mutated, the framework doesn't recompute anything or walk anything. It looks up the variable's entry in that compile-time table, and for each address recorded there, it jumps directly to that exact point in the instruction stream and executes precisely one instruction — read the new value, write it to the DOM. Then it stops. No re-execution of the surrounding component, no walk through unrelated instructions, no revisiting parts of the UI that didn't change.

Multiple state changes in the same tick get coalesced into a single batched pass, so five synchronous mutations don't trigger five separate rounds of this — they're collected and flushed together, with a safety limit against updates that could otherwise trigger each other in an unbounded loop.

Conditional and loop blocks work on the same principle at a slightly coarser level — tracked as named regions rather than individual instructions, so a state change that affects which branch is active, or which items exist in a list, resolves to "which regions does this variable affect" via a direct lookup, not a scan across every conditional or loop in the component.

Why this isn't Virtual DOM with extra steps

There's no tree, at any point, that gets rebuilt and compared. The entire "what needs to update" question is answered once, at compile time, and stored as a flat address table — never re-derived at runtime against a tree structure. A component with hundreds of static DOM nodes and one dynamic binding pays a cost proportional to one — the address recorded for that binding — never the size of the surrounding tree.

Why this isn't Signals with a different name

This is the comparison people reach for fastest, and it's worth being precise about. A signal's dependency relationships are discovered dynamically, at read time — a computation reads a signal, and that read creates a subscription object that has to live in memory for as long as the relationship holds. This compile-time address table is the opposite: built once, entirely at compile time, and it's pure data — a lookup table, not a graph of live subscription objects being created and torn down as the app runs.

The other real difference is granularity, and it's worth being upfront about: signals are fine-grained by construction — one reactive value, one precise set of subscribers. This model currently groups by declared variable name rather than individual binding. That's a real tradeoff against what signals give for free, and it's the thing I'm actively tightening next — recent benchmarking made it clear exactly where that coarseness costs the most: targeted updates to individual list items, not bulk rendering.

Lineage, and what's actually new

Compiling a template into an instruction stream that gets executed rather than diffed isn't new — Ember's Glimmer engine has done that since around 2017, and it's the closest existing relative to this design. What's different is how the "what changed" question resolves at runtime. Prior bytecode-VM approaches build their update-tracking structures at runtime and walk them sequentially when state changes. This model's address table is built at compile time and resolved through direct lookups — no runtime structure to walk, just a jump to a known address.

That's the actual claim: not reactivity reinvented from nothing, but a genuinely different way of assembling ideas that mostly already existed — compile-time indexing, direct addressing — into something with a different performance profile in practice.

Feedback, are genuinely welcom

GitHub Repo: Repo

Introducing DriftJS: An Ultra-Fast, Register-Based Bytecode VM Framework

Hrutav Modha — Wed, 05 Aug 2026 15:25:03 +0000

The frontend ecosystem is always evolving, moving from Virtual DOM diffing to fine-grained reactivity and compiler-heavy approaches. Today, I'm excited to share an experimental project exploring a different path: DriftJS.

DriftJS is a next-generation frontend framework powered by an in-browser register-based Bytecode Virtual Machine (VM).

Check out the GitHub Repository

The Architecture & Compiler Pipeline

Unlike traditional Virtual DOM frameworks that re-evaluate large tree structures, or compiler-only frameworks, DriftJS compiles .drift single-file templates into compact binary-serializable bytecode streams (CompiledModule).

At runtime, a lightweight 256-register VM executes these instructions directly against the DOM.

The compilation and execution workflow consists of 5 tightly decoupled stages:

DriftLexer: On-demand parser-driven tokenization
DriftParser: AST construction
DriftTransformer: Whitespace stripping & Acorn JS expression enrichment
DriftGenerator: Emits a precise 15-Opcode Bytecode Array, Constant Pool, & Reactive Bindings
DriftClientVM: Executes Bytecode via 256 Registers & Keyed LIS Reconciler

🔥 Key Technical Features

🛡️ 100% CSP Compliant: Built-in Acorn AST interpreter evaluates JS expressions in scope without eval() or new Function(), making DriftJS safe for strict Content Security Policy environments.
⚡ Register-Based Virtual Machine: Uses exactly 256 fast virtual registers (r0, r1, ...) for DOM elements, text nodes, and values. Memory allocation is kept incredibly low.
🔄 Keyed LIS Reconciliation: Features a custom Longest Increasing Subsequence (LIS) list reconciler that minimizes DOM node movements, insertions, and deletions during loop updates (triggered by the 0x0E REACTIVE_FOR opcode).
🎯 Fast-Path Attribute Patching: Re-evaluates element attributes in-place without rebuilding DOM subtrees when data object references remain stable using the 0x05 SET_ATTR opcode.
📍 Fine-Grained Reactive Regions: HTML comment anchors visually bound @if and @for blocks, allowing surgical clearBetweenAnchors re-rendering of targeted regions without disturbing surrounding DOM elements.

🏆 Benchmark Results vs React 19

In the official js-framework-benchmark suite, DriftJS shows massive performance gains:

10.8x FASTER than React 19 on "Swap rows (1k)" (119.0ms vs 1285.7ms)
3.05x FASTER on "Clear 1,000 rows" (92.4ms vs 282.0ms)
2.06x FASTER on "Create 10,000 rows" (1842.9ms vs 3804.5ms)
Uses ~1.8x less memory during the "Run-Clear" cycle.
5.75x smaller uncompressed bundle size than React 19.

We Need Your Help! 🤝

DriftJS is currently an experimental prototype. While the single-template bytecode compilation, Acorn expression evaluation, and basic keyed LIS list reconciliation are implemented and passing test suites, there is more to do!

Current limitations include a lack of component composition/nesting, routing, state management stores, and SSR/hydration.

We warmly invite framework researchers, compiler engineers, and open-source contributors to collaborate with us! Whether you want to fix bugs, optimize VM opcode execution, improve compiler error reporting, or add developer tools, we'd love to have you.

Drop by the repo, check out the architecture, and let us know what you think!

I'm a Diploma Student. I Built an AI Agent Sandbox in 2–3 Days Using setfacl

Hrutav Modha — Mon, 23 Mar 2026 17:31:54 +0000

I'm in 4th semester Diploma in Computer Engineering.

I don't know AutoGen, CrewAI, or Docker.

I had a problem, sat at my PC, and solved it.

The Problem

I was running agentic workflows via Gemini CLI using a markdown task file.

Wanted a loop: Developer → Tester → Reviewer.

Issue: Tester could read implementation.

So instead of:

"Does this satisfy the spec?"

It asked:

"Does this match the code?"

That's not testing — it's validation bias. I saw it happen: wrong code passed
because tests were influenced by source.

"Tell AI not to read files" is not a security model. It's trust.

I needed enforcement.

The Idea

Linux already solves this: filesystem-level access control.

useradd --system --no-create-home --shell /usr/sbin/nologin kernelcage-agent
setfacl -m u:kernelcage-agent:--- tests/

If Tester physically cannot read src/, the problem is eliminated at the
OS level. No prompts. No containers. Just the kernel refusing the syscall.

The key insight: setfacl lets you set permissions per user without
touching anyone else's access. My own permissions stay untouched. Only
kernelcage-agent gets restricted.

Architecture

3 agents, enforced by kernel.

No need for 3 users. Agents run sequentially — use one unprivileged
daemon user (kernelcage-agent), flip ACL permissions per turn using
setfacl before handing control to each agent.

Agent	TASKS.md	REVIEW.md	src/	tests/
Developer	R	R	R+W	none
Tester	R	R	none	R+W
Reviewer	R+W	R+W	R	R

Developer cannot read tests/ — kernel refuses the call
Tester cannot read src/ — derives tests only from spec, not implementation
Reviewer sees all, modifies only coordination files

Execution:

sudo -u kernelcage-agent bash -c "<generated_command>"

No sudo, no password — privilege escalation fails instantly at OS level.

The permission flip in Python looks like this:

def mark_no_access(path):
    os.system(f"setfacl -R -m u:kernelcage-agent:--- {path}")
    os.system(f"setfacl -R -d -m u:kernelcage-agent:--- {path}")

def mark_write_access(path):
    os.system(f"setfacl -R -m u:kernelcage-agent:rwx {path}")
    os.system(f"setfacl -R -d -m u:kernelcage-agent:rwx {path}")

def mark_read_only(path):
    os.system(f"setfacl -R -m u:kernelcage-agent:rx {path}")
    os.system(f"setfacl -R -d -m u:kernelcage-agent:rx {path}")

The -d flag sets default ACLs so newly created files inside a directory
automatically inherit the same restrictions. Without it, a file created by
the Developer agent would have no ACL and be readable by everyone.

Protocol

Two markdown files. That's the entire inter-agent communication layer.

TASKS.md — forward progress

- [ ] Task 1
- [x] Task 2

REVIEW.md — bug channel

When this file exists, it overrides normal flow across all three agents.

Present → fix described bug first
Absent → continue with next task

No APIs. No message queues. Files are the protocol.

Feedback Loop

TASKS.md → Developer → src/
           (no test access)
                ↓
           Tester → tests/
           (no src access)
                ↓
           Reviewer → runs suite
                ↓
          FAIL        PASS
           ↓            ↓
      append          mark done
      REVIEW.md       commit + push
           ↓
      Developer
      reads bug,
      fixes src/

No human intervention in the normal path.

Prior Art Search

Searched GitHub, ArXiv, Google Scholar, HackerNews, Reddit, and
documentation of every major agentic framework.

Findings:

All frameworks use either prompt isolation or containers
None applied native Linux filesystem permissions to isolate agents from each other in a coding loop

Closest match: A March 2026 academic paper on a hospital agent OS using
the exact same mechanism — Linux user isolation, ACL-based file permissions,
inter-agent coordination via document writes — for medical agents under
HIPAA compliance requirements.

Same architecture. Different domain. Published after this.

Current Status

Single Python script
Uses a predefined TASKS.md
One unprivileged daemon user
setfacl permission flipping per agent turn

No config system, no multi-provider support, no packaging yet.

Works.

GitHub: https://github.com/hrutavmodha/ai-sandboxer

(Note: setfacl requires ACL support enabled on your filesystem.
Check with mount | grep acl. If not enabled:
sudo mount -o remount,acl /)

Honest Note

Built in 2-3 days.

No prior framework knowledge. No Docker. No awareness of what the
"standard" solution was supposed to be.

Just looked at the problem and reached for what the OS already provides.

Sometimes not knowing the established approach means you find a
different one.

If there's a flaw, I genuinely want to know.

Stars, issues, and brutal feedback all welcome.