Playing nice with others in javascript

Andrew Dupont has written a very interesting article on Prototype, and the recent $() extensions that allow things like $(someelement).hide() and so on.

This is actually a really nice solution. It's syntactical sugar without actually extending the element itself. Andrew argues that as an object oriented language, its reasonable to want to be able to extend objects like HTMLElement in javascript. I know where he's coming from, but out in the wild - in a world where my code has to co-exist with that of other authors (co-workers, customers, and potentially end-users via GreaseMonkey and similar) these core objects and data-types are a shared property and not to be taking liberties with.

A portal is the extreme case, where the portal framework ("style") has its client-side scripts, and included portlets can have their scripts. Portlets might be by the same author or vendor as the portal, or not. The potential for collision and overlapping is huge. This is made worse when you consider that portlets using the same libraries might co-exist on the same page; do we download Prototype.js twice? What if the portlet code was developed against a different version of the same library? And finally, to make a difficult problem basically impossible, its theoretically possible (I gather) to place the exact same portlet (id and all) twice on the same page.

Much of this is just hypothetical. In practice the portal owner has to take some responsibility for what goes on a page, and should enforce some basic conditions like requiring portlets to not tromp around in the window object and global namespace (and not mess with the fundamental data types that other scripts have to share). And in truth - how much scripting is really necessary on these kinds of portal pages? Most functionality will be a click away when the user actually selects a link from the portal and goes there. But there are some interesting use cases where you'd legitimately want to bubble up richer interactions to the aggregated portal page: how about client-side form validation, tooltips, context-menus, productivity (e.g. select all/none) controls.

The Dojo Toolkit goes some way to addressing these issues. It minimizes its footprint in the global namespace - with just the dojo object itself, and a djConfig object. It also has checks in place to safeguard against the unexpected properties of objects that can show up when the core data type object prototypes have been extended (such as Array, Object, Function).

Note, none of this is new or unique to Ajax and the wave of more responsive UI we're seeing recently. The issue existed long before in even the simplest client-side scripting, as well as CSS (most pronouncedly when a stylesheet defines styles directly on an element such as P, TD, UL etc.) The advent of richer browser-based UI does quickly bring the problem to the fore though...