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.
> 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.
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.
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".
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.
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
"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.
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)?
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 only $20B in profits 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?
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 [...]"
Janestreet was banned from asian markets for market manipulation. They took in billions and fisted the average-joe investor. As a high profile ocaml user that casts a big shadow on ocaml too, as many involved in janestreet are also part of ocaml core team in some way.
I wont buy ignorance, as devs clearly know whats going on, so staying silent is pretty much being just as guilty.
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
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.
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.
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.
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.
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.
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)
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.
Sarcasm?
Do you want to have a talk as to why JaneStreet wasn't built on JavaScript?
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".
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
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.
EDIT.
Janestreet PR team is downvoting. Like always, radio silence and just downvotes.
I had expected more from janestreet.
To OP’s original question, they made only $20B in profits last year and have a niche in several financial products
[0]: https://github.com/janestreet/bonsai/blob/f31661450eb133fe89...
Janestreet was banned from asian markets for market manipulation. They took in billions and fisted the average-joe investor. As a high profile ocaml user that casts a big shadow on ocaml too, as many involved in janestreet are also part of ocaml core team in some way.
I wont buy ignorance, as devs clearly know whats going on, so staying silent is pretty much being just as guilty.
This says it is based on Elm. So it has the same clean immutable state structure?
> JSOO does not have tail call optimization
I'm pretty sure you can build tools with this that are fast and pleasant to use.
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.