title: Why not take Javascript event delegation to the extreme?
body: <p>By now most folks on this site are probably aware that:</p>
  
  <pre><code>$("#someTable TD.foo").click(function(){
      $(e.target).doSomething();
  });
  </code></pre>
  
  <p>is going to perform much worse than:</p>
  
  <pre><code>$("#someTable").click(function(){
      if (!$(e.target).is("TD.foo")) return;
      $(e.target).doSomething();
  });
  </code></pre>
  
  <p>Now how much worse will of course depend on how many TDs your table has, but this general principle should apply as long as you have at least a few TDs.  (NOTE: Of course the smart thing would be to use jQuery delegate instead of the above, but I was just trying to make an example with an obvious differentiation).</p>
  
  <p>Anyhow, I explained this principle to a co-worker, and their response was "Well, for site-wide components (eg. a date-picking INPUT) why stop there?  Why not just bind one handler for each type of component to the BODY itself?"  I didn't have a good answer.</p>
  
  <p>Obviously using the delegation strategy means rethinking how you block events, so that's one downside.  Also, you hypothetically could have a page where you have a "TD.foo" that <em>shouldn't</em> have an event hooked up to it.  But, if you understand and are willing to work around the event bubbling change, and if you enforce a policy of "if you put .foo on a TD, it's ALWAYS going to get the event hooked up", neither of these seems like a big deal.</p>
  
  <p>I feel like I must be missing something though, so my question is: is there any other downside to just delegating all events for all site-wide components to the BODY (as opposed to binding them directly to the HTML elements involved, or delegating them to a non-BODY parent element)?</p>