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.
> 
> 
>
Adapter pattern is not a common solution in this case. The only example I know to use this pattern is [extjs](http://www.sencha.com/learn/File%3aExtJS-11-BaseLibs.png). Javascript projects are usually too small and they aren't worth the effort you would make by creating such an abstraction layer.
The common solution for this problem is that you try to use multiple frameworks together for example with [jquery.noConflict](http://api.jquery.com/jQuery.noConflict/).