[mantrax5]

I understood it won't pick up, and lo and behold, I understood it right.

People were right that an x86 sandbox is a silly idea for a web standard, this is why it's no longer one.

As it is right now, it's ASM.JS, without the .JS (and so, without the backwards compatibility).

[7952]

Native code is already heavily used in the form of iOS apps, it just isn't part of the web. I am not sure that this distinction is particularly profound considering how reliant the app ecosystem is on the internet. What iOS offers are basic guarantees about the capabilities of the underlying hardware. Web apps can make no such assumptions, regardless of how cleverly they execute the code. So for native client the application will never run fast enough for a significant number of users despite the design goal of increased speed. Unless the app has latency or bandwidth constraints it will always be more reliably faster to do resource intensive work on a server.

[pekk]

I can tell you didn't read the article because it addresses your point first thing.

[mantrax5]

I actually did read it. And I'm responding to the idea that "see, you complained, and Google changed it, so your former complaints are now misunderstandings" is really not a valid thesis.

[DannyBee]

Your claim that it was ever meant to stay "an x86 sandbox" is contradicted by a lot of things, including the actual launch announcement for NACL:

http://googlecode.blogspot.com/2011/08/native-client-brings-...

" The next milestone for Native Client is architecture independence: Portable Native Client (PNaCl) will achieve this by using LLVM bitcode as the basis for the distribution format for Native Client content, translating it to the actual target instruction set before running. "

I actually dislike PNaCL for a different set of reasons, but claiming it was built as an x86 sandbox, and meant to stay that way, is just revisionist history. If you believed otherwise, it was, in fact, your misunderstanding.

[cliffbean]

Your history omits an earlier chapter, which was the period during which Google introduced NaCl to the world.

http://research.google.com/pubs/archive/34913.pdf (2009)

http://blog.chromium.org/2010/05/sneak-peek-at-native-client... (2010)

No mention of PNaCL anywhere. Eventually they did change their public messaging away from x86 sandbox and towards PNaCl, though not before causing lots of external confusion and fear. And even then, with the time it took to get PNaCl released, some of the external confusion persisted.

The earlier poster does indeed seem to have misunderstood the history, but it's easy to see where such misunderstanding may come from.

[DannyBee]

This is not how it was introduced, the blog post was the introduction. We published earlier research papers because we publish papers.

The plan was always the same.

Before this, the project wasn't really real, it was just research.

If you consider this "public messaging", then I guess google should never release research papers or research SDK's without fear of being raked over the coals?

If so, that's a sad state of affairs.

[cliffbean]

You're right that the first link I posted is a research paper, and that it should be interpreted accordingly. It is interesting though that in the paper, they compare NaCl to other systems, some of which include ISA virtualization, and they specifically say "we made a deliberate choice against virtualization". And this paper is just a small sample of what Google was saying about NaCl in 2009. But you're right, it is still a research project at that point.

However, you apparently missed the second link I posted, which is in fact a blog post and an introduction. NaCl is no longer a research project there. In fact, the post itself specifically describes the difference between research releases and the release it is announcing.

[tptacek]

They held the sandbox breaking contest (our team came in second!) in 2009. You're suggesting they announced in 2011, right?

[zimbatm]

If some code runs orders of magnitude slower it's the same as being incompatible. Yes you might execute an ASM.JS game on older browsers but at 1FPS it's not enjoyable.

[leoc]

Yes, but it seems the blame game plays out differently. If a website won't run because it's demanding a plugin of some kind or a different web browser then the user tends to blame the website; if it runs, painfully slowly, on their browser but quickly on a different model of browser then (s)he tends to blame his/her browser. Really, the way forward is to have things set up so that sites can compile to arch-specific NaCl and PNaCl and "asm.js", and then serve the browser the best one that it will accept.