3 ms·

Sorry, my post maybe came off as more negative than I intended, but the downvotes seem a bit harsh. To me, in the WebASM world, transpiling to JavaScript is st

Sorry, my post maybe came off as more negative than I intended, but the downvotes seem a bit harsh. To me, in the WebASM world, transpiling to JavaScript is starting to seem a little old-fashioned. Readable JavaScript is not as important as long as we have source maps, which WebASM was designed to take into account. Presumably Rust (or Ocaml) compiled to WebASM will also have substantially improved performance compared to transpiled JavaScript, which IMO is worth the longer compile cycles. I think Rust is relevant because Ocaml and Rust share a lot of heritage (indeed, I think Ocaml was one of the most influential languages in the Rust design), so I think that makes it relevant in this discussion.

sjrd 10y ago
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.
grayrest 10y ago
> 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.

sjrd 10y ago

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.

grayrest 10y ago

> 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.