Re: D could catch this wave: web assembly

[Suliman via Digitalmars-d]

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

Re: D could catch this wave: web assembly

[codephantom via Digitalmars-d]

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!

Re: D could catch this wave: web assembly

[bioinfornatics via Digitalmars-d]

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/

Re: D could catch this wave: web assembly

[David Nadlinger via Digitalmars-d]

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

Re: D could catch this wave: web assembly

[Adi via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Ola Fosheim Grøstad via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

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 LDCcan 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?

Re: D could catch this wave: web assembly

[Adi via Digitalmars-d]

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 LDCcan someone please help me regarding this.

Re: D could catch this wave: web assembly

[Ola Fosheim Grøstad via Digitalmars-d]

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?

Re: D could catch this wave: web assembly

[David Nadlinger via Digitalmars-d]

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

Re: D could catch this wave: web assembly

[deadalnix via Digitalmars-d]

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 .

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

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

Re: D could catch this wave: web assembly

[deadalnix via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Dan Olson via Digitalmars-d]

CraigDillabaugh  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

Re: D could catch this wave: web assembly

[CraigDillabaugh via Digitalmars-d]

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)

Re: D could catch this wave: web assembly

[Ola Fosheim Grøstad via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[CraigDillabaugh via Digitalmars-d]

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?

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[CraigDillabaugh via Digitalmars-d]

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?

Re: D could catch this wave: web assembly

[Ola Fosheim Grøstad via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

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

Re: D could catch this wave: web assembly

[Stefan Koch via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[deadalnix via Digitalmars-d]

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 ?

Re: D could catch this wave: web assembly

[Suliman via Digitalmars-d]

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?

Re: D could catch this wave: web assembly

[Abdulhaq via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Suliman via Digitalmars-d]

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?

Re: D could catch this wave: web assembly

[Ola Fosheim Grøstad via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[yawniek via Digitalmars-d]

https://hacks.mozilla.org/2015/12/compiling-to-webassembly-its-happening/

Re: D could catch this wave: web assembly

[Marco Leise via Digitalmars-d]

Am Sat, 20 Jun 2015 15:15:47 + (UTC)
schrieb ketmar :

> 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

Re: D could catch this wave: web assembly

[via Digitalmars-d]

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?

Re: D could catch this wave: web assembly

[deadalnix via Digitalmars-d]

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

Re: D could catch this wave: web assembly

[deadalnix via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

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

Re: D could catch this wave: web assembly

[Kagamin via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[via Digitalmars-d]

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

Re: D could catch this wave: web assembly

[via Digitalmars-d]

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

Re: D could catch this wave: web assembly

[via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

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 

Re: D could catch this wave: web assembly

[via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Kagamin via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[ketmar via Digitalmars-d]

On Wed, 24 Jun 2015 06:43:00 +, Ola Fosheim Grøstad 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.
 
 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 
sane -- it was created for GUI layouting, so authors tried to make GUIs 
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 
will support Cassowary as one of available layout engines. that's why i 
did the porting in the first place! ;-)

signature.asc
Description: PGP signature

Re: D could catch this wave: web assembly

[Joseph Rushton Wakeling via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[ketmar via Digitalmars-d]

On Wed, 24 Jun 2015 11:44:09 +, 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 
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 
model suxalot.

signature.asc
Description: PGP signature

Re: D could catch this wave: web assembly

[Kagamin via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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! :)

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

On 06/24/2015 11:34 AM, ketmar wrote:


i ported [cassowary] to D some time ago.


Github?

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[ketmar via Digitalmars-d]

On Wed, 24 Jun 2015 06:38:38 +, Ola Fosheim Grøstad 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.
 
 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 
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. ;-)

signature.asc
Description: PGP signature

Re: D could catch this wave: web assembly

[ketmar via Digitalmars-d]

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

no, repo.or.cz ;-)

http://forum.dlang.org/thread/btoozbdfmuoopdrfr...@forum.dlang.org

that repo is slightly outdated, as i moved the port to my IV library (and 
aliced it, so no vanilla anymore...)

there is another port mentioned in that thread, it's even available on 
code.dlang.org.

signature.asc
Description: PGP signature

Re: D could catch this wave: web assembly

[ketmar via Digitalmars-d]

On Wed, 24 Jun 2015 15:45:46 +, 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.

signature.asc
Description: PGP signature

Re: D could catch this wave: web assembly

[Adam D. Ruppe via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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

Re: D could catch this wave: web assembly

[Adam D. Ruppe via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[ketmar via Digitalmars-d]

On Tue, 23 Jun 2015 18:26:07 +, 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. 
really a huge step.

signature.asc
Description: PGP signature

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[ketmar via Digitalmars-d]

On Sat, 20 Jun 2015 19:40:35 +, Ola Fosheim Grøstad wrote:

 On Saturday, 20 June 2015 at 16:20:31 UTC, ketmar wrote:
 On Sat, 20 Jun 2015 16:14:43 +, 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…

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.

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.

signature.asc
Description: PGP signature

Re: D could catch this wave: web assembly

[deadalnix via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[ketmar via Digitalmars-d]

On Sat, 20 Jun 2015 17:00:43 +, 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, 
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.


 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.

signature.asc
Description: PGP signature

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

On 06/23/2015 12:37 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
ola.fosheim.grostad+dl...@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.

Re: D could catch this wave: web assembly

[Suliman via Digitalmars-d]

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?

Re: D could catch this wave: web assembly

[Abdulhaq via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Kagamin via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

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 

Re: D could catch this wave: web assembly

[Suliman via Digitalmars-d]

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?

Re: D could catch this wave: web assembly

[Wyatt via Digitalmars-d]

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

Re: D could catch this wave: web assembly

[via Digitalmars-d]

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

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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 

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

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 

Re: D could catch this wave: web assembly

[Joseph Rushton Wakeling via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Kagamin via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

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 
would chuck javascript and compile java, C#, or D to the 
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, 

Re: D could catch this wave: web assembly

[Kagamin via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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* ;) )

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

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/dqddjhccpmxhgcssq...@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 
would chuck javascript and compile java, C#, or D to the 
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

Re: D could catch this wave: web assembly

[Joseph Rushton Wakeling via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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 

Re: D could catch this wave: web assembly

[Nick Sabalausky via Digitalmars-d]

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 

Re: D could catch this wave: web assembly

[via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Joakim via Digitalmars-d]

On Sunday, 21 June 2015 at 06:20:53 UTC, Ola Fosheim Grøstad 
wrote:

Thrown away in favour of what?


As I said before, start from scratch.  Stop trying to shoehorn a 
full app runtime into the browser because you will only lose to 
native app runtimes, which is already happening because they 
aren't constrained by such legacy decisions as an archaic 
document format.


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



You need a scene-graph / DOM.


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


CSS makes design much easier than the alternative.


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



JS is evolving into something close to TypeScript.


You've got to be joking: why would anyone want to use either?  On 
the server, where you could use anything you want and there is 
real competition, almost nobody uses either, node.js in recent 
years and that's about it.  If this webasm effort ever got into 
most browsers, I guarantee that almost everybody would chuck 
javascript and compile java, C#, or D to the browser instead.


You can do some interesting things with caching, sure, but the 
web frontend is still unwieldy and slow and round-trip latency 
anytime you do something is what kills you.


You can prefetch data if you want. If you have a scrolling view 
you can prefetch the next page-height worth of items. I do that 
for images where I have to deal with thousands of images.


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


document format.  You are always going to be constrained by 
the architectural constraints and inefficiency of the document 
format.


You don't have to use it. I use it because it is more 
productive and more easily allows search engine indexing.


Actually, that's one of the big problems with the more dynamic 
model: it breaks search engine indexing.  How does the crawler 
have any idea how to navigate an app UI and generate URLs that 
are meaningful, if they're even made available by the app?


If you don't want it, you can use the HTML5 canvas and fill the 
view with it. But why would you? You would have to do all the 
layout manually and create a separate version for people using 
assistive technologies.


The HTML5 canvas does provide a way out to some extent, but 
you're still stuck with javascript and I believe a certain amount 
of CSS.  You wouldn't do the layout manually, just download a 
javascript library that does a lot of the grunt work for you.  It 
is on the right track, but goes nowhere near far enough.  But as 
I noted earlier, the canvas tag doesn't even support hyperlinks 
natively, which is a pretty big omission for a web technology.


You can do that if you want. Just download binary data and 
plot it to a canvas.


The fact that I could render SVG images to a png and download 
that instead doesn't excuse the fact that they're putting full 
text SVG renderers into the browser.


You can just send paths as binary data to the client and draw 
to HTML5 canvas if you want. No need to render on the server.


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


Of course, that also means that you have to deal with 
resolution/zooming issues, and it also means that you may have 
to wait with the graphics till the whole DOM has loaded. Which 
is another issue that embedded SVG solves.


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


I wouldn't mind an improved version of SVG with LOD support 
etc, but I think that would be a different concept. SVG is 
perfectly fine for embedded CSS styled line-art (which I use it 
for). You can bundle HTML/CSS/JS/SVG in one file and have very 
responsive websites if you wish (one file download).


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


Of course you could use binary SVG dynamically: you'd simply 
need the right hooks in the browser and in the binary format 
to manipulate it using javascript.  It would not require 
binary-format editors or binary HTML.


No, because I typically write the fragments for the SVG as text 
then programatically modify parts of the SVG. Or, I just attach 
event-listeners to parts of the SVG. Not having HTML and SVG in 
the same source would be very confusing.


It wouldn't be confusing at all.  You'd simply do all that in 
your text SVG authoring format and HTML on your side, then 

Re: D could catch this wave: web assembly

[via Digitalmars-d]

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 
chuck javascript and compile java, C#, or D to the 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.

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.

Re: D could catch this wave: web assembly

[Kagamin via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[Marco Leise via Digitalmars-d]

Am Thu, 18 Jun 2015 08:05:46 +
schrieb John Colvin john.loughran.col...@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

Re: D could catch this wave: web assembly

[via Digitalmars-d]

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.

Re: D could catch this wave: web assembly

[ketmar via Digitalmars-d]

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

it's actually a tool for toolkit builders, not for end users. cassowary 
itself is only a solver, it doesn't even have syntax to setup constraints 
(toolkit builder must invent an implement one).

so it's hard to make example for it which doesn't resemble a wall of text 
several pages long only to layout three elements.

the real power of cassowary is it's dynamic constraint solver. but it 
needs to be combined with user-friendly constraint syntax, or it will be 
unusable. so cassowary authors have to write their own toolkit only to 
show some impressive examples on site! ;-)

besides, cassowary comes from university culture, where user-friendly 
presentations are bad or non-existent.


tl;dr: i completely agree with you! ;-)

signature.asc
Description: PGP signature

Re: D could catch this wave: web assembly

[Kagamin via Digitalmars-d]

On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:

On Sat, 20 Jun 2015 15:21:28 +, 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.

Re: D could catch this wave: web assembly

[Kagamin via Digitalmars-d]

On Friday, 19 June 2015 at 15:13:11 UTC, Joakim wrote:
Hmm... Web: write once with html, css, js. Native: write three 
times in obj-c, java, c#. Not sure why the former should sink 
and not the latter.


Because writing it once in HTML/CSS/JS takes you much longer 
than writing it in Java, while being less responsive, then you 
get to enjoy all the myriad ways your UI will be screwed up by 
the different browsers.


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.

Re: D could catch this wave: web assembly

[ketmar via Digitalmars-d]

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.

signature.asc
Description: PGP signature

Re: D could catch this wave: web assembly

[ketmar via Digitalmars-d]

On Sat, 20 Jun 2015 16:14:43 +, 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.


signature.asc
Description: PGP signature

Re: D could catch this wave: web assembly

[ketmar via Digitalmars-d]

On Sat, 20 Jun 2015 16:18:28 +, 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.


 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.

signature.asc
Description: PGP signature

Re: D could catch this wave: web assembly

[ketmar via Digitalmars-d]

On Sat, 20 Jun 2015 15:21:28 +, 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.


 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 
pitiful attempt and barely usable. bwah, it can't even do normal 
constraints!


signature.asc
Description: PGP signature