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.

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

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

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.

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

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?

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?

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

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

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.