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.
> 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,
> 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.
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.
> It does not state an intent to transition PNaCl to this "fully released" state at any particular time in the future, or without standardization.
Per the GoogleIO PNaCL talk, their goal is to have this out with Chrome 30. Even ignoring the impossible time horizon, let's not kid ourselves that there's any will to standardize this thing.
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.
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.
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 :(
> 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.
They don't need to use the "use asm" directive. There are many ways to optimize the asm.js style of code.
The important part is that it is not something that needs standardizing. It is a subset of JavaScript, nothing more. The output of other compilers like GWT is also a particular subset of JavaScript, and for years now browsers have optimized in varying degrees for many such subsets.
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.
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.
> 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.
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.
> 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.
I'm pretty sure PNaCl was created to solve the disconnect between ARM based Chromebooks and Atom based Chromebooks. If it also works for Chrome on Android, I think that is a happy side effect, especially since PNaCl was introduced (through flags) in Chrome shortly after the Samsung ARM Chromebook was released. If you want to create packaged Chrome applications for the Chrome Store, you want them to work regardless of the machine architecture.
> I'm pretty sure PNaCl was created to solve the disconnect between ARM based Chromebooks and Atom based Chromebooks.
I think PNaCl was announced (as a long-range project) before ChromeOS was, and I'm certain it was announced before there were any actual Chromebooks, muhc less a concrete disconnect between ARM-based and x86-based Chromebooks.
It was created to solve the problem of high-performance software being tied to a particular native platform, which was clearly an issue for Google's long-term vision of web-as-dominant-platform long before there were concrete issues of different platforms for Chromebooks.
asm.js is optimized for ahead-of-time verification and compilation. In this respect it's on an equal footing with PNaCl. Why would asm.js necessarily have worse performance?
Not really the same. Anything that implements standard javascript will be able to run asm.js code just fine, even if they don't implement the possible optimizations. The same isn't true for NaCL.
I know for certain that there are previous non-asm.js optimized builds of Firefox that run it fine (with a performance penalty, naturally.)
Chrome currently crashes because Chrome can't handle enough variables per context. This is a bug with V8 that is allegedly getting fixed.
It wouldn't surprise me if mobile support is currently minimal to none though; but this is something that can and almost surely will change independent of asm.js optimization support.
(And this is the Unreal demo specifically - smaller projects should be supported by virtually any modern browser* as far as I know.)
asm.js is a well-specified subset of things that are already pretty much standardized. PNaCl adds a whole lot of new stuff that has not been subject to community review, like (for instance) the entire input processing and rendering API. And it isn't yet clear which quirks are meant to be standard, as opposed to whatever happen to be accidents of the initial Chrome implementation.
If PNaCl were "just" coupling LLVM bytecode with some defined way of invoking existing browser APIs from within the bytecode, this would be a whole lot easier for browsers other than Chrome to support. But that's not what they're doing, or at least, not yet.
PPAPI itself is a Chrome only api at the moment. I'm really concerned about using a plugin api defined by its C/C++ behavior as some kind of standard. So we not only have the DOM apis but also another class of APIs that have their own quirks.
I'm not sure there is a great chance that other browser vendors will adopt LLVM, especially Microsoft. It will basically require them to not only reimplement the native compiler but also the frontend that compiles to LLVM bytecode and any additional SDK tools like a debugger.
Asm.js is a lot easier to implement on every level. It will be served compressed so there wont be a lot of size overhead compared to a bytecode format. If you just use asm.js to call into webGL or audio apis there shouldn't be any big performance difference over using something lower level like PNaCL. Additionally, different browsers may use different optimizations when compiling LLVM code, differing implementations will give different performance characteristics. PNacl is no different than asm.js in requiring that the compiler be optimized.
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?
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.
> 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.
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.
All those things are not enabled for web content. They are additional things that Chrome does, but they do not change how websites are built - they do not change the toolkit of things that web content has available to it.
If you add an extension to Chrome as a user, or use Chrome's syncing, that's fine. You're modifying the browser in a way that you want. But if Chrome adds a feature to web content that is nonstandard, then it risks fragmenting the web: Some sites will use it, and they will only work in Chrome. That's what the standards process is meant to avoid.
> 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.
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?
> 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.
> It is my understanding that you cannot use Blink without V8. I believe it was part of the incentive to fork. Am I wrong?
Part of the incentive to fork was to avoid having to maintain support for multiple JS engines in the core project. I don't think that means that Blink requires V8 so much as that Blink's support for JS engines (compared to pre-split WebKit's) no longer includes explicit support for the engine used by Safari (whose name I can't remember) as part of the source tree, and presumably will over time be more tightly adapted to the needs of V8.
This would seem to mean it will progressively become more difficult to build a Blink-based browser using a different JS engine.
They intend to tie V8 and the Dom deeper in the next versions of Chrome by using a new garbage collector. I'm pretty sure it will be well nigh impossible to use another Javascript engine.
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?
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...) 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.
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.
I agree that write once run anywhere is never quite so simple, but
> The reality is, you are going to either target NaCl on Chrome, asm.js on Firefox
is an oversimplification as well. Many asm.js codebases already run well on Chrome, and that will continue to improve, for the same reasons that all browsers are now fast at SunSpider, Octane, Kraken, etc.
But again, sure, if you need full performance everywhere, you may need to target multiple platforms and not just one. Some games might need to do that, but not all.
I agree for many casual Flash-like games it won't matter. But if you're shipping Call of Duty or Half Life 3, you really can't avoid treating the browser on a platform specific basis.
> Does NaCl/PNaCl have a future now we've seen what Emscripten/ASM.js can do?
Possibly not; Google certainly likes the things they come up with, but it wouldn't be the first time that they spent lots of effort behind one approach but switched to back another approach that solved the same problem that others championed because it was better positioned for standardization; Google's interest in native-like performance on the web are more about the functionality than the mechanism.
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.)
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.
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.
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...
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)