www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - New opportunities for D => ASM.js

reply Etienne <etcimon gmail.com> writes:
I've been reading on Emscripten and LDC and how they would be nice 
together, and came across this nice little library:
http://www.leaningtech.com/duetto/examples/

It's a C++ server/client framework that compiles to JS through clang => 
LLVM bytecode => ASM.js.

I'd like to point out that asm.js is a very fast subset of the 
javascript language that allows almost native speeds (3x slowdown vs C 
only) which enables games to be run in the browser without external 
dependencies.

This had me thinking of forking the Emscripten project in order to 
support the druntime / phobos library & give it access to the browser 
DOM interface, as to allow javascript web applications to be written 
fully in D (to produce interfaces like openUI5 and more).

This would have multiple advantages:
- Suitable for huge front-end development frameworks using safe typing 
and contractual programming
- Opens the door to petaFLOPS of distributed CPU power based simply on 
website visitation without affecting user experience
- Allows Javascript proprietary code to be harder to de-obfuscate or 
reverse engineer
- FAST Browser-based database engines and full runtime capabilities can 
be developed (and added as browser extensions for persistence) to be 
actively used by the server with a simple interface

And most of all, it simplifies web development.

I'm not going to instantly call for a project to be started, but I'd 
love to hear some why do's and why don'ts b/c I don't like to rely on my 
point of view alone.
May 13 2014
next sibling parent reply "Nicolas F." <ddev fratti.ch> writes:
 I'd like to point out that asm.js is a very fast subset of the 
 javascript language that allows almost native speeds (3x 
 slowdown vs C only) which enables games to be run in the 
 browser without external dependencies.


It also doesn't do multithreading, as far as I know. Also three 
times slower for peak performance is not near-native. It's 
bullshit Mozilla marketing. (They actually use the expression "2x 
the speed", yes, it's hilarious.)

And I still think the browser is a terrible platform for anything 
but small flashgames-like games.


 - Opens the door to petaFLOPS of distributed CPU power based 
 simply on website visitation without affecting user experience


If you have JS doing heavy computation on your website for every 
visitor, I'm sure you'll soon run out of visitors to reach that 
number, because that's not a very nice thing to do. It does 
affect user experience.


 - Allows Javascript proprietary code to be harder to 
 de-obfuscate or reverse engineer


That's not an advantage. That's terrible. Please stop.


 - FAST Browser-based database engines and full runtime 
 capabilities can be developed (and added as browser extensions 
 for persistence) to be actively used by the server with a 
 simple interface


"Fast". For reference: If some JS-thing says "fast", it usually 
means "it's not quite so terrible as before". Also, are you 
suggesting that putting a database on the client browser, and 
then having a server call that for data is a good idea and fast?


 And most of all, it simplifies web development.


Hardly.

The only good idea that I see in this is that it allows you to do 
client-side web-development without having to use JS.
May 13 2014
next sibling parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-13 1:30 PM, Nicolas F. wrote:

 The only good idea that I see in this is that it allows you to do
 client-side web-development without having to use J


I do believe it would allow some web frameworks and UI projects to run 
faster by reducing the massive use of fallback scopes and HashMaps. 
Also, nothing says a thread pool won't be in the works if it becomes 
necessary. JS has the advantage of running in every single web browsers 
out there regardless of the OS, and for platforms like the Chrome OS 
that only run JS/HTML, it's also going to be an important tool.

Don't get me wrong, I do believe javascript is a horrible technology and 
I hate how it managed to get there by stacking indirections so much, but 
it's also what browsers rely on and this is supposed to improve it.
May 13 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/13/2014 1:38 PM, Etienne wrote:

 and for platforms like the Chrome OS
 that only run JS/HTML, it's also going to be an important tool.


I thought Chrome wasn't on-board with asm.js?
May 13 2014
next sibling parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-13 2:18 PM, Nick Sabalausky wrote:

 On 5/13/2014 1:38 PM, Etienne wrote:

 and for platforms like the Chrome OS
 that only run JS/HTML, it's also going to be an important tool.


 I thought Chrome wasn't on-board with asm.js?


They are on board, and ironically it runs faster on Chrome's V8 than on 
Firefox
May 13 2014
parent Etienne <etcimon gmail.com> writes:
On 2014-05-13 2:21 PM, Etienne wrote:

 On 2014-05-13 2:18 PM, Nick Sabalausky wrote:

 On 5/13/2014 1:38 PM, Etienne wrote:

 and for platforms like the Chrome OS
 that only run JS/HTML, it's also going to be an important tool.


 I thought Chrome wasn't on-board with asm.js?


 They are on board, and ironically it runs faster on Chrome's V8 than on
 Firefox


Scratch that, I was looking at this:

http://allievi.sssup.it/techblog/wp-content/uploads/2013/05/benchmarks2.png
May 13 2014
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 13.05.2014 20:18, schrieb Nick Sabalausky:

 On 5/13/2014 1:38 PM, Etienne wrote:

 and for platforms like the Chrome OS
 that only run JS/HTML, it's also going to be an important tool.


 I thought Chrome wasn't on-board with asm.js?


They aren't. If you look at Chrome Dashboard, integration of Dart VM is 
the important stuff going on.

NaCL is already integrated and enabled.

--
Paulo
May 13 2014
next sibling parent Etienne <etcimon gmail.com> writes:
On 2014-05-13 2:22 PM, Paulo Pinto wrote:

 Am 13.05.2014 20:18, schrieb Nick Sabalausky:

 On 5/13/2014 1:38 PM, Etienne wrote:

 and for platforms like the Chrome OS
 that only run JS/HTML, it's also going to be an important tool.


 I thought Chrome wasn't on-board with asm.js?


 They aren't. If you look at Chrome Dashboard, integration of Dart VM is
 the important stuff going on.

 NaCL is already integrated and enabled.

 --
 Paulo


It doesn't seem like any work has been in asm.js since a while according 
to this:

http://arewefastyet.com/#machine=12&view=breakdown&suite=asmjs-apps

Dart is very nice, the editor and tools are great, the integration to 
the browser as well... if only the language and libraries were from D :)
May 13 2014
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 14 May 2014 04:22, Paulo Pinto via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Am 13.05.2014 20:18, schrieb Nick Sabalausky:


 On 5/13/2014 1:38 PM, Etienne wrote:

 and for platforms like the Chrome OS
 that only run JS/HTML, it's also going to be an important tool.


 I thought Chrome wasn't on-board with asm.js?


 They aren't. If you look at Chrome Dashboard, integration of Dart VM is the
 important stuff going on.

 NaCL is already integrated and enabled.


