[ANN] promise_jsoo 0.1.0

Hello! I am announcing the first release of promise_jsoo, a library for JS promises in Js_of_ocaml.


https://opam.ocaml.org/packages/promise_jsoo/

The library has bindings to the core Promise methods as well as helper functions that make it easier to deal with a Promise of an option or result. It is also possible to use this library with gen_js_api to make for an easier JavaScript binding experience

Inspired by aantron/promise, this library also uses indirection internally when handling nested promises in order to ensure that the bindings are type safe.

This project is part of ongoing work to port vscode-ocaml-platform to Js_of_ocaml.

Generated documentation can be found here.

Thank you!
- Max

9 Likes

I stumbled across this page while searching for something else.

Am I reading this correct? In 2020, there was an effort to port the vscode-ocaml-platform in OCaml/js_of_ocaml instead of JS/TS ? If so, how did this turn out ? This sounds amazing.

Well, they got it done. vscode-ocaml-platform/dune at master · ocamllabs/vscode-ocaml-platform · GitHub

This is awesome.

In emacs, we can edit an elisp expr, hit C-x C-e, and have it modify the running system.

Here, is it possible to:

  1. have dune build -w running in a terminal

  2. edit a *.ml file corresponding to vscode-ocaml-platform

  3. hitting refresh, but without restarting vscode, have it load the new ocaml/jsoo code ?

In a similar project of mine, albeit a firefox extension, when it was using jsoo, and which also used promise_jsoo, I used to keep two watchers running.

  1. dune build -w to compile *.ml to *.js, like you said
  2. A watcher that watches the *.js files and reloads the extension in vscode. I usually use entr as a watcher.

About 2, I am fairly confident that vscode would have a dev reload mode or something.

May be dune could do both the steps by itself, but I never bothered to look into that.

Actually, the extension was already written OCaml by that point. The port was between two alternative OCaml → JS toolchains: BuckleScript (now ReScript) and Js_of_ocaml. BuckleScript was closer to the JS world, but we were missing out on the latest OCaml version and the ecosystem. Even though it was the same source language, it was still a lot of work to translate between the two due to the toolchain differences.

I thought we were pretty successful :slight_smile:

If you’re interested, I wrote about the process after it was finished: Js_of_ocaml in the VSCode OCaml Platform | Max Lantas

Not sure if it works the same as emacs, but VS Code has the Developer: Reload Window command which basically restarts the editor without closing the window. Since VS Code is an Electron program, I think it’s more-or-less equivalent to reloading a browser tab. I have it bound to WinR or CmdR to restart the window after rebuilding the code.

Technically, the OCaml extension also requires esbuild to bundle the Node dependencies into a single .js file, so only running dune in watch mode wouldn’t be sufficient. However, I think you could remove that build step and have VS Code load the code generated by Js_of_ocaml directly.

The extension development process didn’t change too much after the port from BuckleScript to Js_of_ocaml. The bigger benefits came from access to the native OCaml tooling and libraries.

3 Likes

Indeed it was widely successful. It really lowered the barrier for OCaml programmers like myself that weren’t familiar with the TS stacks.

When I developed the vscode more actively, I had a task to launch the editor using the development version that didn’t require the bundling step. You can see it here: vscode-ocaml-platform/launch.json at master · ocamllabs/vscode-ocaml-platform · GitHub

2 Likes