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)?
Bonsai: Janestreet's UI Library
21–30 of 165 posts
Re: Bonsai: Janestreet's UI Library
#22It 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.
Re: Bonsai: Janestreet's UI Library
#23The “The thinking in bonsai” link 404s.
This says it is based on Elm. So it has the same clean immutable state structure?
Re: Bonsai: Janestreet's UI Library
#24Earlier quoted context omitted.
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.
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.
> 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.
Re: Bonsai: Janestreet's UI Library
#25I am sure it's very performant, but to me it's extremely ugly; Surely someone can fix margins and still have it be performant.
Re: Bonsai: Janestreet's UI Library
#26The "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.
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.
Re: Bonsai: Janestreet's UI Library
#27Can 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?
Re: Bonsai: Janestreet's UI Library
#28Why does this library get posted here, what feels like every month? I remember it seeing at least twice before.
Re: Bonsai: Janestreet's UI Library
#29Why does this library get posted here, what feels like every month? I remember it seeing at least twice before.
HN is obsessed with anything done in niche programming languages, is my guess.