1. Not necessarily, as shown here, Google has a separate optimization step. If you look at the other posts you will see that using other google products, such as closure compiler/etc will make this all significantly smaller. This
makes sense. Have the guys who know how to make JS small work on that problem, thus benefiting BOTH hand rolled JS code and Dart-compiled JS code. If not you are eternally having to do merges of the product, the possibility of being on a stale copy, etc.
2. The reason for spitting out "inefficient" code is already described in my post. This is inefficient for Hello, World. That's fine, it may be the proper tradeoff for efficiency in more complex code. Take CocoaTouch for example. If you write a HelloWorld app for iOS and profile it, you could say "why on earth is this app reading in preferences, sending out didLaunch delegate messages, etc etc etc. Doesn't the code KNOW I don't need that and all I want is to show one string". This is an acceptable tradeoff, because all those things its doing are useful for more complex apps. No one is shipping HelloWorld, so who cares if its slower than the best possible HelloWorld? Is it possible to write a compiler so smart that it would even make HelloWorld super small and fast. Sure, maybe, but those engineering resources are much better spent working on problems real applications face. I'd much prefer Apple focus on scrolling performance than HelloWorld. And similarly, I much prefer Google focus on the problem of writing huge web apps that still perform really well, since thats the remaining unsolved problem for the web.