Real-World JavaScript Anti-Patterns

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&#x27;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 &#x2F; MVC &#x2F; object oriented? Prototypical? This article lacks clarity and draws no useful conclusions.<p>&quot;so one obvious improvement would be to use selectors instead of the execrable DOM API&quot;<p>Additionally, DOM API is slow. Wrapping your access to the DOM in additional layers of abstraction isn&#x27;t a win or &quot;anti pattern&quot;. It&#x27;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 &quot;How do I accomplish my goal by using Angular&#x27;s API (as opposed to jQuery)?&quot;.<p>With React, since my &quot;markup&quot; and code is all just Javascript the common theme has become &quot;How do I accomplish my goal in plain old Javascript?&quot;. The skills I&#x27;ve been picking up are definitely transferable to projects that don&#x27;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 &quot;obviously&quot; 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 &lt; elems.length; i++) { elems[i].addEventListener(&quot;click&quot;, 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&#x27;t : _.partial(_.merge, {}).apply(this, confs); Be the same as: _.merge.bind(_, {}).apply(_, confs);<p>That being said, I&#x27;m glad this forced me to look up _.partial - seems like you can pass &#x27;_&#x27; as a parameter and that position in the arguments will not be bound in the partial function!

They should mention that most of the functions they use and recommend using don&#x27;t exist in IE8 and crappier.

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&#x27;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 &quot;anti-pattern&quot; doesn&#x27;t mean &quot;you typed more than you really needed to&quot;. Rather simple tools can fix that sort of thing.

Using &quot;this&quot; is already an anti-pattern.