Jane Street open-sourced Bonsai in mid-2025, and if you scrolled past the announcement because "OCaml" and "financial firm" don't sound like your stack, I get it. I almost did the same thing. But I spent a weekend reading the source, the docs, and a few talks from Jane Street engineers, and what I found changed how I think about UI architecture.
Bonsai isn't going to replace React at your day job. That's not the point. The point is that it solves problems most web frameworks haven't even acknowledged yet, and the patterns it uses are quietly showing up in other places too.
What Bonsai Actually Is
Bonsai is a library for building interactive web UIs in OCaml. It sits on top of virtual_dom (Jane Street's own virtual DOM implementation, written in OCaml) and compiles to JavaScript via js_of_ocaml. You write components, compose them, and get a running app in the browser.
But the way it handles state and updates is where things get interesting.
Instead of a component model like React's - where each component manages its own state tree and re-renders through reconciliation - Bonsai treats your entire application as a single incremental computation graph. Every piece of state is a "value" in this graph. When something changes, the graph figures out exactly what downstream computations and DOM patches need to fire. Nothing else moves.
This isn't new math. It's based on Jane Street's Incremental library, which they've used internally for years to build trading systems that process millions of market data updates per second. Bonsai brings that same engine to the browser.
The result: you write declarative code, but the runtime is surgical about updates. No virtual DOM diffing. No re-rendering a whole component subtree because one value changed. Just a direct path from state mutation to DOM patch.
Why This Matters for Web Developers
"OK, but I write TypeScript. Why should I care about an OCaml library?"
Fair reaction. Here's why.
The problems Bonsai solves are the same problems every frontend framework is wrestling with right now. React's useEffect dependency arrays, Solid's fine-grained reactivity, Svelte's compile-time analysis, Vue's Vapor mode experiment - these are all attempts to answer the same question: how do we update the UI efficiently without making the developer think about it?
Bonsai's answer is the most disciplined version I've seen. And it works because OCaml's type system eliminates entire categories of bugs that JavaScript frameworks have to runtime-check.
A few things jumped out:
Incremental computation as a first-class primitive. In React, you have useMemo and useCallback as performance hints. They're opt-in, easy to get wrong, and frequently misused. In Bonsai, incremental computation isn't an optimization you bolt on. It's the fundamental mechanism. Every value in your app is automatically tracked, and the system knows what depends on what. You don't memoize things. The graph does it for you.
No stale closure problem. If you've ever debugged a React hook that captured an old value because the dependency array was incomplete, you know this pain. Bonsai's model makes this structurally impossible. Values in the computation graph are always current. The concept of "stale closure" doesn't exist.
Effects are typed and tracked. Side effects in Bonsai aren't fire-and-forget callbacks. They're modeled explicitly in the computation graph, which means the system knows when an effect should run, what it depends on, and when to tear it down. No more empty useEffect arrays that run on every render, or cleanup functions that miss dependencies.
The Incremental Model, Explained Simply
Here's the mental model. Imagine your app as a directed acyclic graph. At the top, you have inputs - user events, WebSocket messages, timers, API responses. Below those, you have derived values that depend on them. And below those, DOM descriptions that depend on those.
When an input changes, the system walks the graph downstream and recomputes only the nodes that actually need updating. If a value doesn't change, its downstream nodes are skipped entirely.
This is different from React's reconciliation model, where a state change triggers a component re-render, which produces a new virtual DOM tree, which gets diffed against the previous one, which produces DOM patches. React's approach works, but it does a lot of unnecessary work. The virtual DOM diff is fundamentally an approximation of what changed - it doesn't know, it checks.
Bonsai's graph knows. It tracked the dependency when you set it up.
Solid.js comes closest to this on the JavaScript side. Signals in Solid work similarly - they track dependencies automatically and update only what changed. But Solid's system is still opt-in in some places (you need createMemo for derived values, you can accidentally break reactivity by destructuring props). Bonsai's model is more rigid, and that rigidity is the feature.
What Web Frameworks Are Stealing From This
You don't need to write OCaml to benefit from these ideas. They're migrating into the JavaScript ecosystem already.
Svelte 5's runes move Svelte toward a signal-based reactivity model that looks a lot like fine-grained incremental computation. $derived values that automatically track their dependencies? That's the same graph idea.
Vue's Vapor mode is an experiment to bypass the virtual DOM entirely and compile reactive updates to direct DOM operations. Same goal as Bonsai: skip the diff step.
React's compiler (React Forget, or whatever they're calling it this week) aims to auto-memoize components so developers don't have to think about useMemo and useCallback. It's trying to get closer to the "the system tracks dependencies for you" model that Bonsai already has.
Signals in Angular, Preact, and the TC39 proposal - the web platform itself is moving toward signals as a standard primitive. If the TC39 signals proposal lands, every framework gets access to a dependency-tracking mechanism built into the language.
The pattern is clear. Frontend architecture is converging on the same set of ideas that Jane Street has been shipping in production for years. Bonsai just happens to be the purest expression of those ideas.
Where Bonsai Falls Short (For Now)
I don't want to oversell this. Bonsai has real limitations.
The OCaml ecosystem for web development is tiny. Tooling is sparse. The learning curve is steep if you've never touched a functional language with algebraic types and pattern matching. Documentation, while improving, still assumes a lot of Jane Street internal knowledge.
And the performance story needs more real-world data. Jane Street uses this internally, but their UIs are trading dashboards with specific characteristics - high update frequency, data-heavy, relatively low visual complexity compared to a consumer app. How Bonsai performs on a large-scale, image-heavy, animation-rich consumer web app is an open question.
There's also the composition model. React's component model is incredibly flexible - you can pass children, render props, higher-order components, hooks. Bonsai's Bonsai.t (the core component type) is more constrained. That constraint is intentional, but it means some UI patterns that are easy in React require more thought in Bonsai.
What I Took Away
After spending time with Bonsai, I started looking at my React code differently. Specifically, I started questioning the places where I reach for useEffect and useMemo as band-aids over a model that doesn't natively track dependencies.
The big takeaway isn't "learn OCaml." It's that the frontend world is slowly admitting that the component-plus-virtual-DOM model has a ceiling. The next generation of frameworks - whether it's Svelte 6, React's compiler, or something we haven't seen yet - will probably look more like an incremental computation graph than a tree of re-rendering components.
Bonsai is a preview of that world, running in production at one of the most technically demanding firms on Wall Street.
That's worth paying attention to, even if you never write a line of OCaml.
Getting Started If You're Curious
Want to poke around? The GitHub repo has examples that cover the basics: counter apps, todo lists, small data dashboards. You'll need opam (OCaml's package manager) and a willingness to read type signatures.
Start with the Bonsai.t type and how Bonsai.state_machine works. That's the component equivalent. Then look at how Bonsai.assoc handles dynamic lists - it's the closest thing to React's .map() rendering, but with incremental tracking baked in.
And if OCaml feels too far out of your comfort zone, read the architecture docs anyway. The mental model translates. Understanding how a dependency graph drives UI updates will make you better at React, Svelte, or whatever you build with next.
