On Thursday, 18 June 2015 at 21:21:13 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 18 June 2015 at 19:39:58 UTC, Nick Sabalausky
wrote:
Great, so it'll have the same fundamental problem as asm.js:
Claims to be backwards compatible, but really isn't because
the backwards fallback method is likely to be prohibitively
slow and will especially fuck mobile browsers that use the
fallback.
Yeah. This fallback thing does not make much sense. They say
WebAssembly will reduce the file size by 7% after compression
compared to asm.js . Who cares?
In fact, _we_ do. Our flagship product is mostly used via a web
application. Lots of Web 2.0 stuff going on there, it's pretty
big. This becomes kind of a problem when many of our customers
are halfway around the world. Even just 7% would be a win (for
bandwidth and latency), but it looks like that's a low-ball
estimate:
https://github.com/WebAssembly/design/blob/master/FAQ.md#can-the-polyfill-really-be-efficient
(The corollary to this is, yes, it does kind of have the same
fundamental problem as asm.js. Because it IS asm.js.)
But if the endgame becomes real and the the order-of-magnitude
parsing speedup happens, it'll be kind of huge.
Maybe this suggestion demonstrates ignorance, but I'm thinking
"They should just use LLVM IR. It already exists." Maybe toss
in some LLVM IR extensions as needed, and boom, done.
The LLVM IR isn't stable, so you need a higher level IR. And
that's hard to design. So maybe 5 years before they get it
right, and _properly_ implemented, in all browsers?
They covered this, too:
https://github.com/WebAssembly/design/blob/master/FAQ.md#why-not-just-use-llvm-bitcode-as-a-binary-format
-Wyatt
