DEV Community: Hrutav Modha

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.