Rendered at 14:02:44 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
flufluflufluffy 4 hours ago [-]
> 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!
deciduously 57 minutes ago [-]
There's also Fable for F# but I believe this commenter is being sarcastic. Javascript is a common backend language.
51 minutes ago [-]
philipwhiuk 3 hours ago [-]
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.
I took this as a joke in reference to the popularity of JavaScript on the backend for the last two decades.
reactordev 50 minutes ago [-]
that's because most people's intro to CS was how to build a webpage.
nobleach 1 hours ago [-]
Yup, and Clojure/ClojureScript!
lbourdages 3 hours ago [-]
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.
danielheath 2 hours ago [-]
> 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.
applfanboysbgon 22 minutes ago [-]
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.
TacticalCoder 9 minutes ago [-]
> 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?
rw2 2 hours ago [-]
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.
pgwhalen 2 hours ago [-]
I’m no UI expert - what’s wrong with the margins?
LooseEquipment 1 hours ago [-]
inconsistent and maybe too tight, but I would think those are issues with the sample UIs and not this library
OneDeuxTriSeiGo 40 minutes ago [-]
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".
jackcarter 19 minutes ago [-]
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.
pgwhalen 54 minutes ago [-]
From experience I can say that traders prefer extraordinarily little whitespace in their UIs.
ctxc 1 hours ago [-]
Probably because they skew towards higher information density
troupo 21 minutes ago [-]
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.
chrischen 2 hours ago [-]
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)?
user2342 43 minutes ago [-]
Interesting! What are Bonsai's dependencies? I use OCaml but - so far - none of Janestreets libraries etc.
LeonidasXIV 10 minutes ago [-]
Basically most of Jane Street's published code[0] via its dependency on Core.
I really want to like OCaml. One day I'll get around to learning it.
Schlagbohrer 2 hours ago [-]
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?
derdi 47 minutes ago [-]
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 [...]"
antonvs 1 hours ago [-]
Probably not, because your agent won’t have much info about this tool in its training set.
tecoholic 2 hours ago [-]
Why does this library get posted here, what feels like every month? I remember it seeing at least twice before.
cassepipe 1 hours ago [-]
Been here 5 years, never saw it
jere 2 hours ago [-]
HN is obsessed with anything done in niche programming languages, is my guess.
bmitc 2 hours ago [-]
Also, Jane Street.
ubercore 3 hours ago [-]
Not sure why, but reminds me of Fog Creek's Wasabi.
adastra22 2 hours ago [-]
The “The thinking in bonsai” link 404s.
This says it is based on Elm. So it has the same clean immutable state structure?
xvilka 5 hours ago [-]
Looks like it's Web-only, no mention of the native UI support (terminal UI excluded).
avsm 4 hours ago [-]
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
aquariusDue 3 hours ago [-]
Unrelated but what do you use to manage your personal website? I love how everything is interconnected.
nbevans 2 hours ago [-]
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.
MrBuddyCasino 1 hours ago [-]
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.
hahahaa 5 hours ago [-]
Oh it needs a userland trampoline!
> JSOO does not have tail call optimization
kubb 4 hours ago [-]
I wish there were more OCaml shops out there
gigatexal 3 hours ago [-]
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.
bobjansen 4 hours ago [-]
This would of been cool back in 2014.
Traster 5 hours ago [-]
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.
troupo 2 hours ago [-]
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.
bofeiw 4 hours ago [-]
Agreed, looks like it's reinventing the wheels. Frameworks does not really matter today, AI agents write the code anyway.
KolmogorovComp 4 hours ago [-]
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.
rmzs0711 4 hours ago [-]
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
OtherShrezzing 3 hours ago [-]
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.
shAIster 3 hours ago [-]
AI certainly writes Internet comments so that the flock does not have a single minute to get independent thoughts.
ForHackernews 4 hours ago [-]
Better frameworks will still help AIs avoid silly mistakes. A smarter framework means you can be productive with a dumber/cheaper AI.
yuanBuilds 27 minutes ago [-]
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".
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.
[0]: https://github.com/janestreet/bonsai/blob/f31661450eb133fe89...
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.
> JSOO does not have tail call optimization
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.