jQuery Plugin Boilerplate, reprise

You are currently browsing comments. If you would like to return to the full story, you can read the full entry here: “jQuery Plugin Boilerplate, reprise”.

28 thoughts on “jQuery Plugin Boilerplate, reprise

  1. philip

    I really found your previous version of this boilerplate useful — just wondering if in this newer version you are suppose to instantiate a plug-in like in your example:

    // create a new instance of the plugin
    var myplugin = new pluginName($(‘#element’));

    or if you need to include a dollar sign before the plug-in name?

    1. Stefan Gabos Post author

      you need to dollar sign before the plugin’s name – i accidentally left it out in the examples. it’s fixed now thanks for telling me.

      the other version it’s still perfectly functional and maybe appeals to more users than this one. this is way off the jQuery way but it’s *exactly* what I was looking for. I didn’t like it in the first place that jQuery “changes the way you write JavaScript” ๐Ÿ™‚ With this version, it’s back to the roots ๐Ÿ™‚

  2. Matt

    Very nice clean and functional design. Thank you for sharing! Question: is it possible to call the plugin with a list of parameters (as is typical with plugins) or is it more OOP such that the plugin is instantiated and then properties set e.g.

    var myplugin = new pluginName($(โ€˜#elementโ€™));
    myplugin.settings.propertyName = ‘actual value’;
    myplugin.settings.propertyName2 = ‘actual value’;

    1. Stefan Gabos Post author

      if you look in the code you’ll see that it is possible to call the plugin with a list of parameters like

      var plugin = new pluginName('$(selector)', { 
          property1: 'value 1', 
          property2: 'value 2'
  3. Davey IJzermans

    First of all thank you very much for this template. It really helped me understand a lot about the anatomy of a jQuery plugin.

    Using this boilerplate however, I cannot access the settings object from outside the plugin as you described. I simply get an undefined error. Any idea why?


    1. Davey IJzermans

      I’ve refactored my code myself in the form of
      $.baseName = { var1 : 'value', functionOne() {}, functionTwo(), };

      I think i have confused the semantics of a plugin and just plain old objects for this particular piece of code.

      Your template certainly helped me kickstart my jQuery building. I bookmarked your website for future jQuery Plugin goodness and reference. Thanks again!

  4. Riccardo Caroli

    Thanks for the code..
    I’m about to rebuild a jquery plugin with classes and I have a question: what’s the point of building jquery classes if you don’t have chainability? Isn’t it better to use standard javascript classes or object literals? thanks

    1. Stefan Gabos Post author

      actually, all the code in the jQuery boilerplate is “standard” JavaScript that happens to have access to the $ (jQuery) object which is passed as argument at the very top. Still, you can have *some* chainability by returning a reference to an element from the class’ methods.

  5. Peter Gledhill

    I like this template very much. Just 1 question regarding the scoping of ‘this’.

    I can use methods.foo_public_method() to call a method from within the ‘init’ function.

    However the scope of ‘this’ will now refer to the ‘method’ object rather than the DOM element. So I can not return ‘this’ (to enable chaining) or access this.plugin.settings.

    Can you suggest any way of avoiding this problem?


  6. P.J.

    Thanks for sharing this. I need to write a jQuery plugin for a site that is also running MooTools. I understand this is not ideal but that’s the situation.

    For compatibility, can I simply replace all instances of ‘$’ in your example with ‘jQuery’?


  7. P.J.

    Great thanks! Now for another question:

    I’m using your boilerplate template for a plugin that will accept several options and do a lot of editing on different dom elements, Ajax calls, etc. I’ll need to pass in options, but there’s no need to pass in “el” since the plugin doesn’t need to be attached to any specific element.

    Should I just create an empty span element or something, and ignore the “el” parameter?

    1. Stefan Gabos Post author

      it’s common sense: just create the plugin like

      $.pluginName = function(options) {

      and remove all the references to el…

  8. P.J.

    One more question, how would I trigger the object’s event hooks (set in the defaults variable)? For example, if I wanted to trigger onSomeEvent when an input’s value was changed or a button was clicked, is this the proper way to do it?



    1. Stefan Gabos Post author

      yes, that’s pretty much it.
      i do it like this:

      // first make sure that there is a callback function 
      if (plugin.settings.onSomeEvent && typeof plugin.settings.onSomeEvent== 'function')
          // execute the callback function
          plugin.settings.onSomeEvent(arg1, arg2, ... argn);
  9. Joseph

    Thanks for this awesome template. However, I noticed that to start the plugin, you need this “messy code” to do it:

    var myplugin = new $.pluginName($(‘#element’),{options…});

    why not send the selector string:

    var myplugin = new $.pluginName(‘#element’,{options…});

    and in the plugin template, do this:

    plugin.el = $(el);

  10. John

    What is the point of the callback methods (like onSomeEvent()) in the defaults? Why not just use public functions?


    1. Stefan Gabos Post author

      so that developers can perform specific tasks at specific time points; like jQuery’s animate(), which executes a function when it’s done.

  11. Vall


    first of all, nice boilerplate. Was looking for something similar for a while now. I’m having a problem with initializing it, the line:
    var myplugin = new $.pluginName($(‘#element’));

    TypeError: $.pluginName is not a constructor

    Any idea what I’m doing wrong? ๐Ÿ˜‰
    #element exists and myplugin variable is not defined before initialization.


  12. Martijn

    For what it’s worth, I disagree with your callback pattern. I think it is better to rely on jQuery’s own eventing system, using the on/off/trigger functions. It’s a lot richer in functionality and a lot more flexible than passing a function.

Comments are closed.