Js_of_ocaml bindings for ReactJS

Hello,

Are there js_of_ocaml bindings for ReactJS (with ideally examples)?

Best regards,
Keiko

2 Likes

Dunno about reactJS, but there is react if you are looking for some reactive programming.

There’s reason-react, which you would probably be able to use since it should have the exact same interface in OCaml, although I’m not sure if you’ll need to use BuckleScript instead of js_of_ocaml in order to make it work.

See https://github.com/fxfactorial/ocaml-reactjs

But I’d actually advise you to try ReasonReact, it’s still OCaml (targeting BuckleScript) and is actually maintained by a team at Facebook. Makes more sense to use it.

If I understand correctly, to use OCaml libraries with BuckleScript, those libraries need to be compiled from the source using BuckleScript. (Please correct me if I’m wrong.) This is not ideal for my circumstances, in particular, given that available BuckleScript OCaml libraries found in https://github.com/reasonml-community/index are not too impressive.

js_of_ocaml appears to be able to compile highly complex libraries that include many runtime tricks. (Please correct me, if I’m wrong.)

Another point that favours js_of_ocaml is that deadcode elimination performed by ocamlclean looks more effective than that of BuckleScript. (But I haven’t done any proper investigation.)

Together with the fact that Eliom supports client-server communication (e.g., remote procedure calls and code-sharing between client and server code), Eliom + js_of_ocaml seems a better choice for me.

1 Like

I asked this question recently in the Reason Discord some time ago. Reason React creators went with Bucklescript and it makes a lot of sense for what they are doing because of excellent and simple interop. For jsoo I think the best way would be to reimplement the interop part of Reason React while keeping the API the same.

js_of_ocaml appears to be able to compile highly complex libraries that include many runtime tricks. (Please correct me, if I’m wrong.)

If you mean Obj.magic, maybe, but they are pretty close, BuckleScript supports most functions in Obj module.

Another point that favours js_of_ocaml is that deadcode elimination performed by ocamlclean looks more effective than that of BuckleScript. (But I haven’t done any proper investigation.)

This is not true. In general BuckleScript generates smaller JS code than js_of_ocaml.

In general, if you are an OCaml programmer and only want to make your code runnable in browser, then I suggest you use jsoo, if your primary
interest is on JS platform, BuckleScript is a better fit

1 Like

Thanks a lot for all the suggestions!

I’d like to come back to my original question:

Are there js_of_ocaml bindings for ReactJS?

Or I have to write them myself…

Best regards,
Keiko

Have you compared BuckleScript against ocamlclean + js_of_ocaml (as I don’t think js_of_ocaml runs ocamlclean per se.) Are the results of the comparison publicly available?

P.S. By highly complicated libraries, I meant something like janestreet/async_kernel and janestreet/incremental_kernel.

Indeed, as far as I can tell from what people are trying to PR on my repos BuckleScript is totally missing on the OCaml interop story.

I already got two pull requests (here and here) to make my libraries usable from it but I don’t merge these things as the way to do this is very brittle, doesn’t scale, and leads to maintenance nightmare —metadata duplication, version numbers in the repos etc.

But I don’t think it should be too hard for bucklescript to generate an overlay for these things from the OCaml repos using the opam metadata.

yes. We made a Mario game , it’s only 7KB gzipped js, you can find it on my GitHub repo. BuckleScript is designed to deliver optimal experience to JS platform

There are technical restrictions: we want to map ocaml module to js module following npm module resolution and good inter operation with js ecosystem. In that case we need take over your build system, it’s understandable that you may not like it.
But we work really hard to polish our build system, it works on all platform (battle tested on windows without relying on Cygwin ), highly performant (400 files in 1.5s) , the build system which gets the namespace right(jbuilder does not give you incremental build when adding files)
Enforce a single build system is key to deliver an end to end experience, good to BuckleScript community in the long term.

2 Likes

It’s not that I don’t like it. The metadata these people were trying to put in my repos would quickly get outdated. Unless you figure out a way to automate that, this strategy just can’t scale. If you want to allow your users to tap in the OCaml eco-system you will have to figure out a better strategy.

2 Likes

@yawaramin replied above with a link - Js_of_ocaml bindings for ReactJS

I had an impression that the project in @yawaramin’s reply has not been completed – it does not appear to provide the complete bindings for ReactJS. (But I might have misunderstood.)

Only for the sake of the preciseness of the information, the compared Mario project with js_of_ocaml does not seem to be using ocamlclean (OCaml Bytecode Cleaner).

That BuckleScript works with nmp is indeed very compelling (as we develop libraries for JavaScript programmers).

The project I referred you to is pretty much the most up-to-date binding you will find for ReactJS on JSOO. If you want something more recent you’ll probably have to write it yourself. The reason, as you can guess, is that the community is favouring ReasonReact.

@yawaramin Thanks a lot for correcting my wrong understanding. I was too hasty. I’ll give it a try.

ReasonReact is indeed compelling, but js_of_ocaml is a great project, too, it works excellently with Jane Street libraries.