Native Client is Widely Misunderstood (2011)

http://chadaustin.me/2011/01/native-client-is-widely-misunderstood-and-what-google-should-do-about-it/

by felipellrocha • 12 years ago

19 22 12 years ago

chadaustin.me

mantrax52• 12 years ago

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

pekk• 12 years ago

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

mantrax52• 12 years ago

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.

zimbatm• 12 years ago

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.

leoc2• 12 years ago

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.

7952• 12 years ago

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.

gress3• 12 years ago

I don't think Google cares about it as a web standard. They just want to deploy it widely through chrome, ChromeOS, and chrome on Android (eventually), and use it as a Trojan horse for their own binary applications and OS components.

tootie• 12 years ago

I'm guessing Apple will cockblock them from ever deploying this to iOS. In that regard, asm.js is far more likely to see adoption.

gress3• 12 years ago

You're right that Apple won't allow that on iOS, but I don't think they care. This is about them establishing a new platform to displace Android and the open web.

ryanackley2• 12 years ago

I don't follow the trojan horse logic since they already have the unfettered ability to ship any binary component they want to the platforms you list without using Native Client.

gress3• 12 years ago

The Trojan horse logic is about being able to ship binary apps to those platforms within chrome without having to build everything in.

higherpurpose• 12 years ago

Native Client implies x86 False. Originally, Native Client was positioned as an x86 sandbox technology, but now it has a clear LLVM story, with x86-32, x86-64, and partially-implemented ARM backends. Portability is a key benefit of the web, and Google understands this.

And yet, Google seems to be pushing Intel chips in Chromebooks, to the point where Intel almost completely dominates the Chromebook market.

NaCl actually doesn't work "as is" on ARM, only PNaCl does, and I think Google tends to prefer NaCl over PNacl, which is why they keep pushing Intel Chromebooks in the market.

jayd16• 12 years ago

Intel is pushing Intel chips in Chromebooks. They're undercutting and OEMs are certainly not going to say no.

ryanackley2• 12 years ago

As someone who has actually developed in NaCl and participated in that community, your statements have no basis in fact and sound completely biased against Google.

Out of the box, PNaCl is now the default toolchain. All the NaCl docs discuss PNaCl as the target of choice. The build target of the tutorials in the NaCl docs is PNaCl. Also, in the dedicated NaCL Google Group, the NaCl team has been saying for years that PNaCl would eventually be the default and preferred target for NaCl components.

leoc2• 12 years ago

There's also a MIPS implementation now too.

Native Client is Widely Misunderstood (2011)

Related Stories