>The bad performance in this article has nothing to do with callbacks, but is all about the overhead associated with function re-definition.
To the author's point, I think they're addressing a common vector of criticism with respect to JS callbacks... Usually when someone is writing their "callbacks are evil" proof, they give the typical "callback pyramid of doom" example to prove their point...the author is just showing that if you do it right and flatten your callback structure out with named functions, etc., it solves a lot of those problems.. I think the author was trying to make the point that callbacks themselves are not the problem, per se, but rather the way they are commonly (and wrongly) used.
Re:Long live the callbacks
by trevnorris on Thursday August 22, 2013 @02:13PM
(#6258898)
Thank you. Yes, that was more along the point. I just get punchy about how I say it after 3am.
Umm... every time you create a function in JavaScript, you create a closure whether you like it or not. (For "root-level" functions, you can think of the closure as being the variables which are global, i.e. belong to the window object.)
What the author really means is, don't define a function 1e6 x 1e3 times instead of just defining it once.
But that has nothing to do with nesting callbacks. In most cases, nested callbacks are only ever called once, because callbacks are being "chained" to each other.
So the performance the author is talking about has nothing to do with closures or even callbacks, but simply the overhead of re-defining functions thousands of times, which is obviously going to have much more overhead.
The right lesson is, nested callbacks are bad for readability, but in most cases have nothing to do with bad performance. The bad performance in this article has nothing to do with callbacks, but is all about the overhead associated with function re-definition.