For our newly ported 10k bucklescript app, what standard library should my team use?
[I’ve read Collections: OCaml standard library vs. Belt vs. Immutable-re but have different concerns so making a new thread.]
We just did a port of our Elm application to bucklescript, using the OCaml syntax. We also write our backend in OCaml, heavily using the Jane Street ecosystem (Base/Core, dune, lots of ppxes, etc). We’re using bucklescript-tea for our framework, and use almost no JS libraries outside our core app, though we hope to change that.
When porting, I ended up writing a shim around all the Elm libraries, and occasionally porting some of them, but now that we’re done we need to think about how to remove this debt, and decide on our team’s best practices going forward.
While porting, I tried using Belt directly, and found it very challenging.
|> a lot, while Belt seems designed for
|. There seems to have been a huge argument about
t-in-back, and the end result was
t-in-front which works poorly for us: we’d like to share code with our backend which uses
|> everywhere, and our frontend is currently written using
|> everywhere as well.
[On the server, we avoid these problems by using Jane Street Core, which uses labels almost everywhere, so the “does-the-t-go-first-or-last” is irrelevant in practice. Surprisingly, Belt doesn’t use labelled arguments very much, which would obviate the problem. We also use the OCaml syntax, so the reason syntax alternatives aren’t available.]
Belt also feels very inconsistent. I would repeatedly have to look up functions as I never got an intuitive sense of which arguments go where. It also has its functions spread across the Belt and Js namespaces: for example there is no Belt.String so we have to use Js.String, and I recall their being functions in Js.Map that weren’t in Belt.Map (can I use them? probably not)
It also feels very incomplete compared to the Jane Street and Elm ecosystems we’re used it, so I found myself writing a bunch of functions myself or porting the Elm functions directly.
Finally, having read lots of github issues, it seems that contributing to Belt involves a lot of work: there appears to be a lot of context involved, and long and contentious discussions, so I’m not confident that we will be able to upstream the work we do to mitigate our problems.
I’d love to hear whether people agree with our (early, limited) assessment, and what strategies people have used to mitigate the issues I’ve seen so far. I’d also be interested in challenges I haven’t come across yet.
Use Jane Street Base/Core
It would be great if we’d be able to use the same libraries on our frontend and backend, esp if it led to code reuse. Does anyone use Base in Bucklescript - I don’t see how to do it? What are the pitfalls? How does one even start with testing this out?
Port Elm libraries
We got spoiled by the very rich Elm standard library, and well as the *-Extra community libraries. One option is to port them over to bucklescript. Our app’s port was largely automated using an elm->ocaml compiler (to be open sourced soon), so this would be pretty cheap for us. We however don’t know the performance and other implications of this - what risks do people see?
Not using Belt
Given there are Js and of course the built-in ocaml libraries, one option would be to use them and skip Belt. However, they also seem quite incomplete and inconsistent to each other, and so would have many of the same problems that we’ve seen with Belt.