Bonsai: A Deep Dive into Jane Street's Open-Source Functional UI Library for OCaml

Why a Quantitative Trading Firm Built Its Own UI Framework

In a world where frontend frameworks are dominated by mainstream solutions like React, Vue, and Svelte, a UI library from Wall Street quantitative trading giant Jane Street has quietly entered the developer spotlight — Bonsai. The name draws from the Japanese art of bonsai, symbolizing the construction of elegantly structured, controllably growing component trees through careful pruning.

Jane Street is one of the world's top quantitative trading firms, long renowned for its deep commitment to the functional programming language OCaml. Founded in 2000 and headquartered in New York, the company trades tens of billions of dollars daily, with operations spanning ETF market-making, equities, bonds, options, and other financial products. Unlike most quantitative firms that choose Python, C++, or Java, Jane Street bet on OCaml as its core development language early on and built a complete toolchain and infrastructure around it. The company maintains millions of lines of OCaml code internally — from trading strategies to risk management systems to internal tools — nearly everything runs on this language stack. Bonsai is a product of this company's effort to build complex web interfaces within the OCaml ecosystem, and an extension of its technical philosophy into the frontend domain.

What Exactly Is Bonsai

Bonsai is a functional UI library based on OCaml, designed for building highly interactive web applications. It's not trying to compete with React for market share — rather, it serves Jane Street's internal need for massive, real-time data-intensive trading and analytics interfaces.

Core Design Principles

Bonsai's core abstraction can be summarized in three key concepts:

• Components as functions: A Bonsai component is essentially a pure function mapping from input to view, emphasizing composability and testability. In functional programming, a pure function means the same input always produces the same output with no side effects. This property allows each component to be reasoned about and verified independently, without producing unpredictable behavior due to unexpected changes in external state.

