www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D could catch this wave: web assembly

reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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
Jun 18 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Jun 18 2015
next sibling parent "Adrian Matoga" <epi atari8.info> writes:
On Thursday, 18 June 2015 at 08:07:47 UTC, Rikki Cattermole wrote:

 Would be pretty awesome to write both client side and server in 
 D using it.
I just found about WebAssembly while having lunch and that was exactly my thought.
Jun 18 2015
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Jun 19 2015
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 18 June 2015 at 08:05:48 UTC, 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
Sigh, another attempt to sneak native code into the browser, rather than just admitting that the web stack blows. I have to admit I was hopeful about NaCl, but it appears to have gone nowhere. Why can't they just admit that the core architecture of the web is horrific, ie an antiquated document format based on some shitty 50-year old IBM markup language (https://en.wikipedia.org/?title=Standard_Generalized_Markup_Language), a programming runtime that was cranked out in 10 days in the middle of the browser wars and certainly shows it (https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_JavaScript), and a stylesheet language hacked on top to eliminate some redundancy, _by adding yet another language_?! 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 But what do they do instead of starting anew? Keep rearranging the deck chairs on the Titanic. "Maybe if we fly in and install a new engine, it won't sink?!" endRant();
Jun 18 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 18 June 2015 at 10:36:16 UTC, Joakim wrote:
 On Thursday, 18 June 2015 at 08:05:48 UTC, John Colvin wrote:
 [...]
Sigh, another attempt to sneak native code into the browser, rather than just admitting that the web stack blows. I have to admit I was hopeful about NaCl, but it appears to have gone nowhere. [...]
afaik this is backed heavily by pnacl authors
Jun 18 2015
prev sibling next sibling parent reply "Abdulhaq" <alynch4047 gmail.com> writes:
On Thursday, 18 June 2015 at 10:36:16 UTC, Joakim wrote:

 Why can't they just admit that the core architecture of the web 
 is horrific, ie an antiquated document format based on some 
 shitty 50-year old IBM markup language 
 (https://en.wikipedia.org/?title=Standard_Generalized_Markup_Language), a
programming runtime that was cranked out in 10 days in the middle of the
browser wars and certainly shows it
(https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_JavaScript), and a
stylesheet language hacked on top to eliminate some redundancy, _by adding yet
another language_?!
Of course this is exactly true and it drives me mad too, but you can't just jettison it in favour of a better architecture. Given that it must be supported else it will break the interweb, what else is there to do but do but to build the new stuff on the side. With a canvas, OpenGL backing and a half-decent 'assembly language' to compile down to, it could be made into (ultimately) a satisfactory development platform. You would only need to use DOM and CSS for the top canvas/OpenGL node and from there down it's all however you want to roll it. As for performance then granted it seems bizarre to require all these layers below, but I remember watching a very interesting video about how running on the OS is subject to large overheads in the kernel, while running in the browser can bypass that and hence is not such a performance drop as you might expect - unfortunatel I can't dig up the link.
Jun 18 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 18 June 2015 at 18:30:24 UTC, Abdulhaq wrote:
 On Thursday, 18 June 2015 at 10:36:16 UTC, Joakim wrote:

 Why can't they just admit that the core architecture of the 
 web is horrific, ie an antiquated document format based on 
 some shitty 50-year old IBM markup language 
 (https://en.wikipedia.org/?title=Standard_Generalized_Markup_Language), a
programming runtime that was cranked out in 10 days in the middle of the
browser wars and certainly shows it
(https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_JavaScript), and a
stylesheet language hacked on top to eliminate some redundancy, _by adding yet
another language_?!
Of course this is exactly true and it drives me mad too, but you can't just jettison it in favour of a better architecture.
Why not? This is exactly what _should_ be done.
 Given that it must be supported else it will break the 
 interweb, what else is there to do but do but to build the new 
 stuff on the side. With a canvas, OpenGL backing and a 
 half-decent 'assembly language' to compile down to, it could be 
 made into (ultimately) a satisfactory development platform. You 
 would only need to use DOM and CSS for the top canvas/OpenGL 
 node and from there down it's all however you want to roll it.
I think the reason these efforts have failed so far is because NaCl was still stuck using the existing web stack for the GUI, which is a huge pain. But if you're just going to avoid the old web stack altogether and try to deploy your canvas/WebGL/assembly native app everywhere using the web browser as a trojan horse, presumably just to get through security or evade sysadmins more easily, you have to question what the point of making it a "web app" even is. And this new stuff isn't integrated, I believe canvas doesn't even support hyperlinks. How is that not broken already? There appears to be little to no thought put into all these new APIs that are simply mashed into the browser. A vector graphics format encoded in text, let alone XML? Yeah, because what I really wanted to do is read bezier curve descriptions in plain text interspersed with hundreds of angle brackets and quotation marks! Throw that in the browser! http://www.w3.org/TR/SVG/paths.html XSLT? Why not?! Throw that shit with libxml in the browser too, along with all their bugs! http://neugierig.org/software/chromium/notes/2010/06/roman-numerals.html If you didn't read Bray's piece I linked above, his conclusion is dead on: "Historical periods featuring rococo engineering outbursts of colorful duplicative complexity usually end up converging on something simpler that hits the right 80/20 points." On Thursday, 18 June 2015 at 18:40:50 UTC, Max Samukha wrote:
 On Thursday, 18 June 2015 at 11:00:37 UTC, ketmar wrote:

 piles of shit on top of piles of shit
A good definition of evolution.
Except evolution actually weeds out the crap, as Linus knows: http://bobweigel.net/projects/index.php?title=Weigel/Notes#Linus_on_Development What we have here is peacocks on some tropical island- only sustained because all the major browser vendors are now OS vendors, Apple, Microsoft, Google, who either don't want the web to replace their OS APIs or have no idea how to make it better- heading down Bray's "colorful" evolutionary dead-ends before they're finally wiped out.
Jun 18 2015
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 18 June 2015 at 19:23:26 UTC, Joakim wrote:
 On Thursday, 18 June 2015 at 18:30:24 UTC, Abdulhaq wrote:
 Of course this is exactly true and it drives me mad too, but 
 you can't just jettison it in favour of a better architecture.
Why not? This is exactly what _should_ be done.
Same reason you can't just stick your head in the sand and pretend the entire existing body of C and C++ code doesn't exist. It sucks, but them's the breaks.
 I think the reason these efforts have failed so far is because 
 NaCl was still stuck using the existing web stack for the GUI,
NaCl failed because it required a plugin, and did so in a way that made it exclusive to one browser vendor. It's like Java only worse. Or that thrice-be-damned Flash.
 But if you're just going to avoid the old web stack altogether 
 and try to deploy your canvas/WebGL/assembly native app 
 everywhere using the web browser as a trojan horse, presumably 
 just to get through security or evade sysadmins more easily, 
 you have to question what the point of making it a "web app" 
 even is.
The point is it runs in a browser. Do you need a more compelling feature than the ability to run unchanged anywhere there's a browser (basically everywhere)? I mean, I too think most of this "web technology" is trash and really wish the lingua fraca of the Internet wasn't awful-- I would love for text to be foremost and for progressive enhancement to fall back to a normal web site when I visit with elinks. But realistically? This is a damn sight better than any of the other attempts so far because it's just a new feature in the JS VM. If it means we can lower code in a proper language to something a browser can run at something resembling the speed of an ordinary scripting language, it'll be a win already.
 And this new stuff isn't integrated, I believe canvas doesn't 
 even support hyperlinks.  How is that not broken already?
Look, I don't fundamentally disagree that this all sucks but dude, chill. Here, go play some Oregon Trail: https://archive.org/details/msdos_Oregon_Trail_The_1990 ;)
 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 -Wyatt
Jun 18 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 18 June 2015 at 21:15:35 UTC, Wyatt wrote:
 SVG has animation, input handling, and an audio API(!) and you 
 take issue with paths?  Weeeeeak. :P
I remember demoing inline SVG with animation for students around 2003 as a useful upcoming technology. I got to use it in production around 2013… on some browsers… Oh, it is a W3C standard now? Cool, oh, I look so much forward to using it… It is right around the corner, like… in-12-years-right-around-the-cornerish.
Jun 18 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 18 June 2015 at 21:15:35 UTC, Wyatt wrote:
 On Thursday, 18 June 2015 at 19:23:26 UTC, Joakim wrote:
 On Thursday, 18 June 2015 at 18:30:24 UTC, Abdulhaq wrote:
 Of course this is exactly true and it drives me mad too, but 
 you can't just jettison it in favour of a better architecture.
Why not? This is exactly what _should_ be done.
Same reason you can't just stick your head in the sand and pretend the entire existing body of C and C++ code doesn't exist. It sucks, but them's the breaks.
The difference is that "existing body of C and C++ code" actually does something and works. The existing web stuff is just GUI markup, that as Bray notes never quite works, so it can easily be ditched. It is _already_ being ditched, for native mobile UIs. I know of major shopping websites in developing markets that have shut down their mobile websites in favor of their mobile apps. It's just too much of a pain to keep the web frontend going.
 I think the reason these efforts have failed so far is because 
 NaCl was still stuck using the existing web stack for the GUI,
NaCl failed because it required a plugin, and did so in a way that made it exclusive to one browser vendor. It's like Java only worse. Or that thrice-be-damned Flash.
No, NaCl has been built into Chrome, one of the major browsers, for a while. I believe it could be used to secure plugins, but did not require you to install one. At least, I've certainly used it without receiving a plugin prompt. And Java and Flash were ubiquitous at one point in their histories.
 But if you're just going to avoid the old web stack altogether 
 and try to deploy your canvas/WebGL/assembly native app 
 everywhere using the web browser as a trojan horse, presumably 
 just to get through security or evade sysadmins more easily, 
 you have to question what the point of making it a "web app" 
 even is.
The point is it runs in a browser. Do you need a more compelling feature than the ability to run unchanged anywhere there's a browser (basically everywhere)? I mean, I too think
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? ;)
 most of this "web technology" is trash and really wish the 
 lingua fraca of the Internet wasn't awful--  I would love for 
 text to be foremost and for progressive enhancement to fall 
 back to a normal web site when I visit with elinks.
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.
 But realistically? This is a damn sight better than any of the 
 other attempts so far because it's just a new feature in the JS 
 VM.  If it means we can lower code in a proper language to 
 something a browser can run at something resembling the speed 
 of an ordinary scripting language, it'll be a win already.
I agree that if webasm finally delivers on the promise of NaCl, which I said I was hopeful for, it will be a worthwhile improvement. If it means you can avoid writing javascript entirely and get decent performance, it is definitely a big win.
 And this new stuff isn't integrated, I believe canvas doesn't 
 even support hyperlinks.  How is that not broken already?
Look, I don't fundamentally disagree that this all sucks but dude, chill. Here, go play some Oregon Trail: https://archive.org/details/msdos_Oregon_Trail_The_1990 ;)
Nah, time to break it.
 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.
Jun 18 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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. - Want asm on iOS? Woops, no more, moving to LLVM. - New version of iOS? Gotta update the app to stay fresh. 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.
 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.
 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.
Jun 18 2015
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/19/2015 01:17 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" 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. - Want asm on iOS? Woops, no more, moving to LLVM. - New version of iOS? Gotta update the app to stay fresh.
Seriously? Web is just as bad. 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.
 2. Instant access. Direct load from advertisment-link.
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".
 3. No update procedure, no lingering messed up version.
A lot of native apps have seamless updating, too. Ex: The browsers themselves. And webdevs do occasionally mess up caching.
 4. No AppStore-related censorship/constraints.

 5. No extra fees.
True (for modern mobile), although that really isn't anything inherent to "native app", as proven by desktops/laptops and pre-iOS mobiles like PalmOS. Plus, so called "side-loading" is seriously freaking easy on Android.
 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.
Exactly. Piling more stuff on top. ;) http://www.quirksmode.org/blog/archives/2015/05/tools_dont_solv.html
Jun 18 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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)
Jun 19 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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).
Jun 19 2015
parent "Joakim" <dlang joakim.fea.st> writes:
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.
Jun 19 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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 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.
Jun 19 2015
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Jun 19 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jun 19 2015
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Jun 19 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jun 19 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Friday, 19 June 2015 at 15:52:09 UTC, Ola Fosheim Grøstad 
wrote:
 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.
I probably haven't been clear enough about what I mean. The original model for the web was a bunch of hyperlinked pages/documents. But that model increasingly breaks down as you make the page more dynamic. What are you linking to anymore: a page, an app, or a widget within the app? Now you have to freeze all state within an app then link to it, like the generated links on Google Maps or when you save a document in Word. As the browser tries to mesh these two worlds, the old-fashioned static hyperlinked pages and the new dynamic widgets of AJAX and HTML5, rifts crop up. The recent web components efforts you highlight do not address this at all, they merely make it easier to build more dynamic webapps. But in doing so, they actually bring the problems I'm talking about more to the fore.
 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.
My point was that text makes some sense for the layout of a document format, but efficiency is key in vector graphics, so you always want to go binary there.
 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.
Then have SVG be an authoring format that is subsequently "compiled" down to an efficient binary encoding for distribution. There is _zero_ reason for text SVG to be the actual end-user format. I bet a lot of the bloat issues that Wyatt pointed out are exactly because of this.
 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 mobile devices, I've been hit by plenty of sluggishness from both, just more so in the browser. 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. That's usually related to tiny text, but that affects the overall layout too.
 I didn't really try to write java, but my impression is that 
 java usually requires huge amounts of boilerplate code, while 
 web is usually succinct.
I don't find HTML/CSS/JS succinct or easy to get right, the latter of which writing a Java/Android UI is at least better at. Of course, the Android devs had to go muff that up by adding XML into the mix.
 Dunno, I don't see there losses, maybe because they only happen 
 on mobile. Yeah, you said nothing about how this is related to 
 desktop as if it doesn't exist.
Pretty soon it won't. :) There are an estimated 2.5 billion smartphone users: http://www.asymco.com/2014/04/07/postmodern-computing/ The highest estimates of desktop and laptop users I've seen don't crack 2 billion. That means desktops are already a minority platform. 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. 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.
Jun 20 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 20 June 2015 at 19:00:08 UTC, Joakim wrote:
 I probably haven't been clear enough about what I mean.  The 
 original model for the web was a bunch of hyperlinked 
 pages/documents.  But that model increasingly breaks down as 
 you make the page more dynamic.  What are you linking to 
 anymore: a page, an app, or a widget within the app?
Yes, but would it be better to just have pages and no apps? I don't think so. When I build an order system it is very useful to build it like an app. The fact is that networking bandwidth is now so large that you often can download the catalog for an online shop at once, compressed it is the size of an image... Of course, the app programmer will have to decide how that maps to urls, or if it should map to urls. You can do it with the hash-tag or by changing the visible url without reloading (on modern browsers). I do that if it is important.
 widgets of AJAX and HTML5, rifts crop up.  The recent web 
 components efforts you highlight do not address this at all, 
 they merely make it easier to build more dynamic webapps.
It kinda does. Because you can then serve pages with markup that do things that are specific for the site. When you can attach behaviour to tags implicitly you get to build your own markup-language for the site.
 My point was that text makes some sense for the layout of a 
 document format, but efficiency is key in vector graphics, so 
 you always want to go binary there.
If the vector graphic is intricate it will take time to render it. So there is a limit to how much data you want, I don't think text-transmission is the main issue.
 Then have SVG be an authoring format that is subsequently 
 "compiled" down to an efficient binary encoding for 
 distribution. There is _zero_ reason for text SVG to be the 
 actual end-user format.  I bet a lot of the bloat issues that 
 Wyatt pointed out are exactly because of this.
You can do that if you want. Just download binary data and plot it to a canvas. But there is no way you could introduce binary SVG when using SVG dynamically. That would require specialized binary-format editors for both SVG and HTML. You would basically want binary HTML too, then.
Jun 20 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Saturday, 20 June 2015 at 19:39:06 UTC, Ola Fosheim Grøstad 
wrote:
 Yes, but would it be better to just have pages and no apps? I 
 don't think so. When I build an order system it is very useful 
 to build it like an app.
No, I'm not arguing for pages at all, I'm saying that model is dead and gone. I think the hyperlink was the killer feature of the web, but everything else, HTML/CSS/JS, is just detritus accumulated on top, that needs to be thrown away.
 The fact is that networking bandwidth is now so large that you 
 often can download the catalog for an online shop at once, 
 compressed it is the size of an image...
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.
 widgets of AJAX and HTML5, rifts crop up.  The recent web 
 components efforts you highlight do not address this at all, 
 they merely make it easier to build more dynamic webapps.
It kinda does. Because you can then serve pages with markup that do things that are specific for the site. When you can attach behaviour to tags implicitly you get to build your own markup-language for the site.
Again, none of this helps with the fundamental problem: you are engineering an app UI layout engine into an old-fashioned document format. You are always going to be constrained by the architectural constraints and inefficiency of the document format.
 My point was that text makes some sense for the layout of a 
 document format, but efficiency is key in vector graphics, so 
 you always want to go binary there.
If the vector graphic is intricate it will take time to render it. So there is a limit to how much data you want, I don't think text-transmission is the main issue.
Text compression will get you part of the way to lessening the bandwidth, but parsing and analyzing the SVG text will always take longer than if it were binary. I have not actually profiled an SVG renderer to see where the bottleneck is, but I bet using text plays a big role.
 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.
 But there is no way you could introduce binary SVG when using 
 SVG dynamically. That would require specialized binary-format 
 editors for both SVG and HTML. You would basically want binary 
 HTML too, then.
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." However, I have long said that they should have tightened up HTML into a binary format around HTML 3 or so, so that needed to be done on its own anyway. On Saturday, 20 June 2015 at 20:31:35 UTC, Nick Sabalausky wrote:
 An excellent example of this is sites like github that actually 
 manage to break the "back" button, even though it's *clearly* a 
 page-based site (that somehow doesn't seem to believe it is).
Heh, you don't know how many times that's hit me. :)
 "Smart" TVs also have trouble there:

 http://www.quirksmode.org/blog/archives/2014/07/samsung_smart_t.html
