A framing from that podcast that helped me better understand the role of Bonsai is that it's really a framework for building incremental distributed state machines.
This framing is also in the post. From the readme:
> Bonsai itself -- this library -- is actually more generic than the above makes it sound. It allows you to build general-purpose incremental, composable state machines. Bonsai_web builds on top of that core library, specializing it for interactive browser-based UIs, but we also have Bonsai_term for building interactive terminal-based UIs.
The value proposition about this web framework over things like React, Phoenix, etc is that it uses incremental computing right ? Using Jane Street's incremental computing library. I see it being used at https://github.com/janestreet/bonsai/blob/f31661450eb133fe89...
A really great place to reach for this is Elixir/Phoenix now that the set theoretic type system is in place with LiveView. I have been doing some pretty large/complex codebases gradually working towards fully integrating working this way for the past 5 years and it has been great.
Yeah… I’ve been a professional Elixir developer for 5+ years and additional 4 as a hobby. The quality of the ecosystem and the practices are nowhere near those in OCaml. Sad to say it. People just want to write imperative procedural code and monkey patch in tests so they can test anything at all.
The general challenge becomes integrating the fractional front-end code written in your backend-language that compiles to JS with the rest of the JS ecosystem.
JaneStreet have a love of writing their own stuff from scratch so it doesn't apply to them but it might to you.
Hence most people end up with frontend-as-backend rather than backend-as-frontend.
Doesn't apply as much to Clojurescript due to it being dynamically typed and its flexibility. Sure, you often write a wrapper, but it's more of an abstraction and a good practice, not a necessity in cljs.
Clojurescript not ClojureJs, and Typescript doesn't run in the browser, it has the exact same issues/limitations: it must be compiled to JavaScript first.
absolutely nobody used those outside of a language demo. We also got --erasableSyntaxOnly last year to remove them from the language. The TS team considers them “mistakes“ for a really long time now
Thanks for the correction! It was a long time ago that I used TypeScript, and making things worse (for my memory) it was an Angular project.
So today, most people and teams avoid the parts of TS that require compilation into different JS, and --erasableSyntaxOnly lets you enforce this, right?
Isn't that like saying the Internet is only written in English if you strip out all the non-English. All C-style languages are fully cross compatible if you only use semicolons.
I can't write Typescript into a browser without cross-compilation and "stripping out types" involves parsing and manipulating code. That's a different language.
No. 98% of typescript specific syntax can be replaced with U+0020 SPACE to yield runnable JavaScript. The runtime semantics of the two languages are congruent. the same cannot be said for any other language im aware of.
I'm sorry but if you need a transpiler to get it to run in a browser, character replacability and runtime semantics don't matter. Typescript doesn't run in the browser, it's obviously a different language.
WASM does not (yet) have access to the DOM or web APIs, meaning every direct interaction with the browser must first go through JS interop anyways, with a resulting performance penalty. There are proposals, and maybe we'll see it happen by 2035, but as of now WASM is best suited for heavier workloads where the edge in application performance outweighs the cost of JS interop with the browser rather than being a universal solution.
> Is there some limitation that WASM has that JS doesn't?
You need a JS trampoline to call your WASM and make browser primitives available to it, and IIRC calls into browser code incur some extra overhead, but those are pretty manageable.
Additionally: for high level languages, source code is _much_ smaller than compiled binaries. If your initial needs are simple, your users are likely downloading more than 10x as much code.
I don't think someone mentioned yet, but the (now defunct?) company Outrun Labs built a product Revery which seems almost exactly like what Jane Street has done (to my amateur eyes). OniVim was their only end user product afaik, built on this tech.
FWIW if you listen to Signals and Threads (the Jane Street podcast) they talk about this.
They have dedicated UX designers who do relatively little code but focus entirely on making the UX as optimal for the traders as possible and one of them was on an episode.
They talked about how most of the normal UX rules for SW go out the window because quants and traders have such different needs than "normal software".
This matters. Beyond performance (a universal good), the definition of "good" UX is strictly dependent on the user. Fintech platforms for traders who open a multi-window thick client application(s) and spend hours in it every day have little in common with consumer mobile apps designed to hold your attention for maybe a minute. It's mind-bogglingly lazy to choose something like MUI (Material UI) as if it were some kind of reasonable foundation irrespective of context.
Is there any professional software that wouldn't benefit from high information density? Most software design is optimized for the non-users who have to approve it.
You can have high information density and still not have words running into each-other. Taking all of the space out from around text and information graphics makes them less legible, even for experienced "power users".
I think the goal here is more an aesthetic of being for "serious traders only" rather than a UI optimized for speed and clarity. The UI designers probably have little choice but to match the preferences of the user group though, even when those preferences are empirically detrimental.
Yeah safety critical software needs to avoid high UI density for the interface itself. For diagnostics and monitoring or general stats you can still do high density but the actual "action space" needs to be kept as low density as possible and preferably with physical separation in the UI (i.e. via physical buttons and displays instead of just a big touch screen or monitor+Mouse and kbd).
Higher information density is ideal but when people are working in less than ideal conditions (stress, lack of sleep, alarms going off, etc) you need to prioritise information clarity and clarity of actions over raw density.
It has to be the right information, filtered and presented in such a way that supports the task. Any kind of human in the loop UI has to manage user cognitive loading. Task saturation is real.
"non-users" are also big targets for software. If you run a software business, chances are you want people who've never used your software to start using your software. In that case, discoverability trumps high information density.
It only adds discoverability for the things that fit the screen. In other words, you have to make it simple. I.e. the lazy way to make something "user-friendly", do as little as possible and force the user to adapt to your ways instead.
this - most of the internal software at my job that's actually important is very dense, with keyboard navigation and shortcuts. The ones that somebody makes to sell themselves to upper management while angling for a promotion look very pretty, and never get used.
And yet, we make such beautiful and vacant software ourselves for our clients, because again, its b2b, so you aren't selling to the people who actually have to use the software. Im glad at least we arent forced that often to use specific internal tools, the better ones just get adopted organically
This makes me think about the bizarre UI regressions in macOS in the last few years. I’ve got this giant, beautiful display and somehow it becomes less rather than more useful over time due to the software it’s presenting.
I'm on the verge of swapping my macbook for a framework laptop. I never really bought into the whole apple ecosystem (I've got a pixel phone), and I find myself using the mac as a less flexible unix box. I'm mostly in the terminal, vscode, or firefox, and using rectangle and homebrew to make it more linux-y to interact with. I'd swapped to the mac because it was a more reliable hardware setup than any linux laptops at the time, but I'm starting to look for other options.
i think wayland set linux desktop back 10 years. it’s finally coming up to parity with X11. but basic stuff like “get the latest release of of consumer GUI app $foo” is still weirdly mired in odd political plays between flat pack people, distros, and the actual devs. at least audio finally seems to be solved with pipe wire!
Yeah, that was the main attraction of a mac for me. It Just Works, but enough stuff is packaged for it that it can drive like a linux box for a lot of coding tasks. I'm not going back to windows anytime soon, either.
I remember getting in to all kinds of driver rabbit holes every other time I tried to run desktop linux, but a bunch of people I was talking to on here a few weeks ago were saying that's all fixed now.
A lot is said in this thread about user preferences for info density, but it is really a lot more than preference. there's also a big component of it that is user productivity focused. Info-dense UIs simply require a lot less scrolling around and pagination to look at relevant data. For example the ability to look at multiple charts side by side instead of having to scroll one chart after another into position enables users to spot differences that they wouldn't otherwise see.
Curious how this compares to Melange which is used by Ocaml shops as well to double up on Ocaml for both front and backend (ahrefs being the major user and sponsor). Does this mean giving up a lot of the JS ecosystem (React, graphql, etc)?
A good GraphQL server and client should be relatively straightforward to make in OCaml. Especially if you start from the premise that fragment spreads compose, rather than inherit.
Relay’s (second) compiler was prototyped in OCaml, but we ended up switching to Rust for the main rewrite in the belief that we’d be able to use the same runtime code across iOS, Android and JS environments.
Please somebody make a good OCaml GraphQL compiler, server, and client.
My understanding is that js_of_ocaml has been around longer and likely has a stronger ecosystem, but Melange was designed more specifically to play nice with the JS ecosystem.
Jane Street made it's way into today's Wall St Journal for its quantitative prowess and hiring of Math PhD's. What was stunning to hear was that their 2nd quarter profits were a record $10.3 billion, nearly double that of Goldman Sachs and Morgan Stanley (much larger firms).
They made money through extreme manipulation of the Indian stock market...when working with a market that has 422X leverage through derivatives its much easier to make money.
They're a trading firm that hires really clever people to use math to trade. Their strategies are, presumably, very complicated and ever changing, and secrecy about them is the point - you get bigger margins for longer if people don't learn about your 'one weird trick' (that and also that there is presumably another side to your trades losing out on upside, and they might not be best pleased to learn about it.
This doesn't seem quite as clear-cut as you're making out.
The Securities and Exchange Board of India (SEBI) have accused Jane Street (JS) of market manipulation, JS claims it was legitimate arbitrage, and the case is still ongoing [1].
As I understand it, the ban only applied to Indian securities (not Asian markets as a whole), and was lifted back in July 2025 after JS paid ~$560 million (the alleged ill-gotten gains) into an escrow fund. They don't appear to have resumed trading, though [2].
The above might be too far-fetched as it only applied to India? They did pay a fine to the regulator and resumed trading (might not be the same strategy though)
To OP’s original question, they made $20B last year and have a niche in several financial products
This is great. It focuses on utility and information density over design. It looks like someone took a terminal UI and transplanted it to the web, Bloomberg terminal style.
I'm pretty sure you can build tools with this that are fast and pleasant to use.
The docs directory happen to be missing, therefore the links to the quick guide and to "thinking in bonsai" pages from the readme are broken.
Also, I'm wondering how does bonsai-web update the DOM, is it via direct modification of the changed elements, or via some DOM differ? I'd say from direct update from a quick look at the source, but I'm unsure.
Jsoo supports self-recursive and mutually recursive tail calls, but for general tail calls it would need to trampoline every single call, since the only major browser with proper tail calls is Safari.
A more practical question: has anyone used this in production in internal apps at work? UIs like this look nice and have a flare that I like, but I guess it feels weird if I want to introduce this with my team over something like tailwindcss and rolling our own components
There's a full terminal implementation of Bonsai as well. I actually use it in my personal workflow these days to manage my contacts database! https://anil.recoil.org/notes/aoah-2025-9
Custom infrastructure; I use my site as a playground for various things over the years. It ran as the first MirageOS unikernel for many years, and recently it's been running on a zero-allocation OxCaml webserver https://anil.recoil.org/notes/oxcaml-httpz to help me get to grips with the new extensions.
It looks like a nice little library; but oh boy must this be so limiting for the product teams that are forced to use. Everything looks like it's straight out of the 1990s.
Can someone who understands web UI programming tell me if this would be good for my local agent to use to produce HTML based reports and outputs for me? Or for TUI outputs?
There was this submission two months ago: https://news.ycombinator.com/item?id=48365904 . Basically they have a TUI frontend for the same thing. And the blog post says: "Bonsai_term would feel familiar to anyone who’d ever done web development here, and it had the huge advantage of being especially amenable to AI assistance. It was actually somewhat of a mystery to us how good the models were at writing Bonsai_term code, given how relatively obscure it is [...]"
The main thing that Bonsai gets you is a nice programming model for making your UIs interactive. If you're mostly producing static reports (with maybe some basic interactive visualization widgets or something), it will not get you much over generating some variant on HTML + JS.
It makes more sense for applications where you have complex interactive logic in the UI, with a lot of different components that need to control and display some shared state.
i maintain a codebase that uses Bonzai (https://github.com/hazelgrove/hazel/); agent based development works just fine, though probably a bit more token churn
At Jane Street we're super excited by Functional programming and by CAML in particular, so when we need low latency software, we use OCAML, when we need hardware, we write out own langauge - HardCAML, and when we need a Web UI, we build a Web UI framework in CAML. Because we fucking love CAML.
But AI do benefit a lot from a strict compiler, and having a simple language improve a lot on type-safety, so I don't think it is to throw, even today.
JaneStreet has enough free cash to not worry about those issues. If one of their key persons dies in service, they can go out and contract the worlds leading expert in that domain, and their annualised rate isn’t even a rounding error on their bottom line.
Pretty much. UI libraries are more or less meaningless now, and I say this as someone who spent the last decade building them. Given a proper data API to work against, you're a single prompt away from a fully tested bespoke lib that's more maintainable and has no dependencies. The weeks of work you saved by reaching for one before is gone, and the tradeoff you had to make of dealing with upstream changes and lack of customization just isn't there anymore.
If you read up on it that was basically India protecting its corrupt cronies. Janestreet showed severe problems with some Indian companies and instead of fixing that and creating a healthier and more transparent market they decided to go after the messenger.
Looks like OPs post was flagged. I have also seen this on multiple ocations. To me this is REALLY fishy. Since the janestreet fraud there has been a massive campaign online to downplay all negative comments, disable comments on JS videos, and overall radio silence.
I know some long term ocaml users and i can tell you that there is stuff boiling under the hood. Many are very much NOT HAPPY with JS and what they did.
It's also a way to retain employees. If you are an expert ocaml writer, you aren't a drop in replacement at the competition. So while I'd love to work there, a lot of the knowledge isn't very marketable after you move on.
It might be a very performant UI framework in OCaml, but all the UI elements look extremely unpolished to me, like what a really smart high-school kid would build the GUI for his side project on Windows in 90s.
Thanks, I can use JS as a functional programming language.
Windows and especially Macintosh UIs from the late 90s/early 00s were by far the most functional UIs we've ever had since the dawn of the desktop era - user research was a serious discipline, accessibility was baked in to the frameworks, and the HID guidelines that devs adhered to gave us uniform conventions that we users could rely on.
If the biggest criticism of Bonsai is "it ain't pretty but it works", then long life to Bonsai - give me more, please!
There's a great Signals and Threads (Jane Street's Podcast) episode about this work: https://signalsandthreads.com/building-a-ui-framework/
A framing from that podcast that helped me better understand the role of Bonsai is that it's really a framework for building incremental distributed state machines.
The entirety of modern financial markets is simply incremental distributed state machines.
This framing is also in the post. From the readme:
> Bonsai itself -- this library -- is actually more generic than the above makes it sound. It allows you to build general-purpose incremental, composable state machines. Bonsai_web builds on top of that core library, specializing it for interactive browser-based UIs, but we also have Bonsai_term for building interactive terminal-based UIs.
The docs are a bit sparing but if you read the source its pretty cool to see how they did this.
The value proposition about this web framework over things like React, Phoenix, etc is that it uses incremental computing right ? Using Jane Street's incremental computing library. I see it being used at https://github.com/janestreet/bonsai/blob/f31661450eb133fe89...
is it this? https://github.com/janestreet/incremental
> And because Bonsai is written in OCaml, it becomes possible to use the same language and types on both the backend and frontend.
Finally! I was waiting for this to become possible!
There's also Fable for F# but I believe this commenter is being sarcastic. Javascript is a common backend language.
I’m that ridiculous person who would rather learn OCaml from scratch if it meant I never had to use JS
Kidding of course. Mostly.
I'd rather learn MUMPS or COBOL than use JS... not kidding.
[dead]
Before JS became a common backend language, you could do this with at least one stack: Clojure & ClojureScript.
Why wait? It’s been possible since forever. I wrote UI in OCaml eight years ago. https://github.com/kccqzy/drawing-guessing/blob/master/clien...
You are the pioneer and must be worshipped.
A really great place to reach for this is Elixir/Phoenix now that the set theoretic type system is in place with LiveView. I have been doing some pretty large/complex codebases gradually working towards fully integrating working this way for the past 5 years and it has been great.
Yeah… I’ve been a professional Elixir developer for 5+ years and additional 4 as a hobby. The quality of the ecosystem and the practices are nowhere near those in OCaml. Sad to say it. People just want to write imperative procedural code and monkey patch in tests so they can test anything at all.
Similar attempts include Scalajs.
The general challenge becomes integrating the fractional front-end code written in your backend-language that compiles to JS with the rest of the JS ecosystem.
JaneStreet have a love of writing their own stuff from scratch so it doesn't apply to them but it might to you.
Hence most people end up with frontend-as-backend rather than backend-as-frontend.
Goes way back to 2006 with GWT.
https://en.wikipedia.org/wiki/Google_Web_Toolkit
KotlinJs and ClojureJs too. You always end up having to write wrappers or dealing with problems that would just work if you just used normal js/ts.
Doesn't apply as much to Clojurescript due to it being dynamically typed and its flexibility. Sure, you often write a wrapper, but it's more of an abstraction and a good practice, not a necessity in cljs.
"due to it being dynamically typed"
hmm ok nope
Clojurescript not ClojureJs, and Typescript doesn't run in the browser, it has the exact same issues/limitations: it must be compiled to JavaScript first.
Compiling TypeScript is just stripping out types
That is true only if you confine your TS code to be pure JS plus type annotations.
There are TS constructs that require compilation into equivalent JS, such as enums and namespaces.
Are there any other?
Namespaces are heavily discouraged. Some teams still use enigma but most people in the know us unions of strings.
I know the TS team regrets enums and I have not seen any plans for adding additional keywords that break type stripping.
The other one I read about was parameter properties in constructors.
And thank you for the correction! It was quite a few years ago that I used TypeScript, and I think the landscape was different then.
Making things even fuzzier in my mind, this was an Angular project, and it was hard to keep track of what was Angular and what was TypeScript.
It sounds like people these days actively avoid the parts of TypeScript that require translation into different JS code.
"fortunately" we can load swc compiled to wasm to deal with that.
absolutely nobody used those outside of a language demo. We also got --erasableSyntaxOnly last year to remove them from the language. The TS team considers them “mistakes“ for a really long time now
Thanks for the correction! It was a long time ago that I used TypeScript, and making things worse (for my memory) it was an Angular project.
So today, most people and teams avoid the parts of TS that require compilation into different JS, and --erasableSyntaxOnly lets you enforce this, right?
Exactly. There is plenty of code change however introduced by bundlers who do “bundling“, polyfill injection, minification, this kind of stuff.
Isn't that like saying the Internet is only written in English if you strip out all the non-English. All C-style languages are fully cross compatible if you only use semicolons.
I can't write Typescript into a browser without cross-compilation and "stripping out types" involves parsing and manipulating code. That's a different language.
No. 98% of typescript specific syntax can be replaced with U+0020 SPACE to yield runnable JavaScript. The runtime semantics of the two languages are congruent. the same cannot be said for any other language im aware of.
I'm sorry but if you need a transpiler to get it to run in a browser, character replacability and runtime semantics don't matter. Typescript doesn't run in the browser, it's obviously a different language.
Except TS has much wider community support. The type definitions/wrappers are already written.
Yup, and Clojure/ClojureScript!
Couldn't WASM solve that problem once and for all? Is there some limitation that WASM has that JS doesn't?
Disclaimer: I am very inexperienced at front-end development.
WASM does not (yet) have access to the DOM or web APIs, meaning every direct interaction with the browser must first go through JS interop anyways, with a resulting performance penalty. There are proposals, and maybe we'll see it happen by 2035, but as of now WASM is best suited for heavier workloads where the edge in application performance outweighs the cost of JS interop with the browser rather than being a universal solution.
> Is there some limitation that WASM has that JS doesn't?
You need a JS trampoline to call your WASM and make browser primitives available to it, and IIRC calls into browser code incur some extra overhead, but those are pretty manageable.
Additionally: for high level languages, source code is _much_ smaller than compiled binaries. If your initial needs are simple, your users are likely downloading more than 10x as much code.
Such attempts are quite common. Some I remember:
https://ocsigen.org/ in Ocaml too
https://websharper.com/ for fsharp and csharp. Really good when I used in in fsharp
Maybe https://melange.re/v7.0.1/ too? (Not sure)
I took this as a joke in reference to the popularity of JavaScript on the backend for the last two decades.
that's because most people's intro to CS was how to build a webpage.
Modern web development is more like computer alchemy
I don't think someone mentioned yet, but the (now defunct?) company Outrun Labs built a product Revery which seems almost exactly like what Jane Street has done (to my amateur eyes). OniVim was their only end user product afaik, built on this tech.
> Finally! I was waiting for this to become possible!
Sarcasm?
Do you want to have a talk as to why JaneStreet wasn't built on JavaScript?
Sarcasm, definitely
I am sure it's very performant, but to me it's extremely ugly; Surely someone can fix margins and still have it be performant.
I’m no UI expert - what’s wrong with the margins?
inconsistent and maybe too tight, but I would think those are issues with the sample UIs and not this library
FWIW if you listen to Signals and Threads (the Jane Street podcast) they talk about this.
They have dedicated UX designers who do relatively little code but focus entirely on making the UX as optimal for the traders as possible and one of them was on an episode.
They talked about how most of the normal UX rules for SW go out the window because quants and traders have such different needs than "normal software".
This matters. Beyond performance (a universal good), the definition of "good" UX is strictly dependent on the user. Fintech platforms for traders who open a multi-window thick client application(s) and spend hours in it every day have little in common with consumer mobile apps designed to hold your attention for maybe a minute. It's mind-bogglingly lazy to choose something like MUI (Material UI) as if it were some kind of reasonable foundation irrespective of context.
Is there any professional software that wouldn't benefit from high information density? Most software design is optimized for the non-users who have to approve it.
You can have high information density and still not have words running into each-other. Taking all of the space out from around text and information graphics makes them less legible, even for experienced "power users".
I think the goal here is more an aesthetic of being for "serious traders only" rather than a UI optimized for speed and clarity. The UI designers probably have little choice but to match the preferences of the user group though, even when those preferences are empirically detrimental.
Yeah safety critical software needs to avoid high UI density for the interface itself. For diagnostics and monitoring or general stats you can still do high density but the actual "action space" needs to be kept as low density as possible and preferably with physical separation in the UI (i.e. via physical buttons and displays instead of just a big touch screen or monitor+Mouse and kbd).
Higher information density is ideal but when people are working in less than ideal conditions (stress, lack of sleep, alarms going off, etc) you need to prioritise information clarity and clarity of actions over raw density.
It has to be the right information, filtered and presented in such a way that supports the task. Any kind of human in the loop UI has to manage user cognitive loading. Task saturation is real.
"non-users" are also big targets for software. If you run a software business, chances are you want people who've never used your software to start using your software. In that case, discoverability trumps high information density.
It only adds discoverability for the things that fit the screen. In other words, you have to make it simple. I.e. the lazy way to make something "user-friendly", do as little as possible and force the user to adapt to your ways instead.
this - most of the internal software at my job that's actually important is very dense, with keyboard navigation and shortcuts. The ones that somebody makes to sell themselves to upper management while angling for a promotion look very pretty, and never get used.
And yet, we make such beautiful and vacant software ourselves for our clients, because again, its b2b, so you aren't selling to the people who actually have to use the software. Im glad at least we arent forced that often to use specific internal tools, the better ones just get adopted organically
Fair point
I guess JS doesn't have to care about this at all because they're not selling their UI to others, just making it in house for in house use
JavaScript?
No, OCaml
Think node, except the other direction. They write their backend in OCaml, and then they also write their web ui in OCaml with a translation layer
Or think of gwt (java) awhile back
JaneStreet, see post title.
I'd kill for tight UIs now. Everything insists on having 15000-mile wide margins, and at most two items visible on an 8K screen.
We are at a point when TUIs from 1990s running in 12" screens with at best a 480x240 resolution display more info than almost anything we have now.
This makes me think about the bizarre UI regressions in macOS in the last few years. I’ve got this giant, beautiful display and somehow it becomes less rather than more useful over time due to the software it’s presenting.
I'm on the verge of swapping my macbook for a framework laptop. I never really bought into the whole apple ecosystem (I've got a pixel phone), and I find myself using the mac as a less flexible unix box. I'm mostly in the terminal, vscode, or firefox, and using rectangle and homebrew to make it more linux-y to interact with. I'd swapped to the mac because it was a more reliable hardware setup than any linux laptops at the time, but I'm starting to look for other options.
i think wayland set linux desktop back 10 years. it’s finally coming up to parity with X11. but basic stuff like “get the latest release of of consumer GUI app $foo” is still weirdly mired in odd political plays between flat pack people, distros, and the actual devs. at least audio finally seems to be solved with pipe wire!
Yeah, that was the main attraction of a mac for me. It Just Works, but enough stuff is packaged for it that it can drive like a linux box for a lot of coding tasks. I'm not going back to windows anytime soon, either.
I remember getting in to all kinds of driver rabbit holes every other time I tried to run desktop linux, but a bunch of people I was talking to on here a few weeks ago were saying that's all fixed now.
2026 is the Year of Linux on the Desktop.
I feel like everything has become a wasteland of whitespace. JIRA is a prime offender here.
From experience I can say that traders prefer extraordinarily little whitespace in their UIs.
A lot is said in this thread about user preferences for info density, but it is really a lot more than preference. there's also a big component of it that is user productivity focused. Info-dense UIs simply require a lot less scrolling around and pagination to look at relevant data. For example the ability to look at multiple charts side by side instead of having to scroll one chart after another into position enables users to spot differences that they wouldn't otherwise see.
Margins on an info dashboard are wasted space.
Probably because they skew towards higher information density
Curious how this compares to Melange which is used by Ocaml shops as well to double up on Ocaml for both front and backend (ahrefs being the major user and sponsor). Does this mean giving up a lot of the JS ecosystem (React, graphql, etc)?
A good GraphQL server and client should be relatively straightforward to make in OCaml. Especially if you start from the premise that fragment spreads compose, rather than inherit.
Relay’s (second) compiler was prototyped in OCaml, but we ended up switching to Rust for the main rewrite in the belief that we’d be able to use the same runtime code across iOS, Android and JS environments.
Please somebody make a good OCaml GraphQL compiler, server, and client.
I've been using Resgraph, but it's based off Rescript, a fork of ocaml.
My understanding is that js_of_ocaml has been around longer and likely has a stronger ecosystem, but Melange was designed more specifically to play nice with the JS ecosystem.
What does JaneStreet do besides sponsoring nerdy Youtube channels and writing UI libraries?
Jane Street made it's way into today's Wall St Journal for its quantitative prowess and hiring of Math PhD's. What was stunning to hear was that their 2nd quarter profits were a record $10.3 billion, nearly double that of Goldman Sachs and Morgan Stanley (much larger firms).
They made money through extreme manipulation of the Indian stock market...when working with a market that has 422X leverage through derivatives its much easier to make money.
https://www.youtube.com/watch?v=VhqosmgfGR0
Market-making in a market that is highly speculative and illiquid isn’t the same as market manipulation though.
They're a trading firm that hires really clever people to use math to trade. Their strategies are, presumably, very complicated and ever changing, and secrecy about them is the point - you get bigger margins for longer if people don't learn about your 'one weird trick' (that and also that there is presumably another side to your trades losing out on upside, and they might not be best pleased to learn about it.
One trick is buy low sell high, apparently only a few know about this.
> really clever people
Sam Bankman-Fried and his League of Legend rankings would like a word
They’re a market maker
manipulate foreign equity markets
Print money?
Governments print money, high frequency traders extract money. They would say that they provide liquidity to the market as a service.
hn: come for the tech news, stay for the pedantry
[flagged]
This doesn't seem quite as clear-cut as you're making out.
The Securities and Exchange Board of India (SEBI) have accused Jane Street (JS) of market manipulation, JS claims it was legitimate arbitrage, and the case is still ongoing [1].
As I understand it, the ban only applied to Indian securities (not Asian markets as a whole), and was lifted back in July 2025 after JS paid ~$560 million (the alleged ill-gotten gains) into an escrow fund. They don't appear to have resumed trading, though [2].
[1]: https://www.reuters.com/legal/government/us-trading-firm-jan...
[2]: https://www.reuters.com/sustainability/boards-policy-regulat...
The above might be too far-fetched as it only applied to India? They did pay a fine to the regulator and resumed trading (might not be the same strategy though)
To OP’s original question, they made $20B last year and have a niche in several financial products
Yes, the fraud was done in india. Why does that matter?
“Banned from the Asian markets” was the original claim. The actual fact is: banned from Indian markets, with the ban now lifted.
Sure, so "its all ok now" seems to be the goto here. Who knows other shady stuff they had done / are doing.
A big wart on them, and the entire ocaml ecosystem.
Trading the underlying to offset your derivative position isn't fraud.
>Janestreet PR team is downvoting. Like always, radio silence and just downvotes.
You're being downvoted for having a needlessly confrontational underinformed hot take on a quant trading firm that is essentially a market maker.
This is great. It focuses on utility and information density over design. It looks like someone took a terminal UI and transplanted it to the web, Bloomberg terminal style.
I'm pretty sure you can build tools with this that are fast and pleasant to use.
The docs directory happen to be missing, therefore the links to the quick guide and to "thinking in bonsai" pages from the readme are broken.
Also, I'm wondering how does bonsai-web update the DOM, is it via direct modification of the changed elements, or via some DOM differ? I'd say from direct update from a quick look at the source, but I'm unsure.
Oh it needs a userland trampoline!
> JSOO does not have tail call optimization
Jsoo supports self-recursive and mutually recursive tail calls, but for general tail calls it would need to trampoline every single call, since the only major browser with proper tail calls is Safari.
A more practical question: has anyone used this in production in internal apps at work? UIs like this look nice and have a flare that I like, but I guess it feels weird if I want to introduce this with my team over something like tailwindcss and rolling our own components
Yes Jane Street
i think “i added ocaml” is much bigger innovation token spend then the styling question
Yeah, Jane Street
Interesting! What are Bonsai's dependencies? I use OCaml but - so far - none of Janestreets libraries etc.
Basically most of Jane Street's published code[0] via its dependency on Core.
[0]: https://github.com/janestreet/bonsai/blob/f31661450eb133fe89...
Looks like it's Web-only, no mention of the native UI support (terminal UI excluded).
There's a full terminal implementation of Bonsai as well. I actually use it in my personal workflow these days to manage my contacts database! https://anil.recoil.org/notes/aoah-2025-9
Unrelated but what do you use to manage your personal website? I love how everything is interconnected.
Custom infrastructure; I use my site as a playground for various things over the years. It ran as the first MirageOS unikernel for many years, and recently it's been running on a zero-allocation OxCaml webserver https://anil.recoil.org/notes/oxcaml-httpz to help me get to grips with the new extensions.
You are crazy intelligent. You are cool.
Seconding the sibling comment - what are you using to run your personal site? It is very nice.
How on earth is this a web UI Library and yet there is no link to any sort of example page (like a github.io page or something) showing this off?
Cont:https://news.ycombinator.com/item?id=46156832
It looks like a nice little library; but oh boy must this be so limiting for the product teams that are forced to use. Everything looks like it's straight out of the 1990s.
Which is fine if you are building tools for financial professionals. It is the aesthetic of choice. And is generally very functional for this purpose.
What do you mean? What's the connection with the product teams? Why would product teams care what low level web framework is used?
Can someone who understands web UI programming tell me if this would be good for my local agent to use to produce HTML based reports and outputs for me? Or for TUI outputs?
There was this submission two months ago: https://news.ycombinator.com/item?id=48365904 . Basically they have a TUI frontend for the same thing. And the blog post says: "Bonsai_term would feel familiar to anyone who’d ever done web development here, and it had the huge advantage of being especially amenable to AI assistance. It was actually somewhat of a mystery to us how good the models were at writing Bonsai_term code, given how relatively obscure it is [...]"
The main thing that Bonsai gets you is a nice programming model for making your UIs interactive. If you're mostly producing static reports (with maybe some basic interactive visualization widgets or something), it will not get you much over generating some variant on HTML + JS.
It makes more sense for applications where you have complex interactive logic in the UI, with a lot of different components that need to control and display some shared state.
Probably not, because your agent won’t have much info about this tool in its training set.
i maintain a codebase that uses Bonzai (https://github.com/hazelgrove/hazel/); agent based development works just fine, though probably a bit more token churn
Not sure why, but reminds me of Fog Creek's Wasabi.
The "Why Bonsai?" I found really funny.
Let me re-write that section for you:
Why Bonsai?
At Jane Street we're super excited by Functional programming and by CAML in particular, so when we need low latency software, we use OCAML, when we need hardware, we write out own langauge - HardCAML, and when we need a Web UI, we build a Web UI framework in CAML. Because we fucking love CAML.
And there's nothing wrong with that. Many languages attempt to do the same thing. Why bother with 15 different languages if you can leverage one?
See also LiveView and Hologram for Elixir.
Agreed, looks like it's reinventing the wheels. Frameworks does not really matter today, AI agents write the code anyway.
But AI do benefit a lot from a strict compiler, and having a simple language improve a lot on type-safety, so I don't think it is to throw, even today.
But what about compilation speed? Hot reload? Maintainability? What is the bus factor for these kind of technologies?
Yea, its cool to have strict type safety, but what's the point of it doesn't have all the benefits from other Frameworks that took years to polish
JaneStreet has enough free cash to not worry about those issues. If one of their key persons dies in service, they can go out and contract the worlds leading expert in that domain, and their annualised rate isn’t even a rounding error on their bottom line.
ocaml has excellent compilation speed, and in my experience the code is very maintainable due to the module and type systems.
AI certainly writes Internet comments so that the flock does not have a single minute to get independent thoughts.
Better frameworks will still help AIs avoid silly mistakes. A smarter framework means you can be productive with a dumber/cheaper AI.
I wish there were more OCaml shops out there
The “The thinking in bonsai” link 404s.
This says it is based on Elm. So it has the same clean immutable state structure?
This would of been cool back in 2014.
Ocsigen and Eliom were started 2005 and are pretty similar, although I can't find any well-known projects using Eliom :/.
Presumably this has learned some lessons from it, so it's probably better.
>"This would of been cool back in 2014."
Pretty much. UI libraries are more or less meaningless now, and I say this as someone who spent the last decade building them. Given a proper data API to work against, you're a single prompt away from a fully tested bespoke lib that's more maintainable and has no dependencies. The weeks of work you saved by reaching for one before is gone, and the tradeoff you had to make of dealing with upstream changes and lack of customization just isn't there anymore.
Actually let me correct you. Its cool now because early 2000's is back on trend baby
Yes. I would make frontends with handlebars back in 2008-2012. It was a big improvement from PHP.
I really want to like OCaml. One day I'll get around to learning it.
I wonder why nobody hasn't created a SKILL file for Bonsai yet. I thought every library today would be introduced with a SKILL file in bundle.
[flagged]
[dead]
[flagged]
If you read up on it that was basically India protecting its corrupt cronies. Janestreet showed severe problems with some Indian companies and instead of fixing that and creating a healthier and more transparent market they decided to go after the messenger.
Why did you feel the need to post this same comment multiple times? Seems a bit suspect itself!
Looks like OPs post was flagged. I have also seen this on multiple ocations. To me this is REALLY fishy. Since the janestreet fraud there has been a massive campaign online to downplay all negative comments, disable comments on JS videos, and overall radio silence.
I know some long term ocaml users and i can tell you that there is stuff boiling under the hood. Many are very much NOT HAPPY with JS and what they did.
Why does this library get posted here, what feels like every month? I remember it seeing at least twice before.
Been here 5 years, never saw it
HN is obsessed with anything done in niche programming languages, is my guess.
Also, Jane Street.
Considering how ridiculously verbose their library is compared to React/Vue it's a good thing we have LLMs to deal with the boilerplate now.
All your money and retirement funds are safe; I’m too dumb to work at JaneStreet; every time I see OCAML I feel less than and confused.
It's also a way to retain employees. If you are an expert ocaml writer, you aren't a drop in replacement at the competition. So while I'd love to work there, a lot of the knowledge isn't very marketable after you move on.
Aww thanks folks. All the downvotes to this means folks don’t think I’m dumb and also don’t like the self deprecating humor.
It might be a very performant UI framework in OCaml, but all the UI elements look extremely unpolished to me, like what a really smart high-school kid would build the GUI for his side project on Windows in 90s.
Thanks, I can use JS as a functional programming language.
Windows and especially Macintosh UIs from the late 90s/early 00s were by far the most functional UIs we've ever had since the dawn of the desktop era - user research was a serious discipline, accessibility was baked in to the frameworks, and the HID guidelines that devs adhered to gave us uniform conventions that we users could rely on.
If the biggest criticism of Bonsai is "it ain't pretty but it works", then long life to Bonsai - give me more, please!
I agree, we have lost the beauty of early user interfaces. You summarised it well, thank you.
Did you maybe confuse bonsai with a CSS library? How to build web UI != How to style HTML. Bonsai solves a different problem.