Okay, so you are talking about exposing integer vs. double distinction (because CPUs are better at int math) and the SIMD support in the Dart VM.
All of those are using explicit typing to do better at mapping from what the developer does to what the native hardware supports than is possible without explicit types in JS, sure. I don't see why this is a bad thing -- its not sacrificing performance in Dart-to-JS implementations that would be attainable, its just taking advantage of not being stuck with JavaScript's lack of types to further optimize the performance of Dart-on-its-own-VM.
The Dart VM being faster than JavaScript can be a problem in itself. But with SIMD you'll get a lot of "Only usable in Dart VM" for a lot of apps (mainly games) written in Dart, because then the necessary speed for many game operations gets possible.
I don't want back to the "Best viewed in IE 5.5 and 1024x768 Pixels" times.
> The Dart VM being faster than JavaScript can be a problem in itself. But with SIMD you'll get a lot of "Only usable in Dart VM" for a lot of apps (mainly games) written in Dart, because then the necessary speed for many game operations gets possible.
Yes, building performance improvements into the Dart VM that go beyond something that is found in most JS engines means that there is the possibility that (given equivalent hardware) some things that peform acceptably on the Dart VM won't perform acceptably when relying on Dart-2-JS.
Which would be a problem if there was a barrier to other browser vendors incorporating the Dart VM, or adapting it to platforms that Google doesn't support. But there's not, and the whole point of Dart -- and why there is a Dart VM -- is because Dart is an effort to provide an alternative to JavaScript, with dart2js as a mechanism to make development in Dart useful even before Dart VM adoption takes off.
But dart2js isn't the long-term goal, its a tool to get passed the problem that without runtime deployment, no one will develop, and without development, no one will deploy the runtime.
> I don't want back to the "Best viewed in IE 5.5 and 1024x768 Pixels" times.
And I don't want the web to stagnate because we can't do anything that might work better than what exist now.
Good thing about new efforts being open is that they avoid both problems.
You're complaining about more speed? Why don't we see the same complaints with asm.js?
If SIMD on Dart works out well, you can bet JS will get SIMD support too, and then dart2js will use that. It's this type of competition that pushes things forward.
All of those are using explicit typing to do better at mapping from what the developer does to what the native hardware supports than is possible without explicit types in JS, sure. I don't see why this is a bad thing -- its not sacrificing performance in Dart-to-JS implementations that would be attainable, its just taking advantage of not being stuck with JavaScript's lack of types to further optimize the performance of Dart-on-its-own-VM.