JavaScript library functions in global namespace - drawbacks?

Question

JS libraries like Underscore.js and LoDash.js provide functions, usually via a global object _:

_.map(...);
_.filter(...);

Such basic functions are global functions in Python and part of the standard library:

map(...)
filter(...)

If I promoted the library functions to global functions...

window.map = _.map;
window.filter = _.filter;

map(...);
filter(...);

... what downsides would there be (other than global namespace pollution)?

Do I have to expect any performance issues?

Will it lead to errors in certain browsers? (e.g. if a built-in JS function is overwritten by a library function, which in turn relies on the native function)

Will chaining still work?

Answer 1

There are multiple downsides, but performance is not likely to be one of them.

What if two libraries have a map() function and the behaviors are slightly different? If they both put their map() in the global space, you won't be able to access one of them. And you might not be able to easily know that the map() you actually want has been overwritten.

By the way, map() and filter() are part of recent-ish JS implementations, but even there, they are part of the prototype of the objects that use them. So you have Array.prototype.map() and Array.prototype.filter().

Answer 2

Here are some reasons to avoid making lots of things like map and filter be global variables:

1. Naming conflicts with other code/libraries attempting to do something similar, but incompatible. If all code is using numerous global functions, then the simple definition of a single global function could completely break your app because it would be redefining such a function used for something else somewhere else in the code. This, all by itself, is a reason to use as few globals as possible. In a team project or a project using significant third party libraries, this is impossible to manage and will inevitably lead to lost productivity or, even worse, bad bugs that might not immediately be apparent.

2. Code modules are less self describing when a symbol is just global. Hmmm, where does the symbol map() come from. Is this built in? Is it defined locally? Is it defined by some library? It's a lot easier to know where gutils.map() comes from (from the gutils module). Large numbers of global anything is just less maintainable than breaking things into well defined modules.

3. There are numerous advantages to defining functions as methods on the objects on which they operate (such as ES5 .map() and .filter() being methods on the Array object rather than as generic globals). Now, it is considered bad practice to add non-standard methods to existing built-in objects (also for naming collision reasons), but adding polyfills that implement standard behavior is encouraged.

See these references for other info:

How and Why to Avoid Globals in Javascript

I've Heard Global Variables Are Bad, What Alternative Solution Should I Use?

Essential Javascript Namespacing Patterns

Javascript Namespaces and Modules

How do I declare a namespace in JavaScript?

---

As to the topic of performance, it should not be your first concern and will likely not even be a relevant concern in most code. It is much more important to start with a robust, maintainable coding strategy and then optimize only small pieces of code where performance is critical than to sacrifice robustness at the beginning in the name of performance.

In any tight loop where performance is criticial, you can always assign any function to a local variable to slightly improve performance and this will be faster than either a module reference or a global reference (because locals are resolved before globals).

So, if you had gUtils.map() in a module and you want to maximize performance inside a particular function, you can do this:

function x() {
    var map = gUtils.map;


    for (var i = 0; i < someBigNumber; i++) {
        map(...);
    }
}

Answer 3

You don't need to worry about performance; even if you add an extra layer to a symbol lookup, most modern JS engines will alias it. Nor should you worry about augmenting native objects causing exceptions - that's allowed. No, the big issue is the namespace pollution, which you seem to be a bit dismissive of.

What happens when your code runs on a newer browser that implements these functions natively? Let's say you'd written this code in 2009, and added .map() to Array.prototype. Your code would now have some big issues if someone added a new library that expected one function signature (the native one's) and got a different one (yours).

If you must do this, at least check whether the global symbol already exists, e.g.

window.map = window.map || myLib.map;

Also, make sure that any code relying on your map implementation can either signal its dependencies to a JavaScript dependency management tool like RequireJS, or that you have a robust DM system already in place, and that your native overrides are attached before any other code executes (e.g., don't put your code in an async script tag, don't defer execution until DOMContentLoaded, etc.)

Answer 4

Consider a library like this,

_ = (function(){

   lib = {};

   lib.function1 = function(){
      //code
   };
   lib.function2 = function(){
     this.function1();
   };

   //more code

   return lib;

})();

if you use,

window.function2 = _.function2;
function2();

The library uses "this" operator in function2. Your way changes the scope of the function2 here. The function2() call will give an error saying "function1 is not defined".