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.

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.

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.

Grrrrreat enjoy!

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.

.

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.

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.

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

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.

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.

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