The problem with wasm right now is that it gives you very little in terms of interoperability with JavaScript. You simply cannot manipulate JS objects (including DOM objects) from wasm.

Compiling a language like BuckleScript to wasm is therefore not possible at the moment, simply because the interop features of BuckleScript cannot be encoded in wasm.

Besides, there are other difficulties: wasm doesn't have any kind of managed heap at the moment, which means that compiling a managed language to wasm requires to embed an entire GC in your production code! It's much better to take advantage of all the VM features offered to JS, like a GC, when compiling a managed language to the Web platform.

> To me, in the WebASM world, transpiling to JavaScript is starting to seem a little old-fashioned.

It's behind a flag in a couple browsers. Even with a flag, if you're going to actually do anything with the DOM, you're going to be shipping a js support library and calling into it. Using something that works now has value, particularly when you could get wasm in the future off the same code if anybody writes an OCaml wasm backend.

> Presumably Rust (or Ocaml) compiled to WebASM will also have substantially improved performance compared to transpiled JavaScript

Bucklescript adds asm.js type hints (but not the use strings) to the js output and does a fair number of optimization passes. Aside from reducing parse time, going from its current output to wasm is unlikely to pick up much in the way of perf. I'm actually not even convinced that wasm is going to be that much faster for load+parse over an optimized js payload because asm.js/wasm have to ship the runtime (allocator, stdlib, etc) while js just has to ship the code.

> Readable JavaScript is not as important as long as we have source maps

I write Clojurescript full time, which has source map support. I completely disagree with this statement.

> Ocaml and Rust share a lot of heritage

Rust was bootstrapped off an OCaml compiler. I like Rust and advocate for it but bringing up another compile-to-js language, particularly one as nascent as Rust doesn't really have anything to do with the merits or drawbacks of Bucklescript.

Readable JavaScript or not might not make a difference in the long run, but it sure helps adoption when a single person on a team can start using Bucklescript without having the pure JavaScripters hate her for it (or even having to know she's not writing her js by hand).

Sourcemaps aren't always possible with some workflows e.g. transpiling then bundling. Plus, readable JS is a huge productivity boost because it lets people transition away from JS into OCaml while still understanding their JS output every step of the way.