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: 
Although it makes sense from a theoretical standpoint, in practice I'd say it's overkill. If nothing else for these two reasons:

1. Anything that adds to the size of
the request (or adds more requests)
is bad - in web world, less is more.
2. If you're using say jQuery, the
chances of you switching to
something like Mootools is (imho) slim to none. From what I've seen, the top libraries each aim to solve different problems (at least in the case of Mootools and jQuery - see [this great doc](http://jqueryvsmootools.com/) for more info on that). I'd assume that you'd incur a tremendous amount of headache if you were to try to implement a middleware library that could easily switch between the two.
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.
> 
> 
>