Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a small JavaScript library that I've written that depends on prototype.js.

I'm considering creating a new version that would use jQuery instead.

The goal is to make it easier for users to install (choose which framework you use!) while not making it harder for me to maintain.

The main issue I see is that I would need to support two separate versions with overlapping functionality. If there is a bug, then I would need to fix it in two separate places.

How can I support multiple different frameworks in a JavaScript library without having a maintenance nightmare?

share|improve this question
    
The short answer is you can support every framework that's ever been made or ever will be made by 1) not relying on any frameworks, 2) not modifying the host environment in ways that will conflict with libraries that might also modify it (e.g. prototype.js), and 3) not trusting that the host environment hasn't been modified in naive ways (e.g. for..in without hasOwnProperty or a similar check). –  Hey Mar 31 '12 at 14:26

3 Answers 3

You don't. You do not build libraries on top of frameworks. You just support standards, like the DOM and ES5.1

Those standards work in modern browsers, if the users of libraries want to support legacy browsers tell them to use any of the standard polyfills.

share|improve this answer
2  
I just disagree there. People use libraries. You can push them on the "learn DOM an ES5" side, but they still use jQuery and prototype. It is pointless to tell people to use yet another polyfill when a library already provides what they need. –  Florian Margaine Mar 31 '12 at 6:01
    
@FlorianMargaine it's absolutely not pointless. A polyfill is only needed for legacy browsers, you don't need libraries/polyfills for modern browsers. And a polyfill is a central location to put all your browser hacks so that when you require 5 different libraries you don't have to fix all the IE bugs in 5 different locations. –  Raynos Mar 31 '12 at 12:19
    
So how would you approach the issue of rewriting prototype/jquery/whatever functionality to include in your library? For example, something as simple as say.. selectors? Being able to say $$('.myclass') is something I almost take for granted.. –  Kit Menke Apr 1 '12 at 5:22

Your issue is the same as if you were asked to do an app which can use either .NET Framework or Java, or a website component which works either with Silverlight or with Flash, depending on what the user has.

It is possible technically, but it leads to duplicate code and maintenance difficulties. There is nothing to do with it.

That's why most JavaScript libraries use one and one only framework.

That's also why most frameworks are able to work side by side: it allows to use several libraries which use several frameworks on a same website¹, avoiding collisions in method names like $().


Note about the advice given in two other answers: “don't build libraries on frameworks”. It is, well, too idealistic. This advice may be applied to maybe 1% of the libraries, probably much less: the libraries which are written by teams of developers able to build a library which will work on any browser, which will still be maintenable, and which require, for some reason, no framework at all.

This may be the case for example if you're writing a library which will be used at the home page of Amazon website²: you have to minimize the size of JavaScript code at all costs for performance/bandwidth reasons, and you have enough competent developers to not use any framework.

Outside Amazon/Google/Apple scale websites, do never follow the “don't build libraries on frameworks” advice, unless your library is too basic to require a framework. Instead:

  • Reuse, instead of reinventing the wheel,
  • Spend time doing something useful and interesting, i.e. writing your library, instead of writing something already available in every framework,
  • Trust the frameworks: they are written by skilled people who know things you may not know or forget,
  • Rely on abstractions: when I use a JQuery animation, I know it will work in Chrome, Firefox, Safari, Opera and even Internet Explorer. When I'm creating my own, I have to test it in those five browsers (up to ten if you count their major versions), and I'm pretty sure I will fail the first time at least in one browser.

¹ This is the thing you don't want to do if you care about the quality of your website. Still, lots of websites don't, and it is not unusual to find two, sometimes even three JavaScript frameworks on a same website side by side.

² Note that according to jQuery website, Google, Dell, NBC etc. are using it, so it's not because you're working on a large scale website that you cannot use a framework. In practice, large companies will end up inventing their own, which fits better their needs. This is the case for example for Google and its Closure Library.

share|improve this answer
    
Do you have some reference for the claim that the advice "don't build libraries on frameworks" applies to less that 1% of JS libraries? I can find many examples of scripts that don't use a GP library / framework / whatever you want to call it. Take a look at twitterjs, highlight.js, jscolor, dynarch calendar, sigma grid, etc. Whether or not they are "libraries" I suppose is open to interpretation, but there is plenty of good JS code that doesn't rely on GP libraries... –  Hey Mar 31 '12 at 13:35
    
...and the reason they don't use any GP library is to avoid issues like the one central to this question. The entire question becomes a moot point if your code does not rely on a framework / GP library. For complete applications this might be a good answer, but for libraries I'm really not sold. –  Hey Mar 31 '12 at 13:36
    
+1 because these are the reasons I chose to include the dependency on prototype.js in the first place!! If I had to write everything from scratch I don't think I would have been interested (or possible since I do this in my free time). –  Kit Menke Apr 1 '12 at 5:33

I agree with Raynos here; don't build libraries on frameworks.

It's not clear to me why prototype.js is a "framework" and jQuery is a "library," though. They seem extremely similar in scope and purpose.

Either they are both frameworks, implying that they're meant for building applications rather than libraries, or they're both libraries... but, as libraries, they are both quite general-purpose; it's probably not the best idea to build other libraries on top of either one, as you've introduced a dependency to your user with a bunch of extra cruft not useful for accomplishing whatever your library is for.

In other words, most libraries (apart from "general purpose" libraries) are meant to provide some specific functionality, and I assume this includes your library. Let's say for the sake of discussion that your library is for drag-and-drop page editing, so you've made use of some of the mouse input handling abstraction code in one of the GP libraries... Okay, but because of the design of the GP libraries, that means you need to include the whole thing just for the mouse handling. This might be acceptable in an application, but for a library it is really not acceptable.

If I wrote a library in C++ and I had to include every single library in the boost framework as a dependency, it would be huge and nobody would use it. Thankfully boost is designed in a modular way, as separate libraries, so nobody does that.

In contrast, the popular GP JS libraries have been designed as one-piece deals. You need mouse input handling? Great, you also have to include keyboard handling, query selectors, XHR wrappers, DOM sugar, etc. Again, you can kind of ignore this in an application, but in a library made for other developers to use, this is nuts. It makes no sense to introduce dependencies where 95% of the code is irrelevant to your library and will never run.

share|improve this answer
    
Out of curiosity, what features from prototype.js is your library using? –  Hey Mar 31 '12 at 9:55
    
Thanks for the answer. I can definitely see your point about introducing a dependency on a huge library when it is only partially used. Right now it uses prototype's "class" stuff, selectors, enumerable, and various utilities. It isn't so much that it couldn't be rewritten in plain JS but enough that it would be a pain. I guess I could just include the parts I need from prototype.js... –  Kit Menke Apr 1 '12 at 5:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.