Own pubsub implementation vs using addEventListener() + CustomEvent?

Question

Is there a bigger difference between a self made pubsub system and what addEventListener() plus using new CustomEvent?

Pseudocode implementation of pubsub (taken from here):

// Publishing to a topic:
events.publish('/page/load', {
    url: '/some/url/path' // any argument
});
// ...and subscribing to said topic in order to be notified of events:

var subscription = events.subscribe('/page/load', function(obj) {
    // Do something now that the event has occurred
});

// ...sometime later where I no longer want subscription...
subscription.remove();

Native API:

var event = new Event('build');

// Listen for the event.
elem.addEventListener('build', function (e) { ... }, false);

// Dispatch the event.
elem.dispatchEvent(event);

Questions

• Will both do the same job? (I think so?)
• So is there actually any noticeable difference? Like performance?
• What are the pros and cons of both if both ways can be used?

I personally think if you implement it yourself the API looks more elegant than using the provided API. But this is not a technical argument. :)

Resources

• David Walsh pub/sub article
• addEventListener()
• Create and trigger events

Answer 1

I have no experience with CustomEvent but checking MDN, I'm missing support on mobile and IE. And the last time I had to deal with native events + custom payload; It was a pain.

Will both do the same job? (I think so?)

No. The native implementation is tightly coupled to the DOM. If your use-case doesn't involve the DOM, imo. it carries too much bloat around to handle event bubbling, cancellation, propagation etc, whereas the event objects I publish in my pubsubs are usually the raw payload.

So is there actually any noticeable difference? Like performance? What are the pros and cons of both if both ways can be used?

The native implementation is pretty much battle tested. It's limited in its features, but there should be no surprises.

A custom implementation can be better customized to your needs, and your personal way of programming. It's usually richer on features leaner, more fluent to read. But it may contain bugs.

Performance wise, I have no idea how much the native implementation is optimized internally, or wether it would be easy to outperform. I'm not sure how to set up a good test to test both approaches on a level playing field.

I personally think if you implement it yourself the API looks more elegant than using the provided API. But this is not a technical argument. :)

Elegance is rarely a self-sufficient goal. Elegant code is faster to read/scan, simpler to understand and therefore less prone to errors. Overall faster development may not be a technical argument, but it's definitely an argument to consider.

---

Ultimately it's up to you, wether native events suit your specific needs, or wether you're better off with a custom pubsub. But to me,

var waitinForOk = okBtn.once('click', function(){...});
//...
if(cancelled) waitinForOk.stop();

reads better than

var okHandler = function(){ 
  okBtn.removeEventListener('click', okHandler); //once
  //... 
};
okBtn.addEventListener('click', okHandler);
//...
if(cancelled) okBtn.removeEventListener('click', okHandler);