Google shows Native Client built into HTML 5

Brad Chen, engineering manager of the Google Native Client

(Credit: Stephen Shankland/CNET)

SAN FRANCISCO--Google wants its Native Client technology to be a little more native.

Google Native Client, still highly experimental, lets browsers run program modules natively on an x86 processor for higher performance than with Web programming technologies such as JavaScript or Flash that involve more software layers to process and execute the code. But to use it, there's a significant barrier: people must install a browser plug-in.

However, Google wants to make the technology more broadly accessible in browsers through new technology coming to HTML, the standard used to build Web pages, and at the Google I/O developer conference Thursday demonstrated its work to make that happen.

Specifically, David Sehr, a tech lead for Native Client, showed off Web Workers standard to let Web pages assign different tasks to independent processing "threads," effectively letting a browser walk and chew gum at the same time rather than waiting for one chore to be finished before the next begins. Web workers are one element of the ambitious but still not finalized HTML 5 standard.

Why care? Because today your browser runs software excruciatingly slowly compared to native applications that run on your computer, but Google wants to speed them up tremendously, a move that would add a lot of muscle to its ambition to make Web-based software more competitive.

"We want to be within single-digit percentages of what you can do with the best desktop native code," said Brad Chen, engineering manager of the Google Native Client (NaCl) project in a talk at Google I/O.

Examples of what can be done include decoding video, encrypting data, video game physics engines, and face recognition. More interesting, perhaps, is when Native Client can work in conjunction with another Google browser plug-in, O3D, that lets browsers take advantage of hardware to accelerate 3D graphics.

Google demonstrated a browser-based image editor built with Google Native Client.

(Credit: Stephen Shankland/CNET)

"With O3D, we think we'll be able to enable high-quality games, the kind you're accustomed to seeing on consoles, as well as CAD applications," Chen said.

Although Google is working hard to enable more powerful Web applications, it's not all altruistic. The company has a growing stable of applications including Google Docs, Google Maps, and Gmail that can become much more competitive with desktop technology such as Microsoft Office. For now, though, Google is trying to hammer out Native Client security issues before promoting it more widely among programmers, much less mainstream users.

Sehr said Google's browser, Chrome, will introduce Web Worker support, he hoped within the next couple weeks. Google has been touting HTML 5 features at Google I/O, and Chrome gives Google a way to advance the state of Web application art.

Though other browsers are building in Web worker support, too, for now the technology is rough and certainly not a foundation a Web programmer could expect widespread support for among browsers.

Google plans to support Native Client both through Web Workers and the plug-in, Chen said in an interview. Built-in support in the browser is helpful, but Chen said Web Workers have undesirable limitations for many chores. For example, the plug-in is necessary for applications that require a fast response to user input, he said.

One such example Google showed at the conference was a photo editor. With it, images could be rotated, zoomed, and have colors and tones adjusted with a variety of sliders. There are online photo editors available today, but they typically use Adobe Systems' Flash plug-in.

This fractal graphics demo showed off a forthcoming Chrome ability to access Native Client applications through the HTML 5 Web Worker standard.

(Credit: Stephen Shankland/CNET)

[andrew.mager]

This makes me want to be better at Javascript.

[Ben_Tyrer]

This is particularly exciting from a video gamer's perspective. If you look at the popularity of an in-browser MMORPG such as Jagex's Runescape, the ability to let browsers take advantage of hardware to accelerate 3D graphics could bring about a wave of this type of medium.

Another example would be the recently launched Quake Live, which people queued up for some time to get into upon launch.

I'm very interested where developers will take this technology in the next few years!

[Police_States_of_America]

