D could catch this wave: web assembly

[Joakim via Digitalmars-d]

On Friday, 19 June 2015 at 05:17:27 UTC, Ola Fosheim Grøstad 
wrote:
> On Friday, 19 June 2015 at 04:18:59 UTC, Joakim wrote:
>> Think about that.  Once you're writing your app in 
>> WebGL/webasm, what are you really gaining over just making it 
>> a mobile app for iOS/Android, both of which support 
>> OpenGL/asm? ;)
>
> 1. You write one app.
>
> - Want asm on Android? Woops, many different configurations.

One configuration covers 90+% of the market, ARM.  Besides I 
never saw the big deal about keeping a couple more binaries 
compiled and ready for less-popular architectures, it is trivial 
to do.

> - Want asm on iOS? Woops, no more, moving to LLVM.

asm is still supported on iOS, it's merely not the default option 
in Xcode anymore.

> - New version of iOS? Gotta update the app to stay fresh.

How is this not true for any evolving platform, including HTML5?

> 2. Instant access. Direct load from advertisment-link.
>
> 3. No update procedure, no lingering messed up version.
>
> 4. No AppStore-related censorship/constraints.
>
> 5. No extra fees.

All true, but there's also a downside for the dev.  Since the 
webapp is never actually installed, it's easily forgotten and 
discarded.  I don't think most mobile devs find these constraints 
onerous.

>> Those days are gone.  The dynamic model of HTML5, where pages 
>> are not even the organizing principle anymore, means they need 
>> to rethink the entire model.  But I see no evidence that 
>> anybody is doing so, simply piling more stuff on top.
>
> Polymer, web components.

I'd heard of Polymer, but not web components.  It appears to be a 
way to build more standardized UI widgets that can be shared 
across sites.  That does nothing to integrate the old 
page/hyperlink model of the web with the new dynamic HTML5 model, 
but as Nick said, simply piles more of the dynamic stuff on top.

>>>> http://www.w3.org/TR/SVG/paths.html
>>>>
>>> SVG has animation, input handling, and an audio API(!) and 
>>> you take issue with paths?  Weeeeeak. :P
>>
>> No, I take issue with the text format, especially XML.  That 
>> was a horrible idea, regardless of how many good features they 
>> built in.
>
> PDF is text format too. SVG is pretty good actually, but the 
> integration with HTML5 could be better.

And you think PDF is well-integrated with the web?  I actually 
was not aware of the internals of the PDF file format, looks like 
it is binary for some key structural aspects, with the document 
aspects in text:

http://resources.infosecinstitute.com/pdf-file-format-basic-structure/

That actually makes some sense for a document format, which is 
what HTML originally was.  It makes no sense for a vector 
graphics format like SVG, where efficiency is key.

On Friday, 19 June 2015 at 08:08:08 UTC, Kagamin wrote:
> On Thursday, 18 June 2015 at 10:36:16 UTC, Joakim wrote:
>> As Tim Bray, of all people, wrote a couple years ago, this 
>> Titanic is losing to native mobile apps and it's only a matter 
>> of time till it's sunk:
>>
>> https://www.tbray.org/ongoing/When/201x/2014/01/01/Software-in-2014
>
> Hmm... Web: write once with html, css, js. Native: write three 
> times in obj-c, java, c#. Not sure why the former should sink 
> and not the latter.

Because writing it once in HTML/CSS/JS takes you much longer than 
writing it in Java, while being less responsive, then you get to 
enjoy all the myriad ways your UI will be screwed up by the 
different browsers.  I do agree with you that having to write 
your native mobile UI three times is not optimal either, as Bray 
notes in his piece, but the web is so bad that even those three- 
well, really two, nobody supports WP :p - ways are better.

>> But what do they do instead of starting anew?
>
> Web and native are not really related, one doesn't preclude 
> existence of the other and doesn't depend on it.

That doesn't answer the rhetorical question you're responding to. 
In any case, they _are_ competing technologies, and one is so bad 
that it is manifestly losing out.

On Friday, 19 June 2015 at 14:18:49 UTC, Wyatt wrote:
> On Friday, 19 June 2015 at 04:18:59 UTC, Joakim wrote:
>> No, NaCl has been built into Chrome, one of the major browsers,
>
> "One of the major browsers".  One.  Not "all".  One.  In the 
> timeframe that NaCl was ever relevant, we're talking about 
> approximately a third of browsers.  And it was never coming to 
> the other 66%.  Ubiquity matters.

The way you wrote your original comment, you seemed to be saying 
that NaCl required a plugin on Chrome too, which is what I 
disputed.  Of course ubiquity matters, but I think the bigger 
issue was likely that NaCl was only ever meant to offload 
computationally-intensive tasks.  I don't think they ever gave it 
access to the DOM, so that you could actually replace javascript 
with other languages.  I'm guessing they're finally doing that 
with webasm, which would greatly increase the utility of this 
approach.

>> Think about that.  Once you're writing your app in 
>> WebGL/webasm, what are you really gaining over just making it 
>> a mobile app for iOS/Android, both of which support 
>> OpenGL/asm? ;)
>>
> Maybe the part where you're maintaining three separate branches 
> with three different sets of highly-specialised domain specific 
> knowledge and bugs?  And that still only covers mobile; 
> iOS/Android aren't everything. (Yet.  (Thankfully.))

If you're using OpenGL instead of the similar WebGL, as was the 
premise, it'll run on practically every platform.  The only 
exception is really old Windows PCs, as many Windows 7 and newer 
PCs come with recent OpenGL drivers.

>> No, I take issue with the text format, especially XML.  That 
>> was a horrible idea, regardless of how many good features they 
>> built in.
>
> I wouldn't call any of those things "good features"-- SVG is 
> fractally terrible.

Heh, I missed the sarcasm in your original comment, I thought you 
were actually trumpeting those as worthwhile features.  My point 
was that implementing SVG in text is such a bad decision at the 
base that it immediately invalidates it, regardless of what other 
good or bad features are heaped on top.