JS unchained

Don’t be a douchbag and limit people to using a specific framework for your plugins, make it independent.

You probably know this problem, you are looking for a plugin to do something like a **slideshow** and about 80% of the plugins (including the one that really solves all your problems) are using a framework different from the one you are using (maybe you are not even using a framework).
So once you found that out you are going to have to spend the night digging through code and replacing every function that is framework specific, good luck.

But why? Maybe programmers are douchbags who just thing of their own little framework and not of other people who want to use their plugin? What is more likely is that people tend to develop something for their own need and later on release it as a plugin, changing everything to work without a framework takes quite some time so they just don't do it and thus we have our problem of framework dependencies. Independence for the rescue.

Declaring independence

To solve this problem I propose the independence pattern (spread the word) which lets developers use the framework of their choice while making it easy for the plugin users to adapt the code to their framework.

The independence pattern provides easy framework adaptability while leaving the author the choice to use any framework she desires.

The options object that is passed to a plugin and holds all configurations that the user might want to overwrite is a well know and used pattern. We can piggyback on this object and misuse it for our own purpose, like so:

options: {
  someSetting: false,
  ffn: {
   selClass: function(selector){
     return $(selector);
   }
  }
}

To explain: the ffn object holds functions for every framework function you use (this shouldn't be too many, otherwise where is the reason in writing a plugin?). As parameters you use the raw data.
If somebody wants to use your plugin but use a different or no framework she can easily replace the code of the functions to adapt for the change in framework, by overwriting the ffn object (this should be possible by passing it within the options object as parameter when initializing the plugin). No more digging through lines of code, figuring out which part has to be change and many more happy little programmers around the globe.

If you want to be extra nice, use as few framework functions as possible. Many functions can be replace by an as short native javascript functions, so use those instead.

If you are really nice and do not need compatibility for <IE8, you can build your plugin with native javascript and people who need this compatibility can substitute the functions where problems arise.

In summary

Whenever you use a framework specific functions write a wrapper functions and put it in the ffn object giving the raw javascript data as a parameter. Inside this wrapper you are free to use framework code and return the result. The user can now replace a function to select an element by class once, instead of digging through your code and replacing every last instance of your framework call. Play nice.