Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
Ben Nadel at Scotch On The Rocks (SOTR) 2011 (Edinburgh) with: Paul Klinkenberg
Ben Nadel at Scotch On The Rocks (SOTR) 2011 (Edinburgh) with: Paul Klinkenberg@frinky )

Using Named Callback Functions In Javascript Methods

By Ben Nadel on

After learning that I could use named functions within self-executing function blocks in Javascript, I was curious to see how else named functions might be used. For instance, can they be used in the creation of closures? Closures in Javascript are simply awesome. We use them all the time - probably way more than we are even conscious of; just think about how many times we pass around event handler callbacks and iteration callbacks in jQuery. Typically, closures are created with anonymous functions; but, can they be created with named functions? And if so, what kind of scoping do they have?

To test this, I created a demo using Javascript's String Replace() method. In addition to simple string replace functionality, the String.replace() method also allows us to use a callback handler in order to provide the iteration's replace logic. Typically, I use an anonymous function in this situation; but this time, I am using a named function:

  • <!DOCTYPE html>
  • <html>
  • <head>
  • <title>Named Callback Functions In Javascript</title>
  • <script type="text/javascript">
  • // Create a character string to test with.
  • var data = "hello world";
  • // Now, replace the vowels in the string with stars.
  • // Notice that the callback used in the replace function
  • // is being defined as a named-function.
  • var noVowelData = data.replace(
  • new RegExp( "[aieou]", "gi" ),
  • function replaceLogic( $0 ){
  • return( "*" );
  • }
  • );
  • // Log results.
  • console.log( noVowelData );
  • // Log the named function defined in the replace() method.
  • console.log( replaceLogic );
  • </script>
  • </head>
  • <body>
  • <!-- Intentionally left blank. -->
  • </body>
  • </html>

As you can see here, I have passed the named function, replaceLogic(), into the replace() method. The logic of the replaceLogic() function is such that it replaces incoming vowels with the "*" character. Once the replace method has executed, I am logging both the resultant string and the named-callback reference to the console. Here is the console output that I get:

h*ll* w*rld
replaceLogic is not defined

As you can see, Javascript's String replace() method was able to execute successfully using the named callback. However, as you can also see from the second line of the console output, the named callback was not bound to the calling context. From further logging (not shown), it appears that the replaceLogic variable is only available to the local execution of the replace function (such that it might be called recursively - not that that would be of any value to us in this particular situation).

I had no idea that it was valid to use named functions in this context, or in the self-executing function block context; however, I kind of like it. I don't know if I can see the best use-cases for it just yet but, it never hurts to have a few more tools in the toolbox.

NOTE: Regarding my intro, I think self-executing functions might create closures as well.

Reader Comments


Wow - that's a beasty article. I read about half of it (more than my brain can handle tonight). I never really though of a difference between function declarations and function expressions (and how they differ in behavior). Thanks for pointing this out.

Hi Ben,

Nice post!

I've got this scenario mentally classified as "an anonymous function which has a name" (not that my definition is good, but I'm not sure if there is a good name out there for this type of function declaration).

In this scenario I believe that you can only use the name inside of the function itself. This is a definitive distinction when compared to "normal" named functions.

I haven't found any great use cases for this yet. For recursion I'm thinking argument.callee is gonna cover the use case.

Regardless - my brain now hurts just a little. Thanks for that!



I had never really thought to use this technique for recursion as Ben pointed out, and there are plenty of other ways to accomplish recursion without needing to use named expressions. Still, it is interesting to consider.

The main use case I had for experimenting with them was in debugging and building a logger object. Having named functions and expressions produces much nicer stack traces, and the logger can actually output the name of the function it was in.

But in the end, I've resigned myself to not using this technique, as it isn't fully cross-browser compatible.



Yeah, it's definitely an interesting thing, right? After reading the article that Nick posted, I think what's going on is that the function here, although it has a name, is a function "expression", not a function "declaration". As such, it is only available in that expression (unlike a function declaration which is actually pre-"compiled" so to speak). Very interesting stuff!

As far as using arguments.callee, the only "concern" there is that it is a deprecated approach. What does that mean? Probably nothing.


Yeah, from what Ben Alman was saying in my other post, this is not a fully cross-browser compatible feature. Although, Alman did seem to imply that the issue was mostly with one particular mobile device.