This is false. It is like claiming that it "should" really compile to just console.log("Hello,Darter!"); They're functionally equivalent so why not right?
Dart was designed for big apps. Google is not aiming at optimizing all the Hello World pages. Every single framework in existence has terrible size characteristics for Hello, World. Loading all of Foundation and UIKit for showing Hello World on the screen in iOS? It SHOULD just magically know to compile to the few commands that show the one text string right? No, that would be a waste of time optimization.
Now, if we start writing big apps in this thing and they are also bloated compared to their JavaScript equivalents then I will agree 100% that there is a problem. But there are just no worthwhile conclusions from the HelloWorld app regarding size. The only worthwhile conclusions are from the high level perspective, aka "how easy is it to write a hello world app".
Well, Dart is designed to replace JavaScript as the client side Web scripting language of choice. Given that goal, they need to do well at small projects as well as large ones.
If Dart ever replaced JavaScript then most code would probably be running under the native implementation and this issue would be moot. I think its acceptable for them to be focusing on the actual problems on the web (writing large maintainable applications), and not focusing too much on image swaps and console logs.
compilers are supposed to optimise what they spit out, so why is this spitting out either a) terribly inefficient code or b) a whole heap of un-used code?
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.
the original example should "compile" to nothing more than the following:
(function () { window.HelloDartTest = { testMain: function testMain() { console.log("Hello, Darter!"); } };
HelloDartTest.testMain(); })();