D could catch this wave: web assembly

[via Digitalmars-d]

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. And then 
you need to wait 5 years for end users to install the viewers, 
before you can use it.

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.

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.

> 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.

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

DOM is a scene-graph.

> You've got to be joking: why would anyone want to use either?

Because it is backwards compatible.

> 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.

> Actually, that's one of the big problems with the more dynamic 
> model: it breaks search engine indexing.  How does the crawler 
> have any idea how to navigate an app UI and generate URLs that 
> are meaningful, if they're even made available by the app?

Google provide ways to index dynamic apps, but it is more work. 
So it costs more in developer time.

> enough.  But as I noted earlier, the canvas tag doesn't even 
> support hyperlinks natively, which is a pretty big omission for 
> a web technology.

Not sure what you mean by that? You trigger on the click and load 
the target page? Or if you wish, you can overlay hyper-link 
rectangles on top of the canvas.

The current model is quite flexible, you can mix technologies. 
Perhaps too flexible.

> actually work. As I already noted, SVG doesn't have to be text 
> to be "embedded."

It has to be part of the DOM. Parsing is not the main issue.

> Very responsive because they're made up of trivially simple 
> line art, perhaps.

Trivial is relative. You can't have full-on photon-based 
simulation. You can have an advanced webGL shader if you want. As 
long as the renderer is the bottleneck you have to design for the 
renderer, no matter what kind of renderer you have. And you have 
many:

1. HTML5/CSS
2. HTML5/CSS GPU transforms
3. SVG
4. Canvas2D
5. WebGL.

That's five different rendering strategies with different 
performance characteristics and you have to design your graphics 
for each one of them.

>> attach event-listeners to parts of the SVG. Not having HTML 
>> and SVG in the same source would be very confusing.
>
> It wouldn't be confusing at all.  You'd simply do all that in 
> your text SVG authoring format and HTML on your side, then 
> compile SVG to a binary encoding on the server and send that to 
> the browser.

That would just be a different encoding of HTML5, if parsing was 
a major bottleneck, that might be a point. But it would have to 
coexist with the textual version and developers would only 
upgrade if it solves a problem.

In the scripting API using text as values might be an issue, but 
that's a different topic.