Well... two of 3 of the languages you provided as example were designed to be transpiled to javascript. I doubt JS is a more suitable target for other languages than an IR like wasm which is being designed to be a compiler target.
I would be interested in hearing a more detailed argument on why ClojureScript & Elm would be better if they targeted WebAssembly.
Even the WebAssembly authors seem to agree that it's not foremost a managed language compile target - The Overview text from http://webassembly.org/ says "Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications."
Elm was designed to be transpiled into javascript just like CoffeScript so let's put it aside for a moment.
WASM is work in progress so I'm sure that if people care enough they can find solutions for such specific issues(i.e. seems that VM languages have their own set of issues). There is a GC proposal so managed languages will benefit a lot(i.e. smaller runtime).
JS is a high level language. I don't see many people compiling to managed languages outside of the browser. Wonder why is that? Few target JVM...but I don't see many(if any) compiling to Java, C#, Ruby or Lua or PHP. I've never seen anyone compiling JavaScript either unless they had to run it in a browser. This should tell you how good JS is when it has to compete on merit as compiler target.
Elm semantics is very far from JS - it's a kind of Haskell-lite. The tooling and diagnostics are very much custom and don't rely on JS developer tools or source maps. (Also, "transpile" is just another word for "compile")
Do you mean that Elm was not designed considering JS as its compilation target? Is Elm used anywhere else than the web browser?
Why nobody compiles to JS outside the web browser if it's such a good compilation target?
>> Also, "transpile" is just another word for "compile"
Well, I prefer to use the "transpile" term when the target is a high level language.
JavaScript is a high level language. It seems some smart folks decided that a new "language/IR" is needed (wasm) so that people can use other languages on the web. Now let's make this new IR a first class citizen on the web.
I'm sure Elm design considered JS, but I'm also sure that if WebAssembly had been available when Elm was designed, it would still have targeted JS rather than WebAssembly. Same goes for ClojureScript.
WebAssembly is a refinement of asm.js, which started as a mechnism to enable C/C++ code to run in browsers. Other, managed languages aren't forced to go the asm.js route because their semantics aren't tightly married to a byte addressable, untyped program heap.
What exactly makes JavaScript a better target for languages such Elm (apart from GC and DOM access which are supposed to be implemented sooner or later) ? You realise that JavaScript itself is also compiled/transpiled by the browser engine(i.e. v8) before it executes, right?
- code size - a runtime for a managed language is much bigger if you have to reimplement & ship the primitives you get from the JS platform.
- implementation complexity: a LLVM-webassembly-toolchain along with your own GC is much harder and more work than a JS backend, and would need to have a rather good payoff to be worth investing in.
- poor cross-browser development tooling support to have a good debugging experience
- GC implementation complexity and performance - firstly, there is no GC support currently and no timeline about when/if something materalizes. The current "future GC" support in webassembly[1] doesn't provide a GC implemnetation, just hooks to peacefully coexist with JS GC.
- JS interop
- browser support
Now, it may be that some of these get solved eventually - but they would all have to be solved, with high quality solutions, to beat JS as a managed language compile target.
>> - implementation complexity: a LLVM-webassembly-toolchain along with your own GC is much harder and more work than a JS backend, and would need to have a rather good payoff to be worth investing in.
I strongly disagree. Wonder why no language(managed or unmanaged languages) designer uses this gem named JavaScript as compile target?(web stuff excluded)
It seems your whole argument revolves around the fact that JS has better support than WASM in browser. We already know this. WASM is a work in progress. It's not ready yet for prime time. This year we will get some managed languages compiled to WASM. Next year we might get GC. I believe in some distant future javascript will be compiled to wasm either by the client or by the browser itself(for backward compatibility). JavaScript is JIT-ed in the browser anyway.
