Choosing an EventBus: DIY EventBus, EventEmitter or BackBone.Events

Posted by: Seth Lakowske

DIY EventBus
I wanted an EventBus implementation. I started to write my own EventBus implementation, but about 2 lines in, I wondered, “Is there an easier way?”

EventEmitter vs. BackBone.Events
It seemed someone else might want a Javascript EventBus implementation, so I googled EventBus and found implementations on Github. They looked plentiful and most implementations seemed simple. One EventBus implementation used Nodejs’s EventEmitter behind the scenes as a delegate. This got me interested in EventEmitter, and EventEmitter2, a slightly more powerful version of EventEmitter. I also remembered BackBone had an EventBus implementation. So I started reading and evaluating my options.

The first criteria I had, and almost always do have, is to determine if the implementation functions on the browser and server. I figured EventEmitter2 might satisfy this requirement. Possibly EventEmitter too. I knew BackBone worked on the browser and found it was simple to import via RequireJS. I found a BackBone implementation on npm. I can

npm install backbone --save

The next thing I considered: If I did pick EventEmitter, would I later be swapping it out for BackBone.Events when I started writing for the browser. EventEmitter2 would likely work in the browser, but If I was going to use BackBone for my browser logic, then I’d be better off with BackBone. I don’t need two EventBus implementations and BackBone.Events fits nicely in the BackBone ecosystem. So if I do plan to write for the browser, I should use Backbone.Events.

BackBone.Events
Since I’m going to write software destined for the browser, I chose BackBone.Events. It saved me time over a DIY EventBus and it allows me to interoperate between server and browser code without swapping out libraries or having duplicate implementations(EventEmitter and BackBone.Events).