Heh, I have never tried to use a browser on a TV, especially since I basically haven't watched a TV screen in the last decade, maybe a couple hours of sports a year. I just download the same or other online videos and watch them on my computer or mobile devices.
 (See the section "The viewport", just underneath the photo with 
 a phone held in front of a TV. Erm...speaking of which: 
 <https://semitwist.com/articles/article/view/html-fragment-linking-is-stupid-here-s-the-fix>)
Hmm, I had not heard of that fragment linking effort you wrote about. I agree that in the old page model it'd be better if the user decides what he wants to link to, but in the new dynamic model, that is very hard to implement.
 Pretty soon it won't. :) There are an estimated 2.5 billion 
 smartphone
 users:

 http://www.asymco.com/2014/04/07/postmodern-computing/

 The highest estimates of desktop and laptop users I've seen 
 don't crack
 2 billion.  That means desktops are already a minority 
 platform.
People have been looking at the sales trends and predicting for years that mobile will kill of PCs. And all that happened (unsurprisingly, IMO) is that the decline in PC sales simply leveled off.
Still declining though, just less than it was: http://www.asymco.com/2014/07/23/is-the-pc-back/ I'd say this is a temporary respite before the final collapse. The only reason it hasn't happened yet is because mobile devices have not worked well with plugging into a large monitor with a mouse and keyboard, but that is now changing.
 Mobile will not, and cannot, replace traditional 
 laptops/desktops (as opposed to merely cooexisting with them as 
 is the case right now) until if/when they finally incorporate 
 all the usability and features of laptops/desktops. Obviously 
 they're not there right *now* yet. But as for the future...
Sure, but current mobile hardware is about as powerful as desktop/laptop chips from a year or two ago, which is what most people are actually running at work: http://www.anandtech.com/show/9289/the-nvidia-shield-android-tv-review/3 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.
 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.

 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.
I don't think "phones/tablets replacing desktops/laptops" is an entirely accurate way of describing how that will happen (if it does). More like "phones/tablets and desktops/laptops will converge into a hybrid".
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. 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.
 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.
 MS, oddly enough, seems to have the highest chance of 
 succeeding at this, as desktop/mobile convergence has been 
 their big goal since Win8. And then Win9 (erm, I mean 10) 
 cleans up some of the mess Win8 left. (Not that I like metro or 
 what the metro "theme" has done to the desktop side of windows, 
 even in Win9^H10, but that's beside the point here.)
They certainly seemed to start on it first, but screwed it up in some key ways. Not allowing the desktop on Windows RT was a big mistake, which they appear to be sort of remedying with their recent Continuum/Universal-app moves. Ironically, this was one of the few cases when Microsoft was too early, because mobile devices were probably not powerful enough when Windows 8 came out three years ago.
 Interestingly, Canonical could've beat everyone to the punch 
 here. They had what was basically "continuum for linux" more or 
 less already working, but then...they just...what, threw it in 
 the trash bin or something? I dunno, I don't quite get 
 Canonical sometimes.
I get the sense that they're a small organization that bit off something way too big for them.
Jun 20 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 21 June 2015 at 05:42:13 UTC, Joakim wrote:
 No, I'm not arguing for pages at all, I'm saying that model is 
 dead and gone.  I think the hyperlink was the killer feature of 
 the web, but everything else, HTML/CSS/JS, is just detritus 
 accumulated on top, that needs to be thrown away.
Thrown away in favour of what? You need a scene-graph / DOM. CSS makes design much easier than the alternative. JS is evolving into something close to TypeScript.
 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.
 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. 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.
 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. 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. 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).
 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. I would have preferred something closer to Microsoft VML which made the vector-graphics part of HTML so that you could just insert a circle anywhere on the screen. But I guess the SVG clip rectangle made implementation of the renderer a lot easier.
Jun 20 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
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
 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. :)
Jun 21 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 21 June 2015 at 09:07:52 UTC, Joakim wrote:
 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.
Start from scratch, in what direction? You need a design that is generic enough, yet more productive than what exists. And then you need to wait 5 years for end users to install the viewers, before you can use it. I don't see native apps winning over the browser based apps. Only in very limited domains, of daily use (like purchasing tickets), but for non-technical reasons. And let's face it, many "native" apps are 50% browser based, just wrapped up in a shell. They use the HTML5 web-view. Because it is easier and performs well enough.
 think about how you want to do it.  Simply dumping more 
 features on top of the old web stack is a recipe for failure.
I hear you saying it, but installed base is way too important a factor to be ignored. What you can do is changing the underlying engine, but keep the compatibility.
 You need a scene-graph / DOM.
Not really, certainly not the latter if you chuck HTML/CSS/JS.
DOM is a scene-graph.
 You've got to be joking: why would anyone want to use either?
Because it is backwards compatible.
 recent years and that's about it.  If this webasm effort ever 
 got into most browsers, I guarantee that almost everybody would 

 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.
 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.
 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. The current model is quite flexible, you can mix technologies. Perhaps too flexible.
 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.
 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.
 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. In the scripting API using text as values might be an issue, but that's a different topic.
Jun 21 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
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:
 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.
Start from scratch, in what direction? You need a design that is generic enough, yet more productive than what exists.
I've sketched out one possibility in the past, with more details in subsequent comments in that thread: http://forum.dlang.org/post/dqddjhccpmxhgcssqtol forum.dlang.org Surely you could think of other approaches that would ditch the current document format also?
 And then you need to wait 5 years for end users to install the 
 viewers, before you can use it.
Not necessarily, you'd probably start by simply linking your app into the viewer, ie using it just like any other UI toolkit library, until it became popular enough that you could separate out the viewer as its own app.
 I don't see native apps winning over the browser based apps. 
 Only in very limited domains, of daily use (like purchasing 
 tickets), but for non-technical reasons.
I think you are complete ignoring the current mobile app wave then. There are plenty of valid technical reasons why web-centric organizations like Facebook tried to use HTML5 for their initial mobile apps but then had to backtrack to native mobile apps.
 And let's face it, many "native" apps are 50% browser based, 
 just wrapped up in a shell. They use the HTML5 web-view. 
 Because it is easier and performs well enough.
More likely because they already built a simple webapp and don't want to duplicate effort. These are the low-end apps that started on the web, whereas those that start on mobile now often don't even bother with a webapp.
 think about how you want to do it.  Simply dumping more 
 features on top of the old web stack is a recipe for failure.
I hear you saying it, but installed base is way too important a factor to be ignored. What you can do is changing the underlying engine, but keep the compatibility.
Browser install base is overrated in this day and age when people install apps aplenty and easily from mobile app stores. They've been trying to change the underlying engine for a couple decades now and haven't gotten very far.
 You need a scene-graph / DOM.
Not really, certainly not the latter if you chuck HTML/CSS/JS.
DOM is a scene-graph.
Which is why I said you could chuck the DOM, but probably want some simpler kind of scene graph instead.
 You've got to be joking: why would anyone want to use either?
Because it is backwards compatible.
You were arguing that it wasn't that bad. If the only reason you can give is because it's legacy tech, you just argued against yourself. :)
 recent years and that's about it.  If this webasm effort ever 
 got into most browsers, I guarantee that almost everybody 

 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 ca
Jun 21 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
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 

 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.
Jun 21 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Sunday, 21 June 2015 at 11:56:13 UTC, Joakim wrote:
 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.
You mean services?
 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.
Huh? Cultural clusters like nation, country clusters. If you make US-oriented news service, you can't target even EU users not speaking about China.
 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? ;)
And how do they differ?
 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.
Yes, if smartphones do that, they will become desktop.
 So yes, the desktop UI is a niche, but a moderately large niche 
 that is about to move to mobile devices also.
Yes, but your claim is that desktop will die, not move.
 devs are certainly not dealing with that complexity at all.
Yes, that's the problem with web: devs can't get web right for decades already, that's also one of the reasons for mobile apps to exist.
Jun 21 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 21 June 2015 at 13:51:06 UTC, Kagamin wrote:
 On Sunday, 21 June 2015 at 11:56:13 UTC, Joakim wrote:
 Apparently most new apps nowadays are ignoring that legacy 
 desktop market.
You mean services?
I meant mobile apps, many of which are services, but even stand-alone apps with no network component.
 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.
Huh? Cultural clusters like nation, country clusters. If you make US-oriented news service, you can't target even EU users not speaking about China.
Sorry, I didn't read the conclusion of that link I gave you: I just linked it for the large graph showing and forecasting the number of global smartphone users. I based my response just on your comment and thought you meant a culture for desktop apps vs. another for mobile apps. If you're talking about geographical cultural clusters, I agree that services are getting more fragmented as the rest of the world comes online, and since those mobile devices and services are killing off the desktop, that global desktop app market is going away.
 That's like saying current PCs are "mainframes for all 
 practical purposes, just more constrained in resources," you 
 honestly believe that too? ;)
And how do they differ?
That doesn't answer my question. :) As for yours, well, for one, a program written for an AIX POWER mainframe isn't going to run unmodified on a PC. It's not going to have a desktop UI either. They're considered completely different categories of computers, even though they're all computers.
 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.
Yes, if smartphones do that, they will become desktop.
I see, so if I start transcribing a novel by voice to the on-board computer in my car on the way to work every day, it becomes a desktop, because I'd have previously written it up in desktop Word? Just because a device takes on some functions that you previously did with a desktop doesn't make it a desktop.
 So yes, the desktop UI is a niche, but a moderately large 
 niche that is about to move to mobile devices also.
Yes, but your claim is that desktop will die, not move.
I was very specific in my claims, at least to Nick above. I said the desktop/laptop form factors and OSs will die out, but multi-window UIs similar to desktop UIs will live on. That is _not_ the desktop moving on, only something like its UI.
 devs are certainly not dealing with that complexity at all.
Yes, that's the problem with web: devs can't get web right for decades already, that's also one of the reasons for mobile apps to exist.
I was talking about both web and native here. High-DPI resolutions have caused me problems with native desktop and mobile apps also. Windows seemed to come particularly late to handling those better. As for the web, anytime you get outside trivial layouts, it gets fairly complex quickly, particularly for cross-browser compatibility. The web stack of HTML/CSS/JS is just not well-suited for app UIs.
Jun 21 2015
parent "Kagamin" <spam here.lot> writes:
On Sunday, 21 June 2015 at 14:46:56 UTC, Joakim wrote:
 Sorry, I didn't read the conclusion of that link I gave you: I 
 just linked it for the large graph showing and forecasting the 
 number of global smartphone users.
Well, people upgrade their phones and there were a lot of phone users.
 That's like saying current PCs are "mainframes for all 
 practical purposes, just more constrained in resources," you 
 honestly believe that too? ;)
And how do they differ?
That doesn't answer my question. :) As for yours, well, for one, a program written for an AIX POWER mainframe isn't going to run unmodified on a PC.
All platforms have incompatibilities, it's not an exclusively mainframe feature.
 It's not going to have a desktop UI either.
PC has applications without a desktop UI, e.g. vibe.d.
 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.
Yes, if smartphones do that, they will become desktop.
I see, so if I start transcribing a novel by voice to the on-board computer in my car on the way to work every day, it becomes a desktop, because I'd have previously written it up in desktop Word? Just because a device takes on some functions that you previously did with a desktop doesn't make it a desktop.
Sounds more like a dictophone than a desktop.
 So yes, the desktop UI is a niche, but a moderately large 
 niche that is about to move to mobile devices also.
Yes, but your claim is that desktop will die, not move.
I was very specific in my claims, at least to Nick above. I said the desktop/laptop form factors and OSs will die out
Desktop has seen form factors and OSes die, it moved on.
Jun 23 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 21 June 2015 at 11:56:13 UTC, Joakim wrote:
 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.
People are already writing less javascript, but without a GC in webasm most languages are better of compiling to javascript or a mix.
 As for Java and Flash, they were very widely used, despite 
 being slow and in their own little world inside the browser.
They were used in very narrow domains.
 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.
Well, you can often get more done in less time by using HTML5/CSS. That's the only reason.
 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. :)
In a way, yes, but that how things grow when you have an installed base. Evergreen browsers could in theory change it, but we rely on Apple and Microsoft to update browsers for old OSes to get there.
 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.
I think the vendors have realized that they need to take babysteps in concert, because there is to much politics involved to accept a "whole-sale solution" like PNACL etc. IMO it basically means that they all want some kind of IR, but don't agree on the specifics.
 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.
Not sure what that means. You need to have a different type-system for values so that you can differentiate between units (px, em, etc).
Jun 22 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Monday, 22 June 2015 at 16:34:58 UTC, Ola Fosheim Grøstad 
wrote:
 People are already writing less javascript, but without a GC in 
 webasm most languages are better of compiling to javascript or 
 a mix.
The problem is that they may be writing less javascript now, but they're still stuck with the performance of javascript, as they're just compiling to javascript. Webasm making that faster and allowing more languages should change that equation much more. As for a GC, why would webasm need to provide one? I'd think the languages would just be able to compile their own GC to webasm, which seems low-level enough.
 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. :)
In a way, yes, but that how things grow when you have an installed base. Evergreen browsers could in theory change it, but we rely on Apple and Microsoft to update browsers for old OSes to get there.
This is nonsense. They're just dumping in everything they can think of, that has nothing to do with backwards-compatibility.
 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.
I think the vendors have realized that they need to take babysteps in concert, because there is to much politics involved to accept a "whole-sale solution" like PNACL etc.
PNaCl is bitcode too.
 IMO it basically means that they all want some kind of IR, but 
 don't agree on the specifics.
That doesn't answer the question of why they're using a bitcode and not a textual IR, as you prefer text for SVG.
 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.
Not sure what that means. You need to have a different type-system for values so that you can differentiate between units (px, em, etc).
I thought you were saying that javascript would have trouble interacting with a binary SVG, which isn't necessarily the case, but maybe you meant something different. On Monday, 22 June 2015 at 16:34:58 UTC, Nick Sabalausky wrote:
 On 06/22/2015 05:16 AM, Joakim wrote:
 I really liked the new Fisher-Price style of desktop Windows
8, Ugh, now *that* one I don't like. Simplicity is nice, but ugly is just ugly. It looks like a re-imagining of Win1 and Win2 drawn up by a hung-over unicorn ;)
Sounds good to me, :) I like the simplicity.
 On Sunday, 21 June 2015 at 18:51:41 UTC, Nick Sabalausky wrote:
 Not if you're just reinventing the form factor by propping up 
 your
 monitor^H^H^H^H^H^H^Htablet and pulling out a keyboard+mouse.

 It's just the particular lineage that (might) go away.
Heh, you're really reaching now. :) Most people wouldn't call a smartphone or tablet in a dock "reinventing the [desktop] form factor."
Of course they won't *call* it that, because they're easily swayed by image and marketing. People refer to iPhone and such as "phones" even though they're obviously much more of a pocket computer (that happens to support cellular communications) than a telephone.
No, it's because that's what the form-factor is and they can see it with their plain eyes, without having an axe to grind.
 Hmmm, you're still outright ignoring most of what I've said 
 about that. I'll repeat myself only one more time:

 "PARTLY because connecting keyboard/mouse is not something 
 people have normally done with smartphones (at least not 
 typically). And ALSO because the gap in processing power is 
 shrinking. And ALSO because you can now connect them to an 
 external monitor. And ALSO because they're gaining desktop UIs. 
 And ALSO misc other stuff."

 Stop picking ONE aspect of all that and pretending my argument 
 revolves purely around that one aspect alone.
---snip---
 *One* feature? No. At least one *MORE* feature.

 That's on top of everything they've already borrowed. You're 
 acting as if smartphones have ALWAYS had host-USB, HDMI-out, 
 processors that approach PC-level power, storage that 
 approaches low-end laptops, multi-processing, commonly getting 
 used with an external keyboard/mouse, etc. A lot of the 
 convergence has *already* been happening, and you never even 
 noticed ;) In fact that's WHY people are starting to notice 
 their potential for replacing traditional PCs.
The problem with mentioning aspects like employing a keyboard and monitor, or the speed and size of the chip or storage, multi-processing, various I/O ports, and so on is that most computers, of many different kinds, always had those. So if you're going to mention those, what you're really saying is that there's no such thing as a desktop or laptop and since the first computers were mainframes, a desktop is really a smaller mainframe, a laptop is a more portable mainframe, and mobile devices are really just very small, very portable mainframes. :D What _differentiates_ a desktop from other computers is the form factor, the software stack commonly used, certain hardware features that they're known for, like x86, and multi-window UIs. On all those counts but the last, mobile devices are completely different, so it's silly to say they're desktops or that they "converged" in any meaningful way other than the UI. But if you have some emotional connection with the term "desktop" and can't take the fact that they're being rendered defunct, I can see why you'd want to ignore all that and just call the new devices "converged" or "desktops." :)
 I've done so already. It's absolutely terrible. At best, it's 
 an occasional replacement for those already-horrid 
 mini-touchscreen-keyboards (which almost anything is better 
 than).
I've been surprised on the few occasions I used google's voice translation about how good it was, but I haven't use it much.
 You and Kagamin seem really bent out of shape by the desktop 
 being
 junked, for some personal reasons of your own, so I'll leave 
 that "Is a
 smartphone really a desktop once it adds a multi-window UI" 
 argument
 here.  I've made my viewpoint clear.
No, we just don't like making points that only get conveniently ignored or twisted around.
Or your position makes no sense and that's all I'm pointing out. On Tuesday, 23 June 2015 at 09:44:19 UTC, Kagamin wrote:
 On Sunday, 21 June 2015 at 14:46:56 UTC, Joakim wrote:
 Sorry, I didn't read the conclusion of that link I gave you: I 
 just linked it for the large graph showing and forecasting the 
 number of global smartphone users.
Well, people upgrade their phones and there were a lot of phone users.
That chart shows current smartphone _users_, not total smartphones bought.
 Desktop has seen form factors and OSes die, it moved on.
