
Blink, PNaCl, And Standards  - thristian
http://robert.ocallahan.org/2013/05/blink-pnacl-and-standards.html
======
dragonwriter
_The_ key premise of this article is unsubstantiated by the provided link. The
article states, "Unfortunately, Google has recently announced that they will
expose Portable Native Client (PNaCl) --- and by extension, the Pepper APIs
--- to all Web pages"; all the article's complaints are based on this
description and the assumption that it will be exposed to all web pages
without first being standardized.

But this claim is misleading; the closest the announcement page that is linked
from the article [1] comes to supporting it is saying "Once PNaCl is fully
released, users will be able to run PNaCl modules on any web page". It does
not state an intent to transition PNaCl to this "fully released" state at any
particular time in the future, or without standardization.

[1] <https://developers.google.com/native-client/announcements> (the relevant
announcement is the May 15, 2013)

~~~
azakai
Google's announcement says

> Once PNaCl is fully released, users will be able to run PNaCl modules on any
> web page – applications will not need to be deployed through the Chrome Web
> Store in order to run PNaCl modules.

NaCl has always been enabled only in the Store, and not on the web, while the
news in that announcement is that it will be enabled on the web.

If you still think that isn't clear, watch the recent Google IO PNaCl talk,
where this is stated as well,

<http://www.youtube.com/watch?v=5RFjOec-TI0>

If somehow there is a misunderstanding of the intent of both announcements,
then I hope Google will clarify that.

~~~
dragonwriter
> NaCl has always been enabled only in the Store, and not on the web, while
> the news in that announcement is that it will be enabled on the web.

...when PNaCl is fully released. Which is what they've said for years, that
they weren't turning any Native Client on for the web until PNaCl was ready to
be "fully released". So that wasn't actually the news.

The _actual_ news was the announcement that PNaCl execution is supported (not
that PNaCl will be "fully released") from Chrome 29, which was, at the time,
the Canary version of Chrome (its since moved to the Dev channel.) Prior to
Chrome 29, the only way to run PNaCl code -- or rather, code that had been
generated by the PNaCl toolchain -- in the browser was to run it through
another tool which generated regular, architecture-specific NaCl code.

~~~
azakai
I understand it is possible to read those announcements in that way. It seems
a bit of a stretch (look at how things are phrased in the video). But again, I
hope you are right.

There are plenty of Google people reading HN, hopefully they can quickly
confirm things one way or the other.

------
lucian1900
Asm.js is no more an open standard than PNaCl. While I'm sure others disagree,
PNaCl is much cleaner in design and with more predictable performance. It's
the one I'd like to see win.

~~~
pcwalton
V8 is implementing optimizations for asm.js, as highlighted in Google I/O. (It
is ignoring the "use asm" directive, though.) So there is some measure of buy-
in from other browser vendors.

There is also a spec for asm.js and a relatively small API footprint, making
it an open standard, albeit one not (yet) sanctioned by ECMA.

~~~
lucian1900
V8 is fixing bugs they had that caused asm.js-style JavaScript to be slower
than it needs to be. I doubt they'll honour the "use asm" directive in the
near future.

asm.js is indeed a smaller API. I guess extreme pragmatism is what has been
driving the web, but it can be argued whether that's great or terrible :(

~~~
mwcampbell
Shortest-path evolution has the best chance of winning, and asm.js is the
shortest path for everyone except Google.

~~~
cromwellian
Winning what? If 500+ million NaCl enabled Chrome users couldn't set off a
revolution in web gaming, why would asm.js? Reality is, gamers don't really
care about what the implementation details are, and whether someone is
distributed as web, or as installable download, or via Optical Disc.

They want the best game that maximizes the bang for their buck. None of the
proposed web solutions do that, although NaCL promises access to more system
resources than asm.js does.

~~~
kevingadd
Well, for one thing, NaCl was a stunning failure because it required platform-
specific compiles. For another thing, it only worked on the Chrome Web Store,
and nobody gives a shit about the Chrome Web Store. It also didn't work on
Android...

