Safely Combining Several Libraries in Your
Applications

Problem

You want to incorporate more than one external library, as well as your own, into one
application without each stepping all over the others.

Solution

The safest approach for using multiple libraries is to pick ones that are all based on the
same framework, such as using only libraries based on jQuery, the framework used in
earlier recipes.

If that strategy doesn’t work, make sure the libraries all use good programming practices,
and none are overriding functionality or event handling provided by the others.

EXPLAIN

Regardless of library purpose, there are fundamental rules governing the behavior of
libraries that must be followed. Well-designed libraries do not do things like this:

window.onload=function() {...}

I use the DOM Level 0 window.onload event handler with some of the examples in the
book because it’s quick, simple, and doesn’t add a lot of code to the sample.

However, if
you have one library that uses the old DOM Level 0 event handling, it overwrites the
event capturing utilized by the other libraries and your own application.

Well-designed libraries
don’t use DOM Level 0 event handling. Well-designed libraries also namespace
all of their functionality. You won’t find the following in a well-defined library:

function foo() { ... }
function bar() { ... }

Each function like this ends up in the global space, which increases the likelihood of
clashes with other libraries, and your own applications. Well-designed libraries typically
use an anonymous function, ensuring no clash with whatever is exposed to the global
space:

A library that plays well with other libraries and applications will not extend existing
objects via the prototype object. Yes, I know it’s a wonderful way of extending objects,
and fundamental to JavaScript, but you can’t control one library from overriding another
if both are extending the prototype property for the same object.

Besides, if the frame‐
work and external libraries you use don’t extend existing objects via the prototype, this
leaves you free to play in your application.
Come to that, library builders should never assume that their library is the only one
used in a project.

Well-designed libraries provide event hooks so that you can hook into the library at the
points where it performs a major action. the jQuery plug-in described
in the solution provided event handler hooks you can use to provide your own func‐
tionality before or after the plug-in’s validation routine.

Well-designed libraries provide good documentation of all of the publicly exposed bits,
including methods, properties, and events. You shouldn’t have to guess how to use the
library, or examine minute portions of the code, in order to figure out what you need
to do.

Well-designed libraries are thoroughly tested, and provide a way to report bugs and
view existing bugs. Test code should be accessible wherever it’s hosted. If there’s a major
security problem with an existing library, you need to know about it. If there are minor
bugs, you need to know about these, too.

Well-designed libraries provide nonminified, original source code. This isn’t essential
—just helpful, and something I look for in a library.
It goes without saying that a good library is one actively maintained, but it can’t hurt to
repeat this assertion.

An even better library is one that’s open sourced, and maintained
by a community of users, who hopefully play well together—or is one you can maintain
on your own, if the original maintainer can no longer do so.
To summarize:

• A good library does not use DOM Level 0 event handling.
• A well-defined library uses an anonymous function to wrap its functionality and
doesn’t pollute the global namespace.
• A well-defined library introduces few global objects.
• Libraries that play well with others provide event hooks. Well-behaved libraries also
don’t extend existing objects via the prototype property.
• Solid libraries are well-tested, and provide these tests as deliverables.
• Stable libraries are actively maintained, and preferably, open sourced.
• Secure libraries provide documentation of known bugs and problems, and a way
to report on any bugs and problems you find.
• Usable libraries are well-documented. Bandwidth-friendly libraries are optimized
and compressed, though you can always compress the library yourself.
• Confident libraries aren’t built on the assumption that no other library will be used.

For the most part, you should be able to find what you need and have it work with your
preferred framework. Be cautious if a library requires you to add a new framework, that
needs to coexist with another framework. However, most well-built framework libraries
could work with others.

As an example of framework coexistence, if you use jQuery, you can use another frame‐
work library, such as Underscore or Mootools. The use of global namespaces should
prevent name clashes. The only exception to the namespace rule is the dollar sign ($)
function, which can be used in other libraries.

You can override the $ by adding the
following, after all the libraries have been loaded:

var $j = jQuery.noConflict();

Once you add this code, instead of:

$("#elem").fadeOut('slow');

use :

$j("#elem").fadeOut('slow');

You can use most well-made framework libraries together, but there is tremendous
overlap in functionality between the libraries, and this overlap in functionality comes
with a cost: bandwidth to download the libraries.

Try to avoid using more than one
framework library at a time. Find the one you like, and be prepared to commit to it for
some time to come.