i guess this is the real reason microsoft is worried [ http://digitaldaily.allthingsd.com/20090508/microsoft-to-eu-you-might-want-to-take-a-look-at-google-when-your-through-with-us/ ] about chrome

[GKrynen]

Shades of days long ago when we had an application on our computer to run the web, this software was called Compuserve and AOL and many others. Data stored on their system then code executed and ran on the users systems, just to push the data back to the server.

[Hunnter2k3]

The Web Workers spec is very interesting, they have tried to emulate the same system with Gears to an extent, and it paid off quite well.
But like all small-scale plugins, ultimately useless... (even though it comes with Chrome natively)

Next 5-10 years of web dev will certainly be an interesting one, a lot of change is going to be happening. (even for Microsoft, actually, ESPECIALLY for Microsoft, unless they want to be a decade behind...)

And it should make my current job much easier since i am developing a web-based game that requires some decently fast JavaScript, but i will also be using background tasks so i can use the massive numbers of users (hopefully!) as processors. (real reason is so i don't need to learn Perl... )
HTML textures failed due to not being fast enough and stalled all current browsers / Chrome's tab.
Going to try Canvas now, but i doubt it will be any different...

Now where did i put that time machine...

[almo-8]

Adobe demonstrated running native code in Flash Player (Quake) in 2007. The difference: Compiling native C/C++ code into ActionScript (for Flash) can execute at the same speed as Google's native client while maintaining platform and browser independence. Google's solution is dependent on a particular family of CPUs. That's a big deal. Sorry Google.

[UsingUrBrainSinceUArent]

That's bull. Adobe's got a lot of the same issues.
Why do you think that Flash (video, in particular) on ARM is so far away?

I'll give you a hint -- "it ain't x85 + 1".

[MadLyb]

So many questions, so few answers.

How is this different than a CLR or JRE?
How do they preserve security, but deal with the limitations that normal browser sandboxing introduces?
How do they achieve standardized performance across OSes, and browsers?
Will the client code be completely available to companies like MS, Opera and the Mozilla foundation?

And the final question...if we have to install a plug-in, why not just make it a container directly in the OS and leave the freaking browser out of it?

[Shankland]

I recommend reading this story on Native Client: http://news.cnet.com/8301-17939_109-10227150-2.html

It should answer some of those questions, though no doubt not sufficiently. Reading the Google description (http://code.google.com/p/nativeclient/) and NaCl paper (it won an IEEE award - http://nativeclient.googlecode.com/svn/trunk/nacl/googleclient/native_client/documentation/nacl_paper.pdf) is also worthwhile.

The software is open-source, so anybody may incorporate or use it. (It's under the new BSD license (http://www.opensource.org/licenses/bsd-license.php) so I imagine even Microsoft could swallow it if it chose). NaCl uses the NPAPI plug-in technology (though Google wants to "revise" that standard to make various improvements, Chen said Thursday), so it should work with most browsers in plug-in form; implementation of the Web Worker version is another matter, of course. Google offers NaCl (though only in experimental form at present) for Chrome, Firefox, and Mozilla on Mac OS X, Windows, and Linux.

It's different from Java runtime environment and Microsoft's CLR in that it's not a full-fledged platform for running code, with a huge range of built-in libraries. Instead it's just a mechanism for developers to create code that can be downloaded over the Web and executed safely (Google argues). The security comes through creation of code through a specialized compiler (Google uses a modified GCC), sandboxing, and static analysis that disassembles the machine code to ensure various prohibited operations aren't taking place.

I didn't mention it in the story, but Google ran a security contest to pay people to find vulnerabilities. That yielded 22 problems, none of them showstoppers, Chen said Thursday.

[Shankland]

@almo-8: The demo was in 2008, and it uses an Adobe Labs technology called Alchemy that translates C or C++ into ActionScript bytecode for execution within Flash Player. That translation imposes a performance penalty, as Adobe acknowledged to me, but it offers security and portability benefits. Native Client has portability issues, too. At present it runs only 32-bit x86 code, but Google has plans for 64-bit and for ARM as well (think Android phones).

@UsingUrBrainSinceUArent Adobe does have processor limitations with Flash, but once it has Flash for a given platform, Alchemy should be able to work there. So they have different issues than Google.

[Qtechbg]

And this is news how exactly? Anyone remember M$ and IE's ActiveX?

[Shankland]

ActiveX and Native Client have very different security models. ActiveX' asks the user whether he or she trusts the publisher of the code. NaCl disassembles the code to make sure it doesn't do anything naughty. How well it works remains to be seen, of course, but it's very different from ActiveX (and Java, and Flash).

[forever4now]

I was wondering what happened to Native Client. It is good to see that it is moving forward. The combination of HTML5 and Native Client should allow for the development of some VERY powerful web apps.

Imagine an application like Photoshop. If Adobe needs to fix a bug, they simply modify the web app & millions of users are automatically updated...on Windows, OS X & Linux machines. Now THAT is efficiency!