But yeah, I'm sure it's just because all code-in-the-browser technologies are
doomed and asm.js is too, not because Google's execution was completely
incompetent.

~~~
dragonwriter
> For another thing, it only worked on the Chrome Web Store

Actually, it works outside of the Web Store, but turning it on outside of the
CWS is behind a defaults-to-off flag in the Chrome's settings, because Google
_didn't want NaCl code getting deployed widely on the web_ , because they
didn't want code that would be locked to one architecture being widely
deployed when they knew the plan was for PNaCl to be the long-term
replacement.

~~~
kevingadd
I'm not going to criticize their thought process behind locking NaCl to CWS;
from a standards and 'open web' perspective, that was a sound choice. That
doesn't change the fact that it largely contributed to its failure in the
market. The game devs I talk to on a regular basis wanted to use NaCl, but
couldn't, because it was tied to the CWS.

~~~
dragonwriter
> That doesn't change the fact that it largely contributed to its failure in
> the market.

Yes, the fact that Google _choose to limit it specifically to prevent it from
being widespread in the market_ contributed to its limited use in the market.
But then, since its purpose wasn't to be widely used in the market (hence the
restrictions imposed) but to validate technology and components for PNaCl,
that's not really that surprising.

------
micro_cam
Am I the only one who feels like locking into a standard for something like
this without first developing and testing an implementation would be a
mistake?

~~~
wmf
There is a process for that: You prototype the feature under an off-by-default
feature flag, then standardize it, then turn it on by default. Apparently
Chrome follows this process for HTML/CSS features but not for PNaCl or DRM.

~~~
dragonwriter
> You prototype the feature under an off-by-default feature flag

Both NaCl and PNaCl, except for Chrome Web Store content, are under an off-by-
default feature flag.

> then standardize it, then turn it on by default. Apparently Chrome follows
> this process for HTML/CSS features but not for PNaCl or DRM.

Except that there is nothing but speculation, at least nothing cited in the
source article, supporting the idea that Google isn't following that path with
PNaCl.

------
cromwellian
NaCL was already part of Chromium prior to Blink, I hardly see the huge
difference between NaCL and PNaCl in this regard.

Besides that, Blink is the rendering engine, Blink != Chrome. To get Chrome,
you have to add in V8, NaCL, codecs, and a bunch of other stuff.

I see the promises to which Blink commits itself as being disjoint from
Chrome. After all, there are lots of Chrome-only APIs, like Chrome extensions,
Chrome sync, Chrome packaged apps, etc.

~~~
pcwalton
NaCl was never enabled for Web content, only for the Chrome Web Store. PNaCl
is going to be enabled for Web content.

~~~
dragonwriter
> NaCl was never enabled for Web content, only for the Chrome Web Store. PNaCl
> is going to be enabled for Web content.

The plan announced from fairly early in NaCl's lifecycle was that when PNaCl
was ready to be "fully released", it would be enabled for all web pages. The
announcement this article points to merely restates that. It does not --
contrary to the article's treatment -- announce imminent plans to "fully
release" PNaCl, or state that that release will happen without
standardization. It simply assumes that that is the case.

It may be true, it may not, but it certainly is incorrect to state that that
is what was announced in the announcement which the article links to and bases
its entire string of complaints on.

~~~
azakai
As mentioned above, I hope you are correct, but Google's announcement and
statements in the Google IO PNaCl talk seem to show otherwise. If there is a
misunderstanding, then hopefully Google can clarify.

If Google only enables PNaCl on the web if/when it is on track to become an
industry-accepted standard, then everything is ok from my perspective - I
think you agree to that?

~~~
dragonwriter
> If Google only enables PNaCl on the web if/when it is on track to become an
> industry-accepted standard, then everything is ok from my perspective - I
> think you agree to that?

