D could catch this wave: web assembly

[Wyatt via Digitalmars-d]

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