I think what you mean is that "mainframes" have "seen form factors and OSes die, it moved on." :)
Jun 23 2015
next sibling parent reply "Suliman" <evermind live.ru> writes:
Am I right understand that web assembly would not completely new 
technology and would be just evolution of asm.js, so all of 
webassembly apps would run in old javascript virtual machine?
Jun 23 2015
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Tuesday, 23 June 2015 at 11:37:41 UTC, Suliman wrote:
 Am I right understand that web assembly would not completely 
 new technology and would be just evolution of asm.js, so all of 
 webassembly apps would run in old javascript virtual machine?
They covered this question in the FAQ, too: https://github.com/WebAssembly/design/blob/master/FAQ.md#why-create-a-new-standard-when-there-is-already-asmjs
Jun 23 2015
parent reply "Suliman" <evermind live.ru> writes:
On Tuesday, 23 June 2015 at 11:41:03 UTC, Wyatt wrote:
 On Tuesday, 23 June 2015 at 11:37:41 UTC, Suliman wrote:
 Am I right understand that web assembly would not completely 
 new technology and would be just evolution of asm.js, so all 
 of webassembly apps would run in old javascript virtual 
 machine?
They covered this question in the FAQ, too: https://github.com/WebAssembly/design/blob/master/FAQ.md#why-create-a-new-standard-when-there-is-already-asmjs
I can't understand what I will see if I open HTML page? Would it's classical HTML page with import of some binary on top of it or what?
Jun 23 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Tuesday, 23 June 2015 at 11:50:48 UTC, Suliman wrote:
 On Tuesday, 23 June 2015 at 11:41:03 UTC, Wyatt wrote:
 On Tuesday, 23 June 2015 at 11:37:41 UTC, Suliman wrote:
 Am I right understand that web assembly would not completely 
 new technology and would be just evolution of asm.js, so all 
 of webassembly apps would run in old javascript virtual 
 machine?
They covered this question in the FAQ, too: https://github.com/WebAssembly/design/blob/master/FAQ.md#why-create-a-new-standard-when-there-is-already-asmjs
I can't understand what I will see if I open HTML page? Would it's classical HTML page with import of some binary on top of it or what?
What you'll see in the browser is what you already see now in HTML5. All that's changing under the hood is that they're providing more ways to compile other languages and use them in place of javascript. So if you "View Source" on the webapp, you'll see HTML/CSS, as you always did, and some kind of textual representation of webassembly instead of javascript. On Tuesday, 23 June 2015 at 11:55:24 UTC, Abdulhaq wrote:
 On Tuesday, 23 June 2015 at 11:09:31 UTC, Joakim wrote:

 As for a GC, why would webasm need to provide one?  I'd think 
 the languages would just be able to compile their own GC to 
 webasm, which seems low-level enough.
From the docs: Even before GC support is added to WebAssembly, it is possible to compile a language's VM to WebAssembly (assuming it's written in portable C/C++) and this has already been demonstrated (1, 2, 3). However, "compile the VM" strategies increase the size of distributed code, lose browser devtools integration, can have cross-language cycle-collection problems and miss optimizations that require integration with the browser.
You cut off two key sentences before that: "Beyond the MVP, another high-level goal is to improve support for languages other than C/C++. This includes allowing WebAssembly code to allocate and access garbage-collected (JS, DOM, Web API) objects." So they're only talking about "GC support" for integrating with javascript and DOM objects, not the GC for some other language compiled to webasm. I thought Ola was talking about the latter, maybe he was talking about the former. On Tuesday, 23 June 2015 at 16:10:58 UTC, Nick Sabalausky wrote:
 On 06/23/2015 07:09 AM, Joakim wrote:
 But if you have some emotional connection with the term 
 "desktop" and
 can't take the fact that they're being rendered defunct, I can 
 see why
 you'd want to ignore all that and just call the new devices 
 "converged"
 or "desktops." :)
As opposed to someone with an emotional connection with the term "smartphone" and can't take the fact that what such devices are turning into is not what they used to be and that they're getting there by borrowing from an old uncool "outdated" style of computing ;)
Actually, I deliberately use the term "mobile devices" and only occasionally "smartphone," as I believe tablets will end up selling much better than they are now, particularly for this kind of docked usage. And I most definitely don't find desktop computing to be "old uncool 'outdated'," as I've often said that touchscreens are a big drop in interaction bandwidth from keyboards and trackpads (using a trackpad exclusively with a laptop and ultrabook over the last decade, I now think mice are a step backwards too), though that tradeoff is understandable for most mobile use. Just don't expect me to actually type anything longer than a couple words on those touch keyboards, I'll just save it for later on my physical keyboard. So no, no emotional connection here, or I wouldn't be calling for multi-window UIs on mobile, that allow real work to get done, for some time now. I simply disagree that taking one feature, multi-window UIs, is "convergence" in any meaningful sense, so you can say they've just become "desktops." I've tried to persuade you and Kagamin otherwise and appear to have failed. :)
 I've done so already. It's absolutely terrible. At best, it's 
 an
 occasional replacement for those already-horrid
 mini-touchscreen-keyboards (which almost anything is better 
 than).
I've been surprised on the few occasions I used google's voice translation about how good it was, but I haven't use it much.
It's much better than I expected too, but even still, approx 50% of the time I use it (50% is NOT an exaggeration here) I end up having to go back and edit its mistakes. Plus it's laggy because of yet another problem: It works by sending everything the mic hears straight to Google. So much for end-to-end encryption/privacy.
Supposedly they've made voice translation work completely offline a little while back, though I'm not sure if they still use the online mode by default.
 And then here's the one that isn't even conceivably fixable by 
 technological improvements: I've found that oftentimes, 
 dictation is just isn't a very natural fit for your mental 
 process, even if it does work flawlesly.

 I know that's somewhat vague, because it's difficult to 
 explain. but I'll put it this way: Dictation is almost like the 
 "waterfall model" of text entry. Versus a keyboard being more 
 naturally suited to iterative refinement, and working out how 
 you want to word something. Sure, you can do that with voice, 
 but it's less natural. (That's actually part of why I prefer 
 email to telephone calls for business and technical 
 communications.)
As you said, editing can be done through a voice interface too. It's just not common yet and people are still getting familiar with that new voice editing process. I bet editing could actually be made much faster through voice, particularly for large documents. I agree with you about text email being preferable to telephone calls for many kinds of communication, but that's not relevant here, as you're sending a voice-transcribed text email if you're using voice translation. On Tuesday, 23 June 2015 at 16:37:23 UTC, Ola Fosheim Grøstad wrote:
 On Tuesday, 23 June 2015 at 11:09:31 UTC, Joakim wrote:
 On Monday, 22 June 2015 at 16:34:58 UTC, Ola Fosheim Grøstad 
 wrote:
 People are already writing less javascript, but without a GC 
 in webasm most languages are better of compiling to 
 javascript or a mix.
The problem is that they may be writing less javascript now, but they're still stuck with the performance of javascript, as they're just compiling to javascript. Webasm making that faster and allowing more languages should change that equation much more.
asm.js/Webasm is more restricted. Those restrictions basically tells the JIT that the code has already been optimized, doesn't need higher level support and it can be translated into machine language as is...
And you're saying this will make webasm as slow as javascript or slower? I think the idea here is to beat javascript's speed: as long as they do that, it's worthwhile.
 Although I don't think javascript is the bottle neck at the 
 moment. I think the layout and render engine is.
You may be right for the UI: I haven't profiled it. But for computationally-intensive stuff like a physics engine, which is what this is supposedly aimed at, javascript is the bottleneck.
 As for a GC, why would webasm need to provide one?  I'd think 
 the languages would just be able to compile their own GC to 
 webasm, which seems low-level enough.
That would be difficult to get right.
It's been done, as the FAQ quoted above notes. If you're talking about integrating with javascript and DOM objects, they say they plan to support that eventually also.
 This is nonsense.  They're just dumping in everything they can 
 think of, that has nothing to do with backwards-compatibility.
Web tech is pretty good at backwards-compatibility. Not sure why anyone would argue against that.
Others have already argued above that it isn't, which I already alluded to once earlier in this thread. But that's not the issue: you seemed to be arguing that the reason there's so much stuff dumped into the web stack is because they keep the old stuff around for backwards-compatibility, whereas I was saying they're dumping in _way_ too much new stuff, forget about the old stuff. I love experimentation and trying out new approaches, but ideally those should get weeded out and rationalized before being baked into the standard. At this point, there's too much stuff getting "standardized," forget about the single-browser experiments. It's almost as though the browser itself has become a giant, bloated experiment, one that never cuts failed attempts.
 That doesn't answer the question of why they're using a 
 bitcode and not a textual IR, as you prefer text for SVG.
Because we don't edit the IR.
So you're editing SVG in the client, ie the browser? You edit your text C++ source on your developer workstation and upload bitcode to the server with webasm, which is what the browser downloads. You could do the same with SVG: edit the text SVG on your workstation and upload a binary encoding for the server and browser. You claimed that "parsing is not the main issue" with SVG, yet it certainly appears to be an issue with webasm.
Jun 24 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 24 June 2015 at 07:25:26 UTC, Joakim wrote:
 So they're only talking about "GC support" for integrating with 
 javascript and DOM objects, not the GC for some other language 
 compiled to webasm.  I thought Ola was talking about the 
 latter, maybe he was talking about the former.
I'm talking about both.
 You may be right for the UI: I haven't profiled it.  But for 
 computationally-intensive stuff like a physics engine, which is 
 what this is supposedly aimed at, javascript is the bottleneck.
Yes, the question is if hardware will aim to support low latency OpenCL etc in the near future. And will webasm map to OpenCL?
 It's been done, as the FAQ quoted above notes.  If you're 
 talking about integrating with javascript and DOM objects, they 
 say they plan to support that eventually also.
I don't think you can have efficient concurrent GC with the IR they seems to aim for.
 alluded to once earlier in this thread.  But that's not the 
 issue: you seemed to be arguing that the reason there's so much 
 stuff dumped into the web stack is because they keep the old 
 stuff around for backwards-compatibility, whereas I was saying 
 they're dumping in _way_ too much new stuff, forget about the 
 old stuff.
Most of the new stuff is good. What new stuff is bad?
 I love experimentation and trying out new approaches, but 
 ideally those should get weeded out and rationalized before 
 being baked into the standard.  At this point, there's too much 
 stuff getting "standardized," forget about the single-browser 
 experiments.  It's almost as though the browser itself has 
 become a giant, bloated experiment, one that never cuts failed 
 attempts.
Yes, they should start deprecating. But more likely you will just get multiple engines in one browser (like with IE). One modern and one backwards compatible.
 So you're editing SVG in the client, ie the browser?  You edit 
 your text C++ source on your developer workstation and upload 
 bitcode to the server with webasm, which is what the browser 
 downloads.  You could do the same with SVG: edit the text SVG 
 on your workstation and upload a binary encoding for the server 
 and browser.
But the point is that it is tedious. So people don't want it. Just like C++ is more tedious than Python for evolutionary development.
 You claimed that "parsing is not the main issue" with SVG, yet 
 it certainly appears to be an issue with webasm.
Only if webasm is directly translated to machine language.
Jun 24 2015
parent "Joakim" <dlang joakim.fea.st> writes:
On Wednesday, 24 June 2015 at 09:38:02 UTC, Ola Fosheim Grøstad 
wrote:
 It's been done, as the FAQ quoted above notes.  If you're 
 talking about integrating with javascript and DOM objects, 
 they say they plan to support that eventually also.
I don't think you can have efficient concurrent GC with the IR they seems to aim for.
OK, I don't know enough about GC and their IR to say.
 alluded to once earlier in this thread.  But that's not the 
 issue: you seemed to be arguing that the reason there's so 
 much stuff dumped into the web stack is because they keep the 
 old stuff around for backwards-compatibility, whereas I was 
 saying they're dumping in _way_ too much new stuff, forget 
 about the old stuff.
Most of the new stuff is good. What new stuff is bad?
Well, I think almost _all_ of it is bad, old or new. :) I've said so several places in this thread, including pointing out which ones. I do think webasm could be worthwhile though.
 I love experimentation and trying out new approaches, but 
 ideally those should get weeded out and rationalized before 
 being baked into the standard.  At this point, there's too 
 much stuff getting "standardized," forget about the 
 single-browser experiments.  It's almost as though the browser 
 itself has become a giant, bloated experiment, one that never 
 cuts failed attempts.
Yes, they should start deprecating. But more likely you will just get multiple engines in one browser (like with IE). One modern and one backwards compatible.
All software should have a clear deprecation timeline, or you just get monstrosities like XP being supported to this day. It'd help if the source would be released at the end, so the users could run with it if they wanted to.
 So you're editing SVG in the client, ie the browser?  You edit 
 your text C++ source on your developer workstation and upload 
 bitcode to the server with webasm, which is what the browser 
 downloads.  You could do the same with SVG: edit the text SVG 
 on your workstation and upload a binary encoding for the 
 server and browser.
But the point is that it is tedious. So people don't want it. Just like C++ is more tedious than Python for evolutionary development.
Yes, but that doesn't mean you give your users your C++ source and tell them to compile it themselves. ;) Once you start degrading the user experience because of developers' tedium, you know the tech is broken.
 You claimed that "parsing is not the main issue" with SVG, yet 
 it certainly appears to be an issue with webasm.
Only if webasm is directly translated to machine language.
Regardless of how it's used, bitcode is the default.
Jun 24 2015
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/24/2015 03:25 AM, Joakim wrote:
 I simply disagree that taking one feature, multi-window UIs, is
 "convergence" in any meaningful sense, so you can say they've just
 become "desktops."  I've tried to persuade you and Kagamin otherwise and
 appear to have failed. :)
Well, I guess it's good that you disagree with that, because I never said it ;) I never claimed that adding one feature alone is convergence. I keep repeating over and over that that PLUS all the other things I'm now tired of mentioning all collectively constitute something that lies in-between traditional "mobile" and traditional desktop, but you seem quite insistent on ignoring that. And I'm also not saying they'll become desktops, as that directly contradicts the whole "lies in-between traditional mobileand traditional desktop" thing.
 Supposedly they've made voice translation work completely offline a
 little while back, though I'm not sure if they still use the online mode
 by default.
That's good to hear.
 As you said, editing can be done through a voice interface too. It's
 just not common yet and people are still getting familiar with that new
 voice editing process.  I bet editing could actually be made much faster
 through voice, particularly for large documents.  I agree with you about
 text email being preferable to telephone calls for many kinds of
 communication, but that's not relevant here, as you're sending a
 voice-transcribed text email if you're using voice translation.
I don't doubt that'll happen, it may even become widely popular. But I do seriously doubt it'll ever be as good as a more direct (physical) interaction. And I don't see that so much as a technological problem as a basic human nature one.
Jun 24 2015
prev sibling next sibling parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Tuesday, 23 June 2015 at 11:09:31 UTC, Joakim wrote:

 As for a GC, why would webasm need to provide one?  I'd think 
 the languages would just be able to compile their own GC to 
 webasm, which seems low-level enough.
From the docs: Even before GC support is added to WebAssembly, it is possible to compile a language's VM to WebAssembly (assuming it's written in portable C/C++) and this has already been demonstrated (1, 2, 3). However, "compile the VM" strategies increase the size of distributed code, lose browser devtools integration, can have cross-language cycle-collection problems and miss optimizations that require integration with the browser.
Jun 23 2015
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/23/2015 07:09 AM, Joakim wrote:
 But if you have some emotional connection with the term "desktop" and
 can't take the fact that they're being rendered defunct, I can see why
 you'd want to ignore all that and just call the new devices "converged"
 or "desktops." :)
As opposed to someone with an emotional connection with the term "smartphone" and can't take the fact that what such devices are turning into is not what they used to be and that they're getting there by borrowing from an old uncool "outdated" style of computing ;)
 I've done so already. It's absolutely terrible. At best, it's an
 occasional replacement for those already-horrid
 mini-touchscreen-keyboards (which almost anything is better than).
I've been surprised on the few occasions I used google's voice translation about how good it was, but I haven't use it much.
It's much better than I expected too, but even still, approx 50% of the time I use it (50% is NOT an exaggeration here) I end up having to go back and edit its mistakes. Plus it's laggy because of yet another problem: It works by sending everything the mic hears straight to Google. So much for end-to-end encryption/privacy. And then here's the one that isn't even conceivably fixable by technological improvements: I've found that oftentimes, dictation is just isn't a very natural fit for your mental process, even if it does work flawlesly. I know that's somewhat vague, because it's difficult to explain. but I'll put it this way: Dictation is almost like the "waterfall model" of text entry. Versus a keyboard being more naturally suited to iterative refinement, and working out how you want to word something. Sure, you can do that with voice, but it's less natural. (That's actually part of why I prefer email to telephone calls for business and technical communications.)
Jun 23 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 23 June 2015 at 11:09:31 UTC, Joakim wrote:
 On Monday, 22 June 2015 at 16:34:58 UTC, Ola Fosheim Grøstad 
 wrote:
 People are already writing less javascript, but without a GC 
 in webasm most languages are better of compiling to javascript 
 or a mix.
The problem is that they may be writing less javascript now, but they're still stuck with the performance of javascript, as they're just compiling to javascript. Webasm making that faster and allowing more languages should change that equation much more.
asm.js/Webasm is more restricted. Those restrictions basically tells the JIT that the code has already been optimized, doesn't need higher level support and it can be translated into machine language as is... Although I don't think javascript is the bottle neck at the moment. I think the layout and render engine is.
 As for a GC, why would webasm need to provide one?  I'd think 
 the languages would just be able to compile their own GC to 
 webasm, which seems low-level enough.
That would be difficult to get right.
 This is nonsense.  They're just dumping in everything they can 
 think of, that has nothing to do with backwards-compatibility.
Web tech is pretty good at backwards-compatibility. Not sure why anyone would argue against that.
 I think the vendors have realized that they need to take 
 babysteps in concert, because there is to much politics 
 involved to accept a "whole-sale solution" like PNACL etc.
PNaCl is bitcode too.
From one party. So it did not get adopted.
 That doesn't answer the question of why they're using a bitcode 
 and not a textual IR, as you prefer text for SVG.
Because we don't edit the IR.
Jun 23 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/23/2015 12:37 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Tuesday, 23 June 2015 at 11:09:31 UTC, Joakim wrote:
 This is nonsense.  They're just dumping in everything they can think
 of, that has nothing to do with backwards-compatibility.
Web tech is pretty good at backwards-compatibility. Not sure why anyone would argue against that.
Relatively speaking, yea, although it's not 100%: There were ways to embed A/V in a page since ages ago, but HTML5 browsers (most notably Chrome, as I recall) eliminated comparability with that when they put in the "new and better" way to do it. This was some time ago, but I ended up having to resort to Flash just to play an audio file, just because Chome refused to allow the old way, and some of the other browsers at the time (not just IE) didn't support the new way. (Yea, yea, I know, webpages with audio are evil, but this was a decision coming down from higher up for a project that was going to be used in nursing homes.) And of course *that* method of playing audio broke once iOS Safari got big. And then browser add-ons keep getting broken by automatic browser updates. At least on FF, anyway.
Jun 23 2015
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/21/2015 05:07 AM, Joakim wrote:
 Simply dumping more features on top of the old web stack
 is a recipe for failure.
Meh, it seems to be working for them so far ;) But I agree, it's a bad approach, and hopefully will finally collapse.
 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.
