Hacker News Reader

Comment by cookiecaper | Hacker News Reader

JavaScript is becoming a must-have compilation target. I hope that we can cut out the middleman soon via WebAssembly.

In particular, I would like to see browser vendors distribute a small number of wasm-compiled VMs that function as first-class JS alternatives. This would provide some sense of stability and blessing, and prevent a delay in page load time caused by the download of an alternate client implementation.

I started to seriously undertake a Dart-based project in the last couple of weeks but eventually decided that the ecosystem is too immature to make it worthwhile. I'm going to try Scala.js for a while and if that doesn't pan out I'll probably be forced into TypeScript. I had previously also tried Go/GopherJs.

View on HN

I use Scala.js at work. Take my advice, try BuckleScript/Reason. You will:

- Save significant amounts of time during each edit-recompile cycle (this really adds up)

- Get better type inference and write more succinct code

- Deploy tiny artifacts thanks to BuckleScript's aggressive dead code elimination, ES6-style module output, and rollup.js's fantastic tree-shaking

- Have fun coding

WebAssembly is quite a small change from asm.js - it's mainly a different transfer format and a parsing speedup. It's targeted towards non-GC languages like C/C++ and Rust - for managed languages, Javascript is the only sane compile target.

Scripts for GC languages wouldn't be compiled directly for WebAssembly -- their runtimes would. That's why I suggest browser vendors bless a few specific alternative runtimes and distribute them with the browser. For example, PyPy would be compiled for WebAssembly, and then Python could be executed directly as a client-side web language. Same with Dart and other languages that depend on a VM to do the heavy lifting.

I guess if wasm some day gets GC support and runtime code generation, there might be something to this idea - for a language like OCaml that is designed for AOT compilation.

> Scripts for GC languages wouldn't be compiled directly for WebAssembly -- their runtimes would

It is not a walk in the park to compile runtime into WebAssembly (unless you are just compiling an interpreter).

Performant runtimes usually include machine specific backends and/or hand written assembly code. You'll need to port that all to target WASM too.

Yeah, though I haven't worked on that directly, I'm sure it's not trivial, but I think there is sufficient demand. Check out http://pypyjs.org , which uses emscripten to compile to asm.js and then bolts on a custom JIT that emits asm.js, for one example of a project that is already trying something like this.

Reply on news.ycombinator.com