TechWeb

Google Brings Portable Native Client To Chrome

Nov 14, 2013 (04:11 AM EST)

Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=240163898


Google Barge: 10 Informative Images
Google Barge: 10 Informative Images
(click image for larger view)
As part of its ongoing effort to make Web apps perform as well as native apps, Google on Tuesday released Portable Native Client (PNaCl), a software framework that allows developers to compile native C and C++ code so that it can be embedded in and run from any website.

Native code can take advantage of CPUs and GPUs in a way that Web applications still cannot to enable computationally demanding applications that involve sophisticated graphics.

Portable Native Client differs from Google's Native Client (NaCl) technology in that it creates architecture-independent output. Where native code compiled with NaCl emerges tuned for a specific instruction set, like x86, ARM or MIPS, programs compiled with PNaCl will run on any hardware platform. In other words, they will work on mobile and desktop devices.

[ But will it play music? Read Google Glass Plans To Play Music. ]

PNaCl compiles native code into an intermediate form. The resulting LLVM-bytecode then gets wrapped in a portable executable file that can be served from a website.

"When the site is accessed, Chrome fetches and translates the portable executable into an architecture-specific machine code optimized directly for the underlying device," explains Google engineer David Sehr in a blog post.

While PNaCl may allow developers to create hardware-independent code, it's not quite platform-independent: PNaCl applications require Google Chrome to run, because other browser vendors haven't integrated the technology.

There's a way around this however: PNaCl applications rely on the pepper.js Javascript library to communicate with Web browsers. Thanks to the Emscripten compiler, PNaCl apps (as LLVM-bytecode) can be converted into JavaScript, so the code will run in other browsers, like Firefox, Internet Explorer, and Safari.

In the near term, PNaCl makes ChromeOS more competitive with OS X and Windows as computing environments suited to computationally demanding applications. Whether Google's technology will benefit the Web in the years to come remains to be seen.

Mozilla has been backing asm.js, a separate effort to make Web apps perform better through a stripped-down, compiler-friendly version JavaScript. In May, Mozilla engineer Robert O'Callahan articulated some of the issues that make PNaCl controversial.

"PNaCl and Pepper are not open standards, and there are not even any proposals on the table to standardize them in any forum," O'Callahan wrote in a blog post. "They have documentation, but for the details one must defer to the large bundle of Chrome code that implements them. Other vendors wishing to support PNaCl or Pepper would have to adopt or reverse-engineer this code."

As for Apple and Microsoft, its hard to see either company going out of its way to help hasten adoption of Google's technology. If Google can encourage enough developers to create compelling PNaCl applications that consumers flock to, perhaps Apple and Microsoft will be forced to adapt. But don't hold your breath; it could take a while.

Beyond the platform and technology differences that divide the major browser makers, there's an additional issue: access. JavaScript, for all its faults, is there for anyone to read. PNaCl code, and to a lesser extent asm.js code, isn't easy to understand. The price we may pay for faster Web apps is the ability to read and learn from the Web's underlying code.