5 ms·

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 r

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?

fulafel 9y ago
Let me count the ways: - 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. [1] https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md https://github.com/WebAssembly/reference-types/blob/master/p...
- themihai 8y ago
  >> - 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.

fulafel 9y ago

Let me count the ways: - 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. [1] https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md https://github.com/WebAssembly/reference-types/blob/master/p...

themihai 8y ago
>> - 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.