I'm interested in PNaCl support in LDC, and a bunch of my friends. I
reckon we could definitely create a movement there...
May 13 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 14 May 2014 at 03:06:52 UTC, Manu via Digitalmars-d 
wrote:

 On 14 May 2014 04:22, Paulo Pinto via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 I thought Chrome wasn't on-board with asm.js?






Not officially, but they probably tweak V8.


 I'm interested in PNaCl support in LDC, and a bunch of my 
 friends. I
 reckon we could definitely create a movement there..


Me too. Especially if it is possible to compile to both pnacl and 
asm.js using the same API.
May 14 2014
prev sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 13 May 2014 13:38:43 -0400
schrieb Etienne <etcimon gmail.com>:


 Also, nothing says a thread pool won't be in the works if it becomes 
 necessary.


Besides that JavaScript is single-threaded. That could be a
bit of a show stopper.

-- 
Marco
May 30 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 30 May 2014 at 14:49:09 UTC, Marco Leise wrote:

 Besides that JavaScript is single-threaded. That could be a
 bit of a show stopper.


I think the most promising idea is to support PNACL+JS. If you 
can write a whole app in only one language and keep the GC high 
level stuff in javascript and the low level heap stuff in LLVM 
then you have something great going.

Modern browsers are getting support for running multiple isolates 
in parallell in javascript.

But phobos isn't suited for this stuff.

Also, compiling to Dart is a bad idea. dart2js is going to drop 
support for IE9 from versjon 1.6
May 30 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 13 May 2014 at 17:30:44 UTC, Nicolas F. wrote:

 It also doesn't do multithreading, as far as I know.


HTML5 support Web Workers running in isolates.


 Also three times slower for peak performance is not near-native.


They claim "1.5", but I think that is questionable.


 The only good idea that I see in this is that it allows you to 
 do client-side web-development without having to use JS.


If you have a framework that allows you to compile to PNACL, 
asm.js, iOS and Android using WebGL/OpenGL 2ES then you are 
pretty close to cross platform for interactive apps. Better than 
Flash, that's pretty good.

Unity apparently compiles to asm.js:

http://beta.unity3d.com/jonas/AngryBots/
May 14 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 14 May 2014 at 09:49:21 UTC, Ola Fosheim Grøstad
wrote:

 On Tuesday, 13 May 2014 at 17:30:44 UTC, Nicolas F. wrote:

 It also doesn't do multithreading, as far as I know.


 HTML5 support Web Workers running in isolates.


 Also three times slower for peak performance is not 
 near-native.


 They claim "1.5", but I think that is questionable.


 The only good idea that I see in this is that it allows you to 
 do client-side web-development without having to use JS.


 If you have a framework that allows you to compile to PNACL, 
 asm.js, iOS and Android using WebGL/OpenGL 2ES then you are 
 pretty close to cross platform for interactive apps. Better 
 than Flash, that's pretty good.

 Unity apparently compiles to asm.js:

 http://beta.unity3d.com/jonas/AngryBots/


They do it via IL -> C++ -> Emscripten.

http://blogs.unity3d.com/2014/04/29/on-the-future-of-web-publishing-in-unity/
May 14 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 14 May 2014 at 11:12:54 UTC, Paulo Pinto wrote:

 They do it via IL -> C++ -> Emscripten.

 http://blogs.unity3d.com/2014/04/29/on-the-future-of-web-publishing-in-unity/


I thought they used Emscription -> ASM.js too? Anyway, it runs 
smooth on my machine.

https://hacks.mozilla.org/2014/05/asm-js-performance-improvements-in-the-latest-version-of-firefox-make-games-fly/


Today I also learned that webkit is moving to an advanced LLVM 
JIT, apparently compiling multiple versions of functions for 
various paths so they can hot swap…

https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
May 14 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 13 May 2014 at 17:16:18 UTC, Etienne wrote:

 I've been reading on Emscripten and LDC and how they would be 
 nice together, and came across this nice little library:
 http://www.leaningtech.com/duetto/examples/

 It's a C++ server/client framework that compiles to JS through 
 clang => LLVM bytecode => ASM.js.

 I'd like to point out that asm.js is a very fast subset of the 
 javascript language that allows almost native speeds (3x 
 slowdown vs C only) which enables games to be run in the 
 browser without external dependencies.

 This had me thinking of forking the Emscripten project in order 
 to support the druntime / phobos library & give it access to 
 the browser DOM interface, as to allow javascript web 
 applications to be written fully in D (to produce interfaces 
 like openUI5 and more).

 This would have multiple advantages:
 - Suitable for huge front-end development frameworks using safe 
 typing and contractual programming
 - Opens the door to petaFLOPS of distributed CPU power based 
 simply on website visitation without affecting user experience
 - Allows Javascript proprietary code to be harder to 
 de-obfuscate or reverse engineer
 - FAST Browser-based database engines and full runtime 
 capabilities can be developed (and added as browser extensions 
 for persistence) to be actively used by the server with a 
 simple interface

 And most of all, it simplifies web development.

 I'm not going to instantly call for a project to be started, 
 but I'd love to hear some why do's and why don'ts b/c I don't 
 like to rely on my point of view alone.


I don't like technologies that originate from one company for 
various reasons, and I hate JS. But then again, what can we do? 
JS is everywhere. I wouldn't mind "compiling" to JS as long as I 
can develop in a proper language like D.

On the other hand, all those JS solutions show that JS is shit 
and nobody is happy with it, everyone hates it and there's no way 
of fixing it. Maybe it's time to start a revolution and get rid 
of JS. Maybe something along the lines of an abstract 
interface-like language that compiles to native code via C, and 
the concrete code can be written in any language.
May 14 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 13 May 2014 at 17:16:18 UTC, Etienne wrote:

 I'd like to point out that asm.js is a very fast subset of the 
 javascript language that allows almost native speeds (3x 
 slowdown vs C only) which enables games to be run in the 
 browser without external dependencies.


You keep saying the browser, but what you mean is firefox (and
other mozilla products).

For the story, mozilla dropped out of the NaCl project so they
can pull out their me too solution. Now we are back to where we
were 10 years ago with the browser war. We could have one unified
standard int he name of NaCl, but fuck that, now we have too.

ASM.js is inferior in every possible way (slower, bigger source,
more overhead, you name it) to NaCl except one: ASM.js run in a
standard JS interpreter. Except that if you are using this, it is
because you need the speed in the first place. To take the
example of video game, can you claim that the game works when you
run it at 0.5fps ?

Sadly, because of mozilla moves with ASM.js, there is no industry 
standard to run native things in the browser. Until things settle 
down, these are cool, but useless technologies.
May 14 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 14 May 2014 at 20:50:47 UTC, deadalnix wrote:

 were 10 years ago with the browser war. We could have one 
 unified
 standard int he name of NaCl, but fuck that, now we have too.