Plus, on the web, doing stuff in the background tends to have a much bigger negative impact on responsiveness than it does outside the web.
 Very responsive because they're made up of trivially simple line art,
 perhaps.
I happen to like that aesthetic style, really. :) But of course an image format needs to be more general.
 On Sunday, 21 June 2015 at 07:38:02 UTC, Nick Sabalausky wrote:
 On 06/21/2015 01:42 AM, Joakim wrote:

 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.
50GB? That's it? I have more than that in music alone. (And no, streaming music services is not an improvement. Although it is occasionally a nice supplement.) My two most recent laptops, I've upgraded to 1TB HDDs. Anything less than that in local storage feels cramped. Plus then I have an old desktop with about 2.5-3TB between three drives. And three USB3 drives ranging from a few hundred GB to 1TB. And a USB2 250GB.
 If I weren't
 filling that 50 GBs up with many GBs of HD video,
VMs also soak up a lot of space. (just sayin')
 that's plenty of space for most people.
To marginalize desktops/laptops, mobile doesn't need to win over "most people". Those are the people they've already won over. It exactly us dev and power users that they need to win over now. And they can't do that by settling for whatever works for "most people".
 As for peripherals, you're talking printers and
 scanners?  Do people even use those anymore? :)
Yes. They're not sexy and don't generate "buzz", but that doesn't mean they aren't relied on. (Personal observation: The modern fashion-oriended tech sector seems to have major trouble recognizing that "buzzworthy" and "important" are not the same thing).
 If there's any demand
 for those at all, the dock for your smartphone will have a USB hub that
 supports them.
Yea. ONE usb port (that needs an adapter to be able to use just about anything out there besides charging) for everything to get funneled and crammed into: charging, HDMI, external storage, printer/scanner, jtag (arduino and such are big these days), optical disc (yes, these are still useful), adpators for whatever new protocols and connectors inevitably come along, etc. And that one-port-only means that you *also* need a hub in addition to everything else. Rendering the whole mess considerably less convenient than an actual all-in-one device: the laptop.
 As for devs, they're a small percentage of the computer-using public,
You're looking at it wrong (IMO): Devs (and non-dev power users, don't forget there's a lot of them too) are a very significant portion of modern-day desktop/laptop users. They're the biggest reason why desktops/laptops haven't already been marginalized. Therefore, if mobile is going to replace desktop/laptop, it MUST support developer needs and support them WELL, not just in a half-hearted way. We devs and power users may be a minority, but we're a very large minority, and we happen to be crucial to everything the everyday-Joe majority users rely on. Mobile *cannot* marginalize us without throwing away it's own chance at ubiquity.
 But even devs, most of whom certainly aren't using massive rigs with
 Xeons and 32 GBs of RAM, will make the switch.
Right, that may very well happen. But again, that will require mobile to adopt the remaining features that have been keeping us on laptops/desktops, and thus become a hybrid. You're stance seems to be that multi-window UI is just about the only one left. I think there's much more than that.
 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.
Well, I guess that's where we disagree.
 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.
That, plus the whole overall approach - gatekeeping, lock-downs, nearly-zero buttons/keys, minimal I/O ports, minimal expandability, neat-total vertical integration (business-wise), etc. Ie, "The way Apple designed the iPhone".
 As I pointed out, the UI will need to be
 adapted for desktop monitors.
Definitely.
 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.
Well, people don't *see* it as the same. But no, there's plenty of other reasons for the troubles of Surface and Surface-alikes. The most notable one being Win8 itself (for about a million reasons). And then the disconnect between high-price and (for most of the surface models, particularly the earlier ones) weak hardware specs compared to even laptops that cost less (yes, surface pro's CPU is beefy, but that's about it). It's *not* the approach itself that's wrong. They just haven't quite gotten all the details right. Just like the current day "connect keyboard to mobile, use as a desktop"... See, the same argument can be made the other way too: Aside from a minority of techies such as yourself, nobody's actually using mobile in the style of "connect a keyboard/mouse, use as a desktop replacement". You could say it's been a failure *so far*. But as you know, that doesn't mean the approach is wrong, it just means there's still a few more details to be ironed out. Same thing with Surface.
 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,
Well, ok, *one* natural place, maybe not "the" natural place ;)
 and the failure of such devices, both on the Android side
 and especially on the Windows side, seems to show this.
I strongly suspect that if you hold up bluetooth keyboard sales up to the same "success/failure" standard as these devices you're referring too, that they would look like "failures" too. I really don't believe the problem there was that the idea was wrong. I think the problem was that people *already* had their laptop/desktop for their keyboard-oriented needs, and the mobile systems just weren't yet ready to be a full replacement for laptops/desktops. The idea was right, but the state of the market was wrong. It was too early for it. But that will all change if mobile improves and desktops/laptops become increasingly marginalized.
  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.
Ok, so it's more like re-inventing the desktop then, instead of the laptop.
 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.
Not if you're just reinventing the form factor by propping up your monitor^H^H^H^H^H^H^Htablet and pulling out a keyboard+mouse. It's just the particular lineage that (might) go away.
 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.
Well, somebody was saying that mobile processors have been getting closer and closer in power to laptops. Which I have to strongly agree with. Maybe that wasn't you though.
 Anyway, it's funny that you
 respond to a quote limited to software and UIs by going on about
 hardware again, never mentioning software. :)
No, you're misunderstanding me (deliberately?) You said "All that is converging is the software UIs". I'm saying "No, that isn't the only thing converging." Obviously I'm not going go on about the part we already agree on (software UI convergence), why would I?
 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?"
Not "converged". "ConvergING" towards some point in between traditional iPhone (and clones) and traditional laptop. And yes, *partly* because connecting keyboard/mouse is not something people have normally done with smartphones (at least not typically). And also because the gap in processing power is shrinking. And because you can now connect them to an external monitor. And because they're gaining desktop UIs. Maybe some other things too I haven't thought of off the top of my head.
  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.
There's really no parallel between that and what I'm talking about.
 I think that
 since the underlying device, a smartphone, is fairly different from a
 mainframe or a PC,
How so? *You're* the one saying (even more than I am anyway) that they are (or will soon be) suitable replacements for PCs. How do you reconcile that with now suddenly saying they're different in a big enough way to be meaningful?
 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.
You've completely over-simplified my argument, and are now objecting that your modified version of my argument isn't valid.
 But even that is only temporary, as voice and gesture recognition will
 soon kill off those input peripherals too. :)
God I hope not. :) Touchscreen mini-chicklet keyboards (not to mention auto-correction) are already clunky and unreliable enough.
 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.
Yet. Almost nobody is *yet*. Almost nobody is using their "smartphone + keyboard" as a desktop/laptop replacement either. Yet. But I think we both agree it's clear that where computing, at the very least *should* go, is somewhere in between traditional iPhone and traditional laptop. And mobiles and PCs are both *trying* to reach for some point in-between. Unless ALL sides turn out to be wrong (which seems unlikely) then naturally the "winner" will be something that does exist somewhere in that middle-ground that everyone's reaching towards. That "winner"'s lineage isn't particularly important (except to the corporations directly involved), because it will no longer be strictly a traditional smartphone nor traditional laptop.
 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. :) Well, I'm not aware of any small mom-and-pop business putting out major OSes or devices. So non-corporate is irrelevant here, hence the arguably-unnecessary qualification.
Jun 21 2015
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 21 June 2015 at 18:51:41 UTC, Nick Sabalausky wrote:
 On 06/21/2015 05:07 AM, Joakim wrote:
 Simply dumping more features on top of the old web stack
 is a recipe for failure.
Meh, it seems to be working for them so far ;) But I agree, it's a bad approach, and hopefully will finally collapse.
What's amazing is how long this house of cards keeps jiggling on, and even worse, how many people actually think it's something worthwhile! It can't be destroyed soon enough.
 Very responsive because they're made up of trivially simple
line art,
 perhaps.
I happen to like that aesthetic style, really. :) But of course an image format needs to be more general.
Actually, I like that "cartoon" style too, wish more people used it. I'm guessing they don't only because it's considered too simple or not as serious. But I bet SVG would be slow even for that, particularly if it was animated. I really liked the new Fisher-Price style of desktop Windows 8, along with better visualizations like the graph when copying files. Damn sight better than the OSX-aping Windows 7, with the unnecessary glass and reflections everywhere, though it was pretty at first.
 On Sunday, 21 June 2015 at 07:38:02 UTC, Nick Sabalausky
wrote:
 On 06/21/2015 01:42 AM, Joakim wrote:
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.
50GB? That's it? I have more than that in music alone. (And no, streaming music services is not an improvement. Although it is occasionally a nice supplement.) My two most recent laptops, I've upgraded to 1TB HDDs. Anything less than that in local storage feels cramped. Plus then I have an old desktop with about 2.5-3TB between three drives. And three USB3 drives ranging from a few hundred GB to 1TB. And a USB2 250GB.
Heh, I'd say you're pretty unusual. Whenever I ask normal people how much disk space they have, they have no idea, and when I check their devices for myself, they're inevitably only using around 10-20% of the 16-32 GBs on their tablets or 80-500 GBs on their laptops.
 If I weren't
 filling that 50 GBs up with many GBs of HD video,
VMs also soak up a lot of space. (just sayin')
I'm up to 22 GBs of VMs right now.
 that's plenty of space for most people.
To marginalize desktops/laptops, mobile doesn't need to win over "most people". Those are the people they've already won over. It exactly us dev and power users that they need to win over now. And they can't do that by settling for whatever works for "most people".
The vast majority of current desktop/laptop users are only stuck with them because they bought them before mobile took off or they need a multi-window UI for certain apps or certain desktop software that hasn't been ported to mobile yet, ie there's no fundamental reason they couldn't use mobile devices instead. Of the 300 million PCs sold last year, I'd say 95+% could make the transition to mobile devices once they have multi-window UIs and all the same software. The remaining 3-5% may never make the transition.
 As for peripherals, you're talking printers and
 scanners?  Do people even use those anymore? :)
Yes. They're not sexy and don't generate "buzz", but that doesn't mean they aren't relied on. (Personal observation: The modern fashion-oriended tech sector seems to have major trouble recognizing that "buzzworthy" and "important" are not the same thing).
Seems like most of those are going to wifi/bluetooth connections that are easily controlled by mobile devices also.
 If there's any demand
 for those at all, the dock for your smartphone will have a
USB hub that
 supports them.
Yea. ONE usb port (that needs an adapter to be able to use just about anything out there besides charging) for everything to get funneled and crammed into: charging, HDMI, external storage, printer/scanner, jtag (arduino and such are big these days), optical disc (yes, these are still useful), adpators for whatever new protocols and connectors inevitably come along, etc. And that one-port-only means that you *also* need a hub in addition to everything else. Rendering the whole mess considerably less convenient than an actual all-in-one device: the laptop.
Well, if you're docking the smartphone at your desk anyway, having a USB hub with several ports built into the dock is not a big deal. As for on the go, yes, you'll need to bring some sort of adapter with you, but new connectors like USB Type-C are geared for that. I don't think this ports issue moves the needle for most people, and most peripherals these days are moving to wireless anyway.
 As for devs, they're a small percentage of the computer-using
public, You're looking at it wrong (IMO): Devs (and non-dev power users, don't forget there's a lot of them too) are a very significant portion of modern-day desktop/laptop users. They're the biggest reason why desktops/laptops haven't already been marginalized. Therefore, if mobile is going to replace desktop/laptop, it MUST support developer needs and support them WELL, not just in a half-hearted way. We devs and power users may be a minority, but we're a very large minority, and we happen to be crucial to everything the everyday-Joe majority users rely on. Mobile *cannot* marginalize us without throwing away it's own chance at ubiquity.
I disagree, as I said above, I peg the group you're talking about at less than 5% of current desktop/laptop users. And most devs are not really power users: some python/django dev is not going to be rocking a desktop as powerful as the Mac Pro anyway. They'd be fine with a tablet, like this guy: http://bergie.iki.fi/blog/working-on-android/
 But even devs, most of whom certainly aren't using massive
rigs with
 Xeons and 32 GBs of RAM, will make the switch.
Right, that may very well happen. But again, that will require mobile to adopt the remaining features that have been keeping us on laptops/desktops, and thus become a hybrid. You're stance seems to be that multi-window UI is just about the only one left. I think there's much more than that.
I don't see it.
 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.
Well, I guess that's where we disagree.
Yep, once multi-window UIs come to mobile, we'll see who's right. :)
 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.
That, plus the whole overall approach - gatekeeping, lock-downs, nearly-zero buttons/keys, minimal I/O ports, minimal expandability, neat-total vertical integration (business-wise), etc. Ie, "The way Apple designed the iPhone".
Most of that is because those aren't things most users care about. In fact, they prefer a more locked-down device, as long as it's more stable and doesn't get corrupted easily. It's why most people buy sedans with automatic transmission, not a sports car with manual. Now, of course there are better ways to do some of those. You could have gatekeeping without it being done by one company, Apple. They'll have to lock it down a little less when it's docked, for example, you'll have constant power and wouldn't want apps to be as aggressively killed. As for expandability, that ship has sailed: most people don't care for it, which is why even Samsung ditched the SD card slot in the recent Galaxy S6. I wouldn't call Android vertically integrated, maybe Samsung, but there are a lot of other component and software vendors. That's a disparate grab bag of "mobile-style," but I'd say nothing there prevents mobile devices from killing off the desktop/laptop PC.
 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.
Well, people don't *see* it as the same. But no, there's plenty of other reasons for the troubles of Surface and Surface-alikes. The most notable one being Win8 itself (for about a million reasons). And then the disconnect between high-price and (for most of the surface models, particularly the earlier ones) weak hardware specs compared to even laptops that cost less (yes, surface pro's CPU is beefy, but that's about it). It's *not* the approach itself that's wrong. They just haven't quite gotten all the details right. Just like the current day "connect keyboard to mobile, use as a desktop"...
I don't think the approach itself will work, though I agree that Win8 hurt it too. One big problem with the all-in-ones so far is that the tablet portion is just too big and unwieldy to be used on its own, at 10.6" to 13".
 See, the same argument can be made the other way too: Aside 
 from a minority of techies such as yourself, nobody's actually 
 using mobile in the style of "connect a keyboard/mouse, use as 
 a desktop replacement". You could say it's been a failure *so 
 far*. But as you know, that doesn't mean the approach is wrong, 
 it just means there's still a few more details to be ironed 
 out. Same thing with Surface.
I'd say the difference is that your all-in-one approach has already been tried, with a lot of marketing behind it. Whereas nobody has really pushed my approach, with most Android tablets not supporting multi-window yet. I do agree that Win8 was botched though, maybe Win10 will do it better.
 and the failure of such devices, both on the Android side
 and especially on the Windows side, seems to show this.
I strongly suspect that if you hold up bluetooth keyboard sales up to the same "success/failure" standard as these devices you're referring too, that they would look like "failures" too.
Yep, the bluetooth keyboard approach with Android tablets hasn't taken off yet either. But they're still waiting on multi-window UIs, you can't expect it to do well before that.
 I really don't believe the problem there was that the idea was 
 wrong. I think the problem was that people *already* had their 
 laptop/desktop for their keyboard-oriented needs, and the 
 mobile systems just weren't yet ready to be a full replacement 
 for laptops/desktops. The idea was right, but the state of the 
 market was wrong. It was too early for it. But that will all 
 change if mobile improves and desktops/laptops become 
 increasingly marginalized.
Well, what's missing? Mobile chips are powerful enough. For me, it's just multi-window and the few apps that require it. What else do you think mobile needs to improve?
  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.
Ok, so it's more like re-inventing the desktop then, instead of the laptop.
Both, as I said, most people using laptops don't need the keyboard to be physically attached. So they'll just stick their dock on the table at the cafe, slot the tablet in, and start typing away on their bluetooth keyboard.
 Not if you're just reinventing the form factor by propping up 
 your monitor^H^H^H^H^H^H^Htablet and pulling out a 
 keyboard+mouse.

 It's just the particular lineage that (might) go away.
Heh, you're really reaching now. :) Most people wouldn't call a smartphone or tablet in a dock "reinventing the [desktop] form factor."
 No, as you already pointed out yourself, the hardware
capabilities are
 converging as well.
Heh, never said anything of the sort.
Well, somebody was saying that mobile processors have been getting closer and closer in power to laptops. Which I have to strongly agree with. Maybe that wasn't you though.
By that rationale, since desktop chips nowadays are as powerful as mainframes from a decade ago, desktops are really just mainframes, right? ;) You and Kagamin are really reaching with these assertions.
 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?"
