Is it practical to mix BuckleScript and Js_of_ocaml in a single project

From what I understand, BuckleScript seems a bit stronger in the area of JS interop (especially with ReasonReact and whatnot), while Js_of_ocaml seems stronger with OCaml interop.

Would there be a practical way to combine both of these in a single project, like using ReasonReact for DOM stuff, but Js_of_ocaml for logic?

I realize the answer is probably “No”, but it doesn’t hurt to ask. I realize there is a teeny, tiny bit of antagonism between these projects, but it would fantastic if there were a way to use them together for the areas in which each project shines.


I’m not entirely sure how that would work, and if it could work, I think that the complications this would introduce would far outweigh the benefits of combining the two in a single project.

For what it’s worth, I don’t see a need in combining bucklescript and jsoo in a single project, but I do see a need in writing libraries that work in both ecosystems. If there was a binding generator that worked for both, I believe that would address the vast majority of the antagonism between the two projects.

It’s what we’re going to do; at least it’s the current plan. We’ll use BuckleScript for stand-alone “web components” to keep them very small and reusable, thanks to BuckleScript almost directly using the browser’s “stdlib”.

We’ll use JSOO for our main client-side application however, which will give us access to most of our back-end library. Our library relies heavily on Core_kernel and Lwt, so BuckleScript wouldn’t allow much reuse at all.

1 Like

My assumption is that type inference and things don’t work across the two projects and you’re just treating your jsoo libraries as JS from BuckleScript. Is that right?

Pretty much. :grinning: Our BuckleScript components will stand alone entirely and be usable by JSOO, vanilla JS or other BuckleScript projects, or anything else which compiles to JS. The only I/O, if any, with these components will be limited to callbacks and state properties stashed in the DOM for all to use.