Finally! I was waiting for this to become possible!
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.
There are TS constructs that require compilation into equivalent JS, such as enums and namespaces.
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.
Disclaimer: I am very inexperienced at front-end development.
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.
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)
Sarcasm?
Do you want to have a talk as to why JaneStreet wasn't built on JavaScript?
> 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.
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".
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.
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
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
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.
Sam Bankman-Fried and his League of Legend rankings would like a word
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...
To OP’s original question, they made $20B last year and have a niche in several financial products
You're being downvoted for having a needlessly confrontational underinformed hot take on a quant trading firm that is essentially a market maker.
[0]: https://github.com/janestreet/bonsai/blob/f31661450eb133fe89...
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.
> JSOO does not have tail call optimization
This says it is based on Elm. So it has the same clean immutable state structure?
I'm pretty sure you can build tools with this that are fast and pleasant to use.
Presumably this has learned some lessons from it, so it's probably better.
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.
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.
See also LiveView and Hologram for Elixir.
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
Thanks, I can use JS as a functional programming language.
If the biggest criticism of Bonsai is "it ain't pretty but it works", then long life to Bonsai - give me more, please!