Not as long as Apple and Microsoft don't want to fuel Chrome Book 
as a competing platform. I would be surprised if they would 
implement PNaCl before there is significant demand in the general 
population.


 ASM.js is inferior in every possible way (slower, bigger source,
 more overhead, you name it) to NaCl except one: ASM.js run in a
 standard JS interpreter. Except that if you are using this, it 
 is because you need the speed in the first place. To take the
 example of video game, can you claim that the game works when 
 you run it at 0.5fps ?


Actually you don't really need that much speed for getting good 
framerates if the gameworld is somewhat static. Apple and 
Microsoft have their own optimizing engines that probably can use 
the constraints in asm.js to generate better code with little 
effort. (They are already tinkering with applying types to 
dynamic variables.)


 Until things settle down, these are cool, but useless 
 technologies.


Not if your framework (like Unity) can compile down to multiple 
formats.
May 14 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/14/2014 5:22 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Wednesday, 14 May 2014 at 20:50:47 UTC, deadalnix wrote:

 Until things settle down, these are cool, but useless technologies.


 Not if your framework (like Unity) can compile down to multiple formats.


While Unity3D provides a great boost in cross-platform...ability, 
they've recently made it very clear they have absolutely no intention of 
ever supporting any Chrome-only technology. (And on top of that, even 
their html5/asm.js stuff still needs a good bit more time and work 
before it's really production-ready for general Unity3D users. :( )

And yet Unity's easily the *most* cross-platform framework out there. 
So, unfortunately, deadalnix is basically right: These things are pretty 
much worthless for right now, until everything bakes a bit more.
May 14 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 15 May 2014 at 05:28:56 UTC, Nick Sabalausky wrote:

 While Unity3D provides a great boost in 
 cross-platform...ability, they've recently made it very clear 
 they have absolutely no intention of ever supporting any 
 Chrome-only technology. (And on top of that, even their


http://docs.unity3d.com/Documentation/Manual/nacl-gettingstarted.html


 there. So, unfortunately, deadalnix is basically right: These 
 things are pretty much worthless for right now, until 
 everything bakes a bit more.


How much are you willing to bet? :-)

You need a modern PC/mac, but gamers tend to be on that 
frontier...
May 15 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/15/2014 4:22 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Thursday, 15 May 2014 at 05:28:56 UTC, Nick Sabalausky wrote:

 While Unity3D provides a great boost in cross-platform...ability,
 they've recently made it very clear they have absolutely no intention
 of ever supporting any Chrome-only technology. (And on top of that,
 even their


 http://docs.unity3d.com/Documentation/Manual/nacl-gettingstarted.html


 there. So, unfortunately, deadalnix is basically right: These things
 are pretty much worthless for right now, until everything bakes a bit
 more.


 How much are you willing to bet? :-)

 You need a modern PC/mac, but gamers tend to be on that frontier...


I hadn't seen that before, however it doesn't really change much. First 
of all, notice that page is pretty old. The last update was over a year 
ago, there's no mention of it working at all on anything beyond Unity 
3.5 (Current Unity3D is at 4.3, and they're already gearing up for 5.0). 
And even at that, the page makes it clear it's last known status is 
basically just a beta feature.

Additionally, Chrome's dropping of NPAPI appears to be central to the 
issue (my understanding is that NaCL requires using either NPAPI or 
PPAPI). And apparently Unity has no intention of porting to PPAPI. See 
the comments here from April 30 of this year (just a couple weeks ago):

http://blogs.unity3d.com/2014/04/29/on-the-future-of-web-publishing-in-unity/

In response to this user comment:
"What about the issue with chrome dropping support for the web player?
...
You still can use PPAPI to build a unity web player, instead of NPAPI, 
as you have NaCl support already."

Unity's Jonas Echterhoff's reply:
" De-Panther: We will no port our plugin to PPAPI (it would not be 
compatible with any existing content anyways, due to shader 
differences), because we don’t believe in doing a plugin which will work 
in a single browser only (What you wrote about WebGL, only for PPAPI it 
is actually the case, as there is only one browser which supports it, 
while all browsers are adding WebGL support these days)."

Also, responding to this: "But what about old unity webplayers and games?"

Unity's Jonas Echterhoff's reply:
" FRANKS GAMES: if browsers drop support for plugins, there is no way, 
we can make that content still work without republishing to WebGL, correct."

I'm not sure whether Unity's NaCL depends on NPAPI or if it's something 
completely separate from the regular "Unity Web Player". But either way, 
it's very clear that NaCL in Unity is either going to be phased out (in 
favor of asm.js/WebGL) or already abandoned.
May 15 2014
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 14 May 2014 at 20:50:47 UTC, deadalnix wrote:

 On Tuesday, 13 May 2014 at 17:16:18 UTC, Etienne wrote:

 I'd like to point out that asm.js is a very fast subset of the 
 javascript language that allows almost native speeds (3x 
 slowdown vs C only) which enables games to be run in the 
 browser without external dependencies.


 You keep saying the browser, but what you mean is firefox (and
 other mozilla products).

 For the story, mozilla dropped out of the NaCl project so they
 can pull out their me too solution. Now we are back to where we
 were 10 years ago with the browser war. We could have one 
 unified
 standard int he name of NaCl, but fuck that, now we have too.

 ASM.js is inferior in every possible way (slower, bigger source,
 more overhead, you name it) to NaCl except one: ASM.js run in a
 standard JS interpreter. Except that if you are using this, it 
 is
 because you need the speed in the first place. To take the
 example of video game, can you claim that the game works when 
 you
 run it at 0.5fps ?

 Sadly, because of mozilla moves with ASM.js, there is no 
 industry standard to run native things in the browser. Until 
 things settle down, these are cool, but useless technologies.


That is what the desktop is for anyway.
May 15 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/15/2014 3:51 AM, Paulo Pinto wrote:

 On Wednesday, 14 May 2014 at 20:50:47 UTC, deadalnix wrote:

 For the story, mozilla dropped out of the NaCl project so they
 can pull out their me too solution. Now we are back to where we
 were 10 years ago with the browser war. We could have one unified
 standard int he name of NaCl, but fuck that, now we have too.

 ASM.js is inferior in every possible way (slower, bigger source,
 more overhead, you name it) to NaCl except one: ASM.js run in a
 standard JS interpreter. Except that if you are using this, it is
 because you need the speed in the first place. To take the
 example of video game, can you claim that the game works when you
 run it at 0.5fps ?




