3 ms·
Better interoperability, definitely not. Scala.js already has the best interoperability out there, excluding languages with the same run-time semantics as JS (s
by sjrd 9y ago
Better interoperability, definitely not. Scala.js already has the best interoperability out there, excluding languages with the same run-time semantics as JS (such as TypeScript). In fact, it is the lack of good interoperability in wasm that currently prevents us from compiling Scala.js to that target.
We could hope for smaller bundles and faster load times, yes. But mostly we should be able to get faster "cruising" execution. Scala.js being statically typed, there is a lot of static guarantees that we lose when compiling to JS. JS engines are very good and can "recover" a lot of it through JIT'ing, but it's still 3x slower than Scala/JVM on average (after warmup of both), so clearly we lose something non-negligible. By compiling to wasm, we would lose the JIT, but keep the static types. It is unclear how fast we would manage to be, but I would hope we can get within 2x of the JVM instead of 3x-ish.
There is a lot of misconception on the Internet that "wasm makes everything faster". For example, a lot of people want to "compile JS down to wasm" to make it faster. That's bullshit, because your language does not have static types to begin with, so you lose the JIT and gain nothing in exchange, which means you'll run much slower. But if you compile a statically typed language down to wasm, you should be able to gain some significant speed.
- paulddraper 9y agoYeah, but Scala started out on a JIT runtime. I'm skeptical a non-JIT would really be that much better.
- sjrd 9y agoAs I said in the parent, in the case of Scala.js, I believe we lose more performance because of the loss of static types than we would if we lost the JIT. Performance measurements in Scala Native, which has no JIT and is still quite young (so not very optimized yet), suggest than we can easily be within 2x of the JVM for Scala code, even without JIT.
- shusson 9y ago> a lot of people want to "compile JS down to wasm" to make it faster. That's bullshit, because your language does not have static types to begin with, so you lose the JIT and gain nothing in exchange, which means you'll run much slower. According to Mozilla's recent blog[1], WASM will in many cases be faster than JIT. In your experience is this not true? [1] https://hacks.mozilla.org/2017/02/what-makes-webassembly-fast/ https://hacks.mozilla.org/2017/02/what-makes-webassembly-fas...
- sjrd 9y agoI read that article. They do not say anything wrong. But if you read between the lines, the article assumes your source language has types and does not have managed memory. Under those conditions, wasm will beat the JIT every time. But if your language has dynamic types and/or managed memory (but mostly dynamic types), then you need a JIT to get anywhere close to decent performance. The silent assumptions in that quite famous article is one reason many people believe that "compiling JS down to wasm" will make it faster. It is not the only article that has completely failed to point out the limitations, though. It's very sad to see, from where I stand. Note that I am not the only one thinking this. Core wasm developers agree. [1] [1] https://github.com/WebAssembly/design/issues/219 https://github.com/WebAssembly/design/issues/219
- shusson 9y agothanks, TIL. That Mozilla blog is misleading.