Comment by bcrescimanno | Hacker News Reader

Comment by bcrescimanno | Hacker News Reader

Parent Full thread

I find this argument totally bogus (at least, currently). 30 years ago; there were often very good reasons to write assembly over C when working on performance sensitive code. Before that, there were good reasons to write native binary for performance sensitive areas. As assemblers (and subsequently C-compilers) matured, they are often able to generate more efficient code than the vast majority of people could write by hand.

I'm not at all convinced that CoffeeScript has yet matured to the point where it can generate better javascript than any qualified JS developer. Now, it may get there some day--but I don't believe it's there yet.

Moreover, in this case, you're introducing an additional layer of complexity and source of errors--the compile time of CoffeeScript. Maybe it doesn't compile. Maybe it compiles such that the Javascript doesn't do what you intended the javascript to do. Maybe the javascript breaks in some browser environments and there's no way to cleanly work around that problem in CoffeeScript.

Again, it's not that I'm against CS--I'm simply against it being the default. It's an additional can of worms that I don't think the majority of Rails developers are ready and / or willing to open.

Actually, CoffeeScript does generate more efficient code than the vast majority of JavaScript developers write by hand -- that's one of the goals. There are a couple reasons why this is the case, for example:

Do you tend to write your "for" loops with an "each" ? If you're using "$.each", "_.each", or "[].forEach", your loops are running a good bit slower than they could be. This CoffeeScript:

    for item in list
      item.marked = true

Generates this JavaScript:

    var item, _i, _len;
    for (_i = 0, _len = list.length; _i < _len; _i++) {
      item = list[_i];
      item.marked = true;
    }

... where you have a nice length-cached loop that runs about as fast as JavaScript is capable of.

Similarly, lots of JS developers avoid using prototypes because they're such a pain in the ass to type out manually -- preferring to manufacture objects via closures instead. This has a huge runtime and memory cost. CoffeeScript's "class" keyword makes it easy to work with JS prototypes effectively, without having to type out "Klass.prototype.method = function ..." all the time.

You're using a comparison between an each method that takes a callback and for loop--that's a pretty weak comparison to draw as the implications are well-known. Moreover, in two of the 3 cases, they're library methods that aren't part of the Javascript language so the concept is a bit disingenuous. In this case, you're comparing two different types of syntactic sugar and saying that one produces better code than the other--far from making a case that for something more complicated than a single for loop, CS can produce higher quality code than an engineer writing javascript.

The point is that people writing real applications often avoid JavaScript's for-loop in favor of each-loops just because the latter are so much more readable and less bug-prone, and ease of reading the code is worth a little bit of performance in most people's minds. CoffeeScript gives you the readability without the performance tradeoff.

Yes, but many of us aren't 'Javascript engineers', we're more general developers. Learning CS and JS together has vasty improved my JS skills because every time I've gone 'why the heck did CS compile to that?' it's been because of some obscure JS idiosyncracy that would otherwise come back to bit me months or years later...

CS has immediately improved the performance of my code considerably.

Those 'each' examples aren't sugar, they're functions. They don't produce code, they are code. To make them faster, you have to use the more verbose for loops in their place.

Sure, a JS developer could write out the for loop each time, but doing so is less readable and more error prone. You could even stick with the each approach and replace with for-loops after profiling, but then you have to actually do the profiling and rewrite your code to get the benefit.

The JavaScript that gets produced by CoffeeScript is pretty predictable and way more readable than I expected it would be when I first started using CS. Once you use it for a while, you pretty much know what your underlying JS is going to look like, and if you ever do run into any truly hairy sections that just have to be JS, you can write that JS in the same file.

Just out of curiosity, do you use CoffeeScript for all your underscore.js and bakckbone.js development?

Nope. Both of those are JavaScript libraries aimed towards widespread adoption by JavaScript users, and therefore aren't written in CoffeeScript.

That said, I did port Underscore.js to CoffeeScript once, and the resulting compiled JS ran (a little bit) faster than the original version.

Why does that stop you from writing them in CoffeeScript, especially if it's faster? Because you want contributions back to the projects from JS-only developers?

Yep. I'm a pragmatist at heart. I don't think that either Underscore.js or Backbone.js would have gotten the same sort of adoption they've seen (eg. github.com/popular/watched) if they had been written in CoffeeScript. Perhaps in a year or two it would be different.

I'm not trying to settle the argument once and for all with this single analogy, I'm just saying that compiling standards-compliant code instead of writing it directly does not violate the principle of complying with standards.

Reply on news.ycombinator.com