jaysoo

Updated the post with timing numbers.

I want to note that the numbers can be deceiving though because they use different mechanisms to record elapsed time.

When I ran the same task though Unix `time` I got numbers that were much closer, although still in Gulp's favour.

Yeah I know. It was just a quick example.

It's useful for something like:

  f = (options) ->
    options.foo or= 'bar'
    # ...

I myself enjoy using CoffeeScript, but I understand it might not be for everyone.

It's always good to look at the pro/cons before choosing a language, so I think discussions like this is good.

That being said, some of the problems this article points out can be addressed by going back to more JS style.

e.g. Not relying on implicit parentheses/commas/braces

I like the "Fancy" for loop because it's closer to what I do in Python (yes I know they are not exactly the same). Same thing with the "Tricky" if statements.

Also the redefinition shortcuts provided in CoffeeScript is pretty much what I do in plain JS anyway.

e.g.

JS: foo = foo || 'bar';

CS:

  foo or= 'bar'

Is it really that strange?

Those statements are basically (as per ECMA-262 11.9.3):

0 === Number('0') 0 === Number('') '0' === ''

If this was socialism then either the government or the public would own Bell/Rogers/Telus.

This is also not free-market capitalism. I'm not sure what you would call it.

The big deal here is that instead of offering competitive plans the big ISPs are _decreasing_ the level of service and _increasing_ the prices of plans.

Also, Bell/Rogers/Telus have the advantage of offering bundles if you use them for cable/satellite+cell phone+Internet, whereas a lot of smaller ISPs would not able to do such things. This screams anti-competition.

FYI, I don't mind paying per usage as long a the rates are reasonable. How about charging us $10-15 for connection fees, and then $0.25/GB of transfer?

Not exactly the same signature, but can handle arbitrary number of calls.

var say = (function() {

    var savedArgs = [];

    return (function recurse () {

        if (arguments.length) {

            for (var i=0, arg; arg=arguments[i]; i++) {

                savedArgs.push(arg);

            }

            return recurse;

        } else {

            alert(savedArgs.join(' '));

            savedArgs = [];

        }

    });

// e.g. say('Hello')('World')('!!')();

// --> alerts "Hello World !!"

The goal could be CSRF instead of actually reading the cookies. If there's a SessionID cookie for example, you can use JS to GET/POST the request to the server without needing to know the value of SessioID because the browser will send it as part of the request anyway.

The HTTP Response Splitting vulnerability can have many implications, XSS and CSRF attacks are just some examples.

No problem. It's one of those things developers don't realize when coming from C-style languages. :)

Blocks in JavaScript do not create scopes. This is different from many other languages (like Java or C).

In fact, Crockford has mentioned this as well: http://javascript.crockford.com/code.html

"JavaScript does not have block scope, so defining variables in blocks can confuse programmers who are experienced with other C family languages."

Which is why this code works:

(function() {

    for (var i=0; i<100; i++);

    alert(i);

Notice the variable `i` is accessible from outside the for-loop.

In the case of closure, yes you will take a small performance hit. But the example given is still invalid because the only scope present is the function-scope (for-loop doesn't create new scope).

For example, if you ran the code below in FireBug you'll get the same results (minor variance aside).

function foo() { var a = 0; for (var i=0, j=a; i<10000000; i++) { var x = j+i; } }

function bar() { var a = 0; for (var i=0; i<10000000; i++) { var x = a+i; } }

(function() { var start = new Date().getTime(), end; foo(); end = new Date().getTime(); console.log(end-start); })();

(function() { var start = new Date().getTime(), end; bar(); end = new Date().getTime(); console.log(end-start); })();

> #13 In any code block, store local references to out-of-scope variables.

That doesn't even make sense. The for-loop block doesn't create a new scope, so it's perfectly valid to refer to the variable `a`. Plus, even if you create a new scope, you can still refer to `a` due to closure.