Smarter function-passed-to-function heuristics?

[Nolan Lawson]

Good candidates for wrapping:

• forEach(function() {})
• map(function() {})
• then(function() {})
• UMD/Browserify/Webpack definitions

Less-good candidates:

• addEventListener('foo', function() {})
• on('foo', function() {})
• once('foo', function() {})
• catch('foo', function() {}) (maybe?)

We can check for the function name as a hint to avoid the paren-wrapping, but it ought to be justified by a benchmark. Maybe a UI library that adds a lot of event listeners would be a good test case for this.

[Nolan Lawson]

Another potential improvement: only apply the function-passed-to-function heuristic at the top level, because that's usually where we find large IIFEs-that-don't-look-like-IIFEs.

[Kris Selden]

@nolanlawson define( in an app should not be made eager or the app is likely to get slower.

[Nolan Lawson]

I thought in RequireJS the defined module is executed immediately? needs to check RequireJS output

[Kris Selden]

It is executed when it is required and only if it is required. Unfortunately our app defines a lot of modules that it does not use right away and some that it does.

[Kris Selden]

define is both the best candidate and worse but needs to know what the core modules of an app are, what gets used by most routes/states of the app. The focus of this has been libraries, which is a good place to start, in our app it would likely give it a decent boost but only if applied to some of our defines.