I don't see how I could disagree with your description of what would be okay
from your perspective. I'm actually not particularly concerned one way or the
other; it certainly isn't as if Google hasn't pivoted to whatever the standard
solution is in the past even when they've previously embraced (and enabled-by-
default) a solution that ended up failing to become the standard. If Google
was trying to push developer-focussed tooling as a business model and so was
invested in its proprietary solutions winning, that would be different, but
AFAICT there business model around improving web performance is to enable
people to do more in the browser without relying on external code for the
underlying OS, and if asm.js addresses that problem its just as good for them
as it would be if PNaCl did it.

------
espadrine
What matters to me as a developer is this:

will there be more compilers targeting PNaCl, or asm.js?

Otherwise said, as a compiler writer, would you rather write a compiler that
works in all browsers, and which needs no tools because of how simple the
output is, or a compiler which targets just one browser, with a complex output
to target?

~~~
cromwellian
If you are a game developer, it doesn't much matter. Do you target a market of
500+ million Chrome users, or 2 billion web users, or 900 million Android
users, or 500 million iOS users?

You can write a game with fragmented performance, cross your fingers and hope
it runs everywhere and try to hit the largest market possible, or, you can
develop for a more predictable platform, target a smaller market, but
potentially gain more revenue with less development cost.

The idea that someone is going to just cross compile to asm.js and poof, the
game will work everywhere is a pipe dream. This attitude is likely to draw
public ire and bad reviews as people who happen to have VMs which won't
optimize it as good as Firefox, get unpredictably bad performance. It's
Android fragmentation made even worse.

The reality is, you are going to either target NaCl on Chrome, asm.js on
Firefox, and native C/C++ on Android NDK or iOS, and you're going to have to
maintain and certify four different versions in order to get best experience.

Not much different than trying to target a PS3, XB360, and Wii with a
multiplatform title.

If you look at modern game platforms, both on mobile, and on console/desktop,
they are leveraging not just GPUs, but multi-core CPUs. If you look at Ars's
evaluation of asm.js ([http://arstechnica.com/information-
technology/2013/05/native...](http://arstechnica.com/information-
technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-
asm-js/3/)) lack of SIMD and multi-threading is a huge performance hit. SIMD
can be fixed (e.g. what Dart did), but shared memory model in JS with
concurrency primitives would be a radical change to the semantics of JS, so I
don't see it happening.

In short, it's a nice dream that you can write once and run everywhere high
performance JS, the reality is, it isn't going to help major game developers
and they will still need per-browser, per-platform extensive testing and
tuning.

End users don't care. When I buy a game from a store, I expect it to run at
30fps with no janks minimally. This is one reason why iOS and consoles extract
great performance from platforms that have lower specs than competitors,
because a fixed target offers more opportunities for optimization.

I love the idea of write once run anywhere, but I think it's the wrong model
for high performance cpu hungry games where you want to maximize overall
system performance.

~~~
kibwen
I agree with your assessment that "write once, run anywhere" will always be
beholden to the lowest common denominator when it comes to games that try to
push the limits of performance. However, with regard to your statement "shared
memory model in JS with concurrency primitives would be a radical change to
the semantics of JS, so I don't see it happening", it isn't entirely hopeless.
Intel's Rivertrail[1] and Mozilla's Parallel JS[2][3] efforts might not pan
out as well as they expect, but at no point has either entity thrown up its
hands and declared the situation as impossible as you imply.

[1] <https://github.com/RiverTrail/RiverTrail/wiki>

[2]
[http://smallcultfollowing.com/babysteps/blog/2012/01/09/para...](http://smallcultfollowing.com/babysteps/blog/2012/01/09/parallel-
javascript/)

[3] <http://smallcultfollowing.com/babysteps/blog/categories/pjs/>

~~~
cromwellian
RiverTrail, like OpenCL is cool, but not every algorithm is amenable to these
models.

------
tim_hutton
Does NaCl/PNaCl have a future now we've seen what Emscripten/ASM.js can do?﻿

~~~
dochtman
It certainly seems unlikely, but I guess it depends on how fast asm.js can
get.

