抽象JavaScript库的最佳方法是什么？

Question

What would be the best way to abstract away any given JavaScript framework (jQuery, MooTools etc.), that sits on the bottom of the framework stack? Essentially, I would like to have a situation where I could swap out the library, do changes only to one layer of the framework (not to every module, for example), and the whole thing could be up and running again.

So, every module should call a framework function(s), which would then be routed to the library.

Answer 1

You may want to use something like the Adapter Pattern . Create your own interface, exposing the methods that you will be using in your application, and then create an adapter for each toolkit that you would like to support (jQuery, MooTools, YUI, etc). Your own interface would then route the method calls to the specific adapters.

If you were to support a new toolkit, all you'd have to do is to write a new adapter that translates methods from your own interface, to the methods of the specific toolkit.

This is something that Ext JS currently does. You can choose which adapter to use (jQuery, YUI, etc) behind the method calls of the framework. For example: Ext.getCmp() would use the jQuery.$() when using the jQuery adapter. However, it is often not a very easy one-to-one mapping.

Ext JS started its life as an extension to the Yahoo UI javascript library. At that time, Ext relied on YUI for all of its low-level cross-browser code. Now that Ext is a standalone JavaScript library, you have the choice of substituting YUI for other JavaScript libraries such as Prototype, or jQuery. The source files that map the low-level Ext API around other JavaScript libraries (or Ext's own base library) are known as adapters and they live in the source/adapter subdirectory. When you include Ext in your website you choose which adapter you want to use.

From: Ext JS Manual: Source Overview

Answer 2

This would be writing a library for...libraries, if you are concerned about performance at all (and why wouldn't you be?) you should go a different route altogether. Another abstraction layer on top of libraries with very different approaches (especially when you get into utilities, animations, etc.) would be very, very inefficient and time consuming.

No kidding, it'd take you less time to port your code several times even in any decent size project before building (or more importantly, maintaining) a library abstraction layer like this would.

Answer 3

You will have to write adapters for each toolkit/library you might want to use for your framework, pretty much like ExtJS/Sencha has done (though theirs are probably not reusable).

Start out by mapping out what methods your adapter should have, it will act as your frameworks low level API.

Next step is to write an adapter for each possible toolkit/library. Some libraries will be hard to write adapters for like YUI, since they load code dynamically. You might have to compile a single .js file with needed functionality first.

Add a new toolkit/library, write a new adapter according to your mapping.

Answer 4

This may have been a reasonable idea if the frameworks had equivalent functionality. Unfortunately they don't; they do different things, and they do them differently. There is cross-over between them, but your wrapper would miss out on a lot because you'd only be able to do your wrapping on stuff that was in both. You'd end up with the lowest common denominator; the worst of both worlds.

My advice is to take the time to learn both libraries - MooTools and JQuery are both very good libraries, and it's good to know them both. Even if you then only use one of them in your project, you will at least be able to make an informed choice before you start.