How to achieve library-agnosticism when building a javascript framework?

Question

I've started looking into architecturing a javascript framework.

I don't want to reinvent the wheel here, especially regarding browser quirks, and know that for that matter, I'll have to rely, at some point, on some commonly-used libraries to handle low-level concerns.

The thing is, I'm not sure how i can depend on an external library for some piece of functionality (say for example dom manipulation), without tying it to my design.

Practical examples would help make a better point, but I'm not at the design stage yet, and I'm merely trying to avoid getting started on the wrong foot.

So I'm looking for some examples, guidelines, best-practices or maybe patterns that could help in this situation.

Any insight ?

EDIT : Bit of a clarification on why I'd want to do this.
My goal is to build something resembling more of an application framework than most traditional libraries like jQuery.
Think layered architecture, where the libraries would fit into the infrastructure layer (as per Evans' definition in Domain Driven Design), and handle things such as events, dom traversing and manipulation etc...

Answer 1

This is a very broad question, but if I were you, I would use jQuery as a base. It is a very easy library to extend and add functionality too.

Answer 2

I'd recommend grabbing a copy of ExtJS and taking a look at how they provide support for replacing the underlying core of their product. You can use their higher level libraries, such as grids, trees, etc, but choose to use YUI or prototype in place of their Ext core.

That should give you a good starting point.

Edit to answer comment:

Once you've downloaded ExtJS, take a look in the "adapter" folder. In there, you'll see the various adapters that exist to make ExtJS work with other libraries. You'll quickly see how they define functions that in turn make use of the appropriate underlying lib.

Answer 3

Segregate your code:

use the external libraries to the fullest possible, within their separate section of code.

Taking jQuery as an example, just designate a section for interfacing with jQuery and then use jQuery within that section of the library like there's no tomorrow, and give it interface functions that the rest of the code uses exclusively.

Frankly, if you integrate a library with your code and try to make it generic enough that you can trivially swap it out with something else, you're probably going to neuter the library to the point where you might as well have not included it at all.

Accept that you may need to rewrite if you end up swapping libraries, but prepare for that by giving the library-interfacing code it's own separate section, and you'll be able to write less generic, more powerful code with those external libraries and save yourself a lot of work.

Answer 4

This doesn't answer your pattern question, but a word about the frameworks. All of the modern JavaScript libraries are pretty good at playing well with each other, but some are better than others. Just make sure that they libraries don't monkey-patch the core objects with arbitrary properties or muck with the global namespace and you should be good to go. JQuery and YUI are both well designed and namespaced libraries. Dojo is also quite good, but a couple years ago when looking at all of the options, it seemed like Dojo encouraged the use of proprietary element attributes in markup as JS hooks. At that time Prototype was the library that mucked with objects like String/Array and didn't play well with others. I haven't looked/used Dojo or Prototype so take that with a grain of salt. I'm actively using YUI and JQuery in the same app; YUI for widgets and event management and JQuery for Selector/DOM manipulation.

Answer 5

I'd suggest you pick a single general purpose library or no library at all, depending on the requirements of the framework you plan to write. It's very difficult to make any kind of recommendation without more information, such as what your framework is aiming to achieve, who will be using it and in what kind of environment.

If you're considering writing a script of reasonable complexity then I would suggest learning the relevant "low level" DOM manipulation techniques for yourself. It's not as difficult as devotees of some of the famous general purpose libraries would have you believe.

Answer 6

Use some kind of interface to link to the library.

Don't do:

$("blah").something();

do

something("blah")

function something(id){
  $(id).something();
}

Since you could call something() 20 times, it'll be simpler to update if the actual use of the library is in only 1 place.

It'll add development time and then complexity, but you won't be as dependent on a library.

Answer 7

I don't think this can be achieved very effortlessly. If you really want this behavior, I think you'd have to manually map the features that are covered by all libraries you want to include support for.

So that the implementation would look like:

yourLibrary.coreFramework = 'prototype';
yourLibrary.doStuff();

And your librar would treat it in the following manner:

function doStuff() {
   var elem = getElement('id');
   // do stuff with 'elem';
}

function getElement(id) {
   switch(this.coreFramework) {
       case 'prototype': return $(id);
       case 'jquery': return $('#'+id);
       /* etc */
   }
}

Answer 8

Check out the jQuery or prototype frameworks.

If you decide you need to, then extend these.