So this includes the full Dart runtime library compiled to JS, and people make a big deal out of it being a long listing.
"Hello World" in Dart, compiled to JavaScript
51–60 of 162 posts
Re: "Hello World" in Dart, compiled to JavaScript
#52I 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 Dart VM buys you sane numeric semantics (integers and floats and bignums). Dart is also quite a bit less dynamic and introspective than JS, which should make it easier to optimize.
Re: "Hello World" in Dart, compiled to JavaScript
#53Earlier quoted context omitted.
[deleted]
Which is a one time cost - and roughly the same you pay for including any other framework out there.
Name one framework as heavyweight as this.
Underscore.js and Backbone.js put together are 1/8th the size of HelloDartTest.dart.app.js.
jQuery plus dozens of jquery.ui plugins can come close in size, but that actually does a lot. This boilerplate doesn't seem to have much functionality in it.
Re: "Hello World" in Dart, compiled to JavaScript
#54Wait, is this an indictment of Dart? Or of Javascript?
I thought it was an indictment of ridiculous comparisons...
Re: "Hello World" in Dart, compiled to JavaScript
#55same code in coffeescript (@ preceding testMain makes it a static method and it looks like print in Dart converts to console.log) class HelloCoffeeTest @testMain: -> console.log "Hello, Coffee!" HelloCoffeeTest.testMain() resulting js var HelloCoffeeTest; HelloCoffeeTest = (function() { function HelloCoffeeTest() {} HelloCoffeeTest.testMain = function() { return console.log("Hello, Coffee!"); }; return HelloCoffeeTes…
CoffeeScript is meant to be synaptic sugar on top of JS. Dart is a language with different semantics that happens to compile to JS. As such it includes a lot of runtime code. More appropriate examples would be Emscripten, Parenscript, or ClojureScript.
There is a legitimate point here though. If I'm a developer working on a new project, and I'm dissatisfied with JavaScript, I have a couple of options. I could try Dart, which will cost me a significant amount of performance in all browsers that aren't Chrome, or I could go with CoffeeScript, which will have good performance in all browsers (including Chrome, since Chrome will be forced by the other browser manufacturers to keep its engine up-to-date). For me that'd be an easy choice, unless one of three things happens:
(1) Dart's performance is so much better than that of JavaScript that it's worth sacrificing performance in every other browser to get hugely better performance in Chrome. That seems unlikely to me, but maybe it's possible.
(2) Chrome ends up with 90%+ market share, so it doesn't matter that I'm bad in all the other browsers. But I can't see this happening as long as e.g. iOS is around and relevant.
(3) I have the resources to write both a Dart version for Chrome and a CoffeeScript version for older browsers. At this point, Google has strictly made my life harder than it would have been otherwise.
I do want to give Dart a fair shake, but I'm having a hard time seeing how it could realistically succeed.
Re: "Hello World" in Dart, compiled to JavaScript
#56The comments on this thread are a disgrace. Read more.
Re: "Hello World" in Dart, compiled to JavaScript
#57Earlier quoted context omitted.
It's not right now. It's a lousy CoffeeScript. The thing that makes dart good is that it could, some day, have it's own runtime. Also, the language is being designed by the team that did v8. So I'd imagine they plan to build support into chrome at some point.
I agree CoffeeScript has nicer syntax, but it retains all of Javascript's semantic warts. Whatever quibbles you might have about Dart's syntax (it's young yet!) it's semantics are much nicer than Javascript.
Well, except for the unsound covariant generics, the lack of an arguments object, and the implicit downcasts, and so on...
Re: "Hello World" in Dart, compiled to JavaScript
#58Earlier quoted context omitted.
Which is a one time cost - and roughly the same you pay for including any other framework out there.
Same results: http://jsperf.com/dart-hello-world-test-with-optimize/2
Let's be realistic with ourselves here: is all that overhead ever going to compete with ten lines of "low level" (ha..) JavaScript? No.
The problem here, and what is making us chuckle so much, is that the project as presented to us is not magical. For whatever reason, some of the brightest minds in our industry have not presented us (at this time) with a cross-compiler that is both robust enough to support large apps, and intelligent enough to self-optimize its output.
Were we expecting a JavaScript killer from Google? Some of us were, with cynical apprehension. Did this release of the project live up to that expectation? Nope. Could others have done a better job? Maybe, maybe not. Could this project improve over time? Certainly. Will Dart become a JavaScript killer without more magic in its cross-compiler? Personally, I doubt it. Tooling may matter for developing large web apps, but performance matters in those large web apps too; running this test in my iPhone's browser leaves me feeling meh.
Re: "Hello World" in Dart, compiled to JavaScript
#59Earlier quoted context omitted.
Which is a one time cost - and roughly the same you pay for including any other framework out there.
Same results: http://jsperf.com/dart-hello-world-test-with-optimize/2
http://jsperf.com/dart-hello-world-test-with-optimize/5
I moved things around so that what code does is roughly equivalent. As you can see Dart is slower, but the Dart runtime does not differ by a margin that matters for many applications - and note the size of the gap differs significantly between JS engines.
Re: "Hello World" in Dart, compiled to JavaScript
#60Earlier quoted context omitted.
Same results: http://jsperf.com/dart-hello-world-test-with-optimize/2
http://jsperf.com/dart-hello-world-test-with-optimize/5 I moved things around so that what code does is roughly equivalent. As you can see Dart is slower, but the Dart runtime does not differ by a margin that matters for many applications - and note the size of the gap differs significantly between JS engines.
In all fairness, you removed the actual print function from the code. Inspection of the non-compiled source suggests that the entire function execution as shown in /2 is called for every call to Dart's print.
print$getter()(1, $noargs, 'Hello, Dart!'); print$getter()(1, $noargs, 'foo'); print$getter()(1, $noargs, 'bar');