11–20 of 162 posts
So, something that lets people who don't understand JavaScript "compile" some other language into JavaScript, is horribly inefficient. Wow, what a surprise.
Do you mean to imply that the point of Dart is to be an easier to understand Javascript?
The result is 94% smaller - 32k, or 9k gzipped. A 32k overhead could be absorbed by most large web applications without being noticed.
http://closure-compiler.appspot.com/code/jscd4ddca10c0a518fc...
class HelloCoffeeTest
@testMain: ->
console.log "Hello, Coffee!"
HelloCoffeeTest.testMain()
var HelloCoffeeTest;
HelloCoffeeTest = (function() {
function HelloCoffeeTest() {}
HelloCoffeeTest.testMain = function() {
return console.log("Hello, Coffee!");
};
return HelloCoffeeTest;
})();
HelloCoffeeTest.testMain();I'll repeat what I said in the GitHub thread: There's this interesting tool called Google Closure Compiler. It does dead code elimination. https://gist.github.com/1277285 Notice that this source is now 2000 lines of pretty printed 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. EDIT: To be c…
I'm sorry, but 2,300 lines of code is in no way acceptable as a "dead code"-eliminated Hello World program. Not by a longshot.
I don't understand why Dart is supposed to be good, someone please explain it to me like I'm an eight-year-old
same 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…
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.
Many googlers I've spoken to firmly believe that you need a strongly typed, OO language with good tooling to be able to develop any large application. They believe web apps are no exception.
Google has worked hard adding types to javascript with the closure compiler. But, there are limits to what you can achieve using javascript.
Comfortable programming in the large is the main value proposition of Dart. Expect to see good developer tools, debuggers, profilers and server-side runtime environments for Dart appearing over the next few years.
(Disclaimer: I don't share this view)
I'll repeat what I said in the GitHub thread: There's this interesting tool called Google Closure Compiler. It does dead code elimination. https://gist.github.com/1277285 Notice that this source is now 2000 lines of pretty printed 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. EDIT: To be c…
I'm sorry, but 2,300 lines of code is in no way acceptable as a "dead code"-eliminated Hello World program. Not by a longshot.
If all you do is one DOM transformation then jquery will seem huge compared to just doing it by hand (probably hundreds or thousands of lines of code vs 3).
I guess at this point I'm just repeating the OP, but this is simply in no way demonstrative of Dart. It can at best serve as a learning tool of the internals (and perhaps there are valid criticisms once you look at those), but any conclusion on code size is very flawed from this one example.
Earlier quoted context omitted.
I'm sorry, but 2,300 lines of code is in no way acceptable as a "dead code"-eliminated Hello World program. Not by a longshot.
What language do you program in where the dependencies are not as heavy as they are here? The only difference I can tell is that it's hidden from you.