HN Debrief

Bonsai: Janestreet's UI Library

  • Programming
  • Developer Tools
  • Open Source
  • Finance
  • AI

Bonsai is Jane Street’s UI library in OCaml. It targets web UIs through bonsai_web and terminal UIs through bonsai_term. The key idea is not "OCaml React" so much as a framework for composing incremental state machines, then specializing that model into an interface. That framing landed better than the marketing pitch. People who had seen Jane Street’s podcast or read the source said the interesting part is the architecture underneath, not the sample screenshots.

If your team already runs on OCaml and builds complex internal tooling, Bonsai looks like a serious option. If you depend on mainstream web packages, designers, and easy hiring, the interop and ecosystem costs will dominate long before framework elegance matters.

Discussion mood

Interested but niche. People respected the engineering and Jane Street’s use case, but most saw Bonsai as compelling mainly for OCaml-first teams building dense internal tools, not as a general replacement for mainstream web stacks.

Key insights

  1. 01

    State machine model is the real draw

    Bonsai is more usefully understood as an engine for composable incremental state machines that happens to power web UIs. That reframes it away from surface comparisons with React or Vue and toward a deeper architecture that can also drive terminal apps through Bonsai_term.

    Evaluate Bonsai on whether your UI is really a complex stateful system, not on whether its widgets look modern. If your hardest problem is coordinating interactive state, this model is the part worth studying.

      Attribution:
    • strongly-typed #1
    • frutiger #1
  2. 02

    JavaScript interop is the adoption tax

    The hard part is not compiling OCaml to JavaScript. That has been solved many times. The pain is living inside a smaller ecosystem where wrappers, bindings, and package compatibility become ongoing work, especially once you need to mix with standard web tools. Bonsai also pulls in much of Jane Street’s library stack through Core, which makes this feel more like joining an ecosystem than adding a lightweight package.

    Audit every browser dependency you rely on before treating Bonsai as a drop-in choice. If your product leans on third-party frontend packages, the integration work will outweigh any language unification win.

      Attribution:
    • philipwhiuk #1
    • vips7L #1
    • sroerick #1
    • LeonidasXIV #1
  3. 03

    Trader UX optimizes for throughput

    Jane Street’s design choices make more sense once you view the target user as a trader or operator living in the interface all day. High information density, multiple views on screen, and reduced pointer travel are not stylistic quirks. They are part of a workflow where seeing more at once directly improves decision speed and error detection.

    Do not judge internal expert software by consumer app standards. If your users are power operators, measure success with task speed, scanability, and keyboard flow before worrying about visual fashion.

      Attribution:
    • OneDeuxTriSeiGo #1
    • chrisweekly #1
    • kfse #1
    • jackcarter #1
  4. 04

    Best fit is interactive apps, not reports

    Bonsai earns its keep when the UI has complicated shared state and many interacting components. For static HTML reports or lightly interactive output, commenters said it adds little over ordinary HTML and JavaScript. One maintainer also said agent-assisted development works fine on a Bonsai codebase despite the library being obscure, which cuts against the idea that niche tools are unusable with LLMs.

    Use Bonsai only if your frontend logic is genuinely complex and long-lived. For generated reports, dashboards with light interactivity, or one-off agent output, keep the stack simpler.

      Attribution:
    • tikhonj #1
    • derdi #1
    • disconcision #1
  5. 05

    WASM does not remove browser constraints

    WebAssembly was raised as a way around JavaScript ecosystem friction, but the replies made clear it does not solve the main problem yet. Browser APIs and the DOM still require JavaScript interop, which adds overhead and complexity, and compiled binaries can be much larger than source for simple apps. Even lower-level runtime details like tail calls remain constrained by browser support.

    Do not assume a WASM path magically fixes frontend portability. For browser-heavy UI work, DOM and web API integration still dictate the shape of the solution.

      Attribution:
    • danielheath #1
    • applfanboysbgon #1
    • debugnik #1

Against the grain

  1. 01

    LLMs reduce the value of UI frameworks

    A strong dissent was that the old reason to adopt a framework or component library has weakened fast. With a decent data API and modern coding models, bespoke UI code can be generated cheaply, tested quickly, and maintained without carrying upstream framework churn. From that angle, Bonsai is arriving after the strategic peak of framework leverage.

    Pressure-test whether your next UI abstraction still buys enough leverage in an LLM-assisted workflow. If custom code is now cheap for your team, framework lock-in becomes harder to justify.

      Attribution:
    • ramesh31 #1
  2. 02

    The source teaches more than the docs

    Some of the strongest praise came with a caveat. The implementation looks impressive, but the public documentation is sparse enough that people recommended reading the source or external podcast material to understand it. That is the opposite of what most teams need from a framework they plan to roll out broadly.

    Treat Bonsai as a source-first tool today, not a polished onboarding experience. If your team will not read internals, expect a slower ramp than the README suggests.

      Attribution:
    • bsmith89 #1
    • dtornabene #1
    • Schlagbohrer #1

In plain english

bonsai_term
The terminal-focused part of Bonsai that uses the same core model to build text-based interactive interfaces.
bonsai_web
The web-focused part of Bonsai that specializes its core state-machine model for browser user interfaces.
ClojureScript
A version of the Clojure language that compiles to JavaScript for browser and web application development.
Core
Jane Street’s standard OCaml library stack, widely used in its open-source packages and internal code.
DOM
Document Object Model, the browser’s programming interface for reading and changing a web page.
Eliom
A web programming framework in the Ocsigen ecosystem that supports writing both client and server logic in OCaml.
Fable
A compiler that turns F# code into JavaScript so it can be used for frontend development.
interop
Short for interoperability, meaning the ability of different languages, libraries, or systems to work together.
js_of_ocaml
A compiler toolchain that turns OCaml bytecode into JavaScript so OCaml programs can run in the browser.
Kotlin/JS
A Kotlin target that compiles Kotlin code to JavaScript for web development.
LiveView
A Phoenix framework feature that keeps most UI logic on the server and updates the browser over a live connection.
Melange
An OCaml-to-JavaScript compiler designed to integrate more smoothly with the JavaScript ecosystem.
OCaml
A statically typed functional programming language from the ML family, often used for compilers, finance systems, and other correctness-sensitive software.
Ocsigen
An OCaml web framework ecosystem for building web applications, including client and server code in OCaml.
Scala.js
A compiler that lets Scala code run in the browser by compiling it to JavaScript.
WebAssembly
A low-level binary format that lets code written in several languages run in the browser at near-native speed.
WebSharper
A framework for building web apps in F# or C# that compiles client-side code to JavaScript.

Reference links

Jane Street and Bonsai background

Alternative same-language web stacks

Terminal and related implementations

Related discussions and external context