Hacker News new | comments | show | ask | jobs | submit login

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 HelloCoffeeTest;
    })();

    HelloCoffeeTest.testMain();



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.


> I could try Dart, which will cost me a significant amount of performance in all browsers that aren't Chrome

But will it, though? Sure, "Hello, World" transpiles to 17,000 lines of code, but I'd want to see some actual benchmarks of actual code to see what kind of performance hit that implies, before deciding against Dart on that basis.

And then there's the whole python argument about developer time being more valuable, and most applications these days not being performance constrained, etc, that could possibly apply here, as well.


Anything happening in a client browser will involve a significant amount of IO - querying / modifying DOM and remote requests. I don't think that choosing Dart over CoffeeScript is going to make much of a difference for most applications.

See Objective-J / Cappuccino which chose to eat the very real overhead messaging in order to gain expressiveness. How many JS apps are as responsive / elegant as 280 North Slides?


I'm referring mainly to the page load time increase, which is important, especially on mobile. (Given what I've seen of the generated code, I suspect runtime performance will be affected too, but I haven't tested, so I can't say for sure.) This is why people create microframeworks—the page load time improvement with e.g. zepto over jQuery is not insignificant.


> synaptic sugar

Is this a typo, tongue-in-cheek, or a technical term I don't know? I've only heard of "syntactic sugar" myself.


Dopamine is synaptic sugar.


Dopamine isn't a sugar - it contains Nitrogen.


I think he means sugar in the metaphorical sense


I know - couldn't resist though :)


> 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.

I think you are correct here. But there is still something very worrying about what Dart compiles into. It isn't just the amount of code, which is what most people are discussing. It's the content too.

The content of the code makes it look like much of that code will be run all the time. In other words, it isn't just some library functions that are called rarely, it is stuff that will end up being called from your inner loops. I might be wrong here, but that's what the code suggests to me.

In that respect, the Dart compiler looks different from both CoffeeScript and Emscripten. CoffeeScript by design compiles into straightforward JS, and Emscripten manages to compile into mostly-straightforward JS as well, which is why it has decent performance. But what Dart compiles into looks like it would not run very fast on most JS engines. It might run fast on Chrome, if they tune its inlining and other capabilities for Dart-like code, but I doubt that would hold anywhere else.

Again, though, I have not profiled the generated code, I just took a look at it, so I might be wrong.


Does CoffeeScript have all these data structures, http://www.dartlang.org/docs/api/index.html?


That's a long list, so probably not. Does Dart have an existential operator?[0]

    zip = lottery.drawWinner?().address?.zipcode
Hey look, I know they're not really comparable. They're solving different problems, are at different stages in maturity and have a different philosophy on how to do things. I also think that Hello World is probably the worst way to compare any two languages, but it's a fun exercise anyway

[0] example code from http://jashkenas.github.com/coffee-script


You can always import JS.Class: http://jsclass.jcoglan.com/


Which is > 300K before minification.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: