D could catch this wave: web assembly

via Digitalmars-d digitalmars-d at puremagic.com
Wed Jun 24 02:37:59 PDT 2015


On Wednesday, 24 June 2015 at 07:25:26 UTC, Joakim wrote:
> So they're only talking about "GC support" for integrating with 
> javascript and DOM objects, not the GC for some other language 
> compiled to webasm.  I thought Ola was talking about the 
> latter, maybe he was talking about the former.

I'm talking about both.

> You may be right for the UI: I haven't profiled it.  But for 
> computationally-intensive stuff like a physics engine, which is 
> what this is supposedly aimed at, javascript is the bottleneck.

Yes, the question is if hardware will aim to support low latency 
OpenCL etc in the near future. And will webasm map to OpenCL?

> It's been done, as the FAQ quoted above notes.  If you're 
> talking about integrating with javascript and DOM objects, they 
> say they plan to support that eventually also.

I don't think you can have efficient concurrent GC with the IR 
they seems to aim for.

> alluded to once earlier in this thread.  But that's not the 
> issue: you seemed to be arguing that the reason there's so much 
> stuff dumped into the web stack is because they keep the old 
> stuff around for backwards-compatibility, whereas I was saying 
> they're dumping in _way_ too much new stuff, forget about the 
> old stuff.

Most of the new stuff is good. What new stuff is bad?

> I love experimentation and trying out new approaches, but 
> ideally those should get weeded out and rationalized before 
> being baked into the standard.  At this point, there's too much 
> stuff getting "standardized," forget about the single-browser 
> experiments.  It's almost as though the browser itself has 
> become a giant, bloated experiment, one that never cuts failed 
> attempts.

Yes, they should start deprecating. But more likely you will just 
get multiple engines in one browser (like with IE). One modern 
and one backwards compatible.

> So you're editing SVG in the client, ie the browser?  You edit 
> your text C++ source on your developer workstation and upload 
> bitcode to the server with webasm, which is what the browser 
> downloads.  You could do the same with SVG: edit the text SVG 
> on your workstation and upload a binary encoding for the server 
> and browser.

But the point is that it is tedious. So people don't want it. 
Just like C++ is more tedious than Python for evolutionary 
development.

> You claimed that "parsing is not the main issue" with SVG, yet 
> it certainly appears to be an issue with webasm.

Only if webasm is directly translated to machine language.



More information about the Digitalmars-d mailing list