But alas, the browser wars are upon us once again. FF vs Chrome is approaching the silly.
On the other hand, there are merits in their differences. Chrome, although it would prefer Dart, looks upon JS as legacy that they can approach via a good VM/JIT, and a brilliant Developer Tools suite.
FF on the other hand is leading into the JS futures on two fronts: asm.js for both performance and C/C++/.. integration into the browser, and ESnext. Google is very reluctant to invest in ESnext now, just look at the compatibility charts.
This makes sweet.js strategic, it lets us at least experiment with ESnext features as far as macros can take us. I'm hoping sweet.js can also help us make use of asm.js from within the browser buy building macros for things like structs, which halve or more memory footprint of object arrays.
Lets be aware of the war, and do what we can do to resolve it.
On the other hand, there are merits in their differences. Chrome, although it would prefer Dart, looks upon JS as legacy that they can approach via a good VM/JIT, and a brilliant Developer Tools suite.
FF on the other hand is leading into the JS futures on two fronts: asm.js for both performance and C/C++/.. integration into the browser, and ESnext. Google is very reluctant to invest in ESnext now, just look at the compatibility charts.
This makes sweet.js strategic, it lets us at least experiment with ESnext features as far as macros can take us. I'm hoping sweet.js can also help us make use of asm.js from within the browser buy building macros for things like structs, which halve or more memory footprint of object arrays.
Lets be aware of the war, and do what we can do to resolve it.