Steal These Ideas From Jane Street's Bonsai

Bonsai, the UI library behind nearly every web application inside Jane Street, hit the Hacker News front page again this week, and the thread played out the way OCaml threads always do: half the commenters marveling that a trading firm ships its whole frontend in OCaml, the other half complaining the demo apps look like they were designed in 1996. Both camps missed the point. Bonsai isn't a curiosity from a parallel universe. It's a preview of architectural decisions the JavaScript world spent the last five years slowly converging on — plus a couple it still hasn't made.

The signals wave, five years early

Bonsai, open-sourced under MIT and in production since 2019, sits on top of Incremental, Jane Street's implementation of self-adjusting computation — the academic lineage that runs through Umut Acar's thesis work. You build a dependency graph of values; when an input changes, only the downstream nodes recompute. If that sounds like signals — SolidJS, Preact Signals, Svelte 5's runes, Angular's reactivity rewrite, the TC39 signals proposal — that's because it's the same idea. Fine-grained reactivity wasn't born in JavaScript (Knockout had observables in 2010), but mainstream JS only committed to it between 2022 and 2025. Bonsai had it as the foundation from day one, not as a performance retrofit.

The part the signals frameworks still haven't fully absorbed: Bonsai applies incrementality to everything, not just rendering. The same primitives that stop the page re-rendering during interaction will incrementalize an expensive business-logic computation over a live-updating dataset. In React you'd assemble that from useMemo, reselect, and prayer; even in Solid, reactivity is culturally a view-layer concern. For Jane Street — where the UI is often a window onto a firehose of market data — the business logic is the hot path, and having one incremental substrate under both is the whole trick.

State machines, not hooks

Bonsai describes its components as purely functional state machines, and — unlike React, which fuses state, incrementality, and rendering into the single abstraction of "component" — it lets you compose those primitives à la carte. State isn't pinned to a position in a render tree. That's not a cosmetic difference. React's "rules of hooks" exist precisely because hook state is keyed to call order within a tree position; Bonsai instead gives you explicit lifecycle and scoping APIs, so embedding a collection of stateful widgets inside, say, a tabbed interface doesn't require hoisting every child's state into a top-level store.

It's also a quiet correction of Elm, which Bonsai credits as an inspiration. Elm's architecture is beautiful until your app grows and every component's state must be manually threaded through one global model and update function. Bonsai keeps the purity and drops the ceremony.

Tests your agent can read

The feature I'd steal first has nothing to do with reactivity. Bonsai UIs are tested with expect tests: the DOM renders as text inline in your test file, and interactions produce diffs.

Handle.input_text handle ~get_vdom:Fn.id ~selector:"input" ~text:"Bob";
Handle.show_diff handle;
[%expect {|
    <div>
      <input oninput> </input>
-     <span> hello  </span>
+     <span> hello Bob </span>
    </div> |}];

No browser, no jsdom, no pixel screenshots — the UI's behavior is a readable, diffable artifact in the repo. In 2026 that matters more than it did in 2019, because coding agents can't look at your app, but they can read that diff and regenerate it. Jane Street's own engineering blog makes this connection explicitly, crediting Claude Code's early-2025 launch with kicking off a terminal-UI renaissance internally and noting that text-renderable UIs let agents verify their own work. Because the Bonsai core was always frontend-agnostic — it's really a library for managing the lifecycle and scoping of state — bolting on a terminal renderer was cheap: Bonsai_term went from a summer-2024 hobby project to production in April 2025, and now powers tools like strace-ui. The web framework grew a TUI framework almost for free. That's the payoff of separating your abstractions properly, and it's a test most JS frameworks would fail.

Should you adopt it?

Almost certainly not, unless you already write OCaml — and the HN skeptics are right about why. The toolchain is opam and dune with whole-program compilation to JavaScript via js_of_ocaml, which means leaving npm behind: bindings to JS libraries are hand-rolled, there's nothing like Vite's hot-module reload with state preservation, and your hiring pool shrinks to people who can be taught OCaml. If what you want is OCaml's type system with the JS ecosystem, Melange is the pragmatic path — it targets the React world and meets npm where it lives. Bonsai is the opposite bet: replace the stack wholesale so the same types flow from your trading engine to your <div>s. That trade pays off spectacularly at a firm with thousands of OCaml engineers and near-zero need for third-party UI packages. That firm is not your firm.

But "don't adopt" and "don't study" are different verdicts. Bonsai is what a UI framework looks like when it's designed from computation outward rather than from components inward, and it's been quietly validating ideas — fine-grained incrementality, state decoupled from the view tree, snapshot tests over semantic markup instead of pixels — years before the mainstream arrived at each one. The signals people got there eventually. Worth checking what else is in the tree.