Monday, December 08, 2008

Native Client: A Technology for Running Native Code on the Web

By Brad Chen, Native Client Team

Modern PCs can execute billions of instructions per second, but today's web applications can access only a small fraction of this computational power. If web developers could use all of this power, just imagine the rich, dynamic experiences they could create. At Google we're always trying to make the web a better platform. That's why we're working on Native Client, a technology that aims to give web developers access to the full power of the client's CPU while maintaining the browser neutrality, OS portability and safety that people expect from web applications. Today, we're sharing our technology with the research and security communities in the hopes that they will help us make this technology more useful and more secure.

At its core, our release consists of a runtime, a browser plugin, and a set of GCC-based compilation tools. Together, these components make it possible to build applications that run in a web browser but incorporate native code modules. To help protect users from malware and to maintain portability, we have defined strict rules for valid modules. At a high level, these rules specify 1) that all modules meet a set of structural criteria that make it possible to reliably disassemble them into instructions and 2) that modules may not contain certain instruction sequences. This framework aims to enable our runtime to detect and prevent potentially dangerous code from running and spreading. We realize that making this technology safe is a considerable challenge. That's why we are open sourcing it at an early stage: we believe that peer review, community feedback, and public scrutiny greatly improve the quality of security technologies like this one.

While it's a big challenge to secure Native Client, we believe that the ability to safely run fast native code in a browser has the potential to provide benefits to users and developers. For example, imagine that you run a photo-sharing website and want to let your users touch up their photos without leaving your site. Today, you could provide this feature using a combination of JavaScript and server side processing. This approach, however, would cause huge amounts of image data to be transferred between browser and the server, leading to an experience that would probably be painfully slow for users who just want to make a few simple changes. With the ability to seamlessly run native code on the user's machine, you could instead perform the actual image processing on the desktop CPU, resulting in a much more responsive application by minimizing data transfer and latency.

To learn more and help test Native Client, please visit our developer site. There you can read our documentation and the Native Client research paper, browse the source code, and download the research release. The release contains the experimental compilation tools and runtime so that you can write and run portable code modules that will work in Firefox, Safari, Opera, and Google Chrome on any modern Windows, Mac, or Linux system that has an x86 processor. We're working on supporting other CPU architectures (such as ARM and PPC) to make this technology work on the many types of devices that connect to the web today.

Once you've gotten your bearings, please report any bugs you find (especially security bugs) using our issue tracker, and join our Google Group to share your thoughts on the technology. We look forward to your feedback!


  1. This is interesting, but it seems like an awful lot of work to short-circuit the JIT—and the history of “anything that isn't ECMAScript-based” in the client is pretty spotty, to say the least and downright disastrous (hey, ActiveX) at worst.

    Don’t get me wrong, if this can be made to work and is adopted (and who's in a better position to drive that adoption but Google?) it'll be very very cool, but I can't help but have a sense of trepidation about it—ultimately, the server has to be untrusted, and JIT from a very sandboxed interpretable language seems to be a good trade-off, especially as the engines are beginning to come of age here. All power to you guys for embarking on this project, though.

  2. This isn't just for server-delivered content, but could be used to sandbox plugins like Flash too (that will likely be the primary use in fact).

    I think it has great potential, and it sounds like an outgrowth of the work on proof carrying code. I'll definitely have to check out the developer docs.

  3. I just hope that we users and developers won't end up with 100 different ways to achieve very very similar results while these results all are a bit differently buggy.

  4. I just want to say that the other shoe just dropped.

    Google Chrome + Native Client + Gears == the future of application deployment and runtime.

    Chrome's independent processes. Gears' offline and local resource access. Native Client for heavy lifting.

  5. Seems like they're trying to reinvent Java, to be perfectly honest, just with a more network oriented bent...


  6. The first thing I thought was - "Umm, how is this different from Java or .NET?"

    Java and .NET code are validated and then compiled to native code on the fly, and thus runs just as fast as any native code would.

    The only reason Java applications have a reputation for being slow is that the Java libraries, especially Java user interface libraries, are bloated and over-engineered.

    Still, why create a new runtime and a new library when you could just create a more streamlined version of an existing library, or push some high-performance libraries (like SWT) into the browser so they are available to applets.

    The only reason you'd really want "native" code is to access native DLLs that are not available for a particular system, but then you're just back in ActiveX land.

  7. I think the important thing here is this is the first time that this has been done un-proprietorially (i.e: technology not belonging to any one company).
    Active X was Microsoft's and Microsoft's only,
    Flash was Macromedia, now Adobe,
    Java was Sun's....

    Java (in terms of applets) isn't something you'll come across very much at all. It's only use seems to be for writing graphically low-emphasis games and gimmicks. A speed tester is the most useful thing to have come out of applets.

    ActiveX was a disaster. Only Microsoft, and devs hated it.

    Flash is still going strong, but Javascript is being favoured increasingly.

  8. Yeah, because there's no way this reinvention of ActiveX could be yet another single-vendor security nightmare in the making.

    No, sir.

  9. No, thanks.

    Browsers are getting better and better at executing JavaScript.

    There's Vorbis decoder in ActionScript that uses 3% of Core Duo CPU.

    There are numerous demos for HTML canvas element, that do exactly what you suggest, 20 times per second.

    We don't need it. We certainly won't need it few iterations of Moore law down the road.

    We've had ActiveX. We have plenty of binary blobs to deal with already.

  10. Um, isn't this called desktop software?

  11. “For example, imagine that you run a photo-sharing website and want to let your users touch up their photos without leaving your site. Today, you could provide this feature using a combination of JavaScript and server side processing.”

    ... Or you could use Flex and execute the code in the Flash Player and call it

  12. @Dobes: Neither Java or .NET is actually compiled to native code. They both run in a VM-of-sorts that translates the compiled program's IL code into something the computer can understand.

    Even if you make native images on .NET still does not run as native code.

  13. To all those comparing this to .NET or Java, there is a major difference between the two, favoring the .NET. In .NET, once the JITTER compiled the MSIL to native code, the native code is kept for the next execution, so even that is done only once.

  14. Think about all apps you can run embedded in your web-site from anywere... skype, vlc, oo, im-clients etc... it's just to log into your page and release them... this is great news!

  15. @Dobes: just because you have a JIT, it does not mean you "execute code at native speeds". Go benchmark.

  16. Interesting. But what problem does this solve exactly? Not sure if I want to run the likes of Quake in the browser.

    If all you have is a hammer, every problem looks like a nail.


  17. JITted code can sometimes run faster than the native code since compiler can take advance of detected processor architecture (special instructions etc.)

  18. Hmm. If only there were some technology that would allow you to create a "virtual machine" that would let you safely sandbox running applications and what if that "virtual machine" ran a standards based framework that enabled executables to work without any danger at all of compatibility issues.

    Oh wait, that sounds a bit like Java doesn't it.

    Still, creating a lightweight VM that ran maybe I dunno -- android? is interesting.

  19. 1) Doesn't Chrome already have something like this? It runs embedded Flash, Java or other content using native code plugins (designed for Firefox, but they work).

    2) Yes, Javascript is improving fast, and ECMAScript 4.0 with classes and types is promising, but some things need native: The Flash player is a native module, and so are Adobe Reader plugin, several video players, 3D players (VRML and the like), etc. You can't call OpenGL from JS.

    3) I see two benefits of native embeddable code: using native code (x86 instructions directly), i.e. faster; and using OS APIs that help in communications, multimedia, etc. For example, it is AFAIK the only way to use OpenGL or DirecX to use 3D hardware acceleration. (I recently looked at the Canvas3D FF extension: promising but maybe not enough and not very portable so far)

    4) Nevertheless I prefer non-native code solutions if possible. If it can be done with Javascript and the DOM and maybe SVG do it.

  20. It would be very cumbersome to supports multiple arch clients. (Why x86 monopoly?) Silverlight seems to have a much better approach and integrates nicely with jscript.

  21. I like it! A "save" ActiveX.

    If it is really save and secure this would finally remove the pseudo requirement "Javascript is the only programming language for the web".

    Finally we will not need 64 Core CPUs to run a video decoder written in Javascript.

    Real software - not just static web pages & AJAX - WITHOUT installation.

    PLEASE make it happen!!!

    Actually, instead of Native Code I would prefer an IR-Code which is statically compiled on the target platform - may be with LLVM - to be platform independent.

    Oh and the most important thing: Please be as silent as possible- like Flash.
    Do not do it like Java: An animated Java Logo here an "update me" popup there... Sun and Java deserve to die just because of the incredible slow startup time and the permanent promotion of Java. Luckily Java is already dead on the browser. Avoid the mistakes sun/java have made.

  22. Boraski - Actually, you can call call OpenGL via JavaScript, via the CANVAS tag.

    One wonders why Google don't just buy Sun - they'd get Java (which Google are massively dependent on in their backend), the new JavaFX (Flash/Silverlight competitor) which could replace Native Code and has a massive install base, which Native Code just isn't going to achieve overnight and there is a vast amount of Java libraries out there.

    Things like Niagara are quite possibly interesting to a company like Google too.

    Not to mention that Sun is massively undervalued - their market cap is similar to their cash balance, in other words, Sun is basically 'free'.

  23. As other already said: please, don't reinvent the wheel. This is Java / .NET. Just take one of these runtimes (ie Mono or the open source JVM) - no you don't have to take all the libraries - and put a wrapper around it which makes you happy.

  24. So How is this different from a smart client except the smart client is being hosted in a browser ?

  25. What most people tend to forget is that JavaScript code almost always end up calling native code to perform most of its functionality.

    JavaScript code tends to grow large, slow and unmaintainable simply because core functionality is not available and must then be emulated in script. With the addition of things like the HTML Canvas element, web developers can now offload much of the work to native code.

    We certainly don't need another ActiveX standard or a wanna-be Java, .NET, Flash format. We need more powerful client side components that are:

    1. Safe for use on the web.
    2. That can be scripted with plain old JavaScript.
    3. That are available on all the common platforms.

    I personally think the X-Appl concept is on the right track, except that it currently only works in Windows.

  26. Native code? Any different from Silverlight? Can easy to use? I thinks the answer is NO.

  27. why Google insist in tell us how cool is Desktop Development? we already know that ... and everytime you guys do something like this you are saying 'we don't like web anymore... we want our own Windows to run.. Gmail?'
    Gears was cool, but this? This is a HUGE SECURITY HOLE.

  28. I agree that we would all benefit enormously from a merge between web apps and desktop apps, disregarding questions of security for a moment. If browsing the internet could somehow be integrated with the full feature set of "native" code (even though, yes, in the end it is all native) then I would be ecstatic.

    As a developer I find that AJAX programming is very poorly suited for the kind of apps people use on their desktops compared to actual desktop programming languages (C, Java).

    The fact that Google Docs even approaches the feature set of a desktop word processor says lots of good things to me about Google's programmers, but it says little to me about AJAX / Web 2.0.

  29. The difference is: it's open source. The difference is: it's open source. The difference is: it's open source. The difference is: it's open source.

    Diediedie, .NET and Java.

  30. Er. Isn't this a step backwards?

    If you have native code, you have to write it (or at least compile it) for multiple architectures.

    That means testing it on all of those architectures too.

    How about a common runtime that has the performance of native applications but means the code only has to be written once and should run the same on any native architecture? A kind of Write-Once-Run-Anywhere type thing.

    It could even be open-sourced, so that anyone could participate.

    Actually, that sound sort of familiar...

  31. Those of you who keep saying "JIT JIT JIT!" please note that the best JIT still often leaves you with just a fraction of your machine's potential (native) speed. For most apps, this is just fine. But there are some apps where you want every iota of speed you can get. This is what Native Client is for.

    I develop on a JIT virtual machine for a living. (VisualWorks Smalltalk) I think it's fantastic. But I still know that there are a few things out there where you should dip into native code.

  32. javascript and java are 2 totally different languages...
    please, if you don't know the differences betwwen javascript and java, don't use these terms until you read about it.

    thank you good people...


  33. by the way, johnnyB, java is OPEN SOURCE, multi platform, JVMs are already running on computers with Windows, Linux, MacOs, Solaris, etc., on mobile phones and even Nasa Mars robots are currently running with Java.

    thank you to share your opened mind.

  34. Dumbest thing I've ever heard. The JVM is a much better option since it already runs on every operating system, it runs native code, and it allows developers to write the code in any number of languages (including, of course, Java).

    Thanks Google for providing now value whatsoever. If you want to be helpful, then help make the JVM better (like better support for dynamic languages).

    Microsoft's CLR/DLR is another option but it's proprietary. Although, even that would be better that what Google is proposing.

  35. This is simply silly.

    There is no compelling reason for using native code in web applications when there is several capable and efficient virtual machine solutions already available.

    Java already has everything you need, and the JVM is really efficient nowadays. And Java is now open source (GPL).

    The main problem with Java is the bloated "core" library and the large runtime size. But this can easily be fixed by defining a suitable subset for web applications.

    And you can use a lot of other programming languages than Java with the JVM.

    And yes, native code is in theory more efficient, but 99 % of the performance problems with todays web applications come from too much communication with the server and/or poor performance of Javascript. Using Java would solve all that.

  36. This will be the Google Operating System.

  37. I've been working on exactly the same project (based on vx32) for the past couple months. Anyone who says this is simply working around JIT is ignoring the fact that almost every computer in popular use today runs at least 32-bit x86 instructions at the native level. Anyway, you beat me to an implementation. It's time to innovate...

  38. I think that Moonlight (open-source cross-platform version of Silverlight, based on Mono) is a better solution as it matches openness with code verifiability and JITting. It can even benefit from SSE optimizations that are in the works. Said that, it still need to evolve to the Silverlight 2.0 profile to leverage all the .NET languages, instead of being dependent on the javascript engine (although it possibly would benefit a lot from Chrome's JS implementation, in the current implementation)

  39. This is fabulous!

    Even if there is Java, Flash and Silverlight this is a great addition to the developer toolbox.

    Let us embrace this new development and figure out if it can be made to work as smoothly as the creators envisioned it and bring a whole new class of applications to the web.



    Java, JavaScript, Flash, Silverlight, Google Native Client, they can all FOAD FOAD FOAD FOAD FOAD!!!!!!

    Content is important, not your fucking stupid apps.


    The web needs fixing, and this is going the wrong way.

  41. So, let me get this straight : You will have a client side set of libraries that will run code that is compiled for it..... Don't we already HAVE Java Applets? Isn't Google sort of going to a lot of trouble to reproduce the exact same thing?

  42. @Dobes I know what JIT is. I'd think I would kinda have to know being a .NET developer and all.

    I suggest you go read this article on .NET, especially the 3rd paragraph which talks about the VM that .NET code runs in.

    I think Google's Native Client is a good idea. I could think of a number uses for it.

  43. Why not just use JPC? They can already run x86 code in any Java environment, including applets. Check out the demos at:

  44. It's a common misconception that you can have Java or CLI (.NET) code that run the same speed as C.

    The truth is, JIT overhead isn't the whole story. There's also garbage collection, overhead associated with the language's object model, etc. These are not negligible, in my experience (or perhaps they are, but added up they make a difference).

    And that doesn't even take into account the memory bloat such languages always seem to have, which can cause problems of its own.

    The nice thing about native C or C++ (or ASM) code, is you can tweak it to be really fast (especially since your doing memory management yourself, usually, and don't have to rely on a garbage collector).

    Of course if you don't need that level of speed, there's no reason not to use Java or one of the CLI languages or whatever (I like python myself :) ).

  45. Most people & companies use web apps when the portability or collaborative aspects of an app trump the limitations of "real" software. C'mon, there's a reason we're still buying bigger & faster computers, and it's not just to make browsers and games run faster.

    This technology isn't so much about writing web apps as it is about writing apps period.

    Photoshop online, anyone? In native mode my ordinary PC can compute anything at least as fast as any server out there, and without transmission delays or making me wait for the dozens of requests ahead of me to complete. Everybody wants everything NOW, and cheaply. My PC works for free, and without any 3rd party subsidizing it either.

    Flame me if you like, but "web apps" are still generally unappealing for a number of reasons, not the least of which are responsiveness, performance and poor choice of software. Yes, web apps have their strong points, but the weak points are truly annoying. Let's get out of web-cheerleading mode for a moment and put thing plainly: web apps, with some exceptions, tend to be somewhat toy-like compared to their native counterparts, and/or they're pokey.

    Does responsiveness really matter, or are users just being fussy? Marketers would tell you that perception is reality, but some HP research from the 80's is illuminating: delays as short as 100 msec can have a significant effect on user satisfaction and productivity.

    Bill Gates has had a recurring nightmare since about 1995. In it, Windows becomes irrelevant as it gets eclipsed by platform-agnostic apps delivered through the browser. Microsoft have been fighting hard to make sure that nightmare remains just a dream, and in the end that's because the marketplace has tried web apps and voted with its feet.

    Java had its shot but it didn't catch on for a number of reasons, and that's a done deal. That train left the station long ago and it's too late to go back in time and pine away about slimmed-down runtimes or whatever.

    It's been 10+ years that the industry's been "serious" about web apps, and what do we have to show? Desktop apps remain paramount by a huge margin and Windows/Mac have 95+% of the market. The only really popular web apps are only popular because they require the web's unique strengths. The current paragigm's not working, folks. I'm not saying this particular technology is the one, but it's a welcome step in a sorely needed direction.

  46. I think the idea of having native x86 code running in the browser is a bit short-sighted. Yes, x86 is very popular, but must mobile devices use an ARM CPU and those won't be able to use Google Native Client. As mobile internat devices grow more popular this will be a real problem. Adobe has realised, that they need to port Flash 10 for ARM-Architecture. The Google Native client should use something like LLVM, this would make the "native code" modules portable and enhance security.

  47. So now Google wants to make its own competitor for Java Applets/JavaFX and .NET/Silverlight? Sorry, but you have to offer a bit more than just "executing native code through the browser". So far, what you offer is a bit thin.

    Besides, if the servers actually start sending native code to the clients, how will that support architectures that you didn't think of today? Think about that "Little Linux Laptop" which runs on MIPS... I bet you'd find a way to execute today's Java or .NET bytecode on that device, by porting the bytecode interpreter or the JIT. Apparently for this Native Client, the app itself has to be ported and updated? Sounds a bit strange...

  48. As many others have stated correctly, this has been done already by companies who are better at it than Google.

    Why don't you focus on making GMail less laggy and improving search results before you reinvent the wheel.

    PS. Most of you seriously need to read up on jittered code and garbage collection.

  49. The thing most commenters don't get is that Native code is far superior to any VM or JIT Compiler, for example plugins like Flash, Java and Silverlight are made in native code.

    This project is something that is more or less inevitable Google just decided to be the one's to jump to this now and do it open like the internet.

  50. Wow this is awesome!

    I wanted to port DOSBOX into an activeX client to run in a browser.

    Why you may ask? It's simple, MS-DOS supports an insane ammount of languages and with DPMI it's half way usable.

    The only real stubmling block has been any and all real documentation on writing browserplugins. I had given up on OSX/Linux as again it's impossible to find any real documentation on how to write plugins.

    Now it seems I could use this, then use an interrupt scheme to call the api via dosbox and be able to program in say Qbasic, Turbo Pascal, Fortran... whatever!

    Either way this is a 'good thing'!

  51. Simple: Cloud Computing's next step, use your power + their data. It has potential to be very useful, but could also lead to terrible security holes.

  52. Yes, this shouldn't be compared with running code in a VM (JIT or not). This is the kind of thing which'll enable those virtual machines and/or compilers /themselves/ to run in. Not to mention (user-space) operating systems, VMs for entire cpu architectures (e.g. vmware), etc. Think a little bigger here people :)

  53. I'd rather see an ARM instruction set or such available; however, with good toolchain design going forward, there's no reason developers couldn't target both and get their apps on PCs and mobile devices alike with a minimum of effort.

  54. To all of you shooting down ActiveX , if you use IE, then your still using it.

    How else do you think Flash works on Windows?

  55. I think this is great. Java and .NET achieve native speed on some kinds of code but not others, and they require you to rewrite everything.

    Native Client allows developers to use the languages and libraries they already have so much invested in. Instead of rewriting, say, Ogg from scratch in Java, you can just run the C library in the browser.

    This will also be very important for scientific, educational, and engineering applications, because it allows high performance numerical code to be run right in the browser.

  56. I think it's a really good idea.

    Java is huge and not really used anymore on the web. I don't even remember the last time I loaded an applet. And anyway it can connect to databases but not really play video or thing like that. The greatest thing I have seen in Java was the the Quake2 port. And that's about it. Of course the game had to be rewritten in Java.

    And Flash can't do anything except playing video and banner ads. There is a few basic games but that's set.

    For .NET, I still don't anything yet in my everyday life on the web so I won't say much.

    ActiveX is just a container those days for plugins. Not doing much.

    Javascript is still too slow to decode and play video or anything else. There is some great apps written with it but usually it is with some API on top of it. And still beside GMail it is still just a web page scripting engine not an application development engine.

    For now "Native Client" it's nothing, just a framework to use native code inside the browser. In itself it can be great. I am really impressed by Quake demo more than Jake2 (the Quake2 port to Java). One it loads in less than a second when Jake2 needed almost 10. You need to compile the source code to test it, but it's the original code, not a port to another language entirely.

    It's a framework with a potential to make crazy thing inside a browser. The problem with Java/Flash is that they come with all their luggages. Their own language, their libraries and you are limited to that. "Native Client" has no libraries instead it use the native version available inside your system. Nothing has to be ported to it : it directly use what is available. Open source project like ffmpeg for video decoding or encoding, VLC for playback, gimp image editing, Open Office, etc... Want to access database : yes it can if it has the libraries. Playing hi-def video, yep.

    The direct problem is security, it's not done and it will be difficult but running the applications inside a sandbox is the first thing to do and it does it. It's more than ActiveX can offer right out the box. Let see what they come up with.

    What it really lacks right now it an application deployment system to install correctly the applications where they belong on the disk where it has no writing privilege but can be easily upgraded. We will see...

  57. Am I the only one who thinks that - "Google is running out of space.. now they want to use our disk space to store everything locally..They start this new trend and shift their products (gmail,etc)to client side.. They think Pied-piper was real and we'll follow this trend!" ?

    How will this even become a Web application? Its like "download a software and run it on your system, which can access the web".. Hmm, now where have I seen this before?

    Guess you guys are bored of fighting it out with MS and now your target is Adobe!!

  58. I think the point of this isn't to replace flash, or javascript apps. I think it's for those (relatively uncommon) situations where you need a lot of processing power; e.g. a web-based image processor, or a web-based 3d modeler, or something.

    This sounds like a more secure, standardized version of browser plugins then something meant for running, oh, a streaming video site, to me.

  59. Nacl = Salt eh?
    Seems nice on the outside. Let's see if this can attain critical mass.

  60. There seems to be a fairly large number of people who are saying that this is just reinventing the java applet. Here are a few things that this has over java:

    Choice of language: you can use any language, whereas java is limited to a select few. People will look at their c++ program and say: "this needs the web to run anyway, so why not make it a web app?". Native Client makes it much easier to port current apps to the web than java ever will.

    Speed: no matter how much JIT goodness you cram into an implementation, it's still not gonna be as fast as native code. Native Client opens up gateways for things like bittorrent clients, games, 3d (and not just vrml), etc, etc.
    Download size: I can bet that a technology that sandboxes x86 code will have a much smaller download size than the whole JRE. This should make adoption easy, as such a technology could easily be included in the browser.

    Perhaps this is not a very good opinion, but I think that people are gonna like this more than they liked java simply because of the reputation that java has of being slow and ugly.

  61. The motive could be to deploy client-side web applications without code. This would give more control without creating network traffic. But...

  62. Adobe announced a research project during Adobe MAX 2008 - Called Alchemy -

    This project aims to pretty much do the same thing, but inside the flash plugin which already has been installed in so many machines already.

    Alchemy is based on LLVM -

    Demos of things that are possible have already started cropping up. Here is Doom 1 game running inside flash player

    PS: How about Google working with adobe and doing a combined effort, and making life easier for end users/developers, than creating a custom plugin of its own ?

  63. I completely agree with JohnD. I think this is the right way to go, but we should be very careful about the potential security risks. I personally believe a light weight VM that sandboxes the web app would be one of the better solutions that provides high levels of security guarantees. Will such an architecture be the same as Java or .Net? No, it won't. There are essential difference between these VMs. This architecture will not use any intermediate language and there won't be any interpretation or JIT compilation, although binary translation for certain classes of instructions might be necessary.
    Such an architecture will guarantee that whatever happens in a web app will remain in the web app, and everything outside of the web app will remain intact.

  64. @robert101, Chris, and StCredZero:

    You may not have noticed, but the JVM technology has come a long way. Java can be as fast as C/C++. And even is it is, say, 20% slower, that makes no difference for most apps, not to mention that an average developer may be simply unable to gain those last 20% in C++ within a reasonable time.

    Ah, and you can compile Java to native code statically if you want to squeeze a bit more speed from the hardware.

  65. Wouldn't it be much better to team up with Adobe and promote Flash, Flex and AIR? This RIA story starts to feel like the browser war 10 years ago...

  66. One reason of still developing Native application is to overcome the limitation of HTTP protocol, will Native client support network protocol other than HTTP?

  67. So many people are completely missing the point here. This will be useful because a significant proportion of the world's codebase is written in "native" languages. If you have 5 million lines of C code, then "why don't you use Java" is not a helpful suggestion.

    Example: a games company decides that it wants to move away from heavyweight installable downloads to provide demonstration version for its games and instead have demos that the user can run ad-hoc in a browser. Recreating the entire game code in Java is not an option, but porting it to Native Client might be.

  68. Naive Client :)

    "Naive Client: A Technology for Running Naive Code on the Web"

  69. Whatever happened to write once run everywhere ?

    Try compiling Java bytecode to native instead.

  70. This thing is awfully similar to Adobe Alchemy. "Alchemy is a research project that allows users to compile C and C++ code that is targeted to run on the open source ActionScript Virtual Machine (AVM2)." If I recall they also have Quake running in flash player 10.

  71. Sanat, don't disagree but I couldn't resist putting in the phrase:

    if all you have is the quote "If all you have is a hammer, every problem looks like a nail." then every tool starts looking like a hammer :)

  72. First and foremost, it's a research project. As such, I applaud Google for exploring ALL options to improve the web. That aspect is worthwhile.

    However, I agree that this might not be the best path forward. I think we're getting closer to finally killing off Active X. There will always be a place for domain specific technology, but we've fought too hard for too many years to once again get locked down to limited platforms and architectures.

    In my opinion, the biggest problem with Active X was that it provided a shortcut for development teams. It provided a short term benefit for them in that they were able to ship some things sooner. However, in the long term these things tend to languish if users get frustrated with not being able to access these efforts as the web evolved around them.

    If this technology is used to augment the Open Web, excellent. I'm for it. If it's used to gain a better understanding of how to sandbox plugins for something like Chrome, awesome. Just remember the Spiderman axiom: "With great power there must also come great responsibility." (Sorry, I realize that's corny.)

  73. From main page of project (capitalization mine): "Native Client is an open-source research technology for RUNNING X86 NATIVE CODE in web applications, with the goal of maintaining the browser neutrality, OS portability, and safety that people expect from web apps."

    How exactly does one adhere to open web standards when one dictates the CPU used by the client? This project, by its own definition, violates the very idea of an open web standard as it rules out anyone using SPARC-based, PowerPC-based, or any other NON-x86 platform.

    Some might argue this is not important as 90+% of client computers are x86-based, but how exactly is that any different from Microsoft's argument that a similar percentage of client computers run Windows.

    I applaud the attempt to get better performance from Web apps. Not so much the implementation.

  74. This looks like a step to Web 3.0 :D
    Good job

  75. Lots of people are way off the mark here... This targets a very specific niche.

    Essentially, Google just removed yet another layer from the proprietary OS onion.

    Ecmascript is still going to be the core language for web apps, don't fret.

    Just think about the raw grunt available to the client side of web apps now...

    Need a new codec: download your native 'nexe' to the browsers app/module cache locally. Need to fiddle with pixels, what about a DB. Need your hip Web X.0 browser plug-in to do something out of the ordinary... Bam...

    I wonder though, how this will meld in with gears and the chromium extension/plugin framework. My bet is they will all be one and the same eventually.

    This one is an all important piece of the google symphony - So now, they must be pretty close to a fully featured 'online office' with their internal Chrome builds now :) nudge - nudge.

    Sit back and enjoy the next couple of years, this is an epic clash of the titans...

  76. Re: JIT vs. native. Unless you've used JDK6 you probably don't know what you're talking about in that respect; I've used Java since 1.0, and modern JVMs are very very fast). Oh, and Java has been open source for a while now.

    Native code might (*might*) be faster than JiTted Java in some cases

    But *portable* native code? That is Hard.
    That means an interpretation layer, if you want portability, which means reinventing the JVM wheel.

    If it's not portable, you might as well stick with ActiveX, and stop pretending to be a RIA.

  77. To all those complaining about SPARC or PowerPC or ARM support, you don't get it.

    This technology is meant to be able to create photo manipulation or video editing software inside a web browser.

    How often do you use a PowerPC or SPARC station do edit pictures of your kid and family??? When are you using a ARM telephone to play games in a web browser? Never and that's my point. We all run x86 to do personnal stuff either Linux, Mac OS X or Windows. And that's enough.

    Who even is not using x86 to write in this blog comments????

  78. Talking about x86 , r u gona compile to windows or linux ?

    I agree that the attempt is to get high performance but what we need is a platform independent native mode COMPILER

  79. "I've used Java since 1.0, and modern JVMs are very very fast"

    JVMs are very very fast for common kinds of code, but they fall flat on their face in some areas related to numerics, memory management, arrays, and high performance computing. That's not good enough because, even though most code will run fast, there's a high risk that any large software project will hit one of the areas that Java can't handle.

    Any platform that wants to compete with native code needs to be fast for everything, it can't cut any corners anywhere.

  80. "...will work in Firefox, Safari, Opera, and Google Chrome..."

    Isn't something missing in this list? Hmmm.....

    (Misspelling intended)

  81. I know I am probably pretty far down the list of comments by now but I think this is one of the best ideas for both the web and standalone applications that was ever conceived. You could run the same program on Windows, Linux and Mac OS without changes, and have true native performance. In other words you could make a high end video game with it, and not just a flashy pong game.

    1. Most bytecode targets a virtual architecture that doesn't exist, so the code will just as poorly on all platforms.

    2. Most VM's like Java and .NET have huge frameworks that are included with them. Typically large parts of these frameworks are written in native code. This makes each and ever framework a potential security hole. It also makes implementing either of those platforms from scratch impossible unless you had hundreds of developers working on it for years.

    3. Most people say JIT's are as fast as native code or faster. While there are special cases where a JIT can be fast or faster, in real life none of the popular platforms are faster than native code performance wise. And this isn't just due to the code translation process. The memory manager and object system add overhead. The marshaling of data between native and VM code has a lot of overhead too. You don't see games like Crysis being written in Java or .NET because the performance is still not good enough.

    4. There are billions and billions of lines of c and c++ code. Almost every desktop application out there has a mature native code source base. This would allow these companies to port their applications to the web and support more platforms without a huge shift in the way they do things.

    5. Running the code on non x86 platforms is pretty easy. There are plenty of high performance x86 emulators out there that support many platforms. It's also something that you could most like JIT and get native execution speed if developers care about speed on non x86 platforms.

    6. And let me state again, something like the Google Native Client is *MORE* secure than Java, .NET or JavaScript by design. It has less places where code can break through. If one API or command has a flaw in the entire Java or .NET framework, people will be able to hack your application. The Google Native Client exposes way fewer API's and those API's are more well defined. And if the runtime will not allow instructions that do nasty things there is no way to jump out of the runtime.

  82. Java is not dead and already allows to launch 3D games in the browser (Jake2 for example).

  83. Java can run 15% faster than native code, a real example is Jake2 :D

  84. Don't get me wrong, the possibilities are endless should this become a secure reality and I am excited to see the progression, but my real stumbling point is why?

    Just because you CAN run native code from a browser, doesn't mean you should. Every time something promising like this comes along it starts off being the new thing then slowly as the faults are discovered it is packaged and stripped down to gain the necessary security until it is no longer the great invention everyone had hoped it would be.

    The rules outlined seem like the perfect setup and as far as functionality and performance #1 is a must, but I have issues with #2: "that modules may not contain certain instruction sequences.". How does Google plan to achieve this? Manually blocking every potentially malicious line of code, because I have to think that the db to handle that would be massively large. Assuming that was even possible, there is a new age of encrypted viruses just over the horizon, what keeps those from being embedded and what protects the server from a compromised machine?

    the x86 code is full of holes and I question the use in the end, but that doesn't mean it shouldn't be explored. Overall AJAX(ActiveX) was a disappointment to its hype, but it has changed the browsing experience and I look forward to seeing this play out.

    best of luck.

  85. "At Google we're always trying to make the web a better platform."

    Why are you trying to put lipstick on a pig?

    I would love to see what you could do it you scrapped the web as a platform and created a new internet application platform from scratch.

    See my attempt at:

  86. IE already incorporates Native Client support with the release of this latest XML buffer overflow feature.

  87. I insist: How is this different from NPAPI plugins which they already support, and which has permitted native code to run in browsers for years, since Netscape through Firefox, Opera and Chrome?

    And, well, from ActiveX on the IE side.

    The Flash player, the shockwave player, The Java plugin, Adobe's PDF reader, realvideo player, WMP, SVG-player for IE, MathML renderer for IE, cortona VRML client, Google Lively, BS contact VRML browser, Google Earth's API, etc. are all native code running in your browser, and so have been for years.

    What is new here? I must be missing something!

  88. The Percent a multi-purpose, highly customizable instrumentation component which provides a versatile percentage interface used to indicate a level or progress. It can be customized to be progress bar, karaok text, pie, grid bar and so on and can be applied in many fields. The user can define the shapes of bar, ellipse, tank, funnel, thermometer, etc.

  89. We have native C/C++ code and have written a Netscape API Plugin for our Web features. We use an ActiveX wrapper to support IE, since MS disabled support for NS Plugins to force them out of business. Anyway, it works great and we do things now one else can do. It has one problem, people need to install the plugin and they can not do it easily. OS companies have scared users, make it hard for users and are constantly changing things that cause problems for users. SO WE GET BLAMED and no one wants to install it. There is nothing wrong with native code if done by a reputable company, but no one trusts anyone but the biggest of name companies and that is just the way they want it. The only reason Flash is successful is because it comes pre-installed in the browser install or OS. Give me an easy way to install my plugin and we have no need for any further tools.

  90. Let me say it this way: I had a lot to do with ActiveX (and still have) and the real use of this technology is the ability to access some OS features directly printers, scanners, DirectX, various UI API features in my case. It is limited to Windows, of course, but when you need to combine the neutral WEB and the specific OS you are content with the limitations and you accept the limits - those are usually intranet apps or applications for use by well-known set of users. It is trade-off features for portability.

    What can be achieved with a multi platform native code technology except some performance benefit? What you are interested in when you look for a native code solution is still platform specific, having yet another "browser independent" platform wont help much and if you consider seriously the effort you would still probably choose something like Java in its place in order to avoid solving a number of unexpected issues for the different base platforms. I have background in Windows CE development and while I must say it is well done even without OS version/variant problems supporting a bunch of different CPU-s and OS versions is a nightmare no matter how much automation you use in your work. The scenario is much similar to this case - you have the same API, but you need to compile for over 10 different CPU-s and 3-4 different OS versions and then put all the binaries in order. A tiny OS issue somewhere makes the already heavy task much heavier ... So, I very much doubt this is the way to go.

    I would say the missing link is somewhere between the managed environments (like Java/.NET) and the scripting (like Javascript), but it seems almost everybody seeks solutions elsewhere and the things become more complicated every day with very little actual gain for us and for the end-users alike. Do not forget the human factor - Java/.NET caused many developers to build innumerable frameworks for everything, good, bad, worse ones. The market causes us to waste time in learning many of them just to get the next job and we end up entangled in these with not spare time to think for something better. If you ask me a native client will simply add one more direction for pointless framework development and tie our hands even more ...

  91. I don't think OS-specific issues would be a problem. A cross-platform library of some sort would probably solve a bunch of such issues. The point of this, as far as I can tell, is to be used in certain speed and memory-critical situations, such as image editing, not to access OS-specific features as in ActiveX.

    The truth is, Java and other such languages aren't always the best. I don't think it's necessarily a matter of raw execution speed, so much as the overhead associated with the object model and the managed memory system.

    Despite what people say, you cannot have a GC algorithm that's as good as managing memory yourself in all cases. There are situations where you can't manage memory yourself effectively, but there are also plenty of situations where you can, and where it does make a difference.

  92. Just port Firefox to Java, compile it using native javac, and then create Applet 3.0 such that they run in THAT browser in native mode run this applet natively. So here just like HTML and Javascript, THAT Jbrowser will execute Applets.

    Since the browser is in java, it can be ported everywhere.

  93. Hello Google native code, can you please help in addressing this problem ?

    Audio/video content sites to take full advantage of PC or smartphone memory and resources. Right now, my internet connection is DSL but low-speed (150kbps in Kuwait), so playing fully streaming songs/videos from internet, causes gaps in loading content. Since the music/video that I am playing from your site is the same, can you enhance your technology so as to be able to store any song after it is played once in my PC/smartphone, so it can be re-used later again, and this will also put less strain on your application servers. Something of the order of Google gears/native code might be needed here.

    Best wishes, Avinash.
    Published at

  94. I am just curious, Is this a software for desktop?

    kimberly ventura

  95. Great Thing !
    I am so happy, Google has released it and - what more - as OpenSource ! :D

    I think NativeClient might be a good idea not only as substitute for Flash or JavaApplets, but act in other cases... example:

    * "NativeClient WebStart" as alternative for Java Web Start ;)

    It would be interesting to let people to run app with one click, run demo of application natively to test, whether we like to install it. Or just.. make some programs running in such way.

  96. Nice..OS portability will be tricky....i will try to contribute as much as possible!!

  97. I'm very late on this but JohnD above refers to a lack of feature rich online applications like Photoshop - check out

  98. Mo, you're missing a much larger picture. The real power of Native Client is being able to harness SSE/SSE2/SSE4 instructions in the browser. Being able to harness SSEx inside a browser opens up enormous possibilities with respect to being able to create amazing real-time 3D experiences within the browser. MS is already working on this with WARP10 and their compute shader. These are two ways HLSL is jitted into native CPU SSEx instructions. Eventually this CPU jitted HLSL will be available in Silverlight.

    GCC already has the ability to vectorize regular C++ code into SSEx instructions. Combine this with Native Client, and a multicore Nehalem CPU and we're talking about the Web going 3D. A new paradigm shift is very near. Native Client is an excellent way to get there.

  99. @Andrew: That's cool and all, but to know that it relies on proprietary Adobe software doesn't really do any justice.

    In order for this application to catch up to Photoshop, the creators would have to rely on updates from Adobe and I doubt Flashes speed, or flexibility will ever catch up to just developing applications in x86 code.

  100. I like this concept. If speed is the goal, limiting it to x86 CPU hardware is going to be a problem down the road, because GPUs such as Tesla and Firestorm are much more efficient. If a version of Native Client could be developed to take advantage of the superiority of GPUs instead of or in addition to CPUs, that would be helpful.

  101. Although actually a very good idea considering it is an OSS effort to streamline things but the project technically is not doing something new ..... if only something comes out of it close to Adobe - flex or silverlight then it is usefull .... otherwise reinvention is just a waste of time .....

    Google chromes javascript engine already converts code to native before executing and is already the fastest javascript engine in the world .... leading to as much as 300% faster code execution than ... webmonkey mozilla's js engine ..... so need of such a project is only valid if it is an alternate oss solution to common runtime like flash and air.

    as flash is still proprietory ....

  102. Did everyone who posted a "too bad it's only for x86" comment just miss the part about ARM and PPC ports?

    I think that if you're looking at this tech as nothing more than a competitor to ActiveX or Java, then you're not seeing the big picture. This is a different way of running applications--a binary sandbox instead of a VM. And it's a completely different approach to verification. The ActiveX trust model is like checking someone's ID as they come into a building. The Native Client model is more like a full body cavity search.

    I don't know if it will take over the world, but it's an option I'm glad to have.

  103. I really think that just making sure Java runs well on your browser would be a more sensible thing to do. They've already solved the security and speed issues.

  104. Its a great idea mainly because its open.
    There will also liekly be prtabilty form Java and :net down to NAcl optiosn too going forward.

    Native Client is designed to run code libraries obviously.
    The challenge as i see it will be to write good GUIS using the current HTML5 languages.

    For example, Sketchup as a web app woudl be a very good challenge. If we presume that Sketchup is written in c, with no ruby, then getting it running in NACL woudl not be too hard.
    BUT, getting that great Sketchup inference like UI working in Html5 (even with o3d) running compisted underneath woudl be quite hard.

    Stuff like Spoutcore and other advanced html5 based javascript libs reallty help no doubt, but its the highly visual and interactive applicatiosn that are the most hard to more fully to the web.

  105. Who laced Google's cool aid again? :) Flash and Java JIT compilers interpret their respective byte-code and compile into *native* code. To all you saying "JIT isn't as fast as native", you need to do your homework--it's as fast or even faster in certain circumstances. Check your benchmarks (link is a little old but Java speed has only been improving):

  106. It would be very cumbersome to supports multiple arch clients. (Why x86 monopoly?) Silverlight seems to have a much better approach and integrates nicely with jscript.

  107. I was thinking about the same thing for a while. Looks like I was late. I even wrote about my idea here []

  108. can anyone explain how to write apps for google native client??

  109. This is cool..I like your post!

  110. There is another dimension to native code I would welcome people's views on. If you have proprietary technology and implement in javascript it can be ripped off. In native code much much harder. I believe this can be very valuable. What do you think?

  111. Why plain text like html,js and css is the world standard instead of precompiled code ,like a .class or .swf. I suppose .class should be smaller in size (after all they are binary) and faster (the are already precompiled).
    Is it just a problem of standards and noneone came up with a brilliant idea to replace this old approach?

  112. I want an extra cpu for html and javascript like JPU .We have GPU, Sound chips, physics accelerators why not a Javascript/HTML5 accelerator ?

  113. So, let me get this straight : You will have a client side set of libraries that will run code that is compiled for it..... Don't we already HAVE Java Applets? Isn't Google sort of going to a lot of trouble to reproduce the exact same thing?
    android developer