O'Reilly logo

JavaScript Cookbook by Shelley Powers

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

17.8. 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 Dojo, Prototype, or 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.

Discussion

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 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 will overwrite 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 use object literals to namespace their functionality:

var BigObject = {
   foo : function () { },
   bar : function () { }
}

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 framework and external libraries you use don’t extend existing objects via the object’s 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. In Recipe 17.7, the jQuery plug-in described in the solution provided event handler hooks you can use to provide your own functionality 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 well-tested, and provide a way to report bugs and view existing bugs. 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. Libraries that provide a subdirectory with self-tests rate high in my book.

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—or is one you can maintain on your own, if the original maintainer can no longer perform this action.

To summarize:

  • A good library does not use DOM Level 0 event handling.

  • A well-defined library uses object literals to namespace its functionality.

  • 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 hopefully provide these self-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 when it comes to using a library that requires you add a new framework, which then needs to coexist with another framework. However, most well-built framework libraries could work with others.

As an example of framework coexistence, and since I’m focusing on jQuery in this chapter, if you use jQuery, you can use another framework library, such as Prototype, MooTools, or Dojo. The use of global namespaces should prevent name clashes. The only exception to the namespace rule is the dollar sign ($), function, which is also used by Prototype. You can override the use of the $ by adding the following, after all the libraries have been loaded:

jQuery.noConflict();

Once you add this code, instead of:

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

use:

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

There are other approaches, too, including assigning a new short character replacement, but these are detailed in the jQuery documentation.

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.

See Also

The jQuery web page documenting how to use the framework with other libraries is at http://docs.jquery.com/Using_jQuery_with_Other_Libraries.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required