¿Por qué no llevar la delegación de eventos Javascript al extremo?

Por ahora, la mayoría de las personas en este sitio probablemente saben que:

$("#someTable TD.foo").click(function(){
    $(e.target).doSomething();
});

va a funcionar mucho peor que:

$("#someTable").click(function(){
    if (!$(e.target).is("TD.foo")) return;
    $(e.target).doSomething();
});

Ahora cuánto peor dependerá, por supuesto, de cuántos TD tenga su mesa, pero este principio general debería aplicarse siempre que tenga al menos algunos TD. (NOTA: Por supuesto, lo inteligente sería usar jQuery delegate en lugar de lo anterior, pero solo estaba tratando de hacer un ejemplo con una diferenciación obvia).

De todos modos, le expliqué este principio a un compañero de trabajo, y su respuesta fue "Bueno, para los componentes de todo el sitio (por ejemplo, una ENTRADA de selección de fecha) ¿por qué detenerse allí? ¿Por qué no vincular un controlador para cada tipo de componente? el CUERPO mismo? No tuve una buena respuesta.

Obviamente, usar la estrategia de delegación significa repensar cómo se bloquean los eventos, así que esa es una desventaja. Además, hipotéticamente podría tener una página donde tenga un "TD.foo" que no debería tiene un evento conectado a él. Pero, si comprende y está dispuesto a evitar el cambio de burbujeo del evento, y si aplica una política de "si pone .foo en un TD, SIEMPRE va a tener el evento conectado", ninguno de estos parece ser un Vaya cosa

Siento que debo estar perdiendo algo, así que mi pregunta es: ¿hay alguna otra desventaja en simplemente delegar todos los eventos para todos los componentes del sitio en el CUERPO (en lugar de vincularlos directamente a los elementos HTML involucrados, o delegar ellos a un elemento padre que no sea BODY) @

Respuestas a la pregunta(6)

Su respuesta a la pregunta