<p dir="ltr">On 3 Sep 2015 8:20 am, "deadalnix via Digitalmars-d" <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
> On Thursday, 3 September 2015 at 04:30:04 UTC, Ola Fosheim Grostad wrote:<br>
>><br>
>> On Thursday, 3 September 2015 at 03:57:39 UTC, Walter Bright wrote:<br>
>>><br>
>>> On 9/2/2015 7:48 PM, Adam D. Ruppe wrote:<br>
>>>><br>
>>>> but still i'm meh on the practical usefulness of such things. I guess if you<br>
>>>> target a canvas and run your code in it that makes more sense but my preferred<br>
>>>> style is a progressive enhancement webpage where you want to know the browser<br>
>>>> platform and work with it rather than around it.<br>
>>><br>
>>><br>
>>> I don't see a whole lot of point to generating JS from another language. You can't do anything more than JS can do, and you're likely to be doing less.<br>
>><br>
>><br>
>> That is silly. asm.js is a very restricted typed subset with strict rules that allows generation of pure assembly in a contiguous memory sandbox. It is a completely different setup. If you move outside those rules the compiler give up and switch to regular JIT with less restrictions. WebAssembly aims to go beyond what you can do otherwise  (like multithreading).<br>
><br>
><br>
> It is twice as slow as native. That's far from allowing generation of pure assembly.</p>
<p dir="ltr">I have far more faith in gccjit.  But it's more like the orange to a conventional jit's apples.</p>