Native Client: Google's (other) plugin play

Native Client: Google's (other) plugin play

Summary: Yesterday Google announced an early developer release of Native Client, a plugin for web browsers that lets you essentially run native code like C or C++ in the browser. In theory it could be extended to other languages.

SHARE:

Yesterday Google announced an early developer release of Native Client, a plugin for web browsers that lets you essentially run native code like C or C++ in the browser. In theory it could be extended to other languages. The main goal is to provide native-like performance and to let C/C++ developers start creating web applications. They've got a couple of cool examples, including Quake running in the browser, on the developer site.

Adobe announced Alchemy at MAX, which is a similar project for the Flash Player. Like Alchemy, Native Client uses GCC-based tools to compile C or C++ into bytecode native x86 code for the specific runtime. Alchemy uses Flash and Native Client has it's own, I assume C-based implementation. Both of these are early projects but it's the start of a trend and an example of the ever-expanding sphere of web applications. It's also very interesting to see this come out of Google, a company that has been doing a lot to expand the functionality of the web browser. They've got Gears for offline/desktop functionality, Native Client for performance, Earth for mapping, and of course Chrome for an actual browser.

Keep an eye on this project. I see the Flash Player or Silverlight has having 3 core parts: the runtime, the rendering engine, and the video codecs. Put those three things together and you've got an RIA plugin. Google has a bunch of disparate projects and none that do all of these, but they have a bunch of the pieces and a ton of engineering talent. It's also telling that Google is starting to be more and more obvious that the web browser/technologies as it exists today just aren't cutting it. That means we'll see more energy for projects like Native Code and Gears.

Topics: Software Development, Browser, Google

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

11 comments
Log in or register to join the discussion
  • Frist Hand Wringing

    Oh joy! Let's celebrate and it's BYOBO (Bring Your
    Own Buffer Overruns)!

    Am I wrong?
    DannyO_0x98
    • Agreed.

      There's a reason Java and .Net (Silverlight) are managed code sandboxes.

      This sounds far too like ActiveX, but worse.
      TheTruthisOutThere@...
    • I am worried too. I assume that since they will generage byte codes, that a

      lot of things will be prohibited, such a writing to the local disk or communicating with arbitrary web sites. These need to be sandboxed, and will hopefully NOT be anything like ActiveX.
      DonnieBoy
  • I do not like the sound of this if it is not sandboxed in its own process.

    Sounds too much like ActiveX. What form of "byte codes" will they generate?
    DonnieBoy
    • Bytecode?

      Its called NativeClient for a reason: the "byte codes" are x86!
      TheTruthisOutThere@...
      • He used the word "bytecode", which is NOT the same as a native binary.

        Maybe it was a mistake? But, you theoretically could make GCC generate an alternate byte code, that would work on any platform that had a VM for that byte code, and also limit the library calls available so you could not write to the local disk. With Chrome, they could isolate these programs in their own process with reduced privileges.

        We do need more information.
        DonnieBoy
        • RE: He used the word "bytecode", which is NOT the same as a native binary.

          My fault. My only familiarity with GCC comes from our Alchemy project which takes C++ and turns it into ActionScript bytecode. This is native x86 code, not any kind of special bytecode. Fixing now.
          ryanstewart
  • More info here.

    Yes, I know full well that byte codes are not native code, hence my phrasing.

    But, Native Client really does use x86: http://google-code-updates.blogspot.com/2008/12/native-client-technology-for-running.html
    TheTruthisOutThere@...
  • Why C and C++?

    So that developers could spend precious time playing with memory leak, wild pointer, segmentation fault and all those "fantastic" C and C++ features? Come on now: If you wanna go that plugin route, let's start with sth manageable like Python, Java and so on.
    LBiege
    • Hey, at least us C/C++ programmers are good lookin'!! But, we DO understand

      the dangers and how to minimize them. I DO agree that Java has a lot of good features.
      DonnieBoy
  • RE: Native Client: Google's (other) plugin play

    I thought it may be relevant to post here about our new application platform ,Tonido that blurs the distinction between web and desktop applications.Our core runtime is developed in C++ as Google Native client and compiled for Windows, Debian and Mac OS X. Tonido platform is also bundled with four interesting applications: Jukebox,Photos,Workspace and Webshare. If you want to know more, Please check our blog post <a href="http://www.codelathe.com/blog/index.php/2009/02/05/tonido-platform-how-it-works/">Tonido Platform - How it Works</a>.
    sphinxguy