> 1) JS is awesome precisely because of the common denominator. But because Chrome said so, devs should go back to triple-testing everything and dusting off their assembly debugger toolchains?
If you absolutely need the flexibility or speed that NaCl offers, then by definition you can't get by with just V8 and HTML5. If you can get by with V8+HTML5, and NaCl offers a speed advantage, a JIT compiler will allow you to have the common denominator as well as the improved speed. If you can get by with V8+HTML5 and NaCl isn't a speed advantage, well....
> 2) With more and more happening on cloud servers, JS engines being mature, and clients just getting faster, the need for that ultimate level of performance feels ever more irrelevant.
But it's always nice to have more speed anywhere. If NaCl is faster than V8, a JIT compiler will allow you -- again -- to have your common denominator and a higher level of performance.
3) ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea. And even if Google manages to keep their implementation airtight and standards-conforming, what happens when NaCl takes off and Microsoft takes a crack at it?
Lets assume that implementations can be made secure with enough time and money, two things that this project is endowed with. I presume you're implying that Microsoft would mess up the implementation, making it a nightmare for devs everywhere. With browser shares being as egalitarian as they are, a JIT compiler would put the onus of a correct implementation on the vendor.
> If you absolutely need the flexibility or speed that NaCl offers, then by definition you can't get by with just V8 and HTML5.
Yes, and in that case perhaps you should not be creating a web app anymore. The web is not the only platform for software development and nor should it be in my opinion.
I find it a bit amusing, albeit rather sad, that you got downvoted for saying that. You're exactly right, of course... the web (that is, html/css/js over http) is NOT the only way to distribute apps, and it isn't appropriate for everything.
Unfortunately, this war has been lost, in the minds of developers in general. Nearly everyone seems to think that the web-browser is a modern day X server, and that it's The One True Way to remote out UIs or to distribute apps.
I do wish people would look beyond this and consider some other options and invest some time and energy on some of the other choices, but it just ain't happening for the most part.
You really want every web page to be shipping their own JIT (or forcing users to grab it from a CDN)? JavaScript JITs are huge.
Also, the idea that you can just ship a JIT in Native Client and have the performance not hugely regress is unproven. Modern JavaScript JITs are fundamentally based around self-modifying code (look up how PICs work). NaCl penalizes self-modifying code by requiring that it run through a verifier. It would require a lot of engineering effort just to avoid huge JS regressions (like this 2.5x slowdown from a year ago [1]); why not spend that manpower to improve JS engines?
If you absolutely need the flexibility or speed that NaCl offers, then by definition you can't get by with just V8 and HTML5. If you can get by with V8+HTML5, and NaCl offers a speed advantage, a JIT compiler will allow you to have the common denominator as well as the improved speed. If you can get by with V8+HTML5 and NaCl isn't a speed advantage, well....
> 2) With more and more happening on cloud servers, JS engines being mature, and clients just getting faster, the need for that ultimate level of performance feels ever more irrelevant.
But it's always nice to have more speed anywhere. If NaCl is faster than V8, a JIT compiler will allow you -- again -- to have your common denominator and a higher level of performance.
3) ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea. And even if Google manages to keep their implementation airtight and standards-conforming, what happens when NaCl takes off and Microsoft takes a crack at it?
Lets assume that implementations can be made secure with enough time and money, two things that this project is endowed with. I presume you're implying that Microsoft would mess up the implementation, making it a nightmare for devs everywhere. With browser shares being as egalitarian as they are, a JIT compiler would put the onus of a correct implementation on the vendor.