Live data from Hacker News

Bonsai: Janestreet's UI Library

github.com

161–165 of 165 posts

Re: Bonsai: Janestreet's UI Library

#161
post #86

Earlier quoted context omitted.

Fair point I guess JS doesn't have to care about this at all because they're not selling their UI to others, just making it in house for in house use

JavaScript?

No, OCaml

Think node, except the other direction. They write their backend in OCaml, and then they also write their web ui in OCaml with a translation layer

Or think of gwt (java) awhile back

Re: Bonsai: Janestreet's UI Library

#162

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 OCa…

I've been using Resgraph, but it's based off Rescript, a fork of ocaml.

Re: Bonsai: Janestreet's UI Library

#163

Earlier quoted context omitted.

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.

Yeah safety critical software needs to avoid high UI density for the interface itself. For diagnostics and monitoring or general stats you can still do high density but the actual "action space" needs to be kept as low density as possible and preferably with physical separation in the UI (i.e. via physical buttons and displays instead of just a big touch screen or monitor+Mouse and kbd).

Higher information density is ideal but when people are working in less than ideal conditions (stress, lack of sleep, alarms going off, etc) you need to prioritise information clarity and clarity of actions over raw density.

Re: Bonsai: Janestreet's UI Library

#164
post #22

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.

Which is fine if you are building tools for financial professionals. It is the aesthetic of choice. And is generally very functional for this purpose.
Post reply on HN