Dart is OSS, so I geuss if it really got mass adoption, Firefox and IE could adopt it. Yes, this would lead to a single implementation, I'm not sure how I feel about this. On the one hand, it limits innovation from multiple implementations, on the other hand, incompatibilities between implementations, have been a big source of programmer headache in the first place. Flash was not bad in that respect and is one reason for it's success, despite its shortcomings. I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore.
Really though, Brendan has made the argument that Javascript is fixable and that it is a good target for higher level languages, and I don't really agree with either of them.
The changes I see being planned for ES.next don't really address some of the fundamental problems with JS, like network transport, or startup costs because of legacy constraints of not wanting to break existing JS. On mobile devices, loading a lot of Javascript is expensive, and I don't see anything in ES.next to bring it anywhere near competitive with native. If mobile is the future and the predominant way we consume the web, then we are at big risk of being dominated by native. Can we afford to wait years more for a promised fix that isn't even in sight?
For a mobile device, ideally you'd want a dynamic language that could be atleast partially statically optimized for a particular device platform, and transmitted in a highly compact format that is cheap to parse and execute on a mobile VM to not make the device waste bandwidth or precious battery performing tasks that could be done on the server for it (like executing a parse and eval)
Likewise, I don't agree that JS is an ideal intermediate format for higher level languages to compile to. I'm not saying LLVM or JVM bytecode are either, but if your HLL contains numerics like 64-bit ints or longs, for example, it's pretty crappy to translate. There's also double costs here: You're running a HLL compiler to parse, compile, and optimize one language, which then must be parsed, evaled, and optimized a second time on your target CPU.
Something like DVM, or a bytecode specifically designed for JS would be better I think.
There's a difference between open-source software and an open-source project. For example, compare the PostgreSQL and MySQL databases. Both are released under an open licence, but PostgreSQL is developed openly on a mailing-list and anyone can step up and contribute, while MySQL is developed privately by an organisation, with occasional source releases. No single entity has a majority control of PostgreSQL, but Oracle has a pretty firm grasp of MySQL.
Likewise, even though Dart is supplied under an open licence, it remains to be seen whether it's operated more like PostgreSQL or more like MySQL. As I understand it, the V8 project is somewhere between the two, and Android is way up the MySQL end of the spectrum. Based on what Brendan has said, I doubt Mozilla would want such a large part of their platform based on a black box they can't control, and I can't really imagine Microsoft doing it.
I don't think your Unix example is quite fair; the number of Unix systems on the planet is orders of magnitude smaller than the number of web-connected system. Even so, there's still a lot of people working with Darwin in the guise of iOS and OS X, and there's a decent number of computers running non-Unix-based operating systems too.
I'll confess I'm not too familiar with the exact changes planned for ES.next, I just recall Brendan saying that improving JS as a primary language and as a compilation target were major goals in the ECMAScript committee. Maybe it's not there yet, but it can get there faster than it will take to add performant Dart VMs to every browser.
"I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore."
Nobody cares about Darwin? Really? I mean, in terms of hacking the kernel, sure, but tons of people are running Darwin. The POSIX standard is more important than ever.
"On mobile devices, loading a lot of Javascript is expensive"
I keep seeing this assertion that bytecode would be smaller than gzipped, minified JavaScript source. I'm actually somewhat skeptical. Has anyone actually tested this?
"could be atleast partially statically optimized for a particular device platform"
I don't want this at all. That's too close to ActiveX for comfort.
"wasting precious battery performing tasks that could be done on the server for it (like executing a parse and eval)"
You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one.
Who said anything about Java bytecode? Java bytecode != bytecode.
"I don't want this at all. That's too close to ActiveX for comfort."
It has nothing to do with ActiveX. It has everything to do with dead-stripping code and targeting particular browsers the way GWT and Closure Compiler do today.
In particular, Javascript VMs today always parse JS even if it's already been cached, hasn't changed, and is loaded from the cache. They must also retain the original source as well as the parsed AST representations due to other semantics (toString()), which wastes gobs of memory on memory constrained devices.
As for size, I believe there's a Microsoft paper floating around somewhere where they use a custom tokenized AST byte code format to achieve significant wire savings.
The reality is, Java on Android already starts up faster than Android and runs faster than JS, so there is ample evidence that JS is underperforming other environments, meanwhile, Android APKs are not any bigger than comparable JS apps from my anecdotal observations.
"They must also retain the original source as well as the parsed AST representations due to other semantics (toString()), which wastes gobs of memory on memory constrained devices."
Wrong. SpiderMonkey doesn't. It retains the bytecode only, throws away the original source, and uses a decompiler when toString() is used. V8 saves the original source, but that's its problem :)
I don't know about GWT, but in my experience closure compiler does not produce different output for different browsers (though it does strip dead code).
It has the ability, but doesn't not part of the default IIRC unlike GWT which is built around permutations. GMail I think varies permutations. However, there are sound reasons for wanting to do so besides differing DOM capabilities, namely, that different JS VMs have different performance characteristics and what may be an optimal pattern for one, isn't for another.
"You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one."
It seems like you are talking about Dalvik VM (Android). Java class files (stack bytecode) are actually converted to Dakvik's register bytecode ahead of time. (Before installation on the mobile device.) I'm unsure if Dalvik bytecode is verified or not.
No, I'm talking about the verifier [1]. In particular: "There are no operand stack overflows or underflows." That requires abstract interpretation.
And every performant Java interpreter is required to convert the stack machine to vregs in order to perform register allocation. That requires abstract interpretation too.
Really though, Brendan has made the argument that Javascript is fixable and that it is a good target for higher level languages, and I don't really agree with either of them.
The changes I see being planned for ES.next don't really address some of the fundamental problems with JS, like network transport, or startup costs because of legacy constraints of not wanting to break existing JS. On mobile devices, loading a lot of Javascript is expensive, and I don't see anything in ES.next to bring it anywhere near competitive with native. If mobile is the future and the predominant way we consume the web, then we are at big risk of being dominated by native. Can we afford to wait years more for a promised fix that isn't even in sight?
For a mobile device, ideally you'd want a dynamic language that could be atleast partially statically optimized for a particular device platform, and transmitted in a highly compact format that is cheap to parse and execute on a mobile VM to not make the device waste bandwidth or precious battery performing tasks that could be done on the server for it (like executing a parse and eval)
Likewise, I don't agree that JS is an ideal intermediate format for higher level languages to compile to. I'm not saying LLVM or JVM bytecode are either, but if your HLL contains numerics like 64-bit ints or longs, for example, it's pretty crappy to translate. There's also double costs here: You're running a HLL compiler to parse, compile, and optimize one language, which then must be parsed, evaled, and optimized a second time on your target CPU.
Something like DVM, or a bytecode specifically designed for JS would be better I think.