Yea, exactly. I've never really complained much about asm.js because, 
well, at least it's an improvement over JS (and isn't just simply 
"another browser-forced language I'm expected to learn, use, and enjoy" 
like Dart). But yea, the whole "backwards compatible with regular JS" is 
a big load of shit, and yet asm.js makes fundamental design compromises 
simply for the sake of that fundamentally broken "feature".


 Sadly, because of mozilla moves with ASM.js, there is no industry
 standard to run native things in the browser. Until things settle
 down, these are cool, but useless technologies.


 That is what the desktop is for anyway.


Yea, see that's the real root issue behind this whole "Browser Wars 2.0" 
clusterfuck. A bunch of web-obsessed asshats keep trying to shove every 
damn thing into a browser window. Shit, they don't even fucking *know* 
why they do it, they just don't question "web is the future", as if it'd 
be some kind of heresy.

We could've had some damn good cross-platform 
zero-install/sandboxed-ez-install infrastructures in place by now (ie, 
the *only* legitimate motivations for webapps) if all these clowns 
hadn't been wasting all their effort on this idiotic pig-with-makeup 
house of cards that is "web 2.0".
May 15 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 15 May 2014 at 17:37:11 UTC, Nick Sabalausky wrote:

 On 5/15/2014 3:51 AM, Paulo Pinto wrote:

 On Wednesday, 14 May 2014 at 20:50:47 UTC, deadalnix wrote:

 For the story, mozilla dropped out of the NaCl project so they
 can pull out their me too solution. Now we are back to where 
 we
 were 10 years ago with the browser war. We could have one 
 unified
 standard int he name of NaCl, but fuck that, now we have too.

 ASM.js is inferior in every possible way (slower, bigger 
 source,
 more overhead, you name it) to NaCl except one: ASM.js run in 
 a
 standard JS interpreter. Except that if you are using this, 
 it is
 because you need the speed in the first place. To take the
 example of video game, can you claim that the game works when 
 you
 run it at 0.5fps ?




 Yea, exactly. I've never really complained much about asm.js 
 because, well, at least it's an improvement over JS (and isn't 
 just simply "another browser-forced language I'm expected to 
 learn, use, and enjoy" like Dart). But yea, the whole 
 "backwards compatible with regular JS" is a big load of shit, 
 and yet asm.js makes fundamental design compromises simply for 
 the sake of that fundamentally broken "feature".


 Sadly, because of mozilla moves with ASM.js, there is no 
 industry
 standard to run native things in the browser. Until things 
 settle
 down, these are cool, but useless technologies.


 That is what the desktop is for anyway.


 Yea, see that's the real root issue behind this whole "Browser 
 Wars 2.0" clusterfuck. A bunch of web-obsessed asshats keep 
 trying to shove every damn thing into a browser window. Shit, 
 they don't even fucking *know* why they do it, they just don't 
 question "web is the future", as if it'd be some kind of heresy.

 We could've had some damn good cross-platform 
 zero-install/sandboxed-ez-install infrastructures in place by 
 now (ie, the *only* legitimate motivations for webapps) if all 
 these clowns hadn't been wasting all their effort on this 
 idiotic pig-with-makeup house of cards that is "web 2.0".


Most of my UI programming at work is Web based, as that is what 
the customers ask for.

On my side projects, I always do native UIs and I am hoping that 
the native mobile apps, finally make the people understand that 
what matters is the network protocols, not the browser.

The ideas behind the browser are great, when looked from the 
Xerox PARC hypermedia research, the implementation however leaves 
a lot to be desired.

The problem is that currently it is a document format, trying to 
be an application, with a clustf**** of JavaScript/CSS/HTML with 
more compatibility issues than when C was being standardized.

--
Paulo
May 15 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 16 May 2014 at 06:21:40 UTC, Paulo Pinto wrote:

 The problem is that currently it is a document format, trying 
 to be an application, with a clustf**** of JavaScript/CSS/HTML 
 with more compatibility issues than when C was being 
 standardized.


I think it is pretty good if you remove IE9 and below, but things 
like lists of items are slower with a DOM based solution when you 
get thousands of items.

I use few native apps these days... I dont really see many 
application areas that cannot run as PNaCl+Dart.
May 16 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 16 May 2014 at 10:36:16 UTC, Ola Fosheim Grøstad wrote:

 On Friday, 16 May 2014 at 06:21:40 UTC, Paulo Pinto wrote:

 The problem is that currently it is a document format, trying 
 to be an application, with a clustf**** of JavaScript/CSS/HTML 
 with more compatibility issues than when C was being 
 standardized.


 I think it is pretty good if you remove IE9 and below, but 
 things like lists of items are slower with a DOM based solution 
 when you get thousands of items.

 I use few native apps these days... I dont really see many 
 application areas that cannot run as PNaCl+Dart.


Good luck explaining to non-technical business owner why the CSS
isn't pixel perfect across Safari Mac OS X, Safari Windows,
Safari iOS, Chrome iOS, Chrome Android, Chrome Mac OS X, .....,
even though they are all Webkit based. Or why the need to spend
more days fixing issues across the same browser engine versions.

Specially when his/her opinion is what counts for releasing a
payment.

--
Paulo
May 16 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 16 May 2014 at 11:38:14 UTC, Paulo Pinto wrote:

 On Friday, 16 May 2014 at 10:36:16 UTC, Ola Fosheim Grøstad 
 wrote:

 On Friday, 16 May 2014 at 06:21:40 UTC, Paulo Pinto wrote:

 The problem is that currently it is a document format, trying 
 to be an application, with a clustf**** of 
 JavaScript/CSS/HTML with more compatibility issues than when 
 C was being standardized.


 I think it is pretty good if you remove IE9 and below, but 
 things like lists of items are slower with a DOM based 
 solution when you get thousands of items.

 I use few native apps these days... I dont really see many 
 application areas that cannot run as PNaCl+Dart.


 Good luck explaining to non-technical business owner why the CSS
 isn't pixel perfect across Safari Mac OS X, Safari Windows,
 Safari iOS, Chrome iOS, Chrome Android, Chrome Mac OS X, .....,
 even though they are all Webkit based. Or why the need to spend
 more days fixing issues across the same browser engine versions.

 Specially when his/her opinion is what counts for releasing a
 payment.

 --
 Paulo


Isn't it sad that we still don't have a standard we can rely on, 
a good one? Web development is really turning me off. JS, 
HTML/CSS is a compatibility hell. I have to use it, there's now 
way out, and I spend more time trying to fix things and finding 
work arounds than actually writing code. And the worst part is 
when your carefully designed code is being compromised, little by 
little, by work arounds you _have to_ find, work arounds against 
common sense and sanity. PHP is yet another can of worms!

