On Friday, 19 June 2015 at 06:30:30 UTC, Nick Sabalausky wrote:
> Form factors and web standards compliance both vary wildly, rendering it "write once, TEST everywhere". That's all the more true if you go all HTML5, web-as-an-applications-platform.

Testing is a factor, but there are compliance references on the net. And it is getting better, much better.

Every once in a while I have to fix an issue after deployment, usually a visual bug in a new browser for which I can find a workaround quickly by searching the web.

> 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. Mobile Chrome and latest Safari are pretty good, aren't they?

>> Polymer, web components.
>>
>
> Exactly. Piling more stuff on top. ;)
>
> http://www.quirksmode.org/blog/archives/2015/05/tools_dont_solv.html

Neh, I prefer rolling my own, but it is more expensive than a well designed reusable widgets for things like admin interfaces. The problem is Javascript, which don't provide the right abstractions. But there are alternatives (Dart, TypeScript etc)

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.

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

On 18 June 2015 at 18:07, Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 18/06/2015 8:05 p.m., John Colvin wrote:
>>
>> This appears to have involvement from all major browser vendors, which provides hope it might actually catch on properly. An llvm backend will be created which will compile to "wasm", hopefully LDC and/or SDC could glue to this.
>>
>> https://www.w3.org/community/webassembly/
>>
>> https://github.com/WebAssembly
>>
>> In particular, see https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/FAQ.md and https://github.com/WebAssembly/design/blob/master/MVP.md
>
>
> I saw it.
> I'm waiting for some sort of spec or example toolchain.
>
> Once we have that I'd be willing to work on bindings and tutorial for it. I honestly see no reason to not add it as a targetType to dub. Would be pretty awesome to write both client side and server in D using it.

We could *really* do with an Emscripten or NaCl toolchain in the mean time! :)
We have commercial products in those platforms, and we'd *love* to use
D at work, but support for those 'platforms' is the key thing holding
us back.

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.

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

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

-Wyatt

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

web: write once with html, css, js and lag on everything that isn't a supercomputer.

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

SVG is factually a reasonably good format.

- XML is the best deal since it allows mixing formats both in terms of attributes and elements. Critically important and frequently used feature.

- Text based is extremely convenient when programming dynamic inlined SVG, and it compresses well (~80%)

- SVG animation is based on SMIL, so it was based on an existing standard which is quite ok for what it does.

Do you guys have any real arguments against SVG? It is currently the most useful interchangeformat for 2D vector graphics.

On Friday, 19 June 2015 at 14:23:54 UTC, weaselcat wrote:
> web: write once with html, css, js and lag on everything that isn't a supercomputer.

I wrote a web application with ajax, xml, xslt and all sorts of dhtml, it was working instantly. Well, it had to cruft like jquery, and problems like this http://www.quirksmode.org/blog/archives/2015/05/tools_dont_solv.html and http://www.quirksmode.org/blog/archives/2015/05/web_vs_native_l.html never occurred to me. Why one would use things like jquery, again? I didn't feel like I need some tools to get things done.

On Friday, 19 June 2015 at 14:47:32 UTC, Kagamin wrote:
> Why one would use things like jquery, again? I didn't feel like I need some tools to get things done.

I guess the primary reason to use jquery was to support IE6-8.

On Friday, 19 June 2015 at 14:47:32 UTC, Kagamin wrote:
> I wrote a web application with ajax, xml, xslt and all sorts of dhtml, it was working instantly.

On Celeron, 256MB RAM and Windows XP on top of that.

On Thursday, 18 June 2015 at 21:21:13 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 18 June 2015 at 19:39:58 UTC, Nick Sabalausky wrote:
>> Great, so it'll have the same fundamental problem as asm.js: Claims to be backwards compatible, but really isn't because the backwards fallback method is likely to be prohibitively slow and will especially fuck mobile browsers that use the fallback.
>
> Yeah. This fallback thing does not make much sense. They say WebAssembly will reduce the file size by 7% after compression compared to asm.js . Who cares?
>
In fact, _we_ do.  Our flagship product is mostly used via a web application.  Lots of Web 2.0 stuff going on there, it's pretty big.  This becomes kind of a problem when many of our customers are halfway around the world.  Even just 7% would be a win (for bandwidth and latency), but it looks like that's a low-ball estimate:
https://github.com/WebAssembly/design/blob/master/FAQ.md#can-the-polyfill-really-be-efficient

(The corollary to this is, yes, it does kind of have the same fundamental problem as asm.js.  Because it IS asm.js.)

But if the endgame becomes real and the the order-of-magnitude parsing speedup happens, it'll be kind of huge.

>> Maybe this suggestion demonstrates ignorance, but I'm thinking "They should just use LLVM IR. It already exists." Maybe toss in some LLVM IR extensions as needed, and boom, done.
>
> The LLVM IR isn't stable, so you need a higher level IR. And that's hard to design. So maybe 5 years before they get it right, and _properly_ implemented, in all browsers?
>
They covered this, too:
https://github.com/WebAssembly/design/blob/master/FAQ.md#why-not-just-use-llvm-bitcode-as-a-binary-format

-Wyatt