It’s my pleasure to announce the release 0.0.2 of Brr, a toolkit for programming browsers in OCaml with the js_of_ocaml compiler.
Once it has made it to the repo, install with opam install brr and consult the API docs and manuals (or via odig doc brr).
This release fixes binding bugs, adds a few new bindings and tweaks some existing signatures. Thanks to all of those who provided bug reports, suggestions and code.
I am deciding whether to go all in with js_of_ocaml (supplemented with brr / vdom / bonsai or similar from OCaml community) or Rescript.
There are lot of data points for Rescript/ReasonML – its been used to build a lot of websites and the code that is transpiled is indeed quite clean and readable. There are other upsides and downsides to Rescript which I will not repeat here.
People using js_of_ocaml are probably much fewer and I’ve not been able to pickup many HOWTOs and experience reports. So I was hoping for a perspective from the js_of_ocaml side from anyone who works regularly with it. Specific experience reports using brr would also be appreciated.
The main issue that I perceive with jsoo is bloat. I jsoo compiled a ocaml-vdom counters (react style) example and that comes to ~100K js minified. A lot of that minified js is probably “pay once” – code for the transpiled ocaml runtime bits for the browser and subsequent code is not going to add more.
Bonsai (again, a react like framework) which janestreet is working on seems even more heavyweight. Their counters example weighs in at 1MB minified. See Cannot build bonsai from tip of tree · Issue #16 · janestreet/bonsai · GitHub and subsequent comments. I’ve also tried out the bonsai examples in my browser, they work but I can feel my browser struggling with the mass of transpiled Javascript :-).
So with such a significant tax, I want to know in which scenarios would js_of_ocaml be really worth it.
My understanding is if you already have a good amount of OCaml code that you could run in the browser it makes sense to use js_of_ocaml OTOH If you are starting from a clean slate, you’re probably better off just using Rescript. Agree? Disagree?
Any comments or experience reports on js_of_ocaml and the merits of using jsoo would be useful.
It seems that this myth sprung at some time. Personally I’m not aware of any facts that support it.
I’m not using the frameworks you mention, so I can’t comment on that.
But if you consider the size of what your browser gets in the face on the simplest “hello world” web page nowadays, I found it to be generally reasonable.
Things I made with Brr include, a single page application drawing app (450Ko uncompressed), a few “add some interactivity” to a web page toys like this vaccination calendar (97Ko uncompressed, which it seems, I used both Note and Ptime for) and a generic client-server front-end interaction library (84Ko uncompressed).
I don’t think you’ll find a definite answer on this except by trying yourself. Also always pay attention to what you use and its dependencies. Especially make sure you don’t duplicate functionality that is already available browsers (e.g. JSON parsing). The Brr webpage howto has a modest section about it here.
In my view the merits of js_of_ocaml is that it integrates well with the OCaml ecosystem and is faithful to its language semantics.
I’d say smooth interop with the node ecosystem is lacking, but OTOH the rapid advances in the libraries built-in in your browser makes that less of a problem. Think about it, left_pad is available everywhere nowadays ! If I really had to use a particular js library in a project I think I would try to vendor it rather than setup an elaborate build bureaucracy.
If you’re interested in also using OCaml on the backend (which personally I think you should be because it’s great!), I would also consider Melange (a fork of Rescript that aims for much better compatibility with OCaml).
Thanks for pointing out Melange – I am aware of it and it can be a cool alternative.
Interestingly, there’s a melange example (with server, client and shared code all written in reason) called r-fullstack-melange that comes with the OCaml dream web framework code also. So its easy to get started if you want to on it. Of course you can go with only melange on the client side and chose any other technology on the server side.
I hope melange picks up more momentum and builds a community around itself. It sounds like there are very few compromises when using this stack.