Comment by BrendanEich | Hacker News Reader

Comment by BrendanEich | Hacker News Reader

Parent Full thread

You have me wrong: NaCl is great, perhaps as near to ideal as it can be (it's still nowhere near "done"; it's experimental where it isn't in DLL hell, libc hell, "portable" LLVM bitcode hell, etc.).

The quality of the NaCl work is not the problem.

The problem is that none of the other browser vendors can or will afford to get on Google's treadmill, trust Google as much as they would have to, then try to implement Pepper (for which the code is the spec, including bug for bug compat), take on all the toolchain dependencies, and hire people to co-maintain on their own release schedules. Not gonna happen.

The OS-specific toolchain-and-runtime alternative looks likelier to me. It solves the distribution problem, sinks the costs at the OS vendors, and avoids requiring coordination at the price of the safe plugins still being OS-specific binaries (which we live with today).

Another problem I have with your comment is the hope that innovation speeds up when we have more native-code plugin options. I doubt that greatly.

Web developers can choose different tools today, but their complexity is mostly confined to the server side and to the development lifecycle there.

Moving some or all of this complexity to the browsers via a large and growing menu of "DLLs" that are required to be downloaded along with primary app source? No way. Remember, the whole gambit of NaCl requires the humongous and messy Pepper API, the API that is nowhere near standardized or ready (or able) to be standardized, which non-chromium.org browsers are not going to support.

It's like the >1000 MS-COM interfaces that ActiveX plugins can and do use in old IE versions.

My bet is that the client side will not grow to look like your random Apache installation with (magically memory- and control-flow-safe) multiple programming language DLLs lying about. We may get to a post-JS future but it won't be that Tower of Babel, not on the client -- especially not on the mobile client.

I agree with what you are saying in the beginning - We definitely need a proper standard and not a single company having design control. I am not so much defending the way Google is going about it, but rather the value of something which plays the essentially same role.

Ideally, I would like the web developer to have as much freedom as a developer for a native application - the freedom to choose a programming language and the ability to compile to a reasonably low level target for performance while still being cross-platform. Now, this somehow needs to be done without the security nightmares of ActiveX plugins. (Though, I dont see the non-security problems with a bunch of shared libraries stored on the browser. This is essentially what the OS does, and my goal is to replace the OS with the browser. Bandwidth will probably improve so that downloading libraries shouldn't be a problem and if not, the web site maintainer can still choose not to develop in a large library environment The popular ones will be cached in any case.)

You seem to be saying that the technical difficulties of doing this in a well-specified (memory and control-flow), secure and cross-platform way are intractable. Maybe this can be solved by moving the VM to a more abstract level.

I don't know how to be more clear. I'm not talking about the technical difficulties by themselves, out of context. The technical difficulties are formidable -- but not insuperable for Google with its many engineers.

I'm saying that in context of market realities, the other browsers won't use shared Google-source as the "implementation is the specification" for NaCl/Pepper, and no one can write a real NaCl/Pepper spec by which any browser could implement an independent and interoperable workalike in less than decades.

So why try if the OSes can do their own non-interoperating workalikes? (And they are already doing this, from what I hear.) If safe native code on the web is mainly for plugins, there's no problem. Plugins are OS-specific today and likely to remain so, safety or no.

Moving the Web VM to a more abstract level... hmm, sounds like JS as better compiler target over time. See also https://github.com/kripken/emscripten/.

OK, Thanks for clarifying. Again, my purpose is not defending NaCl and if this can be done by making JS a better target or by a translator from another VM, that's great, and I hope these projects succeed. And these are worth trying even when the OSes have incompatible workalikes, precisely because they are incompatible. Thanks again for all your work on JS and the open web.

In the very long run, could OS-specific CFI enforcement toolchains and runtimes merge into a single standard, usable on the web?

Maybe, but that is beyond my prediction horizon. Either OS vendors or browser vendors (if there's a difference) would have to standardize a butt-load of APIs.

Since the '60s, researchers have dreamed of universal object files (ANDF, e.g.). It would be too funny if far-future JS merges into this single standard too!

("too funny" in my experience means this will definitely happen...)

Reply on news.ycombinator.com