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.
I don't think someone mentioned yet, but the (now defunct?) company Outrun Labs built a product Revery which seems almost exactly like what Jane Street has done (to my amateur eyes). OniVim was their only end user product afaik, built on this tech.
It's also a way to retain employees. If you are an expert ocaml writer, you aren't a drop in replacement at the competition. So while I'd love to work there, a lot of the knowledge isn't very marketable after you move on.
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)?
A good GraphQL server and client should be relatively straightforward to make in OCaml. Especially if you start from the premise that fragment spreads compose, rather than inherit.
Relay’s (second) compiler was prototyped in OCaml, but we ended up switching to Rust for the main rewrite in the belief that we’d be able to use the same runtime code across iOS, Android and JS environments.
Please somebody make a good OCaml GraphQL compiler, server, and client.
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.
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?
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.
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!
The value proposition about this web framework over things like React, Phoenix, etc is that it uses incremental computing right ? Using Jane Street's incremental computing library. I see it being used at https://github.com/janestreet/bonsai/blob/f31661450eb133fe89...
The docs directory happen to be missing, therefore the links to the quick guide and to "thinking in bonsai" pages from the readme are broken.
Also, I'm wondering how does bonsai-web update the DOM, is it via direct modification of the changed elements, or via some DOM differ? I'd say from direct update from a quick look at the source, but I'm unsure.
A more practical question: has anyone used this in production in internal apps at work? UIs like this look nice and have a flare that I like, but I guess it feels weird if I want to introduce this with my team over something like tailwindcss and rolling our own components
43 comments
[ 0.26 ms ] story [ 22.2 ms ] thread> 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.
Finally! I was waiting for this to become possible!
Relay’s (second) compiler was prototyped in OCaml, but we ended up switching to Rust for the main rewrite in the belief that we’d be able to use the same runtime code across iOS, Android and JS environments.
Please somebody make a good OCaml GraphQL compiler, server, and client.
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.
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!
Also, I'm wondering how does bonsai-web update the DOM, is it via direct modification of the changed elements, or via some DOM differ? I'd say from direct update from a quick look at the source, but I'm unsure.