When it comes to UI development, given the amount of platforms 
these days, I'd say a HTML/CSS based aproach is desireable. But 
connecting HTML to the logic, that's tough. I dream of the day 
when we can attach any language to HTML. Is it so hard?
May 16 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 8:57 AM, Chris wrote:

 Isn't it sad that we still don't have a standard we can rely on, a good
 one? Web development is really turning me off. JS, HTML/CSS is a
 compatibility hell. I have to use it, there's now way out, and I spend
 more time trying to fix things and finding work arounds than actually
 writing code. And the worst part is when your carefully designed code is
 being compromised, little by little, by work arounds you _have to_ find,
 work arounds against common sense and sanity. PHP is yet another can of
 worms!


I actually find HTML/CSS isn't hard to deal with if I ignore all newer 
features and "best practices" and stick to HTML4/CSS2. Any time I've run 
into any problems, I was always able to solve it by taking a step back 
and invariably realizing I was over-engineering something. Take things 
back to basics (and train your designer to know their mockups will 
merely be taken as rough guidelines), and all the real problems just 
simply vanish.

All the problems and incompatibilities and PITA are with the newer, less 
well-baked ideas and features. Developing on FF2 makes widely-compatible 
web apps easy :) (Although, I'll grant that "display: inline-block" is 
awesome.)

Well, at least all that *was* the case until I discovered basically all 
mobile browsers *insist* on completely fucking around with all your 
tables behind your back, *completely* ignoring all instructions to knock 
it the fuck off:

http://semitwist.com/articles/article/view/a-decade-plus-later-and-html-css-is-still-schizophrenic-crapware

But then again, in my experience (even just as a user), mobile browsers 
are horrid fucking shit anyway. Try going to forum.dlang.org on a mobile 
browser (*any* mobile browser), hit "Reply" and try to snip all but one 
sentence of the quoted message. You can't fucking do it. I've blown 
literally half an hour trying to do that (even going so far as trying 
three different browsers and installing updates, none of which solved 
things). And that was even *WITH* a stylus! (Or at least what passes for 
a stylus these days.)

But on a real computer it's freaking trivial - takes literally a few 
seconds. If there were an up-to-date PalmOS, it would even be trivial on 
that too, just because of the intelligent way text boxes worked on Palm. 
But on all this dumbfuck Jobs-ian style horse shit like iOS and Android, 
it's just unusable fucking crap. Damn things are supposed to be portable 
and yet it's usually *faster* to just wait until you get home to 
do...whatever...on a real fucking computer. It's no damn wonder everyone 
lives with their heads buried in their phones these days - it *takes* 
that fucking long to accomplish even the most trivial shit on these 
worthless goddamn Apple-style designs.


 When it comes to UI development, given the amount of platforms these
 days, I'd say a HTML/CSS based aproach is desireable. But connecting
 HTML to the logic, that's tough. I dream of the day when we can attach
 any language to HTML. Is it so hard?


Meh, spend a few minutes with Tk (for example), or any decent RAD tool 
(even Visual Basic, if you ignore the language itself), and it becomes 
very clear just how horrid HTML/CSS/JS are as a UI engine. (Not that I 
ever considered HTML any good for that purpose...)
May 16 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 6:36 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 I use few native apps these days... I dont really see many application
 areas that cannot run as PNaCl+Dart.


I don't see many webapp areas than cannot run as proper software ;)
May 16 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 16.05.2014 20:55, schrieb Nick Sabalausky:

 On 5/16/2014 6:36 AM, "Ola Fosheim Grøstad"
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 I use few native apps these days... I dont really see many application
 areas that cannot run as PNaCl+Dart.


 I don't see many webapp areas than cannot run as proper software ;)


+1 :)
May 16 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 16 May 2014 at 18:55:44 UTC, Nick Sabalausky wrote:

 I don't see many webapp areas than cannot run as proper 
 software ;)


Hehe :) Well, it is a question of cost and control.

You cut:
- development costs
- installation costs
- upgrade costs

You win:
- no more piracy
- full control over data and backups
- fully datacenter based, cuts on maintenance
- cross platform
- less crashes

You loose:
- performance
- privacy
- power user stuff

I'd rather have HTML5 than Adobe Flex which was the main 
competitor.
May 16 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 3:26 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Friday, 16 May 2014 at 18:55:44 UTC, Nick Sabalausky wrote:

 I don't see many webapp areas than cannot run as proper software ;)


 Hehe :) Well, it is a question of cost and control.

 You cut:
 - development costs


Ha ha hah ha. No. God no. ;)


 - installation costs
 - upgrade costs

 You win:
 - no more piracy
 - full control over data and backups
 - fully datacenter based, cuts on maintenance
 - cross platform
 - less crashes


All of that is just as easily solvable without a web browser and 
HTML/CSS/JS. The browser and HTML/etc are completely incidental to the 
way those were solved.

We could've had all that by now if so much effort hadn't been wasted on 
HTML/etc.


 You loose:
 - performance
 - privacy
 - power user stuff


Those are very significant downsides.


 I'd rather have HTML5 than Adobe Flex which was the main competitor.


Well yea, granted. Any software development tool/tech from Adobe is 
guaranteed to be the worst possible garbage imaginable. HTML5 is a 
rancid burger with half a dog turd on it. Adobe Flex/Flash/whatever is 
just simply a big bowl of diarrhea.
May 16 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 16 May 2014 at 19:54:00 UTC, Nick Sabalausky wrote:

 All of that is just as easily solvable without a web browser 
 and HTML/CSS/JS. The browser and HTML/etc are completely 
 incidental to the way those were solved.

 We could've had all that by now if so much effort hadn't been 
 wasted on HTML/etc.


Yes, but today you have the option to build your own framework on 
top of WebGL. That basically just leaves the browser as a shell 
if you want to.


 imaginable. HTML5 is a rancid burger with half a dog turd on 
 it. Adobe Flex/Flash/whatever is just simply a big bowl of 
 diarrhea.


Hehe. But you now have this thing called shadow DOM, so you can 
define your own HTML5 elements with behaviour. You will probably 
see UI kits for that within 1-2 years. (IE9 is holding back 
development).

CSS selectors have also turned out to be quite good and well 
supported these days. You can do a lot of stuff with those.
May 16 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
 define your own HTML5 elements with behaviour. You will 
 probably see UI kits for that within 1-2 years. (IE9 is holding 
 back development).


Stuff like this... https://angulardart.org/demo/
May 16 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 4:03 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Friday, 16 May 2014 at 19:54:00 UTC, Nick Sabalausky wrote:

 All of that is just as easily solvable without a web browser and
 HTML/CSS/JS. The browser and HTML/etc are completely incidental to the
 way those were solved.

 We could've had all that by now if so much effort hadn't been wasted
 on HTML/etc.


 Yes, but today you have the option to build your own framework on top of
 WebGL. That basically just leaves the browser as a shell if you want to.