Not "converged". "ConvergING" towards some point in between traditional iPhone (and clones) and traditional laptop. And yes, *partly* because connecting keyboard/mouse is not something people have normally done with smartphones (at least not typically). And also because the gap in processing power is shrinking. And because you can now connect them to an external monitor. And because they're gaining desktop UIs. Maybe some other things too I haven't thought of off the top of my head.
Except that looking at that smartphone that has all those features that will allow them to kill off the desktop, they'll look exactly the same as smartphones do now. Really, the only difference will be the addition of the multi-window UI capability, nothing else will have "converged." I wouldn't call that convergence between iPhones and laptops, rather smartphones simply picking up yet one more feature that allows them to kill off the desktop/laptop PC.
  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.
There's really no parallel between that and what I'm talking about.
Oh, it's pretty much the same. :) Replace wheels with multi-window UIs and that is exactly the point you're making.
 I think that
 since the underlying device, a smartphone, is fairly
different from a
 mainframe or a PC,
How so? *You're* the one saying (even more than I am anyway) that they are (or will soon be) suitable replacements for PCs. How do you reconcile that with now suddenly saying they're different in a big enough way to be meaningful?
Because they're really only taking one feature from desktops/laptops, the multi-window UI, in order to replace them. Otherwise, they will be the same smartphones that they are now, which you don't call desktops.
 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.
You've completely over-simplified my argument, and are now objecting that your modified version of my argument isn't valid.
That certainly seemed to be one aspect of your argument, which you just repeated above.
 But even that is only temporary, as voice and gesture
recognition will
 soon kill off those input peripherals too. :)
God I hope not. :) Touchscreen mini-chicklet keyboards (not to mention auto-correction) are already clunky and unreliable enough.
I can't wait. I've gotten fairly fast on a keyboard over the years, but I can't wait to just use voice.
 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.
Yet. Almost nobody is *yet*. Almost nobody is using their "smartphone + keyboard" as a desktop/laptop replacement either. Yet. But I think we both agree it's clear that where computing, at the very least *should* go, is somewhere in between traditional iPhone and traditional laptop. And mobiles and PCs are both *trying* to reach for some point in-between. Unless ALL sides turn out to be wrong (which seems unlikely) then naturally the "winner" will be something that does exist somewhere in that middle-ground that everyone's reaching towards. That "winner"'s lineage isn't particularly important (except to the corporations directly involved), because it will no longer be strictly a traditional smartphone nor traditional laptop.
You keep asserting that there's some "middle-ground", when the truth is that mobile devices will just have to pick up one software feature to kill off the PC. I don't think that's "in-between," as it will really be a traditional smartphone. You and Kagamin seem really bent out of shape by the desktop being junked, for some personal reasons of your own, so I'll leave that "Is a smartphone really a desktop once it adds a multi-window UI" argument here. I've made my viewpoint clear.
Jun 22 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/22/2015 05:16 AM, Joakim wrote:
 I really liked the new Fisher-Price style of desktop Windows 8,
Ugh, now *that* one I don't like. Simplicity is nice, but ugly is just ugly. It looks like a re-imagining of Win1 and Win2 drawn up by a hung-over unicorn ;)
 along
 with better visualizations like the graph when copying files.
That graph is nice. Unnecessary perhaps, but certainly nice. I really like the new process manager, actually. I wish KDE's was more like that.
 On Sunday, 21 June 2015 at 18:51:41 UTC, Nick Sabalausky wrote:
 Not if you're just reinventing the form factor by propping up your
 monitor^H^H^H^H^H^H^Htablet and pulling out a keyboard+mouse.

 It's just the particular lineage that (might) go away.
Heh, you're really reaching now. :) Most people wouldn't call a smartphone or tablet in a dock "reinventing the [desktop] form factor."
Of course they won't *call* it that, because they're easily swayed by image and marketing. People refer to iPhone and such as "phones" even though they're obviously much more of a pocket computer (that happens to support cellular communications) than a telephone.
 Well, somebody was saying that mobile processors have been getting
 closer and closer in power to laptops. Which I have to strongly agree
 with. Maybe that wasn't you though.
By that rationale, since desktop chips nowadays are as powerful as mainframes from a decade ago, desktops are really just mainframes, right? ;) You and Kagamin are really reaching with these assertions.
You're twisting my words around here. My point right there was simply "the gap in mobile and PC's processing power is closing". You seem to be taking it as "Merely having the processing power of X is, by itself, enough to makes it actually BE X", which is obviously not my argument at all.
 Not "converged". "ConvergING" towards some point in between
 traditional iPhone (and clones) and traditional laptop. And yes,
 *partly* because connecting keyboard/mouse is not something people
 have normally done with smartphones (at least not typically). And also
 because the gap in processing power is shrinking. And because you can
 now connect them to an external monitor. And because they're gaining
 desktop UIs. Maybe some other things too I haven't thought of off the
 top of my head.
Except that looking at that smartphone that has all those features that will allow them to kill off the desktop, they'll look exactly the same as smartphones do now. Really, the only difference will be the addition of the multi-window UI capability, nothing else will have "converged." I wouldn't call that convergence between iPhones and laptops, rather smartphones simply picking up yet one more feature that allows them to kill off the desktop/laptop PC.
Hmmm, you're still outright ignoring most of what I've said about that. I'll repeat myself only one more time: "PARTLY because connecting keyboard/mouse is not something people have normally done with smartphones (at least not typically). And ALSO because the gap in processing power is shrinking. And ALSO because you can now connect them to an external monitor. And ALSO because they're gaining desktop UIs. And ALSO misc other stuff." Stop picking ONE aspect of all that and pretending my argument revolves purely around that one aspect alone.
  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.
There's really no parallel between that and what I'm talking about.
Oh, it's pretty much the same. :) Replace wheels with multi-window UIs and that is exactly the point you're making.
No, it isn't, but you seem to be misinterpreting nearly everything about my point anyway.
 I think that
 since the underlying device, a smartphone, is fairly
different from a
 mainframe or a PC,
How so? *You're* the one saying (even more than I am anyway) that they are (or will soon be) suitable replacements for PCs. How do you reconcile that with now suddenly saying they're different in a big enough way to be meaningful?
Because they're really only taking one feature from desktops/laptops, the multi-window UI, in order to replace them. Otherwise, they will be the same smartphones that they are now, which you don't call desktops.
*One* feature? No. At least one *MORE* feature. That's on top of everything they've already borrowed. You're acting as if smartphones have ALWAYS had host-USB, HDMI-out, processors that approach PC-level power, storage that approaches low-end laptops, multi-processing, commonly getting used with an external keyboard/mouse, etc. A lot of the convergence has *already* been happening, and you never even noticed ;) In fact that's WHY people are starting to notice their potential for replacing traditional PCs.
 God I hope not. :) Touchscreen mini-chicklet keyboards (not to mention
 auto-correction) are already clunky and unreliable enough.
I can't wait. I've gotten fairly fast on a keyboard over the years, but I can't wait to just use voice.
I've done so already. It's absolutely terrible. At best, it's an occasional replacement for those already-horrid mini-touchscreen-keyboards (which almost anything is better than).
 You keep asserting that there's some "middle-ground", when the truth is
 that mobile devices will just have to pick up one software feature to
 kill off the PC.  I don't think that's "in-between," as it will really
 be a traditional smartphone.

 You and Kagamin seem really bent out of shape by the desktop being
 junked, for some personal reasons of your own, so I'll leave that "Is a
 smartphone really a desktop once it adds a multi-window UI" argument
 here.  I've made my viewpoint clear.
No, we just don't like making points that only get conveniently ignored or twisted around.
Jun 22 2015
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
Nick, you might be interested in this quick thing I just wrote up:

http://arsdnet.net/articles/web-apps.html

A few years ago, I was talking about a new windowing system... 
and believe it or not, I'm still slowly moving forward with it, 
but I think existing X is good enough to start with for this idea.

My old thing was about thin clients used through the web. Well, I 
like downloading programs too sometimes, can we solve that 
problem? Web apps do an ok job, so do app stores. Let's get the 
best of both worlds: download a program that targets a standard 
Linux VM distributed with browsers. I go into a bit more detail 
in the link.
Jun 23 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/23/2015 09:44 AM, Adam D. Ruppe wrote:
 Nick, you might be interested in this quick thing I just wrote up:

 http://arsdnet.net/articles/web-apps.html

 A few years ago, I was talking about a new windowing system... and
 believe it or not, I'm still slowly moving forward with it, but I think
 existing X is good enough to start with for this idea.

 My old thing was about thin clients used through the web.
Yea, totally! Actually, that windowing system of yours has been in the back of my mind whenever I think of "web apps" for the past several years since you first put it up. Although I wouldn't put too much reliance on X, what with Wayland on the way.
 Well, I like
 downloading programs too sometimes, can we solve that problem? Web apps
 do an ok job, so do app stores. Let's get the best of both worlds:
 download a program that targets a standard Linux VM distributed with
 browsers. I go into a bit more detail in the link.
Yea, I'll have to take a closer look at that. My first impression is that "Linux VM" sounds very heavy-weight, but I supposed it need not necessarily be.
Jun 23 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 23 June 2015 at 16:18:01 UTC, Nick Sabalausky wrote:
 Although I wouldn't put too much reliance on X, what with 
 Wayland on the way.
meh, wayland doesn't look very interesting to me, especially in this use case where I'd want a network protocol because the application runs on an isolated VM and needs to communicate with the host somehow.
 Yea, I'll have to take a closer look at that. My first 
 impression is that "Linux VM" sounds very heavy-weight, but I 
 supposed it need not necessarily be.
Well, keep in mind that I want to kill the browser, which is already very heavy-weight! Firefox is like 80 MB.... http://www.tinycorelinux.net/downloads.html that's 9 MB and probably more than the browser VM would need! The core system should be sharable without copying the file every time, and its only job is to run one program, providing it a familiar, consistent base api. I don't think the weight would be much of a problem, though perhaps it might be on the mobile sphere.
Jun 23 2015
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/23/2015 12:36 PM, Adam D. Ruppe wrote:
 On Tuesday, 23 June 2015 at 16:18:01 UTC, Nick Sabalausky wrote:
 Yea, I'll have to take a closer look at that. My first impression is
 that "Linux VM" sounds very heavy-weight, but I supposed it need not
 necessarily be.
Well, keep in mind that I want to kill the browser, which is already very heavy-weight!
Very true. Fair point.
 Firefox is like 80 MB.... http://www.tinycorelinux.net/downloads.html
 that's 9 MB and probably more than the browser VM would need!
ABout 99% of the time, my browser (FF) is soaking up anywhere from 1-1.5GB of RAM. By far the biggest memory hog on my system (at least when I don't have a Windows VM or something running). Well, there is one other exception though: After switching my main desktop to Linux, I found that my favorite editor (Programmer's Notepad 2) has some issues under Wine, so I've been using a lot of Komodo Edit. Unfortunately, among other big annoyances, Komodo seems to have some serious memory leak issues because it's ram usage only ever grows, never shrinks (not even if I close ALL files), and after only a few days it'll hit 1GB+ ram as well, and then start pausing/lagging like crazy. Ugh. I'm trying Kate now. Actually seems to have grown up from an "MS Notepad for KDE" to a fully legitimate code editor since the last time I really looked closely at it (back in KDE3 days). Seems quite promising so far.
 The core
 system should be sharable without copying the file every time, and its
 only job is to run one program, providing it a familiar, consistent base
 api. I don't think the weight would be much of a problem, though perhaps
 it might be on the mobile sphere.
If the weight is a problem on mobile, that would unfortunately be a deal-breaker. Mobile web is every bit as important as desktop web these days, and will likely only grow further.
Jun 23 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 23 June 2015 at 16:36:21 UTC, Adam D. Ruppe wrote:
 On Tuesday, 23 June 2015 at 16:18:01 UTC, Nick Sabalausky wrote:
 Although I wouldn't put too much reliance on X, what with 
 Wayland on the way.
meh, wayland doesn't look very interesting to me, especially in this use case where I'd want a network protocol because the application runs on an isolated VM and needs to communicate with the host somehow.
I'm not sure of your use case, but wayland is clearly a huge step forward compared to X. Take it from someone that have messed up with both.
Jun 23 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 23 Jun 2015 18:26:07 +0000, deadalnix wrote:

 I'm not sure of your use case, but wayland is clearly a huge step
 forward compared to X.
yep, they reinvented DirectFB and dropped alot of libs on top of it.=20 really a huge step.=
Jun 23 2015
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/21/2015 01:42 AM, Joakim wrote:
 I'd say this is a temporary respite before the final collapse. The only
 reason it hasn't happened yet is because mobile devices have not worked
 well with plugging into a large monitor with a mouse and keyboard, but
 that is now changing.
[...]
 Sure, but current mobile hardware is about as powerful as desktop/laptop
 chips from a year or two ago, which is what most people are actually
 running at work:

 http://www.anandtech.com/show/9289/the-nvidia-shield-android-tv-review/3

 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'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. 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. 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. 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.
 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. 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.
 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. 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)... 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.
 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 ;)
 MS, [...]
 They certainly seemed to start on it first, but screwed it up in some
 key ways.  Not allowing the desktop on Windows RT was a big mistake,
 which they appear to be sort of remedying with their recent
 Continuum/Universal-app moves.  Ironically, this was one of the few
 cases when Microsoft was too early, because mobile devices were probably
 not powerful enough when Windows 8 came out three years ago.
Yea, totally agree on this MS stuff. Pretty much the point I was making about Win8/Win10.
 Interestingly, Canonical could've beat everyone to the punch here.
 They had what was basically "continuum for linux" more or less already
 working, but then...they just...what, threw it in the trash bin or
 something? I dunno, I don't quite get Canonical sometimes.
I get the sense that they're a small organization that bit off something way too big for them.
Hmm, yea, that may very well be.
Jun 21 2015
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/20/2015 03:00 PM, Joakim wrote:
 As the browser tries to mesh these two worlds, the old-fashioned static
 hyperlinked pages and the new dynamic widgets of AJAX and HTML5, rifts
 crop up.  The recent web components efforts you highlight do not address
 this at all, they merely make it easier to build more dynamic webapps.
 But in doing so, they actually bring the problems I'm talking about more
 to the fore.
An excellent example of this is sites like github that actually manage to break the "back" button, even though it's *clearly* a page-based site (that somehow doesn't seem to believe it is).
 The highest-DPI devices I use nowadays are mobile devices and, in my
 experience, websites are the ones who most often get it wrong.  That's
 usually related to tiny text, but that affects the overall layout too.
"Smart" TVs also have trouble there: http://www.quirksmode.org/blog/archives/2014/07/samsung_smart_t.html (See the section "The viewport", just underneath the photo with a phone held in front of a TV. Erm...speaking of which: <https://semitwist.com/articles/article/view/html-fragment-linking-is-stupid-here-s-the-fix>)
 Pretty soon it won't. :) There are an estimated 2.5 billion smartphone
 users:

 http://www.asymco.com/2014/04/07/postmodern-computing/

 The highest estimates of desktop and laptop users I've seen don't crack
 2 billion.  That means desktops are already a minority platform.
People have been looking at the sales trends and predicting for years that mobile will kill of PCs. And all that happened (unsurprisingly, IMO) is that the decline in PC sales simply leveled off. Mobile will not, and cannot, replace traditional laptops/desktops (as opposed to merely cooexisting with them as is the case right now) until if/when they finally incorporate all the usability and features of laptops/desktops. Obviously they're not there right *now* yet. But as for the future...
 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.

 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.
I don't think "phones/tablets replacing desktops/laptops" is an entirely accurate way of describing how that will happen (if it does). More like "phones/tablets and desktops/laptops will converge into a hybrid". 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. MS, oddly enough, seems to have the highest chance of succeeding at this, as desktop/mobile convergence has been their big goal since Win8. And then Win9 (erm, I mean 10) cleans up some of the mess Win8 left. (Not that I like metro or what the metro "theme" has done to the desktop side of windows, even in Win9^H10, but that's beside the point here.) Interestingly, Canonical could've beat everyone to the punch here. They had what was basically "continuum for linux" more or less already working, but then...they just...what, threw it in the trash bin or something? I dunno, I don't quite get Canonical sometimes.
Jun 20 2015
parent reply "Joseph Rushton Wakeling " <joseph.wakeling webdrake.net> writes:
On Saturday, 20 June 2015 at 20:31:35 UTC, Nick Sabalausky wrote:
 Interestingly, Canonical could've beat everyone to the punch 
 here. They had what was basically "continuum for linux" more or 
 less already working, but then...they just...what, threw it in 
 the trash bin or something? I dunno, I don't quite get 
 Canonical sometimes.
Threw what in the trash-bin? I'm writing this post from a commercially-purchased Ubuntu phone, and a "fully-converged" device is officially announced from BQ for later this year.
Jun 21 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/21/2015 09:45 AM, Joseph Rushton Wakeling  wrote:
 On Saturday, 20 June 2015 at 20:31:35 UTC, Nick Sabalausky wrote:
 Interestingly, Canonical could've beat everyone to the punch here.
 They had what was basically "continuum for linux" more or less already
 working, but then...they just...what, threw it in the trash bin or
 something? I dunno, I don't quite get Canonical sometimes.
Threw what in the trash-bin?
https://en.wikipedia.org/wiki/Ubuntu_for_Android Though I may very well be missing something.
 I'm writing this post from a
 commercially-purchased Ubuntu phone, and a "fully-converged" device is
 officially announced from BQ for later this year.
Jun 21 2015
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Sunday, 21 June 2015 at 15:59:57 UTC, Nick Sabalausky wrote:
 On 06/21/2015 09:45 AM, Joseph Rushton Wakeling  wrote:
 Threw what in the trash-bin?
https://en.wikipedia.org/wiki/Ubuntu_for_Android Though I may very well be missing something.
Yea, Ubuntu for Android was a cool idea that sadly, as I understand it, got no uptake from manufacturers. So Canonical just pushed ahead with their own full-Ubuntu phone and tablet OS and UI, and played everything much quieter until they'd actually landed hardware partners. It's obviously early days, but I think there's much to be quietly confident about: there's a lot to like in the OS and app design, and it is now by a long stretch the most free (as in freedom) phone OS available.
Jun 22 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/22/2015 04:01 PM, Joseph Rushton Wakeling wrote:
 On Sunday, 21 June 2015 at 15:59:57 UTC, Nick Sabalausky wrote:
 On 06/21/2015 09:45 AM, Joseph Rushton Wakeling  wrote:
 Threw what in the trash-bin?
