3 ms·

js_of_ocaml has deep integration with the DOM, event handling, and tyxml (to emit HTML5 in a type-safe manner). It had a fine-grained reactive DOM before Facebo

js_of_ocaml has deep integration with the DOM, event handling, and tyxml (to emit HTML5 in a type-safe manner). It had a fine-grained reactive DOM before Facebook React was even a thing... Bucklescript could add those features, but it'd take a lot of work, and I'm not sure there would be much benefit over what js_of_ocaml offers. The sweet spot for Bucklescript seems to be in exposing bits of computation-heavy logic through OCaml. The reimplementation of a 55k Immutable.js in 899 bytes of compiled JS makes me go oh-damn-did-you-see-that! On the other hand, js_of_ocaml has rather unparalleled support for building UIs -- which probably makes it a better choice if you want to do your whole web app in OCaml, especially in combination with frameworks like Eliom.

erichocean 10y ago
> The reimplementation of a 55k Immutable.js in 899 bytes of compiled JS makes me go oh-damn-did-you-see-that! Link?
- jallmann 10y ago
  Right there on the github page. https://github.com/bloomberg/bucklescript#more-examples https://github.com/bloomberg/bucklescript#more-examples
afrisch 10y ago
I guess Bucklescript aims at a smoother integration with the JS ecosystem, which means binding to existing frameworks rather than creating new ones (such as tyxml or Eliom). These are different approaches which make sense for different target audiences. That said, it is also quite easy to bind to the JS world with js_of_ocaml and nothing forces you to rely on tyxml or Eliom. You can use either the FFI which comes with js_of_ocaml, or gen_js_api ( https://github.com/LexiFi/gen_js_api https://github.com/LexiFi/gen_js_api ) which we have created to abstract OCaml/JS bindings from the underlying OCaml->JS compilation technology (we hope that Buckescript will support gen_js_api). The web client-side frontend of my company is using exclusively gen_js_api + the js_of_ocaml compiler (but not its FFI nor its standard library), which should make it straightforward to port to Buckescript at some point if the need arise.

erichocean 10y ago

> The reimplementation of a 55k Immutable.js in 899 bytes of compiled JS makes me go oh-damn-did-you-see-that! Link?

jallmann 10y ago
Right there on the github page. https://github.com/bloomberg/bucklescript#more-examples https://github.com/bloomberg/bucklescript#more-examples

afrisch 10y ago

I guess Bucklescript aims at a smoother integration with the JS ecosystem, which means binding to existing frameworks rather than creating new ones (such as tyxml or Eliom). These are different approaches which make sense for different target audiences. That said, it is also quite easy to bind to the JS world with js_of_ocaml and nothing forces you to rely on tyxml or Eliom. You can use either the FFI which comes with js_of_ocaml, or gen_js_api ( https://github.com/LexiFi/gen_js_api https://github.com/LexiFi/gen_js_api ) which we have created to abstract OCaml/JS bindings from the underlying OCaml->JS compilation technology (we hope that Buckescript will support gen_js_api). The web client-side frontend of my company is using exclusively gen_js_api + the js_of_ocaml compiler (but not its FFI nor its standard library), which should make it straightforward to port to Buckescript at some point if the need arise.