~~~
tim_hutton
Now only 1.3x slower than native on one large-ish benchmark (box2d):
<http://youtu.be/qrf9ONmtXbM> (I love the comparison he makes to evolution at
the end. Yes, the process may give ugly creatures sometimes but _they work_.)

~~~
cromwellian
Unless you have a system with 4-8 cores and SIMD, and you want to leave a
multiple of performance on the table: [http://arstechnica.com/information-
technology/2013/05/native...](http://arstechnica.com/information-
technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-
asm-js/3/)

For example, 1200% slower in Mandelbrot rendering with asm.js vs OpenMP C
code.

------
VikingCoder
Do we know for sure that Blink itself needs to support PNaCL / Pepper?

Or is it possible that PNaCL and Pepper can be implemented on top of Blink?

Do we know for sure that Blink itself is violating any of these principles, to
merely expose PNaCL / Pepper in Chrome?

------
zobzu
We're deep in the extend phase and start to see some extinguish attempts.

~~~
PommeDeTerre
Extinguishing JavaScript would actually be a very beneficial thing to do.

It's quite refreshing to see Google trying to offer a viable alternative
that's far more general in nature, and far more technologically-sound than its
competitors.

This contrasts heavily with what Mozilla is trying to do with asm.js. Their
approach, unfortunately, is nothing more than an atrocious hack. Instead of
doing things properly, they just maul JavaScript into a form that isn't as
horrible to work with, from an optimization standpoint. However, this is
clearly inferior to using a proper instruction set, bytecode, or intermediate
representation.

The worst part, though, is that asm.js further entrenches JavaScript. This is
going in the opposite direction of where we ought to be going. We need
browsers that offer a far more general runtime. JavaScript would merely be one
among many other languages targeting such a runtime, rather than being an
integral part of it like we see with asm.js.

------
programminggeek
How is NaCL support any different than allowing Java Applets on a page, or
Flash, or Silverlight?

~~~
wmf
Java, Flash, and Silverlight were NPAPI plugins that could work in multiple
browsers. NaCl uses PPAPI that's only supported in Chrome.

~~~
greggman
Here, Let me fix that for you

Java, Flash, and Silverlight were insecure platform specific NPAPI plugins
that make it easy to p0wn users machines.

PNaCl uses PPAPI that together are designed from the ground up to be portable
and secure. PPAPI provides the only APIs NaCL apps can call. They are cross
platform so you write 1 plugin and it runs on Linux/OSX/Windows. Compare to
NPAPI where the plugin has to be custom for each platform and calls into the
OS directly unrestricted.

~~~
jimbobimbo
Actually, Silverlight is a pretty secure platform: out of 10 listed [1]
vulnerabilities only 7 execute code and 2 gain admin access on the machine.

Here's how Flash player looks like: [2]

And here's Chrome's track of record: [3] (unfortunately, there's no good way
to filter out NaCl defects)

[1] [http://www.cvedetails.com/vulnerability-
list/vendor_id-26/pr...](http://www.cvedetails.com/vulnerability-
list/vendor_id-26/product_id-19887/Microsoft-Silverlight.html)

[2] [http://www.cvedetails.com/vulnerability-
list/vendor_id-53/pr...](http://www.cvedetails.com/vulnerability-
list/vendor_id-53/product_id-6761/Adobe-Flash-Player.html)

[3] [http://www.cvedetails.com/product/15031/Google-
Chrome.html?v...](http://www.cvedetails.com/product/15031/Google-
Chrome.html?vendor_id=1224)

------
RRRA
Is it only being developped as the native side for Chrome OS or is it really
planned as a all around web binary running thingie?

The issue being, nobody should be developing anything for it publicly until at
least 2 competing implementation have been created. But people don't seem to
care about that for some reason...

~~~
wmf
There aren't two competing implementations of Flash or iOS, but some people
made millions developing on those platforms.

------
pjmlp
IE is dead, God save Chrome!

