Mozilla’s Rejection of NativeClient Hurts the Open Web

●---------------------------------------● Happy New Year◎,◎appy shopping ●---------------------------------------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b ------● ●---------------------------------------● Happy New Year◎,◎appy shopping ●---------------------------------------●

I couldn't agree more if I were suddenly granted the magical ability to concur with the power of a thousand suns.

As far as NaCl goes, the absolute last thing the web needs is portability/endianness issues. I'm writing this comment on a phone (ARM), and I also browse on my desktop machine (x86-64) and my netbook (Atom, x86). (Not to even mention PS3/XBox 360/Wii/older Macs, all of which come with browsers.) Wanna make web the web worse? Force developers to target several architectures for their apps, or greet users with "Your CPU isn't supported!" pages. Lots of Webapp developers have trouble with cross-browser issues!

If you look at Firefox plugins (native) versus extensions (Javascript), you can see fairly plainly that, even though it's slower, the ease of development in Javascript (even with all its quirks) outweighs the benefits of native code, even for heavyweight extensions.

The best solution, in my opinion, is to expose a (fast) bytecode VM to web developers. Javascript is okay for a lot of purposes, but it's a messy language, and can be pretty clunky. A bytecode VM (one that at least has a Javascript front-end) could solve most of these problems. Off the top of my head, the JVM has Rhino for JS (as well as support for Ruby, Python, Clojure, and a host of others) and is easily restricted, if somewhat heavyweight. The Lua VM is faster than the JVM, is portable to a number of platforms (having a clean, portable, lightweight implementation), and I suspect that a Javascript front-end would not be hard, given the similarities between the languages (Lua could be described as a cleaner, faster Javascript). The language of choice would be up to the developer, as long as it could target the VM (and we'd not have to put together hacks like minifiers or $language-to-JS compilers like CoffeScript and Objective-J). Getting Google, Microsoft, and Mozilla to agree on a VM is trickier, although I hear MS loves Lua.

I also agree with the app store assessment (1000 suns, etc.), but have little to add.

According to Brendan Eich, the designer of Javascript:

    JS had to "look like Java" only less so, be Java's
    dumb kid brother or boy-hostage sidekick. Plus, I had
    to be done in ten days or something worse than JS would
    have happened.

(See comments from http://www.jwz.org/blog/2010/10/every-day-i-learn-something-... for that and more from him)

Given that constraint, JS is an amazing hack. But it's 2011 now. Why should we have to use Javascript for client code in the browser--why shouldn't we be able to use Ruby, or Python, or C#, or Clojure, or Haskell, or F#, or Lua, or whatever else we want? It seems ridiculous to me that we're having a resurgence of language innovation on the desktop and on the server, but not in the browser.

For the most complicated apps you are right, but most applications are not that complicated and web technology solves problems that Java has not even recognized as problems. Things like advanced accessibility, semantics, device independence (SVG, CSS Media Queries) true open standards ++. You can do much more with a web browser today than "browsing the web" and browsers has done amazing development the last 5 years and will continue with amazing development the next 5 years as well.

The only way I can see PNaCl catching on is if Google deploys it in Chrome and the Android Browser and creates an automatic fallback to a javascript PNaCl interpreter for the browsers that don't have it. Then it becomes about "why is Firefox/IE/iOS slower at running this webapp?"

But even then you'd need Google or someone else to deploy some interesting PNaCl apps to make having it worthwhile.

It's a pity that this is such a long shot because JS isn't a particularly good language and the stack we seem to be heading towards (and that Mozilla favors) is something like CoffeeScript -> Javascript -> bytecode -> machine code. Javascript doesn't seem like a very interesting compiler target or an easy language to make fast[1]. Maybe the new ES5 strict mode or some other subset of javascript can be agreed upon as a basis for compilers, that is easier to run fast. Then that can be the IL for the web.

[1] Best implementations are 3-5x slower than the JVM according to http://shootout.alioth.debian.org/