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