https://en.wikipedia.org/wiki/Ubuntu_for_Android Though I may very well be missing something.
Yea, Ubuntu for Android was a cool idea that sadly, as I understand it, got no uptake from manufacturers. So Canonical just pushed ahead with their own full-Ubuntu phone and tablet OS and UI, and played everything much quieter until they'd actually landed hardware partners. It's obviously early days, but I think there's much to be quietly confident about: there's a lot to like in the OS and app design, and it is now by a long stretch the most free (as in freedom) phone OS available.
Interesting. I'll have to look into that more. (Such as, will it run on Android phones or does it need separate hardware?)
Jun 22 2015
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Monday, 22 June 2015 at 21:50:22 UTC, Nick Sabalausky wrote:
 Interesting. I'll have to look into that more. (Such as, will 
 it run on Android phones or does it need separate hardware?)
Well, the commercially-released phones (two so far from BQ Readers, and one to be put on sale in the EU either today or tomorrow by Meizu) all come with Ubuntu pre-installed, but from what I understand it should be possible to port to run on any device which Android can run on: https://developer.ubuntu.com/en/start/ubuntu-for-devices/porting-new-device/ Embedded OS architecture isn't really my comfort zone, but as far as I can see, they use an Android-derived hardware compatibility layer where any proprietary components (drivers etc.) are isolated from the rest of the OS. The idea is that the Ubuntu OS, the applications, and the hardware support can all be updated independently of one another, i.e. a manufacturer can't lock you in to a particular OS version through the need for particular proprietary hardware drivers.
Jun 24 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/24/2015 11:34 AM, Joseph Rushton Wakeling wrote:
 Embedded OS architecture isn't really my comfort zone, but as far as I
 can see, they use an Android-derived hardware compatibility layer where
 any proprietary components (drivers etc.) are isolated from the rest of
 the OS.
I've always found it absolutely stunningly bad that Android doesn't do that already. I mean, they sort of do, but not very well. Ordinarily, I subscribe quite strongly to Hanlon's razor[1], but in this case I suspect it may be a deliberate business decision to keep their hardware and telecom partners happy. [1] "Never attribute to malice that which is adequately explained by stupidity."
Jun 24 2015
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Saturday, 20 June 2015 at 19:00:08 UTC, Joakim wrote:
 Pretty soon it won't. :) There are an estimated 2.5 billion 
 smartphone users:

 http://www.asymco.com/2014/04/07/postmodern-computing/

 The highest estimates of desktop and laptop users I've seen 
 don't crack 2 billion.  That means desktops are already a 
 minority platform.
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.
 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?
 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.
Jun 21 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
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.
Jun 21 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/21/2015 06:29 AM, Kagamin wrote:
 On Saturday, 20 June 2015 at 19:00:08 UTC, Joakim wrote:
 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.
I think the history of the web all the way up through now proves quite well that web devs *will never* standardize on any sort of "proper way to do things" unless some outside factor forces it.
  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.
Uhh...not these days. These days they mostly all love their gigantic one-inch fonts. Half the websites I visit, I have to zoom *out* just to make reading it reasonably comfortable. (Meh, and then on mobile I have to zoom waaay in before attempting to click on any links, because mobile device manufacturers seem to think my fingers are every bit as slender and precise as a resistive or active stylus. Seriously, when my contract's up I'm moving to a Galaxy Note. F* this Sh* ;) )
Jun 21 2015
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
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
Jun 19 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jun 19 2015
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Jun 19 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jun 19 2015
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 19 June 2015 at 14:47:10 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 19 June 2015 at 14:18:49 UTC, Wyatt wrote:

 Do you guys have any real arguments against SVG? It is 
 currently the most useful interchangeformat for 2D vector 
 graphics.
You want reasons I dislike SVG? I can address a few different levels. It's unbelievably complex even if you reduce it to just the still-graphics parts. This means implementing a renderer it is not even close to trivial (you need to support a huge chunk of CSS, for one thing) and rendering consistency is difficult to get right even in fairly simple situations.[1] Fill rules, path joining, stroke scaling, markers, filters, paint order, the list goes on. It's very byzantine. It's DOM-based anyway, which means you can't reasonably expect good performance when manipulating it in an editor (it only pays lip-service to the concept of "human readable", so you really NEED an editor) or memory requirements. Even just rendering it for output on a device has poor performance (I don't even know if Nvidia has even bothered putting more work into their OpenGL extension for 2D vectors). Even relatively simple animations in SVG can peg a CPU core. It only supports linear gradients, which makes it basically useless for artistic work unless you live in a "Modern" bubble. There's no support for variable stroke width. You can only define one stroke and one fill, so if you want to composite those things, you need to do a lot of duplication. On top of that, blending can only be done through filters (which are milquetoast at best). And text in SVG is...ugh, let's not even start. SVG is somewhat useful if you only need simple diagrams with solid colours and you don't trust PNG for some reason. -Wyatt [1] http://tavmjong.free.fr/blog/?p=1257
Jun 19 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 19 June 2015 at 16:23:00 UTC, Wyatt wrote:
 You want reasons I dislike SVG?  I can address a few different 
 levels.

 It's unbelievably complex even if you reduce it to just the 
 still-graphics parts.  This means implementing a renderer it is 
 not even close to trivial (you need to support a huge chunk of
Yes, it is not for end-user renderers. However, you can reduce most of the useful subset of SVG to paths and transforms.
 Even just rendering it for output on a device has poor 
 performance
That really depends on the engine, of course, as well as the composition of the graphics, what kind of animation etc. If you know how the composition affects the renderer you can get decent performance. You obviously should not use filter effects on animations.
 It only supports linear gradients, which makes it basically 
 useless for artistic work unless you live in a "Modern" bubble.
Oh well, what you call "Modern" I would call timeless. I think most logos can be done well in it.
  There's no support for variable stroke width.  You can only 
 define one stroke and one fill, so if you want to composite 
 those things, you need to do a lot of duplication.  On top of 
 that, blending can only be done through filters (which are 
 milquetoast at best).  And text in SVG is...ugh, let's not even 
 start.
Text in SVG works fine. I've used it for buttons. I think they probably should've left out the filters and stuck with aspect that better suits CSS-theming though.
 SVG is somewhat useful if you only need simple diagrams with 
 solid colours and you don't trust PNG for some reason.
SVG is perfectly fine for any kind of decals, logos, buttons. PNG is way more tedious.
Jun 19 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
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 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.
Jun 19 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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 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.
Jun 19 2015
parent reply "Kagamin" <spam here.lot> writes:
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.
Jun 19 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jun 19 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
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.
Jun 19 2015
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/19/2015 04:08 AM, Kagamin wrote:

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.
Jun 19 2015
parent reply "Kagamin" <spam here.lot> writes:
On Friday, 19 June 2015 at 15:13:11 UTC, Joakim wrote:
 Hmm... Web: write once with html, css, js. Native: write three 

 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.
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. I didn't really try to write java, but my impression is that java usually requires huge amounts of boilerplate code, while web is usually succinct.
 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.
Dunno, I don't see there losses, maybe because they only happen on mobile. Yeah, you said nothing about how this is related to desktop as if it doesn't exist. On Friday, 19 June 2015 at 15:45:20 UTC, Nick Sabalausky wrote:
 We need some sort of SVG-BSON, or something along those lines.
There's EXI.
Jun 20 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 20 Jun 2015 15:21:28 +0000, 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.
/me wonders if windows still cannot into dynamic layouts. in any decent=20 gui lib it's actually *harder* to build a gui which screws itself up on=20 font size/window size change.
 And this is where
 web actually shines: it's designed to adapt gracefully to any user
 settings.
it was designed to ignore that fact altogether. html/css layouting is a=20 pitiful attempt and barely usable. bwah, it can't even do normal=20 constraints! =
Jun 20 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
 it was designed to ignore that fact altogether. html/css 
 layouting is a pitiful attempt and barely usable. bwah, it 
 can't even do normal constraints!
Hmmm, what do you mean by normal constraints? Modern CSS provides many options, too many. CSS is no longer a simple system... So it is probably common to use javascript where CSS could have been sufficient.
Jun 20 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 20 Jun 2015 16:14:43 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
 it was designed to ignore that fact altogether. html/css layouting is a
 pitiful attempt and barely usable. bwah, it can't even do normal
 constraints!
=20 Hmmm, what do you mean by normal constraints?
google://cassowary that is a *real* constraint engine. what we have in css is a half-assed=20 attemt to emulate the real engine without the engine itself. =
Jun 20 2015
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/20/2015 12:20 PM, ketmar wrote:
 On Sat, 20 Jun 2015 16:14:43 +0000, Ola Fosheim Grøstad wrote:

 On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
 it was designed to ignore that fact altogether. html/css layouting is a
 pitiful attempt and barely usable. bwah, it can't even do normal
 constraints!
Hmmm, what do you mean by normal constraints?
google://cassowary that is a *real* constraint engine. what we have in css is a half-assed attemt to emulate the real engine without the engine itself.
I can see why people aren't familiar with that and it's approach: There's zero front-page examples, and any basic "examples 101", "how to use it" seem well-buried. Most people are gonna take one brief look and move on. It seems to really need some better PR.
Jun 20 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 20 Jun 2015 12:32:11 -0400, Nick Sabalausky wrote:

 On 06/20/2015 12:20 PM, ketmar wrote:
 On Sat, 20 Jun 2015 16:14:43 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
 it was designed to ignore that fact altogether. html/css layouting is
 a pitiful attempt and barely usable. bwah, it can't even do normal
 constraints!
Hmmm, what do you mean by normal constraints?
google://cassowary that is a *real* constraint engine. what we have in css is a half-assed attemt to emulate the real engine without the engine itself.
I can see why people aren't familiar with that and it's approach: There's zero front-page examples, and any basic "examples 101", "how to use it" seem well-buried. Most people are gonna take one brief look and move on. It seems to really need some better PR.
it's actually a tool for toolkit builders, not for end users. cassowary=20 itself is only a solver, it doesn't even have syntax to setup constraints=20 (toolkit builder must invent an implement one). so it's hard to make example for it which doesn't resemble a wall of text=20 several pages long only to layout three elements. the real power of cassowary is it's dynamic constraint solver. but it=20 needs to be combined with user-friendly constraint syntax, or it will be=20 unusable. so cassowary authors have to write their own toolkit only to=20 show some impressive examples on site! ;-) besides, cassowary comes from "university culture", where user-friendly=20 presentations are bad or non-existent. tl;dr: i completely agree with you! ;-)=
Jun 20 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 20 June 2015 at 16:20:31 UTC, ketmar wrote:
 On Sat, 20 Jun 2015 16:14:43 +0000, Ola Fosheim Grøstad wrote:

 On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
 it was designed to ignore that fact altogether. html/css 
 layouting is a pitiful attempt and barely usable. bwah, it 
 can't even do normal constraints!
Hmmm, what do you mean by normal constraints?
google://cassowary that is a *real* constraint engine. what we have in css is a half-assed attemt to emulate the real engine without the engine itself.
Keep in mind that a webpage is being rendered while loading…
Jun 20 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 20 Jun 2015 19:40:35 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 On Saturday, 20 June 2015 at 16:20:31 UTC, ketmar wrote:
 On Sat, 20 Jun 2015 16:14:43 +0000, Ola Fosheim Gr=C3=83=C2=B8stad wrote=
:
 On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
 it was designed to ignore that fact altogether. html/css layouting is
 a pitiful attempt and barely usable. bwah, it can't even do normal
 constraints!
=20 Hmmm, what do you mean by normal constraints?
google://cassowary that is a *real* constraint engine. what we have in css is a half-assed attemt to emulate the real engine without the engine itself.
=20 Keep in mind that a webpage is being rendered while loading=E2=80=A6
1. cassowary is dynamic solver, it can continuously adjust it's solution=20 as more and more constraints are added. actually, that is one of it's=20 core features. 2. actually, we should drop that "progressive rendering". so-called "web=20 apps" already dropped that, drawing rotating shit icon instead while they=20 are loading megabytes of js. there is no sense to support progressive=20 rendering anymore: it's either not working completely with "modern web- pages", or page looks like random jumping crap until it fully loads.=
Jun 23 2015
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/23/2015 03:03 PM, ketmar wrote:
 2. actually, we should drop that "progressive rendering". so-called "web
 apps" already dropped that, drawing rotating shit icon instead while they
 are loading megabytes of js. there is no sense to support progressive
 rendering anymore: it's either not working completely with "modern web-
 pages", or page looks like random jumping crap until it fully loads.
Hadn't thought of that before, but that's a good point. Plus, all that background loading and processing just borks the responsiveness of webpage to the point of being effectively-unusable anyway (and even the browser as a while, depending on browser. Mobile ones seem to be worse here.) I'd just as soon the browser do it's thing and get back to me whenever it's finally ready to show it and actually respond to my input events. Progressive rendering made sense back when you could literally watch each image on the page gradually get pulled in over the wire (and when the layout more or less matched the HTML as it came in over-the-wire). But now it's mostly just a clunky user experience.
Jun 23 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 23 June 2015 at 19:42:53 UTC, Nick Sabalausky wrote:
 Progressive rendering made sense back when you could literally 
 watch each image on the page gradually get pulled in over the 
 wire (and when the layout more or less matched the HTML as it 
 came in over-the-wire). But now it's mostly just a clunky user 
 experience.
It still makes a lot of sense. The key is to organize the page so that the top part is reach a stable state while the rest of the page loads. Other solutions will have to wait until we can kiss IE9 goodbye for good. (not yet) You may also embed images in the HTML. Just try "view image in new window" on amazon. So you can embed images in the upper part of your webpage for faster initial display if you want.
Jun 23 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 24 Jun 2015 06:38:38 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 On Tuesday, 23 June 2015 at 19:42:53 UTC, Nick Sabalausky wrote:
 Progressive rendering made sense back when you could literally watch
 each image on the page gradually get pulled in over the wire (and when
 the layout more or less matched the HTML as it came in over-the-wire).
 But now it's mostly just a clunky user experience.
=20 It still makes a lot of sense. The key is to organize the page so that the top part is reach a stable state while the rest of the page loads.
with the current trend to make a page consisting of huge fullscreen image=20 and three columns of useless bla-bla text under it, it doesn't really=20 matter if you will see the page sooner: there is no useful information=20 anyway. ;-)=
Jun 24 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/24/2015 11:37 AM, ketmar wrote:
 with the current trend to make a page consisting of huge fullscreen image
 and three columns of useless bla-bla text under it, it doesn't really
 matter if you will see the page sooner: there is no useful information
 anyway. ;-)
Hear, hear! :)
Jun 24 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 23 June 2015 at 19:03:14 UTC, ketmar wrote:
 1. cassowary is dynamic solver, it can continuously adjust it's 
 solution as more and more constraints are added. actually, that 
 is one of it's core features.
Ah ok, but I suppose that would also mean that things may jump around during loading. You should implement in D and build a GUI over it. ;)
Jun 23 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 24 Jun 2015 06:43:00 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 On Tuesday, 23 June 2015 at 19:03:14 UTC, ketmar wrote:
 1. cassowary is dynamic solver, it can continuously adjust it's
 solution as more and more constraints are added. actually, that is one
 of it's core features.
=20 Ah ok, but I suppose that would also mean that things may jump around during loading.
yes. yet cassowary tries to maintain stability of solution while it's=20 sane -- it was created for GUI layouting, so authors tried to make GUIs=20 with changing elements more or less stable.
 You should implement in D and build a GUI over it. ;)
i ported it to D some time ago. and yes, GUI lib that i'm writing now=20 will support Cassowary as one of available layout engines. that's why i=20 did the porting in the first place! ;-)=
Jun 24 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/24/2015 11:34 AM, ketmar wrote:
 i ported [cassowary] to D some time ago.
Github?
Jun 24 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 24 Jun 2015 12:30:27 -0400, Nick Sabalausky wrote:

 On 06/24/2015 11:34 AM, ketmar wrote:
 i ported [cassowary] to D some time ago.
=20 Github?
no, repo.or.cz ;-) http://forum.dlang.org/thread/btoozbdfmuoopdrfrxgy forum.dlang.org that repo is slightly outdated, as i moved the port to my IV library (and=20 aliced it, so no vanilla anymore...) there is another port mentioned in that thread, it's even available on=20 code.dlang.org.=
Jun 24 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
 On Sat, 20 Jun 2015 15:21:28 +0000, 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.
/me wonders if windows still cannot into dynamic layouts. in any decent gui lib it's actually *harder* to build a gui which screws itself up on font size/window size change.
Windows API would be similar to X11, where you just specify everything in pixels and toolkits building on top of it manually do all the recomputations and layout policies, not the UI server. And then it's still not simple: with small font you can put a lot of information into a window, which simply won't fit with bigger font size, in this case web gets scrolled naturally, while native UI clunks interface and truncates strings trying to fit it into the window.
Jun 20 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 20 Jun 2015 16:18:28 +0000, Kagamin wrote:

 Windows API would be similar to X11, where you just specify everything
 in pixels and toolkits building on top of it manually do all the
 recomputations and layout policies, not the UI server.
only in windows "toolkit" is built into system. and it can't do anything=20 except pixels and stupid "dialog units".
 And then it's still not simple: with small font you can put a lot of
 information into a window, which simply won't fit with bigger font size,
 in this case web gets scrolled naturally, while native UI clunks
 interface and truncates strings trying to fit it into the window.
i lol'd. a typical windows rant, where "toolkits" still doesn't know=20 about such things as "preferred size", "minimal size", and can't add=20 scrolling if necessary, choosing to make controls smaller and smaller=20 instead.=
Jun 20 2015
parent reply "Kagamin" <spam here.lot> writes:
On Saturday, 20 June 2015 at 16:23:47 UTC, ketmar wrote:
 On Sat, 20 Jun 2015 16:18:28 +0000, Kagamin wrote:

 Windows API would be similar to X11, where you just specify 
 everything in pixels and toolkits building on top of it 
 manually do all the recomputations and layout policies, not 
 the UI server.
