Tuesday, January 20th, 2009

How global is your JavaScript?

Category: JavaScript, Library

Mats Bryntse “had an idea about checking the most popular javascript frameworks & APIs to see how they differ in terms of global namespace pollution. This page loads all the frameworks separately in an iframe and compares the window object against the one of a fresh iframe. I also included information about which builtin JavaScript classes have been augmented, not sure how that would be useful but it shows a difference in architectural approach between the frameworks. You can click a row to see the details about the global symbols in the framework/API.

The results vary more than I’d expected and it’s interesting to see the different namespacing strategies at play. YUI/Jquery/Ext keep the numbers down by putting everything in one global object. It seems like Microsoft is using their own kind of namespacing using the $ sign as a namespace delimiter rather than using real object properties as the rest of the frameworks do.”

You can check this out via his checker page. An interesting read and you can narrow in on APIs of your choice.

We like to talk about how evil global variables are, but I wonder if we take this a touch too seriously sometimes. Sure there can be collisions and the like, but a lot of projects are doing just fine :)

Posted by Dion Almaer at 8:33 am
20 Comments

++++-
4.3 rating from 40 votes

20 Comments »

Comments feed TrackBack URI

Nice work but I just discovered that “crypto” and “event” objects are common for each item. So they shouldn’t be counted as globals.

Comment by sekostar — January 20, 2009

Rather than just concentrating on globals, you should consider the augments column too.

The more augments a library does, the less likely it’s to play nice with other libraries!

Comment by Jani — January 20, 2009

@sekostar: Using Chrome/Safari? Try using FF3, data should be correct. I don’t know why the results are different in your browser… Any idea?

Comment by mankz — January 20, 2009

I put everything into a single object. It’s easy to do. I can’t think of a good reason not to.

Comment by Nosredna — January 20, 2009

I agree, namespacing is the way to go, besides I hate those reallyLongMethodAndPropertyNames()

Comment by RyanMorr — January 20, 2009

LM Framework [http://lmframework.com] also uses a single global object.

This is by far the cleanest approach, and has the added advantage of allowing the entire system state to be xmlHTTP’d back to the server for debugging.

Comment by hymanroth — January 20, 2009

The projects may be doing fine, but global pollution represents a growing environmental problem. If you use only one monolithic library, or a small number of them, it probably won’t be a problem, but as the Javascript code base grows, the chances of a nasty surprise bug that ordinary non-JS ninjas will have to deal with increases.

If Javascript advocates really want it to become a serious language, even on the server, and compete directly with Ruby, Python, Java, et al, they’re going to have to get more rigorous and serious about packaging/namespacing. Javascript desperately needs a standard “non-roll-your-own” package/module system.

Comment by cromwellian — January 20, 2009

I thought that this would show only window[…], but it seems it even returns Native methods that are added to prototypes, or generics Array.xxx.

In my opinion, that is not indicative of global space contamination.

Comment by ibolmo — January 20, 2009

Nevermind, just noticed the “augment..”. ;)

Comment by ibolmo — January 20, 2009

“Augmented” makes me at least as nervous as “Globals.” A big old “boo” to MooTools, Prototype, and Microsoft.

Comment by Nosredna — January 20, 2009

I for one am not surprised to see the .NET Ajax library leading the pack. It is coded SO badly (unfortunately the ‘lead’ developer at work refuses to use anything else) and is a pain in the ass to use.
__doPostBack() and Microsoft’s single form element on a page philosophy needs to die a slow and painful death. As do the developers that advocate it.

No surprises to see jQuery, Dojo, Ext up there with low usage of global variables. Makes a difference when the coders know what they are doing.

Comment by scoult01 — January 20, 2009

Eh.. not as much as you’d think. But it is a form of contamination, so no argument here. It’s the good kind of contamination though :).

Comment by ibolmo — January 20, 2009

“We like to talk about how evil global variables are, but I wonder if we take this a touch too seriously sometimes.”

.

I think is worth taking seriously because once a reasonable solution to the problem is taken, the problem is over and the chance of a namespace collision is virtually naught.

.

With regard to namespacing, I think there is no difference between creating a “global variable” and “augmenting”. When creating a global variables, the program is adding a property to the “window” object. When augmenting the program is adding an object to “String.prototype”, for example. What is the difference? Both “window” and “String.prototype” are public objects to which the program is allowed to add properties. Both ways are really augmenting.

.

What is potentially bad is when a program adds “String.prototype.trim” which could easily collide with another library. Instead, if the program added “String.prototype.com_ajaxian_trim” then the chance of a namespace collision is slim. The important part is something reasonably unique is in the property name. Sensibly named properties when augmenting gives good collision protection.

.

Placing all of a library in one global object which is reasonably unique provides namespace protection but gives up other features of the language that can be gained through augmenting.

.

The $ character in property names certainly is not “reasonably unique”. Even “MS_” or “BillyG_” would have been much better protection and are not so long. With a good editor even a long string is only a couple keystrokes away.

Comment by PeterMichaux — January 21, 2009

Global pollution should be a carefully balanced trade-off. Too much or too little of something is not good. Sensible amounts of global pollution can actually increase performance.

Think about the global scope as computer RAM, and namespaces as virtual memory (that exists on the hard disk).

If a function is called repeatedly, putting it in RAM (global scope) makes it quickly accessible. Hiding it behind a namespace makes it take longer to access (to resolve the namespace links). If a function is seldom called, putting it in virtual memory frees the RAM and allows other existing functions in RAM to be called faster.

Programmers should exercise discretion in choosing where to put their functions.

Comment by Jordan1 — January 21, 2009

I updated the tool with a conflict matrix between the frameworks.

Grrrrreat enjoy!

Comment by mankz — January 21, 2009

Nobody seems to talk about collisions in the CSS namespace. CSS basically only has one global namespace and it’s really easy to create selectors that collide with or clobber some 3rd party component you’ve decided to use.

Example:

Designers like to use the name “wrap” for some reason, and it wouldn’t surprise me in the least if toolkits used the same name/id in autogenerated DOM elements.

Comment by mschwartz — January 21, 2009

Note in the above:
example:
<div class=”wrap”>…</div>

Comment by mschwartz — January 21, 2009

Jordan1,

Have you actually tested that? A global is still part of window. has anyone done a test to see how slow it is to access a variable inside an object? Possibly, it’s even faster, since the list of things to check would be smaller. If everyone polluted, the number of objects under “window” could be huge and slow everything down. All depends on the implementation, and could easily be different on different browsers.

Comment by Nosredna — January 21, 2009

mschwartz, Where I work, we namespace CSS by using a prefix like “CO_” so we would have “CO_wrapper”, “CO_header”, etc.

Comment by PeterMichaux — January 22, 2009

The interesting thing here is it says MochiKit has 243 globals, which isn’t the whole story because it actually uses an export system so you don’t have to have anything except for MochiKit in the global namespace at any one time.

Besides that you can code your entire application with those symbols exported, and then restore them to their previous values after your library is compiled.

Comment by jhuni — October 8, 2009

Leave a comment

You must be logged in to post a comment.