I disagree on<p><pre><code> items.forEach(function(item) {
doSomething(item);
});
</code></pre>
being an anti pattern. Many of these looping functions actually pass more than one argument to the callback, so writing<p><pre><code> items.forEach(doSomething);
</code></pre>
will break if doSomething is a function with optional arguments.
I'm not a Javascript developer, but I sort of disagree with the point about forEach and thisArg. Using a closure like that is clearer than relying on some custom magic done by a certain function.<p>Function.prototype.bind() makes sense, though.
Anti patterns? To what specific style of development? Imperative programming? functional? Class based / MVC / object oriented? Prototypical? This article lacks clarity and draws no useful conclusions.<p>"so one obvious improvement would be to use selectors instead of the execrable DOM API"<p>Additionally, DOM API is slow. Wrapping your access to the DOM in additional layers of abstraction isn't a win or "anti pattern". It's a maintenance trade off.
I just realized how I learned to put to good use many of the above stuff when using React. When I used to use Angular a common theme when I was writing my code was "How do I accomplish my goal by using Angular's API (as opposed to jQuery)?".<p>With React, since my "markup" and code is all just Javascript the common theme has become "How do I accomplish my goal in plain old Javascript?". The skills I've been picking up are definitely transferable to projects that don't use React or any other JS library.<p>Though I do keep forgetting to add `.bind(this)` all the time that it makes me miss using `var self = this;`.
While I agree with most of the points he listed, I have an issue with the style on which he presented them: In almost all cases, he presented the wrong solution, followed by an alternative which is "obviously" better - without explaining <i>why</i> it is better. The map-with-side-effects example is even worse, performance-wise than the original. Of course, performance tradeoffs of this kind are usually acceptable, but you usually want to know what you get in return. Especially in the for-each examples, this is not clear at all.
His second bind example is incorrect.<p><pre><code> function handleClick(i) {
this.innerHTML = i;
}
for (i = 0; i < elems.length; i++) {
elems[i].addEventListener("click", handleClick.bind(this, i));
}
</code></pre>
In the for loop, the <i>this</i> value refers to the global object. To get the desired effect, it should be changed to elems[i] (this piece of code is trying to bind a handler to an element).
I was wondering why the author mentioned _.partial after a sections about Function.prototype.bind. Wouldn't :
_.partial(_.merge, {}).apply(this, confs);
Be the same as:
_.merge.bind(_, {}).apply(_, confs);<p>That being said, I'm glad this forced me to look up _.partial - seems like you can pass '_' as a parameter and that position in the arguments will not be bound in the partial function!
Some of these are good. Others, such as using .bind() just to create a handler for the click() event, are terrible. Not only are you creating a NEW closure every time the code runs (via executing .bind) but also you lose th ability to use the actual <i>this</i> inside the handler! Much better to use closures as they were intended, and have that extra _this var to refer to the previous context if necessary.
I disagree with the MyButton.prototype.new example - it isn't difficult to see that it is an api, and usage of new to do something like button.new() makes for very readable code.
There is good stuff here, but "anti-pattern" doesn't mean "you typed more than you really needed to". Rather simple tools can fix that sort of thing.