Google's Native Client belongs on the Server, too
What is Native Client?
Have you heard of Native Client (NaCl) from Google? Yet another open-source client software play from our overlords in Mountainview.The write-up on the project site is pretty good:
Native Client is an open-source technology for running native code in web applications, with the goal of maintaining the browser neutrality, OS portability, and safety that people expect from web apps. We've released this project at an early stage to get feedback from the open-source community. We believe that Native Client technology will help web developers to create richer and more dynamic browser-based applications.Think of it this way:
Right now, the only way to play with the HTML DOM is with Javascript--Javascript with a surface area explicitly limited to the DOM.
Now imagine you could give any x86 the same explicit sandbox--with some clever run-type verification.
While we should all be worried about claims of safety, the promise of high-performance and language agnosticism is tempting.
Forget the CLR and the JVM.
x86 won a long time ago.
Now App Engine, Please
If Google really buys into the safety of NaCl, they should put their data center where their mouth is.They've done a lot of work to provide Python and Java support on App Engine. Why not allow any language on App Engine with NaCl?
Instead HTML DOM being the "safe" surface area, make it HTTP request/response. Think CGI or (as a Ruby guy) Rack--expanded, certainly, for background tasks, datastore/memcache access, email, etc.
A revolution in back-end web programming
There's a painful gap between ease and flexibility on the backend.Sandbox too Small
If you want ease, you're stuck with a limited "approved stack" at a host--Java/Python on App Engine, PHP/Rails at Dreamhost, etc.You're stuck with Ruby 1.8.6 at Heroku. You're waiting for Google to support Python 3.0 on App Engine.
Sandbox too Big
If you want flexibility, you're stuck managing a Linux image on Amazon EC2 or Slicehost.You have to worry about which Linux distro to run...if/when you should patch it.
Not to mention giving up all of the smart scaling one gets from App Engine-like solutions.
Sandbox just right
We need an abstraction layer that fills the gap.NaCl seems like it would fit the bill.
Google could re-write their Python and Java sandboxes for App Engine to run within NaCl. At this point I'd wager, any language/framework--Ruby/Rails, PHP, or even old-school Perl/CGI could be tweaked to run there, too.
Google could open-source this sandbox, no doubt, providing a de facto, language-agnostic web server model.
Which sounds really nice to me.
Shipping Microsoft Singularity
Our friends in Redmond have been playing with the idea of allowing safe execution of 3rd-party code.A research project called Singularity aims to allow high-performance and safety...but it feels like the all too common "boil the ocean" play from Microsoft. New tools, new languages, and a new operating system.
It's a project that's been public for 5 years, with little more than some channel9 videos to show for it. I fear we'll see a lot more research papers before we see any production-approved code.
Google's model with NaCl--"let's make x86 safe"--is ambitious, but tightly constrained. It also piggy-backs on a huge stack of open-source languages, frameworks and tools.
Native Client could be huge.
Huge in the browser.
Just as huge on the server.