This ... has not been my experience. And I write a lot of high-performance native and Java code.
> For dynamic languages, if you want decent performance, all the known techniques require JIT techniques.
Then adopt a bytecode standard so that it can be JIT'd. I don't believe that NaCL is the end of the conversation, just that Mozilla has consistently prevented the conversation from starting, and refused to participate in it unless it involves Eich's JavaScript as the baseline implementation language.
So, you want a standard program representation that's amenable to JIT compilation. But why, exactly, does it need to be a bytecode format, rather than source code in a standardized language?
Let me reiterate some of the advantages of JavaScript:
* A performance arms race among JavaScript implementers has been underway for nearly half a decade now. JS thus has a head start in that area over any hypothetical language or bytecode format that might be integrated in a browser.
* JS already has first-class access to the DOM -- the API that all the browsers already have -- as well as all the other up-and-coming APIs.
* There are already JS debuggers, and with source maps, these debuggers can even be made to work with other languages that can be compiled to JS. All JS developers benefit from this, as well as all developers who use languages that compile to JS.
So basically, JS has a head start over NaCl, Dart, or any other potential "clean" replacement.
As far as I can tell, your only objection then is that there's something aesthetically wrong with using a quirky high-level language as a compilation target for other languages. To that I can only say that worse is better. We might as well get on with the business of writing great apps with the tools we have.
This ... has not been my experience. And I write a lot of high-performance native and Java code.
> For dynamic languages, if you want decent performance, all the known techniques require JIT techniques.
Then adopt a bytecode standard so that it can be JIT'd. I don't believe that NaCL is the end of the conversation, just that Mozilla has consistently prevented the conversation from starting, and refused to participate in it unless it involves Eich's JavaScript as the baseline implementation language.