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
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
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
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 next sibling parent 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
prev sibling next sibling 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 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 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 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 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 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
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
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 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 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 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
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 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 next sibling parent "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
prev sibling next 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.

That is what the desktop is for anyway.
May 15 2014
prev sibling next 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 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 "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
prev sibling 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 next 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 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 next 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 "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...

software security is: https://medium.com/message/81e5f33a24e1#493c-7acd71bf4c69
May 28 2014
prev sibling next sibling parent 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
prev sibling 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