I don t think there is anything wrong using separate functions, depending on the purpose. For a setup function or onReady functions I will like anonymous functions, for callback functions that are really small piece of code like 1 or 2 simple line I will use anonymous functions. For callbacks I often like to use a separate function however, I find it easier to read and especially with most frameworks giving an easy way to pass parameters to the callbacks when making XHR.

However, one advantage nested anonymous functions gives you is the closures around variables that sometimes you might end up needing to pass as parameters if you separate the function.

It is a very tough question to answer because it will be a question of style, performance, purpose that will be different depending what is the purpose of the code you re writing.

I use both ways all the time without thinking too much about what is better. And I believe that in terms of performance if you are worried about a mobile device download time or parsing time then you will end up using some JS Minifier (or maybe Google s Closure Compiler).

Anyway, I do have a criteria that seems helpful to me to decide whether the function should be anonymous or not:

If I had a really good name for the function then it shouldn t be anonymous

What I mean is if your function will be named onSetupReady then the function is not explaining what it does, instead, its name is defining where it should be used (and that would usually be one only place which will call that function). So if that is the case then you can choose to make the function anonymous or not. I usually choose anonymous.

But, if your functions does one just one thing, and that thing in not really obvious, and you are tempted to put a single line comment in the first line of the function (or whatever) to explain what it does. then I won t do that, and I would choose a good name for this function. And I emphasize this rule, even more, when the event which triggers this function is not obvious for that function. Examples:

Anonymous OK

Ext.Window({
    listernes: { 
        beforeclose: function() {  // This function has only one purpose and
            Ext.Msg.show({         // can be named, but I think it s OK. Because
                title: Close? ,    // it is really easy to see what it does.
                msg:  Are you sure? ,
                fn: function(btn) {
                    if (btn ===  cancel ) {
                        return false;
                    }
                },
                animEl:  elId ,
                icon: Ext.MessageBox.QUESTION
            });
        }
    }
}).show();

Anonymous NOT Recommended

var insertExtraToolbar = function() {
    var containerNbar = theGrid.getBottomToolbar().getEl().parent().dom;
    theGrid.elements +=  ,nbar ;
    theGrid.createElement( nbar , containerNbar);
};
theGrid.on( render , insertExtraToolbar);

I used to have the same feelings you did when I first started encountering nested anonymous functions.

Now that I ve gotten much more used to them I actually find nested anonymous functions much easier to read as long as they re only used in one spot. When code is written that way, all the code I m interested in is in a single spot and I don t have to jump around the file nearly as much to figure out what the code is trying to do.

Keep in mind, though, that my opinion only applies if the code is only used in one location. If you keep repeating the same anonymous function in multiple places...I still prefer to break it out like your second example.

In a way, you may have answered your own question. The OnReady function is only run once. for maintainability, it might be a good idea to separate out your code so that you have a section for layout, a section for events, and a section for business logic in your code.

One thing to consider perhaps is that Sencha Touch is geared towards mobile devices that may sometimes have limited resources for you to work with. With that in mind, it might be necessary to structure your code to make it as small and efficient as possible. Your proposed code snippet may be ignoring those constraints that mobile platforms have to deal with.