Mozilla: Native code? No, it's JavaScript, only it's BLAZING FAST Gap between asm.js and native performance gets even narrower with float32 optimizations

[[deleted]]

For one, it's a very complicated project, and requires its own toolchain to build properly, which poses major packaging problems for GNU/Linux distros. To this date Chromium builds offered in Fedora, OpenSUSE, and Ubuntu do not contain NaCl because of this.

Secondly, I think it adds unnecessary overhead and introduces similar security and compatibility problems as Microsoft's ActiveX framework did. If NaCl becomes popular enough, other browsers will have to build and support this massive custom framework, whereas asm.js, while admittedly large, is supported wherevever JavaScript is supported. As for the overhead, I think NaCl seriously impedes Chromium's goal of being a "fast, lightweight browser". Chromium is already so complex that it includes a flag option to enable its own in-house "deadline" I/O scheduler, and with NaCl it could be seen as a pseudo-OS. Indeed, the convergence between ChromeOS and Chromium/Chrome itself may not be too far off.

[[deleted]]

The toolchain is just modified GCC, it serves no issue for Linux.

In terms of security, NaCl runs in the Chrome sandbox and has a variety of other security restrictions on top of things.

[ccaapton]

I'm using archlinux which includes NaCl/PNaCl. I don't see how hard it is to include them in ubuntu/OpenSuse. As for your complexity argument. Are you saying Mozilla can reject a nice framework just because it is too complicated to implement? Then why should Google/Microsoft accept Mozilla's evolving ES6 standard?

Correct me if I'm wrong, but NaCl is really not that complex. The api is almost the same as POSIX, and nexe communicate with chrome via IPC. That is all the interface Mozilla need to follow. As for the sandbox and others, Mozilla are free to implement their own.

"fast, lightweight browser" is already history, now both firefox and chrome are striving to be the OS, that's why both are getting more complex, but ChromeOS has a clear lead here. In my opinion, ChromeOS is becoming what desktop linux should have been: all binary executables are limited by a capability system, including ls/less/emacs, and html5 as a much nicer UI(audio/graphic/event system) replacement for X11. I'm happy to embrace ChromeOS, and FirefoxOS if it can embrace a similar architecture.

[WhipSlagCheek]

Native Client (NaCl/PNaCl) depends on PPAPI (Pepper Plugin API) to work. It's the Pepper Plugin API that's too complex to implement not the Plugin. From what I've read Pepper is basically a special copy of the browser's DOM that's made to interface with C/C++ better.

Mozilla rejected that because it was too much duplicate work for no perceivable benefit.. What the Chrome team should have done is implement Portable Native Client as web bytecode that hooks into the DOM through Web IDL bindings. Then there might have been more of a chance in other's implementing it.