D could catch this wave: web assembly

[Joakim via Digitalmars-d]

Hmm, looks like the rest of my response got lost on the way to 
the newsgroup somewhere, reposting the rest below:

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:
>> 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 call out to javascript to do it.  Reading a bit 
more now, I don't think they're doing that.  In any case, none of 
the latter three technologies that allow using different 
programming languages were ever ubiquitous, the importance of 
which Wyatt and I discussed above.  Just by webasm being 
implemented in all major browsers, it would certainly lead to a 
_lot_ less javascript getting written, once devs actually have a 
choice of other languages, even if they'd still have to wrap 
javascript calls for DOM manipulation.

As for Java and Flash, they were very widely used, despite being 
slow and in their own little world inside the browser.  It was 
Flash that finally brought video widely to the browser, not the 
few HTML tags, codecs, and players that were there before.  And 
neither is as integrated into the web stack as webasm will be.

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

Right, that is the problem.  The old static page model was 
naturally geared towards a search engine, but the new dynamic 
model isn't.  That's a big problem for google, whether they 
realize it or not.

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

I meant that it'd be nice if linking to parts of the canvas had a 
bit nicer support than this:

http://stackoverflow.com/questions/6215841/create-links-in-html-canvas

OK, that's not going to make something so low-level as a canvas 
magically that much better-integrated into the web, but it might 
help.  I haven't messed with canvas much, but it's interesting 
how little it's been used, despite all the hype it got when it 
was first released.

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

That's what you do when you mash a bunch of disparate 
technologies together: make them mixable and flexible and let the 
devs deal with all the complexity and bugs. :)

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

If speed of parsing and analyzing weren't one of the main issues, 
why are they even taking this webasm binary approach?  A binary 
SVG can be made part of the DOM too once it's parsed.

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

We were talking about the original web stack and SVG, ie 1-3 in 
you list.  WebGL is a whole different beast.

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

It's only a different encoding of SVG, which the browser would 
then integrate into the DOM.  At this point, you'd still have to 
have the text fallback, as you say, because they already put it 
in, but an option for binary encoding would significantly 
increase its use.  Of course, as Wyatt said, SVG has a lot of 
other problems too.

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

Nothing that couldn't be made to work with the appropriate binary 
encoding.

On Sunday, 21 June 2015 at 10:13:22 UTC, Kagamin wrote:
> Do you think it's wise to ignore 2 billion users? The size of 
> the mobile market doesn't mean you can target it entirely. The 
> article suggests currently we have era of services and services 
> are clustered by culture, which means you can't target users 
> outside of your cultural cluster, while desktop applications 
> usually target entire desktop market without exceptions.

Apparently most new apps nowadays are ignoring that legacy 
desktop market. :) My point was that as mobile devices become 
usable with larger monitors, that desktop market is going to 
collapse.  As for cultural clusters, that's changing as they're 
now starting to bleed into each other: look at Office on 
Android/iOS and the multi-window stuff coming to mobile devices.

>> All the major mobile vendors are working on multi-window 
>> implementations which will soon allow you to plug your mobile 
>> device into a dock that connects to a 
>> monitor/keyboard/trackpad on your desk and run your mobile 
>> apps in a similar way to the desktop: Apple's just-announced 
>> multi-window feature to go along with their coming iPad Pro, 
>> Google's in-development multi-window implementation that has 
>> been found in the Android M build, and Microsoft's recently 
>> announced Continuum for mobile devices, that lets you plug 
>> your Windows Phone into a monitor and use Office with a 
>> desktop UI.
>
> Are you going to support windows phone?

No, of course not. :) But I'd been saying for a year or two that 
MS was dumb not to put desktop UIs and apps on their mobile 
devices, so you could use them with a monitor, and they're 
finally fixing that.  I can't imagine anyone actually wants to 
use Excel or Word on a touchscreen, I have no idea why they made 
such a big deal out of that.  Will it save Windows Mobile?  I 
doubt it, but given the strength of their office suite, it might 
sustain it a bit longer.

>> What this means is that people will soon be using their mobile 
>> devices for almost everything and desktop computers are 
>> effectively dead. :) Now, workstations were killed off by PCs 
>> and they still sell a couple million worldwide.  Similarly, 
>> there will always be a niche for PCs and mainframes.  It's 
>> just a small niche.
>
> It will be desktop for all practical purposes, just more 
> constrained in resources. Mobile platform will embrace two 
> unrelated ecosystems, and you will still have to choose which 
> ecosystem you target, and since desktop is a minority, why you 
> would care about mobile desktop? It will be minority for all 
> the same reasons that make desktop minority.

That's like saying current PCs are "mainframes for all practical 
purposes, just more constrained in resources," you honestly 
believe that too? ;)

I disagree that the ecosystems are unrelated, though I agree that 
they're different, but yes, the desktop UI on mobile devices will 
definitely be a minority.  Most people using computers just want 
to read a little, hit a couple buttons, and listen to music or 
watch a video once in awhile, anywhere they are.  That's what 
mobile devices are for.  The former dominant use case for 
computers, creating content or getting work done, are a small 
part of what computers are bought and used for nowadays.

So yes, the desktop UI is a niche, but a moderately large niche 
that is about to move to mobile devices also.  There will always 
be a tiny niche of users that sticks with desktops/laptops, 
workstations, and mainframes.

On Sunday, 21 June 2015 at 10:29:26 UTC, Kagamin wrote:
> On Saturday, 20 June 2015 at 19:00:08 UTC, Joakim wrote:
>> On Saturday, 20 June 2015 at 15:21:29 UTC, Kagamin wrote:
>>> High DPI settings screw up native UI too if it's not 
>>> pixel-precise, and ignoring user preferences is infraction, 
>>> I'm afraid. And this is where web actually shines: it's 
>>> designed to adapt gracefully to any user settings. Well, of 
>>> course when site design strays from how web was designed to 
>>> work, it runs into problems, that should be obvious.
>>
>> The highest-DPI devices I use nowadays are mobile devices and, 
>> in my experience, websites are the ones who most often get it 
>> wrong.
>
> I mean only design possibility, which is not taken advantage of 
> in modern web, unfortunately.
>
>>  That's usually related to tiny text, but that affects the 
>> overall layout too.
>
> Designers like their 5-pixel fonts and believe everybody will 
> appreciate them. But I think pixel-oriented design is a flawed 
> design choice for web, web wasn't designed to work that way.

It certainly can be hard to get this stuff right on any app 
platform, whether web or native mobile, with the proliferation of 
screen sizes, viewing distances, and DPIs these days, as Nick 
pointed out with the smart TV example above.  But I have to 
wonder if most of those small-font sites/apps render right on 
anything other than a _single_ device, which means their devs are 
certainly not dealing with that complexity at all.