• Incremental Computation: This is Bonsai's most distinctive feature. Built on top of Jane Street's other open-source library Incremental, it only recomputes the portions of state that have actually changed, maintaining high performance in scenarios with frequent data updates. The core idea behind incremental computation originates from academic research on Self-Adjusting Computation, first systematized by Umut Acar and others at Carnegie Mellon University in the early 2000s. The fundamental principle is to build a Dependency Graph of computations — when input data changes, the system only re-executes affected computation nodes along dependency edges, rather than recomputing the entire result from scratch. This shares similarities with reactive programming common in frontend (such as Vue's reactivity system or MobX), but incremental computation is theoretically more general and rigorous — it not only tracks data dependencies but can also handle complex computation topologies, including dynamically created and destroyed dependency relationships. Jane Street's Incremental library implements an efficient change propagation algorithm that can complete updates in O(amount of change) rather than O(total data size) time complexity.

• Explicit state management: Unlike implicit state mutations in imperative frameworks, Bonsai requires developers to describe state transitions in a declarative, type-safe manner. This means every state change must go through explicitly defined transition functions, and the shape of state along with possible mutation paths are fully constrained at the type level. This approach eliminates many common state management bugs, such as accidental state modification or inconsistencies caused by race conditions.

For interfaces like stock quotes, order books, and real-time risk dashboards that may update thousands of times per second, the value of incremental computation is particularly pronounced — it avoids triggering a full component tree re-render with every data change. A typical quantitative trading interface might simultaneously display real-time quotes for hundreds of financial instruments, each updating dozens of times per second, while also showing derived metrics calculated from those quotes (such as volatility, Greeks, P&L, etc.). In such scenarios, any unnecessary recomputation leads to UI jank, while incremental computation ensures only display areas truly affected by data changes get updated.

Why OCaml Instead of TypeScript

Many people's first reaction is: why not use TypeScript? The answer is rooted in Jane Street's technical DNA.

OCaml (Objective Caml) is a member of the ML language family, born at France's National Institute for Research in Computer Science and Automation (INRIA), with nearly 30 years of history. It combines functional, imperative, and object-oriented programming paradigms, but its core strengths lie in functional features: Algebraic Data Types, Pattern Matching, Type Inference, and Parametric Polymorphism. Unlike Haskell's pure functional approach, OCaml allows mutable state and side effects when needed — this pragmatic design makes it more suitable for industrial-grade applications. OCaml's compiler is known for fast compilation speeds and generating efficient native code, and its type checker can catch null value errors, type mismatches, and unhandled pattern branches at compile time.

OCaml possesses an extremely powerful static type system and excellent compile-time checking capabilities, catching a large number of potential errors during compilation. For financial trading systems — scenarios where the cost of failure is extremely high — the reliability provided by type safety is far more important than ecosystem convenience. A bug in a trading interface — such as incorrectly displaying an order status or price — could lead a trader to make wrong decisions, resulting in losses of millions of dollars. By comparison, while TypeScript's type system continues to evolve, it is fundamentally a superset of JavaScript with numerous type escape hatches (such as the any type and type assertions), and its runtime behavior is entirely determined by JavaScript's dynamic semantics. OCaml's type system is core to the language — there is no legitimate way to bypass type checking.

Bonsai compiles OCaml code to JavaScript via js_of_ocaml to run in the browser, allowing the team to use a unified language and type system across frontend and backend. js_of_ocaml is a compiler that translates OCaml bytecode to JavaScript, developed by INRIA's Ocsigen team. Unlike ReScript (formerly BuckleScript), which compiles OCaml syntax directly to readable JavaScript, js_of_ocaml generates more machine-readable JavaScript code. However, its advantage lies in complete support for OCaml language features — including the module system, Functors, exception handling, and garbage collection — all running seamlessly in the browser environment. The generated code size is typically acceptable after optimization, and runtime performance is comparable to handwritten JavaScript. Data model definitions can be shared between server and client, reducing risks from cross-language serialization and type inconsistencies.

Bonsai's Technical Features and Engineering Value

Maintainability Through a Strong Type System

In large team collaboration, the type system serves as "living documentation." Bonsai component input/output contracts are strictly constrained at compile time, allowing quick identification of affected code during refactoring — this is crucial for complex systems that evolve over the long term. Jane Street's internal frontend applications have accumulated hundreds of thousands of lines of code across hundreds of modules and components. At this scale, any interface change can impact a large amount of downstream code. OCaml's type system ensures the compiler automatically finds every location that needs modification, rather than relying on developer memory or incomplete documentation. This is one reason why Jane Street can maintain a monorepo and frequently perform large-scale refactoring.

Composable Component Architecture

Bonsai emphasizes composing small components — developers can assemble simple components into complex interfaces like building blocks. Since each component is purely functional, behavior is predictable and easy to unit test, aligning with Jane Street's consistent emphasis on engineering rigor. In Bonsai, composition happens not only at the view level but also at the state and logic levels. Developers can combine two independent stateful components into a larger component while maintaining state isolation for each. This composition approach is more structured than React's hooks — in React, hook composition relies on calling-order conventions, whereas Bonsai's composition is type-safe, with the compiler ensuring the correctness of how things are combined.

Performance Optimization for High-Frequency Data Scenarios

The incremental computation model gives Bonsai excellent performance in data-intensive applications. Traditional virtual DOM diffing requires traversing and comparing the entire tree, while Bonsai directly tracks the dependency graph and only updates nodes that have actually changed.

To understand the significance of this distinction, it's worth reviewing how the virtual DOM works: Frameworks like React re-execute a component's render function on every state change, generating a new virtual DOM tree, then recursively compare (diff) the new tree against the old one, and finally apply minimized changes to the real DOM. The time complexity of this process is proportional to the component tree's size. While React provides optimization mechanisms through memo, useMemo, shouldComponentUpdate, etc., these are essentially developer-provided hints manually marking "which parts don't need recomputation" — adding cognitive overhead and prone to omissions.

Bonsai's incremental computation model fundamentally inverts this logic: the system automatically knows which inputs each computation node depends on, and when an input changes, only nodes depending on that input are recomputed. This means in a table displaying prices for 1,000 stocks, when one stock's price updates, the system only recomputes the row related to that stock without needing to traverse or compare the other 999 rows. The performance advantage of this approach in high-frequency data update scenarios is very significant.

An Objective View: Niche but Highly Inspirational

It's important to clearly recognize that Bonsai is a highly niche tool. It has a steep learning curve, requiring developers to master OCaml and functional programming paradigms, and its ecosystem and community size can't remotely compare to mainstream frameworks. OCaml itself may only have tens of thousands of active developers globally, far fewer than the JavaScript community's millions. This means teams using Bonsai will face greater challenges in hiring, third-party library support, and community Q&A.

However, its value lies precisely in demonstrating a different possibility: when a company is willing to invest in ultimate reliability and performance, it's entirely possible to build a frontend solution based on functional programming that's radically different from the mainstream. In fact, Bonsai isn't the only project attempting to bring functional programming to the frontend. The Elm language, with its pure functional design and promise of "no runtime exceptions," has influenced the entire frontend community (Redux was directly inspired by the Elm Architecture); PureScript's Halogen framework pursues similar goals in type-safe UI construction; the Haskell community's Reflex-FRP explores functional reactive programming for frontend applications. What makes Bonsai unique in this lineage is that it's not an academic experiment or personal project — it's a solution validated in real production environments by a top commercial company.

For developers researching frontend architecture, functional UI design, or incremental computation, Bonsai is a reference sample well worth deep study.

Conclusion

Bonsai isn't a tool for everyone, but it's a window into understanding "how else could frontend frameworks be designed." It embodies Jane Street's engineering culture of taking functional programming to its logical conclusion, and reminds us that beyond the ecosystem dominated by commercialized frameworks, there's still a group of engineers solving real-world complex problems with fundamentally different approaches.

For developers willing to step outside their comfort zone, exploring Bonsai's source code and design philosophy may bring entirely new insights about type safety, incremental computation, and component composition. Even if you don't plan to use OCaml or Bonsai in production, understanding the design philosophy behind it — using the compiler as the first line of defense, computation graphs as the core abstraction for performance optimization, and composability as a fundamental architectural principle — can help you make better architectural decisions with whatever framework you use.