The editorial argues that mainstream frameworks force a choice between React's pure-function abstraction (undermined by useEffect/useRef) and signals-based fine-grained reactivity (undermined by subtree rebuilds). Bonsai's bet is that modeling the entire UI as one incremental computation graph collapses that tradeoff, giving developers the cleaner mental model without paying the performance tax.
The editorial emphasizes that while the theoretical lineage (Adapton, Salsa, Jane Street's own Incremental) is well-known in academia, Bonsai is different because it has been shipping trader dashboards and order tickets at a firm where bugs cost real money. The hundreds of contributors, component model, effect handling, form combinators, router, RPC integration, and DOM-snapshot test harness are cited as evidence this is a serious production framework, not a research toy.
The editorial notes the docs assume prior OCaml knowledge and that there is no getting-started tutorial for newcomers. Combined with the js_of_ocaml compilation pipeline, this signals Jane Street is publishing the library as-is for a technical audience already fluent in the ecosystem, rather than courting mainstream adoption.
By submitting the raw GitHub repo link with no explainer, the submitter treats the audience as already familiar enough with Jane Street and OCaml tooling to evaluate Bonsai on its own terms. The 160-point score with only 58 comments suggests interest is concentrated among readers who recognize the significance without needing hand-holding.
Jane Street pushed Bonsai to a public GitHub repo, and Hacker News noticed. Bonsai is the UI library the firm has been using internally for years to build the trader-facing dashboards, order tickets, and monitoring tools that sit in front of one of the highest-volume quant trading operations on earth. It compiles OCaml to JavaScript via `js_of_ocaml` and runs in the browser like any other SPA framework.
Bonsai's central idea is that a UI is a pure, incremental function from a model to a view, and the framework's job is to recompute only the parts of that function whose inputs actually changed. That's not new in academia — it's the same lineage as Adapton, Salsa, and the Incremental library Jane Street open-sourced years ago — but shipping a full component framework built on it, in production, at a firm that measures bugs in dollars, is a different story than a research prototype.
The repo is not a weekend polish job. It has hundreds of contributors' worth of history, a component model (`Bonsai.t`), effect handling, form combinators, a router, RPC integration, and a test harness that lets you snapshot the entire virtual DOM output for a given model. The docs assume you already know OCaml. There is no getting-started tutorial that pretends you don't.
Most UI frameworks make you choose between two lies. React tells you components are pure functions of props, then hands you `useEffect`, `useRef`, and a reconciler that reruns your function on every keystroke. Signals-based frameworks (Solid, Svelte 5, Vue's Composition API) tell you reactivity is fine-grained, then quietly rebuild large subtrees when a signal's identity changes. Both approaches work. Both leak.
Bonsai's bet is that if you model the entire UI as one big incremental computation graph, the framework can give you React's mental model and Solid's performance profile without the caveats. A `Bonsai.t` is a value that, given a model, produces a view. Compose two of them and you get a new one. There is no component lifecycle, no `useMemo`, no dependency array. The incremental engine underneath tracks which sub-computations depend on which pieces of state and only re-runs the ones whose inputs moved.
The interesting comparison isn't Bonsai vs. React — it's Bonsai vs. Elm. Elm proved you can ship a strictly-typed, pure-functional UI to production and have humans still enjoy writing it. Elm also stalled, partly because the language deliberately refused to grow. OCaml has none of that restraint: it has modules, functors, GADTs, effect handlers landing in the compiler, and a serious industrial user base. If you wanted to bet on a functional UI stack that would still be maintainable in a decade, the argument for OCaml over Elm was already strong. Bonsai makes it concrete.
The community reaction on HN was telling: the top comments weren't "can I use this at work" — they were "finally, a real-world example of incremental computation at UI scale." That's the honest read. Very few teams are going to port a React app to OCaml. But the patterns Bonsai formalizes — treating the UI as a data structure, scoping recomputation with static analysis of the dependency graph, testing components by feeding them a model and diffing the output — are exactly the patterns the rest of the ecosystem is haphazardly rediscovering. React Server Components, Signals, Suspense boundaries, and the whole "resumability" conversation in Qwik are all attempts to bolt some form of incrementality onto a framework that started without it.
There's also a cultural signal here. Jane Street has open-sourced a lot of OCaml infrastructure — Core, Async, Incremental, `ppx_jane`, `patdiff` — but Bonsai is the first piece that touches the surface a non-OCaml developer might care about. It's a statement that the firm thinks the ideas are portable even if the language isn't.
Be honest about what you'd actually do with this. If your team ships TypeScript, you're not switching to OCaml because Jane Street published a repo — and Bonsai's authors would probably tell you not to try. The compile toolchain, the ecosystem gap, the hiring pool, the sheer weight of npm — none of that goes away because the design is elegant.
What's worth doing is reading the Bonsai source with your current framework in mind. Look at how `Bonsai.state` differs from `useState`: the state isn't stored in a hidden fiber tree keyed by call order, it's a first-class value in the computation graph. Look at how `Bonsai.assoc` handles a list of dynamic children without keys — the incremental engine already knows which child depends on which row of the input map. Then look at the last three bugs you fixed in your React app. How many were dependency-array mistakes, stale closures, or `key` prop issues that would simply not exist in this model?
The practical takeaway for most teams is: when you reach for Zustand, Jotai, or TanStack Query, you're building an ad-hoc incremental computation graph on top of a framework that doesn't have one. That's fine — it's how the ecosystem evolved. But it's worth knowing there's a coherent alternative design where that graph is the framework, not a library bolted on top. It sharpens the questions you ask about your own architecture: which pieces of state actually drive which pieces of the view, and is your framework helping you enforce that or hiding it?
Bonsai is unlikely to dent React's market share, and that's not the interesting question. The interesting question is which of its ideas leak into the mainstream over the next two years. Signals already borrowed the fine-grained-reactivity half; the incremental-computation-graph half is the harder, more valuable piece. Watch the frameworks that are already rethinking their reconciler — Solid, Qwik, and whatever the React team ships after Server Components stabilize — and see which of them start describing themselves in Bonsai's vocabulary. Ideas travel faster than languages.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.