D could catch this wave: web assembly

[Joakim via Digitalmars-d]

On Sunday, 21 June 2015 at 06:20:53 UTC, Ola Fosheim Grøstad 
wrote:
> Thrown away in favour of what?

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.

If you want to build an app runtime that has hyperlinks built in, 
like the web does, start from a clean sheet and really think 
about how you want to do it.  Simply dumping more features on top 
of the old web stack is a recipe for failure.

> You need a scene-graph / DOM.

Not really, certainly not the latter if you chuck HTML/CSS/JS.

> CSS makes design much easier than the alternative.

Only if the alternative is web design circa 1995.  Once you chuck 
HTML, CSS has no reason to stick around.

> JS is evolving into something close to TypeScript.

You've got to be joking: why would anyone want to use either?  On 
the server, where you could use anything you want and there is 
real competition, almost nobody uses either, node.js in 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.

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

Prefetching and caching is used by _all_ app runtimes, whether 
Java or Objective-C.  They don't change the fact that the web 
frontend is much slower and difficult to work with.

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

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?

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

The HTML5 canvas does provide a way out to some extent, but 
you're still stuck with javascript and I believe a certain amount 
of CSS.  You wouldn't do the layout manually, just download a 
javascript library that does a lot of the grunt work for you.  It 
is on the right track, but goes nowhere near far 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.

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

Simply repeating a point, which I already addressed and noted was 
irrelevant, doesn't add anything to the discussion.

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

So your point is that your suggested binary fallback doesn't 
quite work as advertised to replace SVG?  Never heard of anyone 
suggesting an alternative, then pointing out it doesn't actually 
work. As I already noted, SVG doesn't have to be text to be 
"embedded."

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

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

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

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.  The browser would have to understand this binary 
encoding instead of text SVG and do all the same steps it does 
with text SVG now, except it would all work much faster for the 
user. :)

On Sunday, 21 June 2015 at 07:38:02 UTC, Nick Sabalausky wrote:
> On 06/21/2015 01:42 AM, Joakim wrote:
>> At this point, it's just a software issue.  Mobile devices 
>> just need UI
>> features like multiwindow to make more capable use of large 
>> desktop
>> monitors.
>>
>
> No, there's more to a desktop/laptop than just processing power 
> and keyboard/monitor/mouse. The mobile devices are also 
> (currently) shit at storage space (not to mention virtual 
> memory) and peripherals. And then for devs, ie the people who 
> actually make all this stuff in the first place, there's even 
> more improvements needed.

I have almost 50 GBs of storage on my tablet, between the 
built-in flash and an SD card, about half what I have on my 
ultrabook.  If I weren't filling that 50 GBs up with many GBs of 
HD video, that's plenty of space for most people.  As for 
peripherals, you're talking printers and scanners?  Do people 
even use those anymore? :) If there's any demand for those at 
all, the dock for your smartphone will have a USB hub that 
supports them.

As for devs, they're a small percentage of the computer-using 
public, similar to hard-core gamers who want the most expensive 
graphics cards.  But even devs, most of whom certainly aren't 
using massive rigs with Xeons and 32 GBs of RAM, will make the 
switch.  The biggest issue there is the x86-centric toolchains 
most are using, but those should transition to ARM fairly quickly.

> I'm not saying it can't or won't reach parity with traditional 
> laptop/desktop. The groundwork is there and it IS now feasible 
> at least. But there's still a lot left. And, to even get there 
> at all, the mobile OS/device devs will have to accept that it 
> will require adopting more and more desktop/laptop features.

Not much left if you ask me, just multiwindow UIs, which could 
have been done at least a year earlier, and transitioning the few 
remaining desktop apps that haven't made the mobile transition 
yet.

> And I think that's the biggest question mark, as they seem 
> quite loathe to accept that mobile-style (or really, iOS-style, 
> which everyone else in mobile copied wholesale) isn't 
> universally superior for everyone in every way. This attitude 
> will prevent them from reaching parity and replacing 
> desktops/laptops until for as long as they choose to cling to 
> it. How long they'll cling to it is the question.

"mobile-style" is a very vague term, presumably you're referring 
to the prevailing mobile touch GUIs.  As I pointed out, the UI 
will need to be adapted for desktop monitors.

