Hi! Thanks for the write and for sharing I posted a question a few days back that seems on topic, but which, afaict, is not answered in your post (which, iiuc, is target at reason/rescript users more than OCaml users):
As a Jsoo user, my naive assumption was that anything that didn’t involve system interactions would compile, but this seems to be the case. I couldn’t find any readily available documentation explaining these limitations tho, nor what is required to make dependencies available for code that comiles via melange. Any pointers here would be helpful and gratefully received
We should make it probably clearer on the documentation, I will open an issue. For now let me try to draft some requisites from the top of my head.
Making a library “melange ready” there are the following rules:
To have all dependencies modes melange
To have dune 3.1 and OCaml 5.0/5.1 (depending on Melange’s version)
Don’t rely on system dependencies (similar on jsoo)
Having all dependencies modes melange is the biggest difference from jsoo, where you can add modes js in your “entry” and all subsequent libraries will be compiled to js (ofc unless some system dependency is used and no shim is available).
Having recently moved a code base from rescript to melange: I think it’s just great!
(the server/back end code is in OCaml)
*I tried JSOO and didn’t find sufficient documentation to get started with a typical web FE application, like using it with a bundler, CSS modules, translations etc.
Some of the tradeoffs with rescript, that you mentioned
Variants representation as strings : I really miss this, it makes interop with css, DOM, JS libraries much simpler
uncurry by default : I like uncurry by default (in JS land), the generated code is much more idiomatic and I wish there was a middle ground that both allows interop with OCaml, and doesn’t generate JS with ugly curry calls.
but I would trade all of these to be able to share code between the BE and FE.
Thanks for sharing the lessons learnt for having a bigger code base in Rescript and the limitations that come with that. I’m not a company, so when making choices about technologies to use for personal projects I find such reads very reassuring - I don’t want to be the first person to encounter every typical workflow problem.
(a general issue I find with OCaml is there’s not enough noise from companies using it - is it used successfully for web applications, am I going to be the first person to need to solve translations etc.)