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.

On 06/19/2015 03:51 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Friday, 19 June 2015 at 06:30:30 UTC, Nick Sabalausky wrote:
>> If by "instant" you mean "this web 'app' leaves my mobile browser
>> completely unresponsive for up to a full minute every time I tap a
>> link, every time I use it".
>
> Well, if it does not target a cellphone then it probably won't be
> pleasant on a small screen anyway.

I find plain-old-desktop-HTML sites to be WAAAY more pleasant on mobile than a lot of "mobile version" sites (which tend to behave really weirdly and be slow). Even Wikipedia's "mobile" version is a pain since it keeps auto-collapsing *while* I'm in the middle of reading a paragraph and also every...single...time...I hit "back" (and therefore have to re-scroll to where I was).

On 06/19/2015 11:13 AM, Joakim wrote:
>
> 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.

We need some sort of SVG-BSON, or something along those lines.

On 06/19/2015 10:47 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>
> - Text based is extremely convenient when programming dynamic inlined
> SVG, and it compresses well (~80%)
>

So? Overly-bloated and redundant data always compresses well.

On Friday, 19 June 2015 at 15:13:11 UTC, Joakim wrote:
> asm is still supported on iOS, it's merely not the default option in Xcode anymore.

I read somewhere that it might be phased out in 1-2 years and is forbidden on iWatch.

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

Actually, it does, as the logic is moved more into elements. Like Angular and Polymer.

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

I'd think the opposite, that binary format makes sense for PDF since it is an enduser format, but it is easier to debug when text so it is probably text for the same reasons as SVG.

For SVG I want flexibility and transparency. It would be counterproductive if it was not in XML. Editing would be horrible. And yes, I edit SVG by hand, PDF too. I don't think I've ever used SVG or built PDF generators without manually editing either format as raw text.

> Because writing it once in HTML/CSS/JS takes you much longer than writing it in Java, while being less responsive, then you

Dunno about less responsive. Java apps often feel more sluggish than well written web apps. Java is probably better for larger programs, but most programs aren't large. Many programs are just simple interfaces to online databases.

On 06/19/2015 04:08 AM, Kagamin wrote:
>
> Native: write three times in obj-c, java, c#.

That's just simply 100% not true at all. I really don't know where you're getting that. You may need a few bindings to those different languages at the boundaries where your app talks to the underlying platform, but that's it.

On Friday, 19 June 2015 at 15:38:50 UTC, Nick Sabalausky wrote:
> On 06/19/2015 03:51 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> On Friday, 19 June 2015 at 06:30:30 UTC, Nick Sabalausky wrote:
>>> If by "instant" you mean "this web 'app' leaves my mobile browser
>>> completely unresponsive for up to a full minute every time I tap a
>>> link, every time I use it".
>>
>> Well, if it does not target a cellphone then it probably won't be
>> pleasant on a small screen anyway.
>
> I find plain-old-desktop-HTML sites to be WAAAY more pleasant on mobile than a lot of "mobile version" sites (which tend to behave really weirdly and be slow). Even Wikipedia's "mobile" version is a pain since it keeps auto-collapsing *while* I'm in the middle of reading a paragraph and also every...single...time...I hit "back" (and therefore have to re-scroll to where I was).

I usually click on the "Request Desktop Site" option in Chrome, particularly on my tablet, where I do most of my mobile browsing.  Wikipedia's collapsed sections on mobile never seemed like a good idea, but I think they're rolling back some of that, at least on tablets.

The worst part is the new "mobile-ready" versions of many websites, the ones with the giant bar at the top with the hamburger menu at the top left, are somehow so bloated that they regularly slow down my core i5 ultrabook, with a single browser tab ballooning up to 500-600 MBs on a particularly egregious WP blog.  I can only imagine how they perform on actual mobile devices! :D Not to mention those UIs are horrible for a regular desktop monitor, with giant swathes of pixels eaten up by "touch-friendly" menus that are useless on my non-touch LCD screen, yet they're apparently incapable of detecting that and scaling down the UI for non-touch screens.

On Friday, 19 June 2015 at 15:45:20 UTC, Nick Sabalausky wrote:
> On 06/19/2015 11:13 AM, Joakim wrote:
>>
>> 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.
>
> We need some sort of SVG-BSON, or something along those lines.

It exists!  Likely just a lightly modified version of the binary XML efforts though:

http://www.svgopen.org/2005/paperAbstracts/IntroducingBinarySVG.html

And judging by the few and old links to that effort, looks like it didn't get very far.

On Friday, 19 June 2015 at 15:49:04 UTC, Nick Sabalausky wrote:
> On 06/19/2015 10:47 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>
>> - Text based is extremely convenient when programming dynamic inlined
>> SVG, and it compresses well (~80%)
>>
>
> So? Overly-bloated and redundant data always compresses well.

I don't find size to be a big deal.  I want to keep the shapes simple to not overload the renderer anyway.

The fact that it is embedded in the HTML5 source means it saves a roundtrip. The fact that it is text means I can easily add dynamic styling to it and more.

On 06/19/2015 11:52 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>
> Dunno about less responsive. Java apps often feel more sluggish than
> well written web apps.

I've *never* found that to be true, and I'm someone who's always found Java to be sluggish.

But web apps, even the better ones, just reinvent a whole new level of sluggish. Even just tying into a comment box on GitHub is frequently laggy to the point of being completely unsusable, and that's even on up-to-date firefox (I usually write in LibreOffice and copy/paste to GitHub). There's no excuse for that level of bloat. My freaking Apple 2 didn't have text-entry lag.

On Friday, 19 June 2015 at 16:05:50 UTC, Nick Sabalausky wrote:
> I've *never* found that to be true, and I'm someone who's always found Java to be sluggish.

Really? A well written web app of the simpler kind will be dominated by C/C++ code in the browser, not javascript.

Of course, many web programmers add cruft and don't really understand what is going on.