This is a pattern we’ve been using to organize a big jQuery project that is now composed of 150+ files. When we first started with the project, we kept all page components in their respective jQuery plugins. This was good enough at that time. But as the project grew it became harder and harder to maintain it.
Plain objects vs plugins
This looks like a step back from making cool plugins but there are actually some benefits. Let’s look at this horizontal slider plugin as an example:
This pattern takes advantage of prototypal inheritance (
Object.create) to create a new instance of
Slider. The advantages of this are:
- It’s much cleaner and easier to understand since you’re sort of creating a “class” and one would just have to create a new instance to use it.
- It’s not tightly coupled with jQuery. If it ever happens that you’ll have to switch to a different library, it’ll be easier to do so.
- Object members are exposed (e.g.
currentPage), can easily be inspected and used.
The disadvantages of this are:
- A single instance can operate on a single element only. You can easily work around this though.
- It’s not a jQuery plugin – it’s not cool (debatable)
inherit the members of Slider into a new (instantiated) object.
Now that we have simple objects instead of plugins, we can easily group these into namespaces – objects within objects. We can have a base namespace:
And then put our objects under it:
This now looks at least more organized and maintainable. And you’d have a nice DOM view (FireBug):
What we can learn from this is that jQuery doesn’t really force you to follow a specific design pattern. It’s excellent at DOM manipulation, but it doesn’t provide much outside that. This is actually good, since this means that you can apply your own design on top of it. jQuery should be part of your project and not the backbone of your project.
Speaking of backbone, Backbone.js is a great complement to jQuery that’s definitely worth checking out.