only in windows "toolkit" is built into system. and it can't do anything except pixels and stupid "dialog units".
Well, it's just windows api was simple enough to be usable directly, while X11 didn't fly that way and didn't receive development since everybody used toolkits and all features were implemented in toolkits, which in the end used X11 as plain canvas rather than windowing system.
 And then it's still not simple: with small font you can put a 
 lot of information into a window, which simply won't fit with 
 bigger font size, in this case web gets scrolled naturally, 
 while native UI clunks interface and truncates strings trying 
 to fit it into the window.
i lol'd. a typical windows rant, where "toolkits" still doesn't know about such things as "preferred size", "minimal size", and can't add scrolling if necessary, choosing to make controls smaller and smaller instead.
Knowing minimal size won't help you if the amount of information simply doesn't fit. Dialogs can be scrolled, but master-detail views can't: master and detail views already reserve scrolling for themselves, so it can't be reused for the entire window, well, at least it won't work naturally.
Jun 20 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 20 Jun 2015 17:00:43 +0000, Kagamin wrote:

 Well, it's just windows api was simple enough to be usable directly,
 while X11 didn't fly that way and didn't receive development since
 everybody used toolkits and all features were implemented in toolkits,
 which in the end used X11 as plain canvas rather than windowing system.
nope, X is a window system. it's windows which is *not* window system,=20 but window system with very simplistic toolkit bolted on top of it. that=20 was not a bad idea considering the hardware windows aimed, but now it's a=20 legacy crap, and almost anyone is hacking around it.
 Knowing minimal size won't help you if the amount of information simply
 doesn't fit.
somehow it still works for me.
 Dialogs can be scrolled, but master-detail views can't:
 master and detail views already reserve scrolling for themselves, so it
 can't be reused for the entire window, well, at least it won't work
 naturally.
i believe that we should stop here, as we are clearly talking about=20 different things. i can't even imagine why widget may want to "reserve=20 scrolling for itself" and what that means. and i can't see why any part=20 of window can't be scrolled, especially when you have a clear widget=20 hierarchy, and detail views living in their own containers.=
Jun 23 2015
parent reply "Kagamin" <spam here.lot> writes:
On Tuesday, 23 June 2015 at 18:58:00 UTC, ketmar wrote:
 nope, X is a window system. it's windows which is *not* window 
 system, but window system with very simplistic toolkit bolted 
 on top of it. that was not a bad idea considering the hardware 
 windows aimed, but now it's a legacy crap, and almost anyone is 
 hacking around it.
That's just OO wrappers.
 Knowing minimal size won't help you if the amount of 
 information simply doesn't fit.
somehow it still works for me.
 Dialogs can be scrolled, but master-detail views can't:
 master and detail views already reserve scrolling for 
 themselves, so it
 can't be reused for the entire window, well, at least it won't 
 work
 naturally.
i believe that we should stop here, as we are clearly talking about different things. i can't even imagine why widget may want to "reserve scrolling for itself" and what that means. and i can't see why any part of window can't be scrolled, especially when you have a clear widget hierarchy, and detail views living in their own containers.
I'm talking about native UI getting screwed up on high DPI. Native UI is supposed to fit whatever space it's given, otherwise it works, but not as good as it's supposed to. Imagine your desktop doesn't fit the screen and gets scrolled. On the other hand web was supposed to be scrolled from the beginning, hence it can better adapt to different settings.
Jun 24 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 24 Jun 2015 11:44:09 +0000, Kagamin wrote:

 I'm talking about native UI getting screwed up on high DPI. Native UI is
 supposed to fit whatever space it's given, otherwise it works, but not
 as good as it's supposed to. Imagine your desktop doesn't fit the screen
 and gets scrolled. On the other hand web was supposed to be scrolled
 from the beginning, hence it can better adapt to different settings.
yeah. that's why people constantly complains that the very same web pages=20 looks like crap on their mobiles, or on their desktops. a perfect fit! as i told -- you have absolutely no idea about layouting, and why html=20 model suxalot.=
Jun 24 2015
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 24 June 2015 at 15:30:58 UTC, ketmar wrote:
 yeah. that's why people constantly complains that the very same 
 web pages looks like crap on their mobiles, or on their 
 desktops. a perfect fit!
That's because they are designed to be pixel-precise, like native UI, so they have the same issues with user settings as native UI. But poor design choice is a responsibility of the respective designer. Well, this was already said many times in this thread.
Jun 24 2015
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/24/2015 11:45 AM, Kagamin wrote:
 On Wednesday, 24 June 2015 at 15:30:58 UTC, ketmar wrote:
 yeah. that's why people constantly complains that the very same web
 pages looks like crap on their mobiles, or on their desktops. a
 perfect fit!
That's because they are designed to be pixel-precise, like native UI, so they have the same issues with user settings as native UI. But poor design choice is a responsibility of the respective designer. Well, this was already said many times in this thread.
It's not always because of being designed to be pixel-precise. "Responsive design" and "mobile-first" are very deliberately NOT pixel-precise, but most of them look like shit on the desktop (at least until you zoom out about ten times). That's because with such sites, desktop often ends up getting treated as if it were a high-DPI 5"-6" screen. The new "vw" font size units are going to lead to even more disaster in that regard.
Jun 24 2015
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 24 June 2015 at 16:42:28 UTC, Nick Sabalausky wrote:
 It's not always because of being designed to be pixel-precise. 
 "Responsive design" and "mobile-first" are very deliberately 
 NOT pixel-precise, but most of them look like shit on the 
 desktop (at least until you zoom out about ten times).
http://abload.de/img/tmpm5p88.png Lucky you are if you have only problems with font size. There's also a problem that people don't set up their preferred font size, so it's understandable that designers may want to work this around. And e.g. FF doesn't honor that setting anyway.
Jun 25 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 25 June 2015 at 08:13:07 UTC, Kagamin wrote:
 Lucky you are if you have only problems with font size. There's 
 also a problem that people don't set up their preferred font 
 size, so it's understandable that designers may want to work 
 this around. And e.g. FF doesn't honor that setting anyway.
Apple messed up the whole preferred font size by having a smaller default size for Safari than other browsers. That meant that the site looked wrong on Safari if not hardcoding the font-size, from the viewpoint of customers. YMMV. If the site is "responsive" you should get it right by zooming the whole page anyway. And it makes sense to have larger figures if you need larger fonts. Others in the thread has used the term "pixel perfect" to refer to the "px" unit. FWIW "px" does not refer to pixel, but is a perception related unit which is based on the normal view distance to the screen. This is usually rounded off to the closest whole pixel block (1x2, 2x2, 3x3 etc).
Jun 25 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 24 Jun 2015 15:45:46 +0000, Kagamin wrote:

 That's because they are designed to be pixel-precise, like native UI
in *my* world, native UIs doesn't even know what "pixel" is.=
Jun 24 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 18 Jun 2015 08:05:46 +0000, 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.
=20
 https://www.w3.org/community/webassembly/
=20
 https://github.com/WebAssembly
=20
 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
they will never stop, won't they? "modern web: building piles of shit on=20 top of piles of shit". (sigh)=
Jun 18 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 18 June 2015 at 11:00:37 UTC, ketmar wrote:
 they will never stop, won't they? "modern web: building piles 
 of shit on top of piles of shit". (sigh)
Indeed. «Even before browsers ship native support for WebAssembly, developers can ship applications on the Web using a polyfill which converts WebAssembly to JavaScript. » Basically binary asm.js... What are they thinking? And whyyyyyyy are they calling a binary format "assembly"?
Jun 18 2015
next sibling parent reply David Gileadi <gileadis NSPMgmail.com> writes:
On 6/18/15 10:41 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 And whyyyyyyy are they calling a binary format "assembly"?
Because it sounds faster, of course :)
Jun 18 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 18 June 2015 at 18:14:09 UTC, David Gileadi wrote:
 On 6/18/15 10:41 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 And whyyyyyyy are they calling a binary format "assembly"?
Because it sounds faster, of course :)
I can't wait for the GTO version, I bet it is even faster!
Jun 18 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 18 June 2015 at 17:41:44 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 18 June 2015 at 11:00:37 UTC, ketmar wrote:
 they will never stop, won't they? "modern web: building piles 
 of shit on top of piles of shit". (sigh)
Indeed. «Even before browsers ship native support for WebAssembly, developers can ship applications on the Web using a polyfill which converts WebAssembly to JavaScript. » Basically binary asm.js... What are they thinking? And whyyyyyyy are they calling a binary format "assembly"?
wow I didn't even read it, I thought it was going to be like a standardized pnacl from the naming. this is ridiculous, you could release /dev/null for the web and it would generate unlimited hype.
Jun 18 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 18 June 2015 at 18:15:32 UTC, weaselcat wrote:
 I didn't even read it, I thought it was going to be like a 
 standardized pnacl from the naming.
Well, it is hard to say what it will become, maybe it is possible come up with an IR that doesn't sacrifice performance and still can easily be translated into Javascript with reasonable performance. But what's the point? One could compile an application to both asm.js and WebAssembly instead. Sounds like politics could turn this into a long stumbling process.
Jun 18 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 18 June 2015 at 18:33:16 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 18 June 2015 at 18:15:32 UTC, weaselcat wrote:
 I didn't even read it, I thought it was going to be like a 
 standardized pnacl from the naming.
Well, it is hard to say what it will become, maybe it is possible come up with an IR that doesn't sacrifice performance and still can easily be translated into Javascript with reasonable performance. But what's the point? One could compile an application to both asm.js and WebAssembly instead. Sounds like politics could turn this into a long stumbling process.
That is already the case. Mozilla dropped the NaCl wagon in the middle of the road, letting Google alone on that one, to promote their concurrent ill advised "standard". Now there is 2 standard, one that is actually pretty good, but supported only by google, and another one that is retarded, but supported more widely. As nobody want to admit they fucked up, the whole joyous band of over-bloated bogus standard designers decided to bless us with a 3rd "standard" that is roughly equivalent to PNaCl, but is not PNaCl, because pride is more important that webdev's sanity.
Jun 18 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 18 June 2015 at 21:51:15 UTC, deadalnix wrote:
 Now there is 2 standard, one that is actually pretty good, but 
 supported only by google, and another one that is retarded, but 
 supported more widely. As nobody want to admit they fucked up, 
 the whole joyous band of over-bloated bogus standard designers 
 decided to bless us with a 3rd "standard" that is roughly 
 equivalent to PNaCl, but is not PNaCl, because pride is more 
 important that webdev's sanity.
I looked into PNaCl a bit, but when it comes to Google I always get the feeling that they feel it is sufficient to make native programming possible rather than pleasant. Same for Android NDK, and some might say Go (perhaps unfair). In that respect WebAssembly is a good thing, if it takes off, the browser-competition means that they will need to focus on tooling/in-browser-debugging. I haven't been able to figure out if it will support a GC?
Jun 18 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 18 June 2015 at 22:07:06 UTC, Ola Fosheim Grøstad 
wrote:
 I looked into PNaCl a bit, but when it comes to Google I always 
 get the feeling that they feel it is sufficient to make native 
 programming possible rather than pleasant. Same for Android 
 NDK, and some might say Go (perhaps unfair).

 In that respect WebAssembly is a good thing, if it takes off, 
 the browser-competition means that they will need to focus on 
 tooling/in-browser-debugging.

 I haven't been able to figure out if it will support a GC?
PNaCl is not meant to be used as such. You do you code in some other language and compile it to PNaCl. Mozilla made it a Google thing. They basically dropped the project int he middle of the road to push their alternative standard, asm.js . This created the mess we see here in the first place. They fucked up and now don't want to admit it, so now we need 3 "standards" instead of one.
Jun 18 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 18 June 2015 at 22:20:25 UTC, deadalnix wrote:
 On Thursday, 18 June 2015 at 22:07:06 UTC, Ola Fosheim Grøstad 
 wrote:
 I haven't been able to figure out if it will support a GC?
PNaCl is not meant to be used as such. You do you code in some other language and compile it to PNaCl.
Yeah, I know, I meant the whole environment with Pepper. For WebAssembly to take off it probably has to support languages like Ruby, Python and others that are used on the server. Guess they could do debugging using "source maps"... I think too many people care about IE for PNaCl to take off without Microsoft support. asm.js had a strategic advantage by running on all platforms, so browser vendors couldn't avoid supporting it, either add some optimizations for it or appear sluggish.
Jun 18 2015
prev sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 18 June 2015 at 22:20:25 UTC, deadalnix wrote:
 On Thursday, 18 June 2015 at 22:07:06 UTC, Ola Fosheim Grøstad 
 wrote:
 I looked into PNaCl a bit, but when it comes to Google I 
 always get the feeling that they feel it is sufficient to make 
 native programming possible rather than pleasant. Same for 
 Android NDK, and some might say Go (perhaps unfair).

 In that respect WebAssembly is a good thing, if it takes off, 
 the browser-competition means that they will need to focus on 
 tooling/in-browser-debugging.

 I haven't been able to figure out if it will support a GC?
PNaCl is not meant to be used as such. You do you code in some other language and compile it to PNaCl. Mozilla made it a Google thing. They basically dropped the project int he middle of the road to push their alternative standard, asm.js . This created the mess we see here in the first place. They fucked up and now don't want to admit it, so now we need 3 "standards" instead of one.
This appears to be the coming together of all those teams to finally work together, as noted by a Chrome developer, Peter Kasting: http://arstechnica.com/information-technology/2015/06/the-web-is-getting-its-bytecode-webassembly/?comments=1&post=29227533 He justifies the previous efforts as laying the groundwork for this standard, which is certainly reasonable.
Jun 18 2015
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/18/2015 01:41 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Thursday, 18 June 2015 at 11:00:37 UTC, ketmar wrote:
 they will never stop, won't they? "modern web: building piles of shit
 on top of piles of shit". (sigh)
Indeed. «Even before browsers ship native support for WebAssembly, developers can ship applications on the Web using a polyfill which converts WebAssembly to JavaScript. »
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.
 Basically binary asm.js... What are they thinking?
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. But the web world has always been so very NIH-syndrome, though.
 And whyyyyyyy are they calling a binary format "assembly"?
Probably because .NET/Mono have already established the name "assembly" for that sort of thing. That'd be my guess. They could call it an "object file" but that would intuitively suggest something more along the lines of ELF/COFF/whatever, which I assume isn't quite what they have in mind.
Jun 18 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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 my experience performance issues usually are in the layout/render engine, or something related to it.
 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? Of course, in 5 years hardware has changed and regular Javascript JITs have improved, so by then we need WebAssembly2… So, 8 years?
Jun 18 2015
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/18/2015 05:21 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 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 my experience performance issues usually are in the layout/render
 engine, or something related to it.
The layout/render stuff has to support so much dynamic-DOM cruft on every...single...element...of the page, it's pretty much inevitable that the browser itself is where the bottleneck is on a normal page, rather than network. (Which is really weird if you look at it from the perspective of someone who remembers dial-up.)
Jun 18 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 18 June 2015 at 22:24:09 UTC, Nick Sabalausky wrote:
 On 06/18/2015 05:21 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 The layout/render stuff has to support so much dynamic-DOM 
 cruft on every...single...element...of the page, it's pretty 
 much inevitable that the browser itself is where the bottleneck 
 is on a normal page, rather than network.
My impression is that browsers focus too much on typical layout, which makes using it as a generic programming platform challenging when you scale up. Like, using lots of absolute positioning ought to be easy on reflow, but in my experience it isn't. But I think it is unforgivable that Chrome still stutters when doing longer animations. The biggest browsers never need to fix their issues because everybody works around them anyway.
 (Which is really weird if you look at it from the perspective 
 of someone who remembers dial-up.)
I believe I browsed BBSes with a borrowed 300 baud modem with "earmuffs" that you attach physically to a real phone handset. With a font using 4bit wide characters to get 80 columns on a 40 columns computer. Barely readable. :)
Jun 18 2015
prev sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
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
Jun 19 2015
prev sibling parent "Max Samukha" <maxsamukha gmail.com> writes:
On Thursday, 18 June 2015 at 11:00:37 UTC, ketmar wrote:

 piles of shit on top of piles of shit
A good definition of evolution.
Jun 18 2015
prev sibling next sibling parent "Mattcoder" <stop spam.com.br> writes:
On Thursday, 18 June 2015 at 08:05:48 UTC, John Colvin wrote:
 ...
I hope this don't turn into this: https://imgs.xkcd.com/comics/standards.png Matheus.
Jun 18 2015
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 18 June 2015 at 08:05:48 UTC, 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
What a fucking waste. We had that years ago with NaCl. Mozilla really fucked up on that one. Let's how that goes. I'd be supportive of any effort for SDC to support this, but really don't have enough bandwidth to work on it myself.
Jun 18 2015
prev sibling next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 18 Jun 2015 08:05:46 +0000
schrieb "John Colvin" <john.loughran.colvin gmail.com>:

 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'd be more happy with code that runs outside and independently of the browser, but it seems to be the trend to move everything into virtual machines and browsers. I see the main reason notebooks have to be replaced every few years as once again <memory per open tab> * 15 >= 50% <installed system ram>. If you have a perfectly working old notebook with Windows XP on it, I can recommend QtWeb for its low resource usage and modern-ish feature set. It is a little unstable and rough around the edges though: http://www.qtweb.net/ -- Marco
Jun 20 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 20 Jun 2015 14:06:50 +0200, Marco Leise wrote:

 If you have a perfectly working old notebook with Windows XP on it, I
 can recommend QtWeb for its low resource usage and modern-ish feature
 set. It is a little unstable and rough around the edges though:
 http://www.qtweb.net/