> But suppose, sooner or later, they've finally managed to 
> improve enough to render the traditional line of 
> desktops/laptops obsolete. It *WON'T* be a case of "mobile 
> killed desktop". Because they will have, by necessity, BECOME 
> just as much desktop as smartphone - the only difference being 
> the lineage. It would be, in effect, exactly the same as 
> laptops gaining mobile capabilities and mobile-friendly UI. 
> Except, oh wait, that's happening too, see MS Surface Pro.

That's what I detailed below: it's not the same and the failure 
of Surface and other Windows two-in-ones shows that.

> So it's NOT mobile replacing desktop/laptop. It's not "the new 
> defeating the old" as the smartphone/tablet fans would have 
> everyone believe. It's just plain old convergence. Neither side 
> will "win" over the other because winning this game requires 
> erasing the lines between both sides.

It _is_ convergence of software UIs, but it is killing off of the 
old hardware form factors and previous underlying desktop 
operating systems.

>> Yes and no.  As hardware form factors, the old desktop and 
>> laptop models
>> are being ditched.  The desktop box will almost completely 
>> disappear,
>> while the folding laptop is only really needed by a small 
>> niche, those
>> for whom "lap-ability" in a plane or conference seat is 
>> needed.  I
>> picked up a bluetooth keyboard for my tablet last year: that 
>> suffices
>> for me, and I bet most people, since I'm always going to put 
>> them down
>> on a hard surface before typing.  I bet 97% of the people who 
>> currently
>> use laptops are in this category.
>
> And then you need some place to set the phone/tablet. The 
> natural choice is to dock it into the keyboard, ideally with 
> some sort of hinge. At which point you've just re-invented the 
> laptop form factor.

I disagree that the keyboard is the natural place to dock the 
phone/tablet, and the failure of such devices, both on the 
Android side and especially on the Windows side, seems to show 
this.  I simply prop up my tablet on my desk on the side of 
something, whereas most will likely just dock them in small 
holders, either just to hold them up or to provide ports to 
connect to a larger monitor.

> The usefulness of laptop form factor won't go away, People will 
> just start failing to recognize that it's just a laptop in new 
> clothes with a few more tricks.

It will go away, for the reasons I've given.  Does that mean 
nobody will use laptops?  Of course not, people still use 
mainframes and giant workstations.  You just never see them 
around anymore, because it's such a small niche. :)

>> As for the desktop OS, Windows has essentially no penetration 
>> on mobile,
>> while OS X and linux live on only in the core kernels of their 
>> mobile
>> counterparts.
>>
>> All that is converging is the software UIs, where mobile 
>> devices will be
>> able to display apps appropriately both for constrained 
>> touchscreens and
>> larger monitors controlled by a keyboard/trackpad.  Only in 
>> that last
>> sense are mobile devices converging, by adding software UIs to 
>> work on
>> large screens.
>>
>
> No, as you already pointed out yourself, the hardware 
> capabilities are converging as well.

Heh, never said anything of the sort.  Anyway, it's funny that 
you respond to a quote limited to software and UIs by going on 
about hardware again, never mentioning software. :)

> And then you have on one hand the whole "hooking up a 
> keyboard/mouse" to a phone/tablet (and monitor too, HDMI-out 
> has become pretty common on Android)...

What is your point, that because we're still using keyboards and 
mice, they're "converged?"  A car still moves on wheels yet 
nobody would say it "converged" with a horse and carriage.  One 
feature, the wheels, carried over, but most of it is completely 
different.  I think that since the underlying device, a 
smartphone, is fairly different from a mainframe or a PC, it's 
far-fetched to say the devices are "hybrid" or "converged," 
simply because they're all using similar input peripherals when 
used at a desk.

But even that is only temporary, as voice and gesture recognition 
will soon kill off those input peripherals too. :)

> And on the other hand, you have laptops getting their 
> mainboards moved to the upper-half and becoming detachable from 
> the bottom half, and getting smaller, lighter, better battery 
> life...
>
> That...is form-factor convergence.

That might be actual hardware form-factor convergence, if anybody 
were buying those two-in-ones, but almost nobody is.

>>> Of course, that's dependent on the phone/tablet folks actually
>>> managing to pull it off. Which is certainly a possibility, I 
>>> agree,
>>> but I'm not convinced they'll necessarily manage to, at least 
>>> not in
>>> the short term.
>>
>> It's around the bend and frankly should have been done sooner.
>>
>
> Never underestimate the power of corporate ineptitude ;)

I agree with the sentiment, just not sure what you're trying to 
indicate with the "corporate" qualifier.  "Ineptitude" alone 
would have sufficed. :)