Implementing what a static jQuery pubsub might look like even though everyone hates the idea.

jquery.pubsub.js

 /*
  usage:
  
  $.bind('customEvt', function( event ){ 
    console.log( event );
  });
  
  $.trigger('customEvt');
  
 */

;(function ($) {

  $.bind = function( type, data, fn ){

    if ( arguments.length === 2 || data === false ) {
        fn = data;
        data = undefined;
    }
  
    jQuery.event.add( document, type, fn, data );

  };

  $.trigger = jQuery.event.trigger;

})( jQuery );

Regarding jQuery.trigger = jQuery.event.trigger;

This wouldn't work because jQuery.event.trigger expects a jQuery collection.

jQuery.event.trigger doesn't expect a jQuery collection, it's a static method. http://jsfiddle.net/rwaldron/Z56dG/1/ proves that my suggestion works exactly as expected.

I'm not sure where you get 15% faster from - it's incorrect. Of the 2 of 3 recorded results on that jsperf show $doc.bind being faster, but not even enough to be considered statistically significant. http://en.wikipedia.org/wiki/Statistical_significance

Whoops, I was looking at jQuery.fn.trigger (https://github.com/jquery/jquery/blob/master/src/event.js#L971), and not jQuery.event.trigger. Good point.

Also, when you perform an entire publish/subscribe, static bind trigger is 46 percent faster: http://jsperf.com/bind-vs-fn-bind

When you run your jsperf, it comes out 12 - 15% faster every time.

Also, when you perform an entire publish/subscribe, static bind/trigger is 46% faster than the dynamic methods: http://jsperf.com/bind-vs-fn-bind

With all due respect, that jsperf doesn't tell me anything about trigger. there is way too much going on in those tests to really gauge anything. Take a look at this: http://jsperf.com/trigger-vs-fn-trigger Again, the differences are statistically insignificant. This has proven to be a great academic exercise

Neither of you jsperfs are testing anything conclusive. Please review these...

http://jsperf.com/fn-bind-vs-bind

http://jsperf.com/trigger-vs-fn-trigger

I think the confusion is that you're looking at the individual test results and not the stored results at the bottom (in the browserscope table)

I updated the $.trigger to directly reference jQuery.event.trigger.

What's the benefit of going through the jQuery event system vs just maintaining an independent, pubsub-only object that tracks subscriptions, a la the @phiggins approach?

rmurphy: I agree, we should be using an of DOM event pubsub object for managing subscriptions. My thinking is that in the event.js rewrite an overload would be provided in jQuery.event.add() that allows for not passing a DOM element, in which case events would get added to a pubsub-only object.

I realize that jQuery is a DOM-centric library, but a lot of people use jQuery which gives it the power to teach people good practices, and providing a documented jQuery style way of doing pubsub could lead users to do off DOM events well.

Imagine using the jQuery event like so

$.bind('customEvt', function( e ){
console.log( e.data ); // my message
console.log( e.type ); // customEvt
});

$.trigger('customEvt', 'my message');

e.data and e.type are familiar to jQuery users. I feel like extending this familiar API to pubsub would be enormously influential, and if it's only ~10 lines of code, it might be worth it.

I also have some ideas about jQuery managing event bubbling off DOM which I'm still thinking through.

Re: $.bind... please re-read above.

I realize that $.bind and e.data clobber native properties (of function and message event respectively) which is probably bad, but that's another story. If it becomes clear that a built in pub sub is a good idea, then we can work out the semantics later. $.on, or something (which is not very jQuery :( ).

$.bind === Function.prototype.bind; // true get it? its not "just a property" its a fundamental jQuery-will-not-do-it deal breaker.

Additionally, your most recent example is not handling custom data correctly, See: http://jsfiddle.net/rwaldron/jEU3w/

"not very jQuery"? What then, would be "jQuery" enough for you?

As for "overloads", the whole point of the 1.7 events re-write is to stop doing major overloads and create straight forward behaviours that are both backwards compatible and future proof.