Qt+WebKit. low resource usage. you must be joking.=
Jun 20 2015
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Sat, 20 Jun 2015 15:15:47 +0000 (UTC)
schrieb ketmar <ketmar ketmar.no-ip.org>:

 On Sat, 20 Jun 2015 14:06:50 +0200, Marco Leise wrote:
 
 If you have a perfectly working old notebook with Windows XP on it, I
 can recommend QtWeb for its low resource usage and modern-ish feature
 set. It is a little unstable and rough around the edges though:
 http://www.qtweb.net/
Qt+WebKit. low resource usage. you must be joking.
No I was serious. I compared it to pretty much every other complete graphical web browser on XP and it "won" by a big margin. (I opened 5 different web sites in each browser and compared their memory use in the task manager). Remember when tabbed browsing was no option on old notebooks? Now it is and my preference in terms of closing old tabs is doing it like a mark and sweep garbage collector - every once in a while. -- Marco
Sep 09 2015
parent reply yawniek <dlang srtnwz.com> writes:
https://hacks.mozilla.org/2015/12/compiling-to-webassembly-its-happening/
Dec 17 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 17 December 2015 at 20:22:41 UTC, yawniek wrote:
 https://hacks.mozilla.org/2015/12/compiling-to-webassembly-its-happening/
Thanks for sharing! This looks promising.
Dec 18 2015
parent reply Suliman <evermind live.ru> writes:
On Friday, 18 December 2015 at 10:21:49 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 17 December 2015 at 20:22:41 UTC, yawniek wrote:
 https://hacks.mozilla.org/2015/12/compiling-to-webassembly-its-happening/
Thanks for sharing! This looks promising.
Could anybody show how C++ App for web will look like? I really can't fund any examples except AST. Would it have access to DOM or it would look like Java applet?
Dec 22 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 23 December 2015 at 07:37:39 UTC, Suliman wrote:
 On Friday, 18 December 2015 at 10:21:49 UTC, Ola Fosheim 
 Grøstad wrote:
 On Thursday, 17 December 2015 at 20:22:41 UTC, yawniek wrote:
 https://hacks.mozilla.org/2015/12/compiling-to-webassembly-its-happening/
Thanks for sharing! This looks promising.
Could anybody show how C++ App for web will look like? I really can't fund any examples except AST. Would it have access to DOM or it would look like Java applet?
WebAssembly is an AST representation, so I'm not sure what else you expect than an AST ?
Dec 23 2015
parent reply Suliman <evermind live.ru> writes:
On Wednesday, 23 December 2015 at 10:02:18 UTC, deadalnix wrote:
 On Wednesday, 23 December 2015 at 07:37:39 UTC, Suliman wrote:
 On Friday, 18 December 2015 at 10:21:49 UTC, Ola Fosheim 
 Grøstad wrote:
 On Thursday, 17 December 2015 at 20:22:41 UTC, yawniek wrote:
 https://hacks.mozilla.org/2015/12/compiling-to-webassembly-its-happening/
Thanks for sharing! This looks promising.
Could anybody show how C++ App for web will look like? I really can't fund any examples except AST. Would it have access to DOM or it would look like Java applet?
WebAssembly is an AST representation, so I'm not sure what else you expect than an AST ?
For example I do not know JS. And only C++. How would look like my web-app with WASM?
Dec 23 2015
parent Abdulhaq <alynch4047 gmail.com> writes:
On Wednesday, 23 December 2015 at 10:06:20 UTC, Suliman wrote:
 For example I do not know JS. And only C++. How would look like 
 my web-app with WASM?
First have a look at this, qt-emscripten: http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos WASM will allow programming languages and libraries to be compiled down to WASM code and then run in the browser, rather like is happening with qt-emscripten (C++ is converted to javascript). As regards how it is rendered, DOM, OpenGL etc., I guess that will be an implementation choice.
Dec 23 2015
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 18 June 2015 at 08:05:48 UTC, 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
So it has been 13 pages of heated debate, but no PR is to be seen for LDC or SDC...
Jun 25 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 25 June 2015 at 18:38:59 UTC, deadalnix wrote:
 On Thursday, 18 June 2015 at 08:05:48 UTC, 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
So it has been 13 pages of heated debate, but no PR is to be seen for LDC or SDC...
Well, first we have to decide if a PR would even be worthwhile... ;)
Jun 25 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 26 June 2015 at 01:16:37 UTC, Joakim wrote:
 On Thursday, 25 June 2015 at 18:38:59 UTC, deadalnix wrote:
 On Thursday, 18 June 2015 at 08:05:48 UTC, 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
So it has been 13 pages of heated debate, but no PR is to be seen for LDC or SDC...
Well, first we have to decide if a PR would even be worthwhile... ;)
By this time we'd have a PR and we could play with it to decide using first hand experience.
Jun 25 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 June 2015 at 02:29:40 UTC, deadalnix wrote:
 By this time we'd have a PR and we could play with it to decide 
 using first hand experience.
For which browser? It isn't implemented, is it?
Jun 27 2015
parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 27 June 2015 at 15:01:53 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 26 June 2015 at 02:29:40 UTC, deadalnix wrote:
 By this time we'd have a PR and we could play with it to 
 decide using first hand experience.
For which browser? It isn't implemented, is it?
You got your wish, they just exposed webasm through v8 a couple days ago: https://bugs.chromium.org/p/chromium/issues/detail?id=575167#c13 It should show up in the latest Chrome Canary builds soon, where it can be turned on through chrome://flags. I'm unsure how you'd actually pass webasm to v8 though, probably have to dig through the tests to figure that out. Now that it's in a browser and llvm has a WebAssembly target, as mentioned in yawniek's link above, porting D to use webasm through ldc might make a good GSoC project, with the caveat that all the webasm tools are under development. For any students interested, here's a good WebAssembly overview I just saw: https://software.intel.com/en-us/articles/webassembly-an-initial-view
Mar 14 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 14 March 2016 at 07:46:28 UTC, Joakim wrote:
 On Saturday, 27 June 2015 at 15:01:53 UTC, Ola Fosheim Grøstad 
 wrote:
 On Friday, 26 June 2015 at 02:29:40 UTC, deadalnix wrote:
 By this time we'd have a PR and we could play with it to 
 decide using first hand experience.
For which browser? It isn't implemented, is it?
You got your wish, they just exposed webasm through v8 a couple days ago:
Thanks!!! *SMOOCH*!
 Now that it's in a browser and llvm has a WebAssembly target, 
 as mentioned in yawniek's link above, porting D to use webasm 
 through ldc might make a good GSoC project, with the caveat 
 that all the webasm tools are under development.
Yes, that sounds like a very interesting GSoC project that probably could be turned into a master thesis.
Mar 14 2016
prev sibling parent reply CraigDillabaugh <craig.dillabaugh gmail.com> writes:
On Monday, 14 March 2016 at 07:46:28 UTC, Joakim wrote:
 On Saturday, 27 June 2015 at 15:01:53 UTC, Ola Fosheim Grøstad 
 wrote:
 [...]
You got your wish, they just exposed webasm through v8 a couple days ago: [...]
I am still getting student interest in new proposals ... are you interested in mentoring?
Mar 14 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 14 March 2016 at 15:14:17 UTC, CraigDillabaugh wrote:
 On Monday, 14 March 2016 at 07:46:28 UTC, Joakim wrote:
 On Saturday, 27 June 2015 at 15:01:53 UTC, Ola Fosheim Grøstad 
 wrote:
 [...]
You got your wish, they just exposed webasm through v8 a couple days ago: [...]
I am still getting student interest in new proposals ... are you interested in mentoring?
I'm not qualified to mentor a WebAssembly port, as I'm not versed on compilers or IR. Dan would probably be best, as he got a lot of the ARM codegen to work for iOS, try him? Maybe Ola would be interested too. I can chip in general input on porting, based on my Android experience.
Mar 14 2016
parent reply CraigDillabaugh <craig.dillabaugh gmail.com> writes:
On Monday, 14 March 2016 at 15:53:39 UTC, Joakim wrote:
 On Monday, 14 March 2016 at 15:14:17 UTC, CraigDillabaugh wrote:
 On Monday, 14 March 2016 at 07:46:28 UTC, Joakim wrote:
 On Saturday, 27 June 2015 at 15:01:53 UTC, Ola Fosheim 
 Grøstad wrote:
 [...]
You got your wish, they just exposed webasm through v8 a couple days ago: [...]
I am still getting student interest in new proposals ... are you interested in mentoring?
I'm not qualified to mentor a WebAssembly port, as I'm not versed on compilers or IR. Dan would probably be best, as he got a lot of the ARM codegen to work for iOS, try him? Maybe Ola would be interested too. I can chip in general input on porting, based on my Android experience.
Thanks. Dan or Ola ... are either of you interested in mentoring something like this?
Mar 14 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 14 March 2016 at 16:14:55 UTC, CraigDillabaugh wrote:
 On Monday, 14 March 2016 at 15:53:39 UTC, Joakim wrote:
 I can chip in general input on porting, based on my Android 
 experience.
Thanks. Dan or Ola ... are either of you interested in mentoring something like this?
I haven't spent much time with the dmd compiler source beyond the parser/lexer and generally don't have much time in the summer season (we have farm), but I can chip in.
Mar 15 2016
parent reply CraigDillabaugh <craig.dillabaugh gmail.com> writes:
On Tuesday, 15 March 2016 at 11:56:40 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 14 March 2016 at 16:14:55 UTC, CraigDillabaugh wrote:
 On Monday, 14 March 2016 at 15:53:39 UTC, Joakim wrote:
 I can chip in general input on porting, based on my Android 
 experience.
Thanks. Dan or Ola ... are either of you interested in mentoring something like this?
I haven't spent much time with the dmd compiler source beyond the parser/lexer and generally don't have much time in the summer season (we have farm), but I can chip in.
Maybe you can provide the students with fresh vegetables then :o)
Mar 15 2016
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 15 March 2016 at 13:01:31 UTC, CraigDillabaugh wrote:
 On Tuesday, 15 March 2016 at 11:56:40 UTC, Ola Fosheim Grøstad 
 wrote:
 On Monday, 14 March 2016 at 16:14:55 UTC, CraigDillabaugh 
 wrote:
 On Monday, 14 March 2016 at 15:53:39 UTC, Joakim wrote:
 I can chip in general input on porting, based on my Android 
 experience.
Thanks. Dan or Ola ... are either of you interested in mentoring something like this?
I haven't spent much time with the dmd compiler source beyond the parser/lexer and generally don't have much time in the summer season (we have farm), but I can chip in.
Maybe you can provide the students with fresh vegetables then :o)
Maybe deadalnix would be interested in mentoring, I think he showed some interest earlier. Or worst case, 3-4 of us could tag team, if that's allowed.
Mar 15 2016
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 15 March 2016 at 16:12:46 UTC, Joakim wrote:
 Maybe deadalnix would be interested in mentoring, I think he 
 showed some interest earlier.  Or worst case, 3-4 of us could 
 tag team, if that's allowed.
I can. I know LLVM fairly well (I'm not a committer), but I do not have that much experience with WebAssembly.
Mar 15 2016
next sibling parent Joakim <dlang joakim.fea.st> writes:
On Tuesday, 15 March 2016 at 20:18:40 UTC, deadalnix wrote:
 On Tuesday, 15 March 2016 at 16:12:46 UTC, Joakim wrote:
 Maybe deadalnix would be interested in mentoring, I think he 
 showed some interest earlier.  Or worst case, 3-4 of us could 
 tag team, if that's allowed.
I can. I know LLVM fairly well (I'm not a committer), but I do not have that much experience with WebAssembly.
Oh, you don't have five years experience with WebAssembly? We won't even look at the rest of your resume, straight into the trash it goes. :)
Mar 15 2016
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 15 March 2016 at 20:18:40 UTC, deadalnix wrote:
 On Tuesday, 15 March 2016 at 16:12:46 UTC, Joakim wrote:
 Maybe deadalnix would be interested in mentoring, I think he 
 showed some interest earlier.  Or worst case, 3-4 of us could 
 tag team, if that's allowed.
I can. I know LLVM fairly well (I'm not a committer), but I do not have that much experience with WebAssembly.
s/not/now .
Mar 15 2016
prev sibling parent David Nadlinger <code klickverbot.at> writes:
On Tuesday, 15 March 2016 at 20:18:40 UTC, deadalnix wrote:
 I can. I know LLVM fairly well (I'm not a committer), but I do 
 not have that much experience with WebAssembly.
Yes, please! I'd volunteer myself, but this summer will be too busy for me academically. — David
Mar 15 2016
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 15 March 2016 at 13:01:31 UTC, CraigDillabaugh wrote:
 Maybe you can provide the students with fresh vegetables then 
 :o)
GSoC == Google Summer of Cultivation?
Mar 16 2016
prev sibling parent Dan Olson <gorox comcast.net> writes:
CraigDillabaugh <craig.dillabaugh gmail.com> writes:

 On Monday, 14 March 2016 at 15:53:39 UTC, Joakim wrote:
 On Monday, 14 March 2016 at 15:14:17 UTC, CraigDillabaugh wrote:

 I'm not qualified to mentor a WebAssembly port, as I'm not versed on
 compilers or IR.  Dan would probably be best, as he got a lot of the
 ARM codegen to work for iOS, try him?  Maybe Ola would be interested
 too.

 I can chip in general input on porting, based on my Android
 experience.
Thanks. Dan or Ola ... are either of you interested in mentoring something like this?
I would, except I am currently a mentor for a student CubeSat project. I probably shouldn't take on more this year. I don't know anything about WebAssembly, but if clang does a good job with targetting wasm, then teaching LDC to do the same could be a manageble project for a student in my opinion. There might be some difficult problems. For example, I just looked and the LLVM WebAssembly target doesn't support thread-locals. But that wouldn't stop progress. -- Dan
Mar 15 2016
prev sibling next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 18 June 2015 at 08:05:48 UTC, 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
As far as SDC support goes... I am pretty torn. We need more platforms to see if our API is going to hold up. But at the same time we need to be focused on compiling more of D... If someone is willing to do this I can provide a little support.
Dec 24 2015
prev sibling next sibling parent reply Adi <guardianaditya gmail.com> writes:
On Thursday, 18 June 2015 at 08:05:48 UTC, 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
Hello everyone, I am a student in college and am a newbie to webassembly and I wish to do a project to implement support for webassembly for SDC and LDC....can someone please help me regarding this.
Mar 18 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 18 March 2016 at 12:09:02 UTC, Adi wrote:
 On Thursday, 18 June 2015 at 08:05:48 UTC, 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
Hello everyone, I am a student in college and am a newbie to webassembly and I wish to do a project to implement support for webassembly for SDC and LDC....can someone please help me regarding this.
It is not clear what you need help with, the WebAssembly docs are listed above and GSoC has its own student manual. There is also a contact email address for Craig, if you have general questions about GSoC that aren't covered in the docs. Can you say what you need help with?
Mar 19 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 19 March 2016 at 08:05:12 UTC, Joakim wrote:
 It is not clear what you need help with, the WebAssembly docs 
 are listed above and GSoC has its own student manual.
The WebAssembly spec seems to be expressed in OCaml: https://github.com/WebAssembly/spec/tree/master/ml-proto Perhaps not as clear a standard text document, but the OCaml source is fairly readable.
Mar 19 2016
prev sibling parent reply Adi <guardianaditya gmail.com> writes:
On Saturday, 19 March 2016 at 08:05:12 UTC, Joakim wrote:
 It is not clear what you need help with, the WebAssembly docs 
 are listed above and GSoC has its own student manual.  There is 
 also a contact email address for Craig, if you have general 
 questions about GSoC that aren't covered in the docs.  Can you 
 say what you need help with?
Hello Sir, I need help to write my proposal for gsoc.
Mar 19 2016
parent David Nadlinger <code klickverbot.at> writes:
On Saturday, 19 March 2016 at 16:18:00 UTC, Adi wrote:
 I need help to write my proposal for gsoc.
What exactly do you need help with? You can find some general hints at the GSoC student guide: http://write.flossmanuals.net/gsocstudentguide/writing-a-proposal/. There are currently no extra hard rules for the D foundation, at least not this year. As a general note, though – I'm not involved with GSoC this year, neither as a student nor a mentor –, your proposal should demonstrate that you have researched the project at hand somewhat carefully (including the formal aspect!) and should convey that you will be able to pull your own weight over the course of the summer. — David
Mar 19 2016
prev sibling parent reply bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Thursday, 18 June 2015 at 08:05:48 UTC, 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
WebAssembly reach a first step a first consensus on the design of the initial (MVP) WebAssembly API and binary format: - http://webassembly.org/ - https://developer.mozilla.org/en-US/docs/WebAssembly - https://github.com/webassembly To remember it will be the next open standard by a W3C Community Group to create portable and efficient application across major web browser. A such feature can offer to D a chance to have a killer app in 3D web application instead to develop complex C++ code. Some examples: - https://github.com/JasonWeathersby/WASMSobel/ - https://github.com/mdn/webassembly-examples/
Oct 23 2017
parent reply codephantom <me noyb.com> writes:
On Monday, 23 October 2017 at 22:32:55 UTC, bioinfornatics wrote:
 To remember it will be the next  open standard by a W3C 
 Community Group to create portable and efficient application 
 across major web browser. A such feature can offer to D a 
 chance to have a killer app in 3D web application instead to 
 develop complex C++ code.
Consensus is irrelevant. Google will lead, others will simply follow. The web stack is like rubbish...a heterogeneous mixture of discardable material!
Oct 23 2017
parent Suliman <evermind live.ru> writes:
On Tuesday, 24 October 2017 at 02:08:42 UTC, codephantom wrote:
 On Monday, 23 October 2017 at 22:32:55 UTC, bioinfornatics 
 wrote:
 To remember it will be the next  open standard by a W3C 
 Community Group to create portable and efficient application 
 across major web browser. A such feature can offer to D a 
 chance to have a killer app in 3D web application instead to 
 develop complex C++ code.
Consensus is irrelevant. Google will lead, others will simply follow. The web stack is like rubbish...a heterogeneous mixture of discardable material!
https://github.com/arcanosam/imgui_wasm_demo
Oct 26 2017