Meh, it leaves the browser as a resource-sucking, interface-damaging 
vestigial limb. Besides, the web's already enough of a leaning tower of 
abstractions as it is.


 imaginable. HTML5 is a rancid burger with half a dog turd on it. Adobe
 Flex/Flash/whatever is just simply a big bowl of diarrhea.


 Hehe. But you now have this thing called shadow DOM, so you can define
 your own HTML5 elements with behaviour. You will probably see UI kits
 for that within 1-2 years.


Hmm, taking a quick look at it, it doesn't appear to offer anything that 
can't already be done (albeit less hygienically). It appears to just 
function as a form of DOM namespaces.

Still a good thing for them to add, of course, just doesn't sound like 
it's really all that much of a "create your own elements" feature, at 
least any more than what's already possible. Rather, it's just a nice 
ability to help aid making/using HTML-based widgets. ('Course, this is 
based on only a few minutes of web searching on the topic, so I could be 
wrong about any of it.)

It does have the distinction though of being the web technology with by 
far the coolest name :)


 (IE9 is holding back development).


Meh, IMO it's not IE9, it's MS's insistence on trying to kill XP without 
ever bothering to put out a real replacement (Vista and Win8 were 
basically just screwups, and Win7 is really just "MS OSX"). If MS hadn't 
refused to put newer IEs on XP (a clear attempt at forcing Windows 
upgrades), then we'd be rid of older IEs much quicker.

But no, the newer Windows have gotten so shitty, and so steadfast on 
forcing their latest UI-of-the-week "improvements" on anyone who doesn't 
want it, that in order to sell Windows upgrades MS has to resort to 
things like refusing IE updates. (They can't even manage to compete with 
a nearly 15-year-old OS without going so far as yanking security support 
and browser updates. That's how bad they've gotten at "improving" and 
upgrading Windows.) Ehh, but now I've managed to sidetrack myself on yet 
another tangential rant...
May 17 2014
prev sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Friday, 16 May 2014 at 19:54:00 UTC, Nick Sabalausky wrote:

 On 5/16/2014 3:26 PM, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Friday, 16 May 2014 at 18:55:44 UTC, Nick Sabalausky wrote:
 You loose:
 - performance
 - privacy
 - power user stuff


 Those are very significant downsides.


Well, on me it has also the side effect of "you loose mental 
sanity"...

I'm not an HTML/Javascript gui, but for strange reasons I had to 
use Meteor at work: whoa I really really can feel the pain when I 
have to switch from a D project to that mess...

;-P

---
Paolo
May 17 2014
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 2:21 AM, Paulo Pinto wrote:

 The ideas behind the browser are great, when looked from the Xerox PARC
 hypermedia research, the implementation however leaves a lot to be desired.

 The problem is that currently it is a document format, trying to be an
 application, with a clustf**** of JavaScript/CSS/HTML with more
 compatibility issues than when C was being standardized.


Exactly. I actually love HTTP/HTML as a document system (especially the 
older versions of HTML that deliberately left style/formatting mostly up 
to browser/user, with the ability to override when really necessary). 
Not perfect of course, but still quite good overall.

But then using it as a GUI engine and software platform is like abusing 
Latex or PDF to make software run inside Acrobat Viewer. All the effort, 
bloat and compromises...and for what point?
May 16 2014
next sibling parent reply David Gileadi <gileadis NSPMgmail.com> writes:
On 5/16/14, 11:52 AM, Nick Sabalausky wrote:

 But then using it as a GUI engine and software platform is like abusing
 Latex or PDF to make software run inside Acrobat Viewer. All the effort,
 bloat and compromises...and for what point?


I assume that question is mostly rhetorical, because of course the point 
for many companies is that while some subset of users may have Acrobat 
Viewer installed, everyone has a browser. Compare the process of 
installing a native app (even on simple devices like phones) to the 
single click for loading a web app. Add to that making sure the user 
gets timely bug fixes and new features and it's easy to see why web apps 
make sense for many companies.

It's just tragic that the format for them evolved through HTML; it's 
become monstrous and deformed in all the ways you've discussed.
May 16 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, May 16, 2014 at 12:15:40PM -0700, David Gileadi via Digitalmars-d wrote:

 On 5/16/14, 11:52 AM, Nick Sabalausky wrote:

But then using it as a GUI engine and software platform is like
abusing Latex or PDF to make software run inside Acrobat Viewer. All
the effort, bloat and compromises...and for what point?


 
 I assume that question is mostly rhetorical, because of course the
 point for many companies is that while some subset of users may have
 Acrobat Viewer installed, everyone has a browser.


Given my belated discovery today (that PDFs can contain scripts,
attachments, and movies), I regard this as a most fortunate thing! Else
we'd be stuck with AdobeOS inflicting bloat, security holes, and broken
functionality on computers everywhere.



 Compare the process of installing a native app (even on simple devices
 like phones) to the single click for loading a web app. Add to that
 making sure the user gets timely bug fixes and new features and it's
 easy to see why web apps make sense for many companies.
 
 It's just tragic that the format for them evolved through HTML; it's
 become monstrous and deformed in all the ways you've discussed.


I long for the day when we will finally shed all vestiges of HTML,
Javascript, CSS, and whatever it is that's the hot item today, and
replace it all with a properly-designed universal system. Sadly, I will
probably not live to see that day.


T

-- 
Why is it that all of the instruments seeking intelligent life in the universe
are pointed away from Earth? -- Michael Beibl
May 16 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 3:15 PM, David Gileadi wrote:

 On 5/16/14, 11:52 AM, Nick Sabalausky wrote:

 But then using it as a GUI engine and software platform is like abusing
 Latex or PDF to make software run inside Acrobat Viewer. All the effort,
 bloat and compromises...and for what point?


 I assume that question is mostly rhetorical, because of course the point
 for many companies is that while some subset of users may have Acrobat
 Viewer installed, everyone has a browser.


My point was just to illustrate the absurdity of contorting a document 
format into an applications platform.

As an irrelevent side note with no particular point being made: Acrobat 
Viewer is still depressingly common, and I'd say PDF viewers in general 
are about as ubiquitous as web browsers.


 Compare the process of
 installing a native app (even on simple devices like phones) to the
 single click for loading a web app. Add to that making sure the user
 gets timely bug fixes and new features and it's easy to see why web apps
 make sense for many companies.

 It's just tragic that the format for them evolved through HTML; it's
 become monstrous and deformed in all the ways you've discussed.


Yea. See, none of those perceived benefits of web apps have ever 
actually required web browsers at all. It would have taken less effort 
to build those benefits *outside* of web browsers, than what has already 
gone into the endless failed attempts to de-shitify "web as an 
applications platform". But no, everything's run by managers, and 
managers want quick fixes because they don't comprehend hidden costs. :(
May 16 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, May 16, 2014 at 02:52:43PM -0400, Nick Sabalausky via Digitalmars-d
wrote:

 On 5/16/2014 2:21 AM, Paulo Pinto wrote:

