Bonsai: Janestreet's UI Library

Posted by KolmogorovComp 4 hours ago

Comments

Comment by flufluflufluffy 3 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!

Comment by deciduously 4 minutes ago

There's also Fable for F# but I believe this commenter is being sarcastic. Javascript is a common backend language.

Comment by philipwhiuk 2 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.

Comment by raphinou 1 hour ago

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)

Comment by vintermann 10 minutes ago

I took this as a joke in reference to the popularity of JavaScript on the backend for the last two decades.

Comment by lbourdages 1 hour 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.

Comment by danielheath 1 hour 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.

Comment by nobleach 36 minutes ago

Yup, and Clojure/ClojureScript!

Comment by rw2 1 hour 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.

Comment by pgwhalen 43 minutes ago

I’m no UI expert - what’s wrong with the margins?

Comment by LooseEquipment 32 minutes ago

inconsistent and maybe too tight, but I would think those are issues with the sample UIs and not this library

Comment by pgwhalen 2 minutes ago

From experience I can say that traders prefer extraordinarily little whitespace in their UIs.

Comment by ctxc 11 minutes ago

Probably because they skew towards higher information density

Comment by chrischen 1 hour 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)?

Comment by Schlagbohrer 53 minutes 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?

Comment by antonvs 16 minutes ago

Probably not, because your agent won’t have much info about this tool in its training set.

Comment by tecoholic 49 minutes ago

Why does this library get posted here, what feels like every month? I remember it seeing at least twice before.

Comment by cassepipe 13 minutes ago

Been here 5 years, never saw it

Comment by jere 45 minutes ago

HN is obsessed with anything done in niche programming languages, is my guess.

Comment by bmitc 43 minutes ago

Also, Jane Street.

Comment by adastra22 1 hour ago

The “The thinking in bonsai” link 404s.

This says it is based on Elm. So it has the same clean immutable state structure?

Comment by ubercore 1 hour ago

Not sure why, but reminds me of Fog Creek's Wasabi.

Comment by MrBuddyCasino 25 minutes 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.

Comment by xvilka 4 hours ago

Looks like it's Web-only, no mention of the native UI support (terminal UI excluded).

Comment by avsm 3 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

Comment by aquariusDue 1 hour ago

Unrelated but what do you use to manage your personal website? I love how everything is interconnected.

Comment by bobjansen 3 hours ago

This would of been cool back in 2014.

Comment by nbevans 1 hour 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.

Comment by hahahaa 3 hours ago

Oh it needs a userland trampoline!

> JSOO does not have tail call optimization

Comment by kubb 3 hours ago

I wish there were more OCaml shops out there

Comment by gigatexal 2 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.

Comment by Traster 3 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.

Comment by troupo 1 hour 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.

Comment by bofeiw 3 hours ago

Agreed, looks like it's reinventing the wheels. Frameworks does not really matter today, AI agents write the code anyway.

Comment by KolmogorovComp 3 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.

Comment by rmzs0711 3 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

Comment by OtherShrezzing 2 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.

Comment by shAIster 1 hour ago

AI certainly writes Internet comments so that the flock does not have a single minute to get independent thoughts.

Comment by ForHackernews 3 hours ago

Better frameworks will still help AIs avoid silly mistakes. A smarter framework means you can be productive with a dumber/cheaper AI.