Comment by _urga | Hacker News Reader

Comment by _urga | Hacker News Reader

I have used Javascript exclusively on client and server since late 2008. First Rhino and then Node. Before that I used Rails.

I can understand the syntax gripes that some people have towards Javascript but I think this has more to do with a Ruby notion of "elegance" coupled with a lack of familiarity with Javascript then it does with actual issues with Javascript. In fact, I prefer Javascript to Ruby.

I have gone the whole way with Prototype and then the whole way back. These days I prefer using just 20 or so functional DOM helpers rather than Prototype's Element extensions or JQuery's wrappers. A handful of DOM functions are significantly faster. As a result I have found it useful to keep third party dependencies to a minimum. A minimum of zero is working well for me so far. Writing raw Javascript is refreshing, even if it means a "prototype" here or there. I have written many "var" statements and have yet to see an undeclared variable pollute the global scope. I write for loops often. Sometimes I use forEach or reverse while loops. I don't seen any need for Coffeescript enumerators.

I keep checking up on Coffeescript from time to time but I prefer the explicit syntax of Javascript. After spending hours refactoring code the Rails way, I have come to prefer code that's big-O efficient, as fast as possible, as direct as possible, and if it takes a few lines less that's great.

You may have been misinformed -- the values of direct, raw, fast code are a big part of the reason why CoffeeScript works the way it does, and why many scripts can end up running faster after getting ported to CoffeeScript. The golden rule of CoffeeScript is to avoid adding any library code to the runtime, and to avoid introducing any special calls, to the greatest extent possible.

Many folks rely on a "forEach" (or "each") iterator for all of their loops over arrays, because it's convenient. Unfortunately, it's also a very slow way to write an inner loop. CoffeeScript's comprehensions expand into regular JS loops over arrays and objects, so you get native speed, without the hassle. This:

    for item in list
      sum += item.amount

Compiles into this JavaScript:

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

I'd write that snippet the following way:

    for (var i = 0, ii = list.length; i < ii; i++) {
        sum += list[i].amount;
    }

Or:

    for (var i = 0, ii = list.length; i < ii; i++)
        sum += list[i].amount;

There are ways to make normal JavaScript not look ugly ;)

EDIT: fixed minor oversight

The small bug in your code actually makes a good case for using the more concise syntax of coffeescript to help avoid those kinds of errors, while generating code that's just as efficient.

I disagree. In a real programming environment I'd notice immediately after running the code.

Where are you setting `item` here?

And I'd write

    for i in [0...list.length] by 1
      sum += list[i].amount

to get equivalent compiled output.

I've used C and Java since high school, but I'm happy to be rid of that old `for` syntax. And I love that curly braces means only one thing in CoffeeScript: "I'm defining a new object with these key-value pairs."

Yah but your example for Javascript uses some dubious code. Did you know that "for .. in" loops are also native to Javascript? Why not use one for JS, why only Coffeescript? Also, it seems like you are doing some useless variable declrations.

Let me rewrite it for you: 1)

var list = [{amount:2}, {amount:5}], i, sum = 0;

for (i = 0; i < list.length; i++) { sum += list[i].amount; }

console.log(sum);

2) Or let's go even more simple...

var list = [{amount:2}, {amount:5}], i, sum = 0;

for (i in list) { sum += list[i].amount; }

Personally, i don't find anything difficult about that.. Actually looks incredibly simple. What are you actually saving by using Coffeescript...? Some brackets, parens and a semi-colon? I don't know, those are just second nature for me. I've never really stopped and thought, "wow, if only I didn't have to type these extra parens, this is really killing me..."

Not once.

JavaScript's for-in construct is not the same as iterating through all elements in the array as it will enumerate over all of the object's properties (see here: http://stackoverflow.com/questions/500504/javascript-for-in-...)

The other "complexities" in the compiled JavaScript are there for perf reasons (not accessing the "length" properties in the condition portion of the for loop, for example).

Your comment underlies why some users find CoffeeScript useful in dealing with some of the idiosyncrasies and performance minutiae associated with JavaScript.

Right, for..in is not the same as iterating through all elements in an array. Understood. But it works excellent in the example the OP created and in my follow-up example.

And I agree that accessing the length property in the conditional is not ideal.

I guess it comes down to this for me: I don't feel that Javascript has an unduly burdensome list of common idiosyncrasies to justify developing in a 'different language'/syntax that compiles into javascript and changing my development workflow to reap said questionably useful benefits.

Perhaps I am simply not the intended audience.

if order does not matter:

var sum=0,i=list.length; while(i--) sum += list[i].amount;

if it does: var sum=0,i=0,ln=list.length; while (ln-- && (sum += list[i++].amount));

but the for in syntax is nicer indeed.

I mean "direct" as in as few abstractions as possible, and "raw" as in as close to the metal as possible.

I am used to writing native loops in Javascript, so taking your example I would usually write:

  var length = list.length;
  while (length--) sum += list[length].amount;

Here, the hand-tuned Javascript is 38% smaller than the compiled CoffeeScript, albeit a few more characters to type than the source CoffeeScript. The reverse while loop is also slightly faster to execute than the for loop in the compiled CoffeeScript.

And I know that forEach loops incur additional overhead so I use them when it's convenient, when the arrays are small. I don't need to compile my Javascript just to keep from accidentally using forEach in situations where native loops would be better. I usually try to think about these things when I code and I enjoy being able to decide when to use a forEach loop, when to use a reverse while or a vanilla for loop etc. Sometimes, it's good to be specific in how you write code.

Furthermore, I would write for loops more succinctly than the compiled CoffeeScript in your example. You can use a for loop to declare the "item", "_i" and "_len" variables inside the loop itself without writing them twice. There's no need for the temporary item variable and the for loop is then short enough to be on one line:

  for (var _i = 0, _len = list.length; _i < _len; _i++) sum += list[_i].amount;

Here, the hand-tuned Javascript is 32% smaller than the compiled CoffeeScript.

I don't mind typing a few more characters if it means I can get closer to the code and serve smaller, faster code to users (or servers). If it means just one less deployment step, or one less 3rd party dependency, or one less leaky abstraction, it's worth it. I think this proves true in the cases above, where CoffeeScript certainly makes the compiled code longer, slower than it needs to be.

Reply on news.ycombinator.com