The ideas behind the browser are great, when looked from the Xerox
PARC hypermedia research, the implementation however leaves a lot to
be desired.

The problem is that currently it is a document format, trying to be
an application, with a clustf**** of JavaScript/CSS/HTML with more
compatibility issues than when C was being standardized.


 
 Exactly. I actually love HTTP/HTML as a document system (especially
 the older versions of HTML that deliberately left style/formatting
 mostly up to browser/user, with the ability to override when really
 necessary). Not perfect of course, but still quite good overall.
 
 But then using it as a GUI engine and software platform is like
 abusing Latex or PDF to make software run inside Acrobat Viewer. All
 the effort, bloat and compromises...and for what point?


No software is feature-complete until it can read email. :-)

Today I skimmed over the PDF spec... and was horrified to discover that
I had been living in a fool's paradise, thinking that it was only a
passive *document* format. Turns out that it is yet another of those
document format turned Turing-complete messes. With its own embedded
flavor of Javascript, even. (And obviously, it's gratuitously
incompatible with "standard" JS). With the ability to attach files.
(Huh, what?! I thought PDF was *the* attachment... nope, not only it can
contain executable JS code, which is just a repetition of that security
nightmare that is Outlook + ActiveX, it can also encapsulate an entire
directory structure within itself. Yep. No bloatware here, move along.)
PDFs can also embed *movies*. (!!!)

So basically, you can create an entire interactive website inside a
single PDF file, complete with scripting, movies, embedded subfiles
(basically a self-contained directory structure aka URL tree). It would
utterly suck, of course, given that probably only crappy Adobe bloatware
would be able to interpret the resulting mess. But you could do it. And
obviously somebody *has* done it, since otherwise where did all these
features come from? One of these days, somebody's gonna reinvent the
browser inside a PDF file...

This seriously tempts me to go back to standardizing on Postscript. I
just want the *document* part of it, darnit!! What's with this obsession
of making every single file format Turing-complete so that it can run
scripts and play movies?! Why reinvent the computer inside a file
format?! Argh...

This is exactly the same thing that happened with HTML/HTTP. HTTP was
originally designed to be stateless because... the whole point was to
serve *static documents*?! It's a totally sucky protocol for interactive
media, to say the least. All the pathology with cookies, Javascript,
AJAX, and the rest of that jazz that got piled on top, basically arose
from trying to shoehorn a stateless protocol into something stateful.
Nobody ever considers to *replace* the darn protocol with something
*designed* for that purpose. Or that three-headed 5-eyed slimy
monstrosity that is HTML, with something a little more... *suitable*?...
for describing UI elements. Y'know, like a GUI toolkit or something! But
no, we have to use HTML because HTML is cool, and therefore that makes a
HTML UI implementation cool. The Emperor has no clothes, and nobody says
a thing lest they be regarded as fools.

A future generation -- if there even will be one, at the rate we're
going -- will look back and laugh at the foolishness that is today's
computing world.


T

-- 
What is Matter, what is Mind? Never Mind, it doesn't Matter.
May 16 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 16 May 2014 at 19:28:26 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 Today I skimmed over the PDF spec... and was horrified to 
 discover that
 I had been living in a fool's paradise, thinking that it was 
 only a
 passive *document* format. Turns out that it is yet another of 
 those
 document format turned Turing-complete messes. With its own 
 embedded
 flavor of Javascript, even. (And obviously, it's gratuitously
 incompatible with "standard" JS). With the ability to attach 
 files.


Yeah, it is quite messy. I read it a year ago in order to 
generate some PDF files with images, and was surprised by the 
length of the PDF format documentation and getting more than one 
image onto a page takes planning… I get the impression that they 
tried to target Word with all kinds of features for sending in 
forms and what not. The text based format looks like it came from 
the past… Same with HTTP and SMTP. It looks like a telex from the 
1950s. Why on earth did they pick a date format that is so hard 
to parse, not to mention all the plain wrong uses of said format 
that you also have to parse. HTML5 is great in comparison!

IT tech has always been driven by: ease of installation, ease of 
getting started, and if not, the ease of getting a hackish 
implementation on it's feet (this is HTTP). Then evolve from that.

As a contrast SVG is actually pretty clean. A bit too complex 
perhaps and the integration with HTML is poor. Actually MS' VML 
had better integration… Postscript was cool, but could be slow.
May 16 2014
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 3:26 PM, H. S. Teoh via Digitalmars-d wrote:

 No software is feature-complete until it can read email. :-)


Heh :)


 Today I skimmed over the PDF spec... and was horrified to discover that
 I had been living in a fool's paradise, thinking that it was only a
 passive *document* format. Turns out that it is yet another of those
 document format turned Turing-complete messes. With its own embedded
 flavor of Javascript, even. (And obviously, it's gratuitously
 incompatible with "standard" JS). With the ability to attach files.
 (Huh, what?! I thought PDF was *the* attachment... nope, not only it can
 contain executable JS code, which is just a repetition of that security
 nightmare that is Outlook + ActiveX, it can also encapsulate an entire
 directory structure within itself. Yep. No bloatware here, move along.)
 PDFs can also embed *movies*. (!!!)


The scripted-PDFs is news to me, but I have known for some time that PDF 
is absurdly over-engineered. At it's core, it actually *isn't* a 
document format really, it's a container format. And definitely is 
designed to contain literally anything you fell like cramming into it. 
And not exactly the best container format in the world, either.


 This is exactly the same thing that happened with HTML/HTTP. HTTP was
 originally designed to be stateless because... the whole point was to
 serve *static documents*?! It's a totally sucky protocol for interactive
 media, to say the least. All the pathology with cookies, Javascript,
 AJAX, and the rest of that jazz that got piled on top, basically arose
 from trying to shoehorn a stateless protocol into something stateful.
 Nobody ever considers to *replace* the darn protocol with something
 *designed* for that purpose. Or that three-headed 5-eyed slimy
 monstrosity that is HTML, with something a little more... *suitable*?...
 for describing UI elements. Y'know, like a GUI toolkit or something! But
 no, we have to use HTML because HTML is cool, and therefore that makes a
 HTML UI implementation cool. The Emperor has no clothes, and nobody says
 a thing lest they be regarded as fools.


+1 million :)

I'm actually kinda disappointed something like Adam's old experimental 
windowing toolkit hasn't taken the world by storm.


 A future generation -- if there even will be one, at the rate we're
 going -- will look back and laugh at the foolishness that is today's
 computing world.


I wish I could believe that. But it hinges on the assumption that people 
actually *will* wise up. Which is a notion I've become increasingly 
skeptical of. :/ But hey, who knows.
May 16 2014
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Friday, 16 May 2014 at 19:28:26 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 No software is feature-complete until it can read email. :-)

 Today I skimmed over the PDF spec... and was horrified to 
 discover that
 I had been living in a fool's paradise, thinking that it was 
 only a
 passive *document* format. Turns out that it is yet another of 
 those
 document format turned Turing-complete messes. With its own 
 embedded
 flavor of Javascript, even. (And obviously, it's gratuitously
 incompatible with "standard" JS). With the ability to attach 
 files.
 (Huh, what?! I thought PDF was *the* attachment... nope, not 
 only it can
 contain executable JS code, which is just a repetition of that 
 security
 nightmare that is Outlook + ActiveX, it can also encapsulate an 
 entire
 directory structure within itself. Yep. No bloatware here, move 
 along.)
 PDFs can also embed *movies*. (!!!)

 So basically, you can create an entire interactive website 
 inside a
 single PDF file, complete with scripting, movies, embedded 
 subfiles
 (basically a self-contained directory structure aka URL tree). 
 It would
 utterly suck, of course, given that probably only crappy Adobe 
 bloatware
 would be able to interpret the resulting mess. But you could do 
 it. And
 obviously somebody *has* done it, since otherwise where did all 
 these
 features come from? One of these days, somebody's gonna 
 reinvent the
 browser inside a PDF file...

 This seriously tempts me to go back to standardizing on 
 Postscript. I
 just want the *document* part of it, darnit!! What's with this 
 obsession
 of making every single file format Turing-complete so that it 
 can run
 scripts and play movies?! Why reinvent the computer inside a 
 file
 format?! Argh...

 This is exactly the same thing that happened with HTML/HTTP. 
 HTTP was
 originally designed to be stateless because... the whole point 
 was to
 serve *static documents*?! It's a totally sucky protocol for 
 interactive
 media, to say the least. All the pathology with cookies, 
 Javascript,
 AJAX, and the rest of that jazz that got piled on top, 
 basically arose
 from trying to shoehorn a stateless protocol into something 
 stateful.
 Nobody ever considers to *replace* the darn protocol with 
 something
 *designed* for that purpose. Or that three-headed 5-eyed slimy
 monstrosity that is HTML, with something a little more... 
 *suitable*?...
 for describing UI elements. Y'know, like a GUI toolkit or 
 something! But
 no, we have to use HTML because HTML is cool, and therefore 
 that makes a
 HTML UI implementation cool. The Emperor has no clothes, and 
 nobody says
 a thing lest they be regarded as fools.

 A future generation -- if there even will be one, at the rate 
 we're
 going -- will look back and laugh at the foolishness that is 
 today's
 computing world.


 T


What a refreshing thread!
That's a hope in the world after all!

;-P

--
Paolo
May 17 2014
prev sibling parent "Joakim" <dlang joakim.airpost.net> writes:
On Friday, 16 May 2014 at 19:28:26 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Fri, May 16, 2014 at 02:52:43PM -0400, Nick Sabalausky via 
 Digitalmars-d wrote:

 But then using it as a GUI engine and software platform is like
 abusing Latex or PDF to make software run inside Acrobat 
 Viewer. All
 the effort, bloat and compromises...and for what point?


 No software is feature-complete until it can read email. :-)

 Today I skimmed over the PDF spec... and was horrified to 
 discover that
 I had been living in a fool's paradise, thinking that it was 
 only a
 passive *document* format. Turns out that it is yet another of 
 those
 document format turned Turing-complete messes. With its own 
 embedded
 flavor of Javascript, even. (And obviously, it's gratuitously
 incompatible with "standard" JS). With the ability to attach 
 files.
 (Huh, what?! I thought PDF was *the* attachment... nope, not 
 only it can
 contain executable JS code, which is just a repetition of that 
 security
 nightmare that is Outlook + ActiveX, it can also encapsulate an 
 entire
 directory structure within itself. Yep. No bloatware here, move 
 along.)
 PDFs can also embed *movies*. (!!!)

 So basically, you can create an entire interactive website 
 inside a
 single PDF file, complete with scripting, movies, embedded 
 subfiles
 (basically a self-contained directory structure aka URL tree). 
 It would
 utterly suck, of course, given that probably only crappy Adobe 
 bloatware
 would be able to interpret the resulting mess. But you could do 
 it. And
 obviously somebody *has* done it, since otherwise where did all 
 these
 features come from? One of these days, somebody's gonna 
 reinvent the
 browser inside a PDF file...


Heh, this recently came up in a good article about how broken 
software security is:

https://medium.com/message/81e5f33a24e1#493c-7acd71bf4c69
May 28 2014
prev sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Friday, 16 May 2014 at 06:21:40 UTC, Paulo Pinto wrote:

 On my side projects, I always do native UIs and I am hoping 
 that the native mobile apps, finally make the people understand 
 that what matters is the network protocols, not the browser.

 The ideas behind the browser are great, when looked from the 
 Xerox PARC hypermedia research, the implementation however 
 leaves a lot to be desired.

 The problem is that currently it is a document format, trying 
 to be an application, with a clustf**** of JavaScript/CSS/HTML 
 with more compatibility issues than when C was being 
 standardized.

 --
 Paulo


Can not agree more!
--
Paolo
May 17 2014
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 14 May 2014 at 20:50:47 UTC, deadalnix wrote:

 On Tuesday, 13 May 2014 at 17:16:18 UTC, Etienne wrote:

 I'd like to point out that asm.js is a very fast subset of the 
 javascript language that allows almost native speeds (3x 
 slowdown vs C only) which enables games to be run in the 
 browser without external dependencies.


 You keep saying the browser, but what you mean is firefox (and
 other mozilla products).

 For the story, mozilla dropped out of the NaCl project so they
 can pull out their me too solution. Now we are back to where we
 were 10 years ago with the browser war. We could have one 
 unified
 standard int he name of NaCl, but fuck that, now we have too.

 ASM.js is inferior in every possible way (slower, bigger source,
 more overhead, you name it) to NaCl except one: ASM.js run in a
 standard JS interpreter. Except that if you are using this, it 
 is
 because you need the speed in the first place. To take the
 example of video game, can you claim that the game works when 
 you
 run it at 0.5fps ?

 Sadly, because of mozilla moves with ASM.js, there is no 
 industry standard to run native things in the browser. Until 
 things settle down, these are cool, but useless technologies.


With their new LLVM JIT compiler, Webkit has gained optimizations 
that, as side effect, also benefit asm.js code patterns.

https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

However, I think the place of native applications, is on native 
platforms. As mentioned on another reply.

--
Paulo
May 15 2014