D could catch this wave: web assembly

[via Digitalmars-d]

On Tuesday, 23 June 2015 at 11:09:31 UTC, Joakim wrote:
> On Monday, 22 June 2015 at 16:34:58 UTC, Ola Fosheim Grøstad 
> wrote:
>> People are already writing less javascript, but without a GC 
>> in webasm most languages are better of compiling to javascript 
>> or a mix.
>
> The problem is that they may be writing less javascript now, 
> but they're still stuck with the performance of javascript, as 
> they're just compiling to javascript.  Webasm making that 
> faster and allowing more languages should change that equation 
> much more.

asm.js/Webasm is more restricted. Those restrictions basically 
tells the JIT that the code has already been optimized, doesn't 
need higher level support and it can be translated into machine 
language as is...

Although I don't think javascript is the bottle neck at the 
moment. I think the layout and render engine is.

> As for a GC, why would webasm need to provide one?  I'd think 
> the languages would just be able to compile their own GC to 
> webasm, which seems low-level enough.

That would be difficult to get right.

> This is nonsense.  They're just dumping in everything they can 
> think of, that has nothing to do with backwards-compatibility.

Web tech is pretty good at backwards-compatibility. Not sure why 
anyone would argue against that.

>> I think the vendors have realized that they need to take 
>> babysteps in concert, because there is to much politics 
>> involved to accept a "whole-sale solution" like PNACL etc.
>
> PNaCl is bitcode too.

 From one party. So it did not get adopted.

> That doesn't answer the question of why they're using a bitcode 
> and not a textual IR, as you prefer text for SVG.

Because we don't edit the IR.