[x-yuri]

Сейчас это единственный вариант, подходящий по требованиям, который я вижу.

озвучь требования что ли

API вынуждает писать логику, которая зависит от плагинов.

jQuery вынуждает писать логику, которая зависит от плагинов. Но это не проблема. Проблема в том, что jQuery не предоставляет возможности создавать компоненты. Если же ты про взаимодействие через API, то взаимодействующие компоненты не обязательно будут зависеть друг от друга, можно просто создать какой-нибудь координирующий уровень, который не будет работать через события (Service Locator). Например, в случае с псевдоселектом, он мог спросить у этого координатора форму и отправить ее

services().get('form')->submit();

причем так даже лучше в данном случае, чем отправлять событие, потому что события это уведомления и они хороши, когда имеется сложная логика взаимодействия, когда заранее неизвестно, кого уведомлять. Но в общем-то так слишком сложно, потому что это код, специфичный для формы. Это что-то типа "не допущу, чтобы форма зависела сама от себя". Можно просто в обработчике события отправить форму, как я писал выше

Классическая ситуация - таб. Если он не активен, его содержимое незачем обновлять. Да мало ли на странице может быть скрытых блоков.

обновлять? Возникает подозрение, что ты хочешь сделать что-то extjs-подобное или приложение типа gmail, т.е. которое обновляется. Озвучь свои цели

по поводу MVC, я вижу причину отделять модель от вида/контроллера, если нету четкого соответствия одна модель - один вид/контроллер. А вид с контроллером обычно слишком тесно связаны. Еще бывает смысл вынести код, который напрямую работает с DOM в отдельный класс, чтобы, если надо будет менять внешний вид, оно по-крайней мере не было перемешано с логикой работы. И в этом случае один класс (основной) - модель+контроллер, второй (работа с DOM) - контроллер+вид. По поводу первого из этих двух случаев есть смысл общаться через события, а именно уведомлять об изменениях модели

если взять WPF, например, там стандартные компоненты изначально никак не связываны. Стандартный способ их связать - в коде окна, т.е. в коде окна ты ловишь события от компонентов и изменяешь/управляешь другими компонентами. Т.е. что-то типа

new Select({ 
    'change': function(){ 
        $('#my-form').submit(); 
    } 
})

MVC там можно сделать, если нужно, но это не навязывается. А можно какое-нибудь третье решение придумать

а то, что ты хочешь сделать, называется Mediator. Но для каждого паттерна есть, условия, при которых его имеет смысл применять. Он может использоваться в одной части приложения и не использоваться - в другой

Вообще мое имхо, что такая событийная модель более естественна для js. Поскольку большАя часть тех операций для которых он используется имеют ассинхронную природу.

я не говорю, что события - плохо. Я говорю, что кроме событий есть несобытия И кстати, про асинхронность (обновление) B~Vladi только сейчас упомянул, по крайней мере явно. При обновлении информации на странице, конечно, без событий не обойдешься. А что будет происходить при получении ответа от сервера... случаи разные бывают