Jsoo, production use and user facing applications questions

Been using JSOO in “production” for ≥ 8 years in various projects.

aren’t the bundles huge? doesn’t it need to include a lot of ocaml code translations (runtime) as a minimum before user code is included?

No, JSOO is really good at minimizing the output

is chunk splitting even possible? is it possible to split a big application in smaller asynchronously loaded bundles?

Yes it is possible, separate compilation and all (it’s more of a build-system than JSOO problem I guess).

how do common ocaml concepts like include-ing a module and functors translate to jsoo, don’t these create copies and increase the bundle sizes further (meaning that commonly used ocaml libraries also increase the bundle size significantly)?

Not sure, but I think one of the nice things of starting off of the bytecode is that all those things are all gone by then.

is there good tree shaking/dead code elimination? for example would using a single function of Base result in a bundle including all of Base or just this one function and its dependencies?

Yes it seems to really use the minimum required

This project uses Tyxml, Base, Fmt, Lwd, Lwt, Ezjsonm, Digestif, Base58, ZArith, (json-)data-encoding, and a bunch of Tezos libraries (incl. the whole AST + parser & printer for the Micheline syntax). And it really uses all those things, they are not just randomly dragged dependencies:

 $ curl https://tqtezos.github.io/TZComet/main-client.js | wc -c
890171

have you had issues with debugging, source maps and etc.?

Issues, yes a ton, browsers are an awful mess to deal with. But it is unrelated to JSOO (options like --pretty, --no-inline etc. are far enough to make JSOO the least of your problems).

is it possible to use something jsx-like syntax to generate html similar to ReasonReact?

Funny, 10 years ago, ocsigen had a “tyxml syntax” long before anyone had heard of JSX. At the time, it seems that the consensus was “This is very cool, but it’s a bad idea, writing OCaml values directly is just so much better.” Now, there is an equivalent ppx extension (but I haven’t tried).

how are promises handled, for example is Lwt code automatically translated to promises?

Not sure what you mean. Lwt.t values “are” promises, all the low-level js-of-ocaml APIs just use Lwt.

what about json, serialisation and yojson, is it easy and efficient (without increasing the bundle size too much) to serialise/deserialise types through yojson?

You can use the “native” JSON module from JS, or any ocaml library that does it. The project above is an example of using data-encoding with Ezjsonm (libraries “imposed” by Tezos stuff).

13 Likes