Question: Coming from Java, I'm wondering if a Java best practice applies to JavaScript.

In Java, there's a separation of interface and implementation, and mixing them up is considered a bad practice. By the same token, it is recommended to hide implementation details of your library from end developers.

For example, log4J is one of the most popular logging libraries out there but it is recommended to write code to the slf4j library or the Commons Logging library that "wraps" log4j. This way, if you choose to switch to another logging framework such as logback, you can do so without changing your code. Another reason is that you, as a user of a logging library, how logging is done is none of your concern, as long as you know what logging does.

So back to JavaScript, most non-trivial web applications have their own custom JavaScript libraries, many of which use open source libraries such as jQuery and dojo. If a custom library depends on, say jQuery, not as an extension, but as implementation, do you see the need to add another layer that wraps jQuery and makes it transparent to the rest of JavaScript code?

For example, if you have the foo library that contains all your custom, front-end logic, you'd introduce the bar library that just wraps jQuery. This way, your foo library would use the bar library for jQuery functions, but it is totally oblivious to jQuery. In theory, you could switch to other libraries such as dojo and google web toolkit without having a big impact on the foo library.

Do you see any practical value in this? Overkill?

Answer: 
There are good arguments calling this development practice - wrapping in order to switch later - into question in any language.

A good quote by Oren Eini, from his [writeup on wrapping ORMs](http://ayende.com/Blog/archive/2010/07/30/the-false-myth-of-encapsulating-data-access-in-the-dal.aspx):

> 
> Trying to encapsulate to make things
>  easier to work with, great. Trying to
>  encapsulate so that you can switch
>  OR/Ms? Won’t work, will be costly and
>  painful.
> 
> 
>
I've done this before, and can talk a bit about the experience of writing a library/toolkit wrapper. 

The plan was to move from Prototype to some other library. Dojo was the first choice, but at the time I wasn't sure whether that's the library to move everything to (and by everything I mean ~5MB of Prototype-happy JS). So coming from a world of clean interfaces, I was set to write one around Prototype and Dojo; an awesome interface that would make switching out from dojo a breeze, if that was in fact necessary.

That was a mistake that cost a lot of time and effort for a few reasons. The first one is that although two libraries can provide the same functionality, (a) their API will almost always be different, and most importantly (b) the way you program with one library will be different. 

To demonstrate, let's take something as common as adding a class-name:

```
// Prototype
$("target").addClassName('highlighted');

// Dojo
dojo.addClass("target", "highlighted");

// jQuery
$("target").addClass("highlighted");

// MooTools
$('target').set('class', 'highlighted');

```

Pretty straight-forward so far. Let's complicate it a bit:

```
// Prototype
Element.addClassName('target', 'highlighted selected');

// Dojo
dojo.addClass("target", ["highlighted", "selected"]);

// jQuery
$("target").addClass(function() {
   return 'highlighted selected';
});

// MooTools
$("target").set({
    "class": "highlighted selected"
});

```

Now after choosing an interface for your version of the addClass you have two options: (1) code to the lowest common denominator, or (2) implement all of the non-intersecting features of the libraries. 

If you go with the 1st -- you'll loose the "personality" / best qualities of each of the library. If you go with #2 -- your addClass' code will be at 4 times larger than the ones provided by any of the libraries, since for example when Dojo is included, you'll have to write the code for the function as the first param (jQuery) and the Object as the first param (MooTools). 

Therefore, although it is theoretically possible, it isn't practical, but is a very nice way to understand the intricacies of the libraries out there.