3 ms·

> The real issue is that no one but Google thinks NaCl is good for the web. Are you sure about that? I like NaCl. I don't know about depending on x86 instruc

> The real issue is that no one but Google thinks NaCl is good for the web. Are you sure about that? I like NaCl. I don't know about depending on x86 instructions, but I like the idea of NaCl. I think it's pretty clear that the web needs some kind of low-level VM that's closer to the metal than JavaScript. It's been argued that LLVM isn't the answer, so maybe PNaCl is on the way out, but overall I think NaCl makes sense in Google's strategy: they want to see web apps take over. They want the web to replace Windows and OS X. Therefore it's natural that they want to download native or near-native code to the browser, and NaCl is just a way to do it safely. It's _not_ the same thing as ActiveX, I really believe that. However, it's clear that it's necessary to be extremely careful, and I'm not convinced they need to go 100% native -- I think a solution like PNaCl is more along the right lines. Web apps and games are not going away, and I think it's clear that we need something easier to statically optimize than JavaScript as the runtime system for the web.

azakai 15y ago
> Are you sure about that? I like NaCl. Sorry if I wasn't clear before, when I said "no one but Google thinks NaCl is good for the web", I was talking in the context of browser makers. I meant the fact that Google is the only browser maker that thinks NaCl is good for the web. > Web apps and games are not going away, and I think it's clear that we need something easier to statically optimize than JavaScript as the runtime system for the web. We can do that in a portable, standards-based way without a complete break like NaCl with its downsides. Consider what the PyPy compiler does to RPython: It compiles RPython, a subset of Python, down to C, by statically discovering all the types and so forth. The same can be done for JavaScript, since the performance-sensitive code people are writing is almost always statically-typed (but implicitly, without writing types) anyhow, just like RPython. In fact we are already moving towards that now, with technologies like the global type analysis in SpiderMonkey TI. With a few more years of work, that approach should make performance-sensitive JavaScript as fast as we need it to be. There is no technical impossibility here, it just takes time - we are half-way there, with things like RPython showing this is definitely feasible.

azakai 15y ago

> Are you sure about that? I like NaCl. Sorry if I wasn't clear before, when I said "no one but Google thinks NaCl is good for the web", I was talking in the context of browser makers. I meant the fact that Google is the only browser maker that thinks NaCl is good for the web. > Web apps and games are not going away, and I think it's clear that we need something easier to statically optimize than JavaScript as the runtime system for the web. We can do that in a portable, standards-based way without a complete break like NaCl with its downsides. Consider what the PyPy compiler does to RPython: It compiles RPython, a subset of Python, down to C, by statically discovering all the types and so forth. The same can be done for JavaScript, since the performance-sensitive code people are writing is almost always statically-typed (but implicitly, without writing types) anyhow, just like RPython. In fact we are already moving towards that now, with technologies like the global type analysis in SpiderMonkey TI. With a few more years of work, that approach should make performance-sensitive JavaScript as fast as we need it to be. There is no technical impossibility here, it just takes time - we are half-way there, with things like RPython showing this is definitely feasible.