Wednesday, May 12th, 2010

Native Client now comes with an actual SDK

Category: Google

<>p>

A year after the initial Native Client release we have a more polished Native Client SDK for developers.

The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes: a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code, ports of popular open source projects like zlib, Lua, and libjpeg, and a few samples that will help you get you started developing with the NPAPI Pepper Extensions. Taken together, the SDK lets you write C/C++ code that works seamlessly in Chromium and gives you access to powerful APIs to build your web app.

Salt and Pepper indeed. A friend at a browser vendor was looking into Pepper and thought that the specs were definitely….. thorough shall we say? Take Pepper Audio by itself. A bit of a beast! :)

It is interesting to watch Google give C/C++ developers (and legacy code) a different path to the Web (beyond NPAPI and… ActiveX!). You can imagine this being increasingly important when you think about Chrome OS.

Ideally, the Web platform itself evolves fast enough that this project is always an onramp for legacy code…. what do you think?

@hbridge has an interesting view:

Pepper is very much a work in progress and we expect it to change — that’s why this is a preview! Feedback welcome :)

ActiveX was designed to provide unrestricted access to native APIs so it wound up being a security nightmare.

NaCl is designed to give access to native code performance, but only to APIs similar to what JS offers, so security model is same.

Related Content:

Posted by Dion Almaer at 1:12 pm
3 Comments

++---
2 rating from 2 votes

3 Comments »

Comments feed TrackBack URI

I have mixed feelings about NaCl. On the one hand, I know that for web apps to compete with native we’ll need something in addition to JavaScript. This seems like a pragmatic way of doing that.

I just hope it doesn’t get abused too badly. I mean, sure it may be safe and performant, but its not very webby. I would prefer to see work done on making the browser friendly for multiple languages, including possibly NaCl style binaries – but instead of targeting a built in OpenGL api, it would be nice if it could directly use WebGL and canvas.

Comment by genericallyloud — May 12, 2010

@genericallyloud: I don’t think there’s too much danger of this being abused in practice, because it’s necessarily a painful way to develop. Apps that absolutely need it (often game ports, I imagine) will use it, but those that require less horsepower will likely stick with js->canvas/webgl/audio-tag/video-tag.

Comment by jgw — May 12, 2010

Is Native Client like XPCOM in Mozilla browsers?

Comment by Yansky — May 13, 2010

Leave a comment

You must be logged in to post a comment.