D could catch this wave: web assembly

[via Digitalmars-d]

On Sunday, 21 June 2015 at 05:42:13 UTC, Joakim wrote:
> No, I'm not arguing for pages at all, I'm saying that model is 
> dead and gone.  I think the hyperlink was the killer feature of 
> the web, but everything else, HTML/CSS/JS, is just detritus 
> accumulated on top, that needs to be thrown away.

Thrown away in favour of what? You need a scene-graph / DOM. CSS 
makes design much easier than the alternative. JS is evolving 
into something close to TypeScript.

> You can do some interesting things with caching, sure, but the 
> web frontend is still unwieldy and slow and round-trip latency 
> anytime you do something is what kills you.

You can prefetch data if you want. If you have a scrolling view 
you can prefetch the next page-height worth of items. I do that 
for images where I have to deal with thousands of images.

> document format.  You are always going to be constrained by the 
> architectural constraints and inefficiency of the document 
> format.

You don't have to use it. I use it because it is more productive 
and more easily allows search engine indexing.

If you don't want it, you can use the HTML5 canvas and fill the 
view with it. But why would you? You would have to do all the 
layout manually and create a separate version for people using 
assistive technologies.

>> You can do that if you want. Just download binary data and 
>> plot it to a canvas.
>
> The fact that I could render SVG images to a png and download 
> that instead doesn't excuse the fact that they're putting full 
> text SVG renderers into the browser.

You can just send paths as binary data to the client and draw to 
HTML5 canvas if you want. No need to render on the server. Of 
course, that also means that you have to deal with 
resolution/zooming issues, and it also means that you may have to 
wait with the graphics till the whole DOM has loaded. Which is 
another issue that embedded SVG solves.

I wouldn't mind an improved version of SVG with LOD support etc, 
but I think that would be a different concept. SVG is perfectly 
fine for embedded CSS styled line-art (which I use it for). You 
can bundle HTML/CSS/JS/SVG in one file and have very responsive 
websites if you wish (one file download).

> Of course you could use binary SVG dynamically: you'd simply 
> need the right hooks in the browser and in the binary format to 
> manipulate it using javascript.  It would not require 
> "binary-format editors" or "binary HTML."

No, because I typically write the fragments for the SVG as text 
then programatically modify parts of the SVG. Or, I just attach 
event-listeners to parts of the SVG. Not having HTML and SVG in 
the same source would be very confusing.

I would have preferred something closer to Microsoft VML which 
made the vector-graphics part of HTML so that you could just 
insert a circle anywhere on the screen. But I guess the SVG clip 
rectangle made implementation of the renderer a lot easier.