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.
I am used to writing native loops in Javascript, so taking your example I would usually write:
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:
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.