My introduction to postal.js at codeapaLOUsa is yet another reason why that event was worthwhile. The freely available postal.js is an in-memory service bus for server and client-side JavaScript development. It is written in JavaScript, so it can easily be incorporated in your JavaScript code. This is another option that brings JavaScript closer to traditional languages.

Jump on the service bus

A service bus provides an asynchronous messaging architecture for the communication and interaction between applications; in this case, it is the communication and interaction between separate areas of an application. The postal.js library brings the publish-subscribe pattern to JavaScript and your application, which is probably Web-based but it can be used in server-side apps via node.js as well. It allows a message to be published to the service bus, whereas the publisher doesn’t have to be aware of who will be consuming these messages.

The message receivers are subscribers that watch the service bus for certain message types. This type of arrangement is not a foreign concept; for instance, the event-driven approach used in Web-interfaces via DOM events where the handlers of these events can be viewed as subscribers.

The caveat about postal.js is the decoupling of publishers and subscribers; this is key to simplifying your JavaScript and avoiding messy spaghetti code, where a change in one place can have ripple effects in your code. This may not be a big issue with a small application, but it is a big deal as application size grows and changes are made.

Free delivery

The postal.js library is freely available from GitHub. You can navigate to the lib/standard area to download the postal.js file. The alternate postal.min.js file provides a smaller representation of the library, thus a smaller (or minimum) size and download. In addition, the postal.diagnostics.js file provides specific diagnostic capabilities. We focus on the standard postal.js in this post. It is used just like any other JavaScript library — reference the postal.js file and start using it. A review of the source code provides some clues on how it works; I’ll look at the key concepts associated with using the standard postal.js.

What channel?

The channel is the key element of postal.js — it is where messages are sent and received. I love the description of the channel concept on the project page: “…it’s like a dedicated highway for a specific set of communication.” Channels are given names. Publishers send data to the channel, and subscribers can listen for specific channels or listen to all channels (aka wildcard). Any JavaScript object can be placed on the channel. Additional metadata about the data placed on the channel may be included.

A channel is easily defined using one of the two lines:

var newChannel ="ChannelName", "TopicName");
var newChannel ={channel:"ChannelName", topic: "TopicName");

With the channel defined, you can place objects on it. The following code places an object with details on my editor on the new created channel:

newChannel.publish(type: "Editor", value:"Mary Weilage"} );

The following line gives a quick example of subscribing to the channel once the channel variable is created. The body of the subscribe call defines a function that is used to receive subscription messages. In this case, the function uses the name attribute for the data received via the channel message. The final line stops the subscription so no more messages are received regardless if anything is placed on the bus.

var channelSub = newChannel.subscribe(function (data) { $("#TechRepublicExample").html("Name:" +;

There are a number of good online resources about the postal.js library on the Web. This article provides a great example via jsFiddle; it demonstrates code decoupling and simplification, as well as using the service bus to control objects on a Web page.

Other options

While postal.js provides nice features to embrace the publish-subscribe message bus architecture in your application, it is not the only option available. The main difference between postal.js and other solutions is the approach; postal.js is a memory-based solution (channel and data stored in memory), whereas other solutions like Amplify use an event delegation approach.

In my opinion, the postal.js library seems a little more flexible than other libraries (though I am not an expert on any of them). The extensibility and the customization options with postal.js are certainly selling points for the library. You can control and define looping, timing, and processing options.


All in all, I am impressed by postal.js and the many scenarios where it can be used. Most of these types of solutions can do what you need, so in the end it comes down to personal preference (most things do with developers).

What is your preferred approach to messaging within JavaScript applications? What are you favorite JavaScript libraries? Let us know in the comments.

Keep your engineering skills up to date by signing up for TechRepublic’s free Software Engineer newsletter, delivered each Tuesday.