D could catch this wave: web assembly

[Joakim via Digitalmars-d]

On Sunday, 21 June 2015 at 10:07:05 UTC, Ola Fosheim Grøstad 
wrote:
> On Sunday, 21 June 2015 at 09:07:52 UTC, Joakim wrote:
>> As I said before, start from scratch.  Stop trying to shoehorn 
>> a full app runtime into the browser because you will only lose 
>> to native app runtimes, which is already happening because 
>> they aren't constrained by such legacy decisions as an archaic 
>> document format.
>
> Start from scratch, in what direction? You need a design that 
> is generic enough, yet more productive than what exists.

I've sketched out one possibility in the past, with more details 
in subsequent comments in that thread:

http://forum.dlang.org/post/dqddjhccpmxhgcssqtol@forum.dlang.org

Surely you could think of other approaches that would ditch the 
current document format also?

> And then you need to wait 5 years for end users to install the 
> viewers, before you can use it.

Not necessarily, you'd probably start by simply linking your app 
into the viewer, ie using it just like any other UI toolkit 
library, until it became popular enough that you could separate 
out the viewer as its own app.

> I don't see native apps winning over the browser based apps. 
> Only in very limited domains, of daily use (like purchasing 
> tickets), but for non-technical reasons.

I think you are complete ignoring the current mobile app wave 
then.  There are plenty of valid technical reasons why 
web-centric organizations like Facebook tried to use HTML5 for 
their initial mobile apps but then had to backtrack to native 
mobile apps.

> And let's face it, many "native" apps are 50% browser based, 
> just wrapped up in a shell. They use the HTML5 web-view. 
> Because it is easier and performs well enough.

More likely because they already built a simple webapp and don't 
want to duplicate effort.  These are the low-end apps that 
started on the web, whereas those that start on mobile now often 
don't even bother with a webapp.

>> think about how you want to do it.  Simply dumping more 
>> features on top of the old web stack is a recipe for failure.
>
> I hear you saying it, but installed base is way too important a 
> factor to be ignored. What you can do is changing the 
> underlying engine, but keep the compatibility.

Browser install base is overrated in this day and age when people 
install apps aplenty and easily from mobile app stores.  They've 
been trying to change the underlying engine for a couple decades 
now and haven't gotten very far.

>>> You need a scene-graph / DOM.
>>
>> Not really, certainly not the latter if you chuck HTML/CSS/JS.
>
> DOM is a scene-graph.

Which is why I said you could chuck the DOM, but probably want 
some simpler kind of scene graph instead.

>> You've got to be joking: why would anyone want to use either?
>
> Because it is backwards compatible.

You were arguing that it wasn't that bad.  If the only reason you 
can give is because it's legacy tech, you just argued against 
yourself. :)

>> recent years and that's about it.  If this webasm effort ever 
>> got into most browsers, I guarantee that almost everybody 
>> would chuck javascript and compile java, C#, or D to the 
>> browser instead.
>
> Java has been available for years, almost nobody used it. Flash 
> was available for years and it was only used in limited 
> domains. Active-X was available. PNACL is available. asm.js is 
> available, and webasm doesn't offer much more than asm.js in 
> the near future.
>
> You can wish, but certainly not guarantee.

You seem to have missed the discussion above.  I guessed that 
they were allowing webasm to directly manipulate the DOM, rather 
than having to ca