
Javascript patterns - ekpyrotic
http://shichuan.github.io/javascript-patterns/
======
rnd33
Regarding function declarations, it considers function declarations to be an
antipattern and advises you to instead use function expressions at all times
([https://github.com/shichuan/javascript-
patterns/blob/master/...](https://github.com/shichuan/javascript-
patterns/blob/master/general-patterns/function-declarations.html)).

I'm really skeptical about this. Using function expressions has some quite
subtle consequences (hoisting, accidental/unintended closures) which you
automatically avoid when using function declarations. Function declarations
are also very useful since they allow you to use the function before it is
defined (in the code), which mean you can read the code (and use the function
name as an abstraction) without having to scroll past all function
implementations.

To expand a bit on the accidental closures part, a variable bound by a closure
is an implicit dependency of that function. By breaking function expressions
out as function declarations you can be more explicit about what kind of input
that piece of code needs from the outside. I just think overuse (nesting etc.)
of closures can lead to some quite messy code, it gets harder to reason about
when a variable was actually bound and to what.

~~~
arnorhs
Actually, the reason you can use the function at a place in code before it's
defined is actually because of variable hoisting. The name of the function is
hoisted to the beginning of the scope in which it's defined. (this may be what
you mean, but it was unclear from the comment)

But I agree that I don't think doing var func = function(){}; is in any way
better than a normal function declaration. Actually, I think it's a bit
ridiculous to even have one recommended over the other.

~~~
jbnicolai
Not just the name, the entire function declaration is hoisted. That's the
difference between:

    
    
        function () {
          ...
          var a = function () {};
        }
    

which gets hoisted to:

    
    
        function () {
          var a;
          ...
          a = function () {};
        }
    

and:

    
    
        function () {
          ...
          function a () { };
        }
    

Which gets hoisted in it's entirety to:

    
    
        function () {
          function a () { };
          ...
        }
    

Which will cause difference behaviour between the two when calling a in the
_..._ section, working in the latter case but undefined in the first.

I don't think the grandparent was unclear about this in his post though.

~~~
Zecc
And as a bonus, the latter gets its name set. Of course you could also name it
in the function expression, but then you'd just be repeating yourself.

------
simoncion
This UI is pretty terrible on somewhat small screens. Here's what it looks
like when sized to 1024x768:

[http://i.imgur.com/X78sHxx.png](http://i.imgur.com/X78sHxx.png)

Note that the links behind the blue translucent rectangle are unclickable.

~~~
voltagex_
Considered adding a Github Issue for this?
[https://github.com/shichuan/javascript-
patterns/issues](https://github.com/shichuan/javascript-patterns/issues)

(or do you mind if I add one for you?)

~~~
simoncion
Feel free to add one for me. Link to that imgur picture if you care to.
Thanks! :)

------
avodonosov
Are you really going to write "var getData = function getDataF () { };"

instead of "function getData() {}"

for pseudo benefits like

* 1. Makes it easier to understand "functions as an object". * 2. It enforces good semicolon habits. * 3. Doesn't have much of the baggage traditionally associated with functions and scope.

?

~~~
rnd33
Agreed, and what exactly is the baggage traditionally associated with
functions and scope that you avoid by using a function expression?

------
bulatb
Previous discussion:
[https://news.ycombinator.com/item?id=5392984](https://news.ycombinator.com/item?id=5392984)

This source has some problems.

------
alfl23
It's not bad, but you barely scratch the surface. Here's one:
[http://stackoverflow.com/questions/12973706/javascript-
colle...](http://stackoverflow.com/questions/12973706/javascript-
collection/12973883#12973883)

------
amckinlay
Aren't these considered "idioms"?

------
dpweb
Why call eval like this? (1, eval)('this');

~~~
dcherman
I'm pretty sure it's due to
[http://es5.github.io/#x10.4.2](http://es5.github.io/#x10.4.2) section 1A.

Calling eval like that causes it to be an indirect eval call which results in
it being executed in the global context.

------
mattparlane
Very cool. I'd recommend adding something about callbacks defined in loops,
ie:

    
    
      for (var i = 0; i < 10; i++) {
        $('.thing').click(function() {
          alert(i);
        });
      }

------
_mikz
one page PDF would be great

------
puppetmaster3
Good.

~~~
theonej
these patterns are cute. I especially like the one where for loops are
described, as if the variable declaration practices are important.

~~~
deelowe
And the recommendation to avoid i++ due to "excessive trickiness?" followed by
a recommendation to use while(i--) with i initialized somewhere else as a for
loop substitute? What the heck? That sounds terrible.

~~~
svachalek
I thought I might learn something until I saw that exact comment, then decided
it was safer to stop reading immediately.

