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.
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.
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.
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)?
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'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
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?
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.
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 [...]"
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
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
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.
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.
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.
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.
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.
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.
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!
> 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!
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...
There's also Fable for F# but I believe this commenter is being sarcastic. Javascript is a common backend language.
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.
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.
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.
6 replies →
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.
2 replies →
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)
3 replies →
> 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?
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.
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.
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)?
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.
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
14 replies →
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'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.
> really clever people
Sam Bankman-Fried and his League of Legend rankings would like a word
They’re a market maker
Print money?
Governments print money, high frequency traders extract money. They would say that they provide liquidity to the market as a service.
1 reply →
[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
2 replies →
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.
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...
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?
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.
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 [...]"
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
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
Seconding the sibling comment - what are you using to run your personal site? It is very nice.
Unrelated but what do you use to manage your personal website? I love how everything is interconnected.
1 reply →
Not sure why, but reminds me of Fog Creek's Wasabi.
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.
The “The thinking in bonsai” link 404s.
This says it is based on Elm. So it has the same clean immutable state structure?
I really want to like OCaml. One day I'll get around to learning it.
I wish there were more OCaml shops out there
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.
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.
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.
3 replies →
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.
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.
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.
[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!
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.
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.
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!