This post is inspired by my answer at StackOverflow.

So why we should use publish/subscribe? Why it is useful? Is it making our work harder or it makes our application better?

And the answer…

It’s all about loose coupling and single responsibility, which goes hand to hand with MV* (MVC/MVP/MVVM) patterns in JavaScript which are very modern in the last few years.

Loose coupling is an Object-oriented principle in which each component of the system knows it’s responsibility and don’t care about the other components (or at least tries to not care about them as much as possible). Loosing coupling is a good thing because you can easily reuse the different modules. You’re not coupled with the interfaces of other modules. Using publish/subscribe you’re only coupled with the publish/subscribe interface which is not a big deal – just two methods. So if you decide to reuse a module in different project you can just copy and paste it and it’ll probably work or at least you won’t need much effort to make it work.

As talking about loose coupling we should mention the separation of concerns. If you’re building an application using MV* architectural pattern you have always a Model(s) and a View(s). The Model is the business part of the application. You can reuse it in different applications, so it’s not a good idea to couple it with the View of a single application, where you want to show it, because usually in the different applications you have different views. So it’s a good idea to use publish/subscribe for the Model-View communication. When your Model changes it publish an event, the View catch it and update itself. You don’t have any overhead from the publish/subscribe, it helps you for the decoupling. In the same manner you can keep your application logic into the Controller for example (MVVM, MVP it’s not exactly a Controller) and keep the View as simple as possible. When your View changes (or the user click on something, for example) it just publish a new event, the Controller catch it and decides what to do. If you are familiar with the MVC pattern or with MVVM in the Microsoft technologies (WPF/Silverlight) you can think for the publish/subscribe like the Observer pattern. This approach is used in frameworks like Backbone.js, Knockout.js (MVVM).

Here is an example:

//Model
function Book(name, isbn) {
    this.name = name;
    this.isbn = isbn;
}
   
function BookCollection(books) {
    this.books = books;
}
    
BookCollection.prototype.addBook = function (book) {
    this.books.push(book);
    $.publish('book-added', book);
    return book;
}
    
BookCollection.prototype.removeBook = function (book) {
   var removed;
   if (typeof book === 'number') {
       removed = this.books.splice(book, 1);
   }
   for (var i = 0; i < this.books.length; i += 1) {
      if (this.books[i] === book) {
          removed = this.books.splice(i, 1);
      }
   }
   $.publish('book-removed', removed);
   return removed;
}
    
//View
var BookListView = (function () {
 
   function removeBook(book) {
      $('#' + book.isbn).remove();
   }
 
   function addBook(book) {
      $('#bookList').append('<div id="' + book.isbn + '">
  ' + book.name + '
</div>');
   }
  
   return {
      init: function () {
         $.subscribe('book-removed', function (book) {
             removeBook(book);
         });
         $.subscribe('book-aded', function (book) {
             addBook(book);
         });
      }
   }
}());

Another example. If you don’t like the MV* approach you can use something a little different (there’s an intersection between the one I’ll describe next and the last mentioned). Just structure your application in different modules. For example look at Twitter.

If you look at the interface you simply have different boxes. You can think of each box as different module. For example you can post a tweet. This action requires update of few modules. Firstly it has to update your profile data (upper left box) but it also has to update your timeline. Of course, you can keep references to both modules and update them separately using their public interface but it’s easier (and better) to just publish an event. This will make the modification of your application easier because of loosing coupling. If you develop new module which depends on new tweets you can just subscribe to the “publish-tweet” event and handle it. This approach is very useful and can make your application very decoupled. You can reuse your modules very easy.

Here is a basic example of the last approach (this is not original twitter code it’s just a sample by me):

var Twitter.Timeline = (function () {
   var tweets = [];
   function publishTweet(tweet) {
      tweets.push(tweet);
      //publishing the tweet
   };
   return {
      init: function () {
         $.subscribe('tweet-posted', function (data) {
             publishTweet(data);
         });
      }
   };
}());

var Twitter.TweetPoster = (function () {
   return {
       init: function () {
           $('#postTweet').bind('click', function () {
              var tweet = $('#tweetInput').val();
               $.publish('tweet-posted', tweet);
           });
       }
   };
}());

For this approach there’s very good talk by Nicholas Zakas. For the first MV* approach the best articles and books, I know, are published by Addy Osmani.

Drawbacks. You have to be careful about the excessive use of publish/subscribe. If you’ve got hundreds of events it can become very confusing to manage all of them. You may also have collisions if you’re not using namespacing (or not using it in the right way). An advanced implementation of mediator which looks much like an publish/subscribe can be found here https://github.com/ajacksified/Mediator.js. It has namespacing and feature like event “bubbling” which, of course, can be interrupted. Another drawback of the publish/subscribe is the hard unit testing, it may become difficult to isolate the different functions in the modules and test them independently.