Specifically, I want to support "plugins" that modify the behavior of parts of the library.

I couldn't find much information on the web about this subject. But here are my ideas for how a library could be extensible.

  1. The library exports an object with both public and "protected" functions. A plugin can replace any of those functions, thus modifying the library's behavior. Advantages of this method are that it's simple and that the plugin's functions can have full access to the library's "protected" functions. Disadvantages are that the library may be harder to maintain with a larger set of exposed functions and it could be hard to debug if multiple plugins are involved (how to know which plugin modified which function?).

  2. The library provides an "add plugin" function that accepts an object with a specific interface. Internally, the library will use the plugin instead of it's own code if appropriate. With this method, the internals of the library can be rearranged more freely as long as it still supports the same plugin interface. This could also support having different plugin interfaces to modify different parts of the library. A disadvantage of this method is that the plugins may have to re-implement code that is already part of the library since the library's internal functions are not exported.

  3. The library provides a "set implementation" function that accepts an object inherited from a specific base object. The library's public API calls functions in the implementation object for any functionality that can be modified and the base implementation object includes the core functionality, with both external (to the API) and internal functions. A plugin creates a new implementation object, which inherits from the base object and replaces any functions it wants to modify. This combines advantages and disadvantages of both the other methods.

  • So far both answers haven't really answered my question. I wonder if anyone has a answer for this. Commented Jul 2, 2012 at 21:05
  • I am facing the same issue. How would you approach this today? Did you gather enough information to answer your own question?
    – user8363
    Commented Mar 25, 2015 at 17:23
  • I've used both methods 1 and 2. Method 1 is generally simpler to implement in the library, but passes more burden to the plugin code. Method 2 takes more work to set up in the library, but means that possibly a wide variety of plugins can coexist peacefully. Commented Apr 2, 2015 at 0:41

2 Answers 2


To me, Extensibility means Interchangable_Parts.

At a high-level: to be extensible, over time - some code must be added, and some code must be removed. Extensibility is a painless system to achieve: addition, reuse, and replacement - over time.

In order to architect extensible systems, fundamental prerequisites exists in knowledge of advanced methodologies. Fortunately many are well documented in JavaScript.

Without specific knowledge of what you are attempting....

Here is a short list:

  1. Modules - AMD.
  2. Design Patterns - MVC, Namespaces.
  3. Loose Coupling - Pub-Sub/Evented Views, App Architecture.
  4. Templates.
  5. Data-binding.

In many ways, a zest to learn the topics above becomes an art over a science.

You will have to:

A. Research many options B. Prototype many technologies C. Become a JSpolyglot and JSagnostic. D. and Fail-Fast, when applying best-fit over personal ideology.

  • Fail-Fast is based on entrepreneurial tech-companies motto for success. This is beneficial to realize for evolving software. If your software is Modular, you design to improve parts separately. You don't want to invest too much effort on a failing model.

  • Stub things off that you know you can extend later, and continue extending iteratively. This requires a certain amount of vision and discipline.

  • Stand on the shoulder of giants. Don't waste your time trying to re-invent the wheel. Use what the social-coding community is generating, and extend upon it. This will give you the best chance at modularity. And, the best chance to incorporate best practice Design Patterns.

  • Look at what others are doing in regards to plugins. Paul Irish has a few famous documents regarding '10 things I learned from reading jQuery source code.' If you want to write plugins, you should do this too. You should also look at ExtJS, and YUI, with reserved judgement; benefits arise from being agnostic. Each use divergent methodologies that can assist to your need.

  • Modular architecture. This is the basis for all flexibility. The biggest challenge, i've seen across languages, is to decouple abstracted objects- but then still allow them to communicate. Essentially, this is a non-trivial trade-off.

Here are recommended technologies for separation of concerns:

require.js, backbone.js, underscore.js, GitHub.

There are easily a thousand more. But if you have a single takeaway, it is to look at AMD and require.js. Many people say this is the future for modular JS.

Hopefully there are some terms dropped here that get you searching in the right direction. All the best! Nash

  • 1
    Thanks for the detailed post. I'm sure many of these will be useful for me. Commented Jun 30, 2012 at 6:21

This is an interesting topic that looks similare to the following post - How to extend javascript library through plugins?. I hope that post answers your question.

I would also recommend to loook at Closures for hiding things.

  • 1
    Thanks for the link. There's some interesting stuff there. Closures are good for hiding things though, and don't really seem to apply to making an extensible library. Commented Jun 30, 2012 at 5:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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