views:

150

answers:

8

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...

A: 

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.

marcgg
+4  A: 

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.

Josh Stodola
+2  A: 

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.

jvenema
That took a considerable amount of effort on Jack Slocum's part, and in the end only the "lowest common denominator" from each library was/could be used. Anything more complex that the Ext widgets needed had to be hand-coded into Core anyway.
Crescent Fresh
What CrescentFresh said is true. However, for figuring out how to abstract another library's API, Ext's adapters can still serve as a useful example.
bmoeskau
@bmoeskau: oh yes, abs. Didn't mean to imply otherwise :)
Crescent Fresh
Sounds like a good suggestion, but as I'm not familiar with ExtJS, and seeing that the codebase is quite big, could you provide some pointers as to where I could see where this happens ?
julien
A: 

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 */
   }
}
David Hedlund
Instead of the switch, I'd see which library was present at the beginning and do some meta programming to get rid of runtime checks.
Nosredna
yeah, that's a much better way, actually. my main point was that support for the common functions of the frameworks concerned would have to be implemented manually. the means of doing that was subordinate, but indeed, yours would be the better way.
David Hedlund
Either way, it's a lot of work. Much more code to write and be debugged. I'd just target jQuery, since it seems to be the overwhelming popular favorite at the moment.
Nosredna
+1  A: 

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.

Tchalvak
Seems like the most sensible approach to take for a first draft, i could still refactor to provide bridge different libs through the same framework function, but it's hard to think about all the use-cases at first.
julien
A: 

Check out the jQuery or prototype frameworks.

If you decide you need to, then extend these.

Matt Joslin
It is true that you should keep in mind how much of a "solved question" you're dealing with here. Rolling your own is redoing a lot of work, certainly something to keep in mind.
Tchalvak
+1  A: 

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.

bic72
+1  A: 

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.

Tim Down