"Hello World" in Dart, compiled to JavaScript

As me1000 (Randy Luecke) says Dart is not meant for hello world. If you run this through closure-compiler it's reduced to 2000 lines which is nothing next to Underscore, jQuery, Dojo, etc.<p>We all know the benefits of offloading code to a well known and well tested library or framework, especially if you're writing an app that is thousands of lines anyway. How is this contentious at the end of 2011 unless you're just hating Dart for the sake of it?<p>I haven't looked into the language yet and unless you haven't either let's all refrain from judgements based on this silly metric alone. Circle jerks and knee-jerk reactions are for Reddit, not HN.<p>Don't get me started on the whining about math performance. Reminds me of dinosaurs whining about how assembly is better than C is better than Java is better than.... There is more to software development than math. Crazy, new fangled, inefficient languages eat the lunch of older languages every single time. You have to be insane to pull out that gem. If math is your bottleneck then don't use Dart, if you know that math is your bottleneck then you shouldn't have to be told this! Sorry for the rant but half of the complaints I've read about Dart are utterly ridiculous, and speculative to boot.

So the joke is that a prototype of a whole separate language has to include its runtime in its cross-compiled output? Did people... think this wouldn't be the case? Do they think that Javascript is not thousands of lines of C/C++ lurking in your browser?<p>Good joke guys, but I don't think you realize which way the punchline is pointing...<p>It sort of amazes me that people are being so hard on Dart, given that they should be grasping for <i>any chance</i> to leave the warty and dated pile of compromises that is Javascript behind. Even the javascript community seems to tacitly admit that Javascript is a bit of diamond amongst a whole lot of dross; hence CoffeeScript and books like "Javascript: The Good Parts".

This is called "a runtime". A bunch of things that have to be loaded on the target machine for use by a compiled program. Just about every compiler works this way, whether the output is machine code or JavaScript. It is possible to not emit or load the parts of the runtime which will not be used by a given program, but that's difficult and in many cases even impossible.<p>I am not a web programmer, and I don't use JS and don't plan to use Dart, but I am flabbergasted that a bunch of techies are going wild and posting facepalm pictures over a perfectly normal technical situation. Maybe Google will pare down the runtime in the future, maybe they will figure out a way to exclude parts of it which are not needed, but right now they are just making the default technical choice that just about all compilers make. This is a non-story. Compile "Hello world" into an executable, and see how many kilobytes it takes on most architectures, despite the object file being a few bytes. Geez.

Funny. But to be fair, a Hello World in C compiles to a 27k binary. Yeah yeah, optimize this, leave out that and you can get it smaller. Still doesn't change the fact that Hello World is not the target use-case for either C or Dart. Dart is intended for very large applications (compared to JS), so the additional weight for includes isn't that big of a deal.<p>It also doesn't change the fact that Dart sucks. For other reasons though.

I'll repeat what I said in the GitHub thread:<p>There's this interesting tool called Google Closure Compiler. It does dead code elimination. <a href="https://gist.github.com/1277285" rel="nofollow">https://gist.github.com/1277285</a><p>Notice that this source is now 2000 lines of <i>pretty printed</i> JS. Given that anything interesting these days uses jQuery or Underscore.js clientside, and similar things serverside, this amount of JS for even Hello World is standard fare.<p>EDIT: To be clear, I don't really give two hoots about Dart ... yet. I use ClojureScript and since ClojureScript ships with a similarly rich API / data structure set, Google Closure Compiler is essential to keeping code size down.

I compiled that code with the google closure compiler. I used advanced optimisations for dead code removal.<p>The result is 94% smaller - 32k, or 9k gzipped. A 32k overhead could be absorbed by most large web applications without being noticed.<p><a href="http://closure-compiler.appspot.com/code/jscd4ddca10c0a518fcb6ea6f56676ef790/default.js" rel="nofollow">http://closure-compiler.appspot.com/code/jscd4ddca10c0a518fc...</a>

same code in coffeescript (@ preceding testMain makes it a static method and it looks like print in Dart converts to console.log)<p><pre><code> class HelloCoffeeTest @testMain: -&#62; console.log "Hello, Coffee!" HelloCoffeeTest.testMain() </code></pre> resulting js<p><pre><code> var HelloCoffeeTest; HelloCoffeeTest = (function() { function HelloCoffeeTest() {} HelloCoffeeTest.testMain = function() { return console.log("Hello, Coffee!"); }; return HelloCoffeeTest; })(); HelloCoffeeTest.testMain();</code></pre>

I don't understand why Dart is supposed to be good, someone please explain it to me like I'm an eight-year-old

This reminds me of the very early days of C++ were people would use the size of a compiled "Hello World" to argue their point. C++ targets a completely different domain from JS where the size of the runtime etc. is somewhat important and it makes sense to think about this.<p>I always thought that JS had this culture of "it works and is fast enough for most users" attached to it, so I'm curious what is so different here? Every JS application nowadays comes with tons of framework code already. Does it make a big difference if you carry around a (non-minified) 17000 lines runtime?<p>Of course, if you argue about elegance, none of this matters.

While this is hilarious, it's exactly fair. Dart is still in a very early tech preview, and they clearly haven't optimised code generation yet.<p>Right now, it's probably designed to be run through something like Closure Compiler, which removes dead code and minimizes the output.

Oooooooo. So it's Javascript except with a highly constraining layer of blub on top of it. I'll go back to learning coffeescript then...

So this includes the full Dart runtime library compiled to JS, and people make a big deal out of it being a long listing.

It's official now: Dart is meant as a practical joke to show why Javascript needs to be replaced by something sane like a bytecode VM.<p>Either that, or I don't want to surf this internet anymore.

I think the problem of Dart and Google's many strategies in web application developer tool area is the belief that the current state of web app development is in a very serious terminal illness that requires chemotherapy, with a complete change of how we do things, while many others - notably the CoffeeScript camp - have shown that we are still essentially in good shape and all we need is some herbal tea to help the immune system. I am not discounting the value of the bold move of Google, but I am very disappointed to see a big negligence of the good parts of JavaScript and other dynamic languages and a blind copy of Java (mis)features. I have not seen Google contributing to the common and popular JavaScript frameworks like jQuery (and Microsoft did... what a strange world). Maybe it's NIH syndrome at play.

They obviously embed into the emitted javascript the whole Dart runtime. Whether it is needed or not.

Wait, is this an indictment of Dart? Or of Javascript?

This comparison is asinine at best. The runtime is bound to be bigger. And remember DART eventually will have the runtime included in Chrome and hopefully other browsers. The way things are going in the browser world, all people might actually care about is Chrome and if there is a wonderful IDE support which comes with strongly typed languages, there is a real shot at this becoming a standard.

I wonder if the only speed benefits that the Dart VM gives would be able to be beaten out by a smart compiler. I know this is early for the cross-compilation code (it doesn't trim out anything it doesn't need here), but I hope this isn't what is ultimately used in that comparison.

The comments on this thread are a disgrace. Read more.

I'm noticing all those functions being defined with ever increasing argument counts. I'm sure Google will optimise the output one day, as soon as they learn about arguments.length.

Google Dart was designed to build large scale web applications, yet all their demos and example code only includes small applications. That still require quite a lot of code to build.<p>I don't see any profit of building a application in dart, if you have to create more code your self than you would with a regular HTML5 based application.<p>As this "Hello World" demo shows, the only thing It's good at is creating bloat and this will probably stay this way until native parsers are implemented.

Wow. Reminds me of GWT...

I prefer coffescript <a href="https://gist.github.com/1277567" rel="nofollow">https://gist.github.com/1277567</a>

If Microsoft had suggested this, they would be persecuted and beat into submission.

So, something that lets people who don't understand JavaScript "compile" some other language into JavaScript, is horribly inefficient. Wow, what a surprise.

People got just as pissed off as this over the amount of code Fructose (my Ruby-PHP compiler) outputted for Hello World.<p>Looks like most here don't know how compilers work.

I haven't seen such a neatly formatted piece of JavaScript code in a long time.

so fuckin what

I can't believe that a gist somehow turned into a 4chan thread. I found that infinitely more horrifying than the fact that a hello-world program nearly crashed my browser through sheer size.

ewwwww