насколько я понимаю, делаем два запроса и ставим общий обработчик, который сработает после завершения обоих. Вроде того: http://habrahabr.ru/blogs/nodejs/116581/ . В ноде такая хрень реально пригодилась бы.

ну может в ноде...

в том числе.
Как правило при работе с Ajax:

$.when($.get('foo.html'), $.get('bar.html')).done(function(arg1, arg2) {
     alert("выполнены все запросы");
});
// однако если в when передается Deferred Object, то предпологается что запросы уже выполнены

идея реализации асинхронных цепочек:

var funcs = [
    function(NEXT) {
        new Request('foo.html', onSuccess: function(arg1){
            this.arg2 = arg2;
            NEXT();
        }).get();
    },
    function(NEXT) {
        new Request('bar.html', onSuccess: function(arg2){
            this.arg2 = arg2;
            NEXT();
        }).get();
    },
    function() {
        alert("выполнены все запросы");
    }
];
var i=-1;
function _next() {
    i++;
    if ( ! funcs[i]) {
        return;
    }
    funcs[i].call(funcs, _next);
}
_next();

а можно какой-нибудь конкретный пример двух запросов с одним обработчиком в конце? Ну или просто что-то, что не укладывается в раки асинхронной цепочки...

например запросом удаляется 1-на запись из таблицы, а у тебя в UI можно выбрать несколько записей и удалить их группой.

только какие преимущества перед стандартными методами синхронизации?
стандартизировано... доступ извне... ну мб кароче...

Вы абсолютно не правы. querySelectorAll в jQuery как раз в роли кросс-браузерной реализации с возможностью fallback. Все остальное является первостепенным: анимации, управление DOM, асинхронные запросы на сервер.

На счет качества тут можно долго спорить, могу лишь сказать, что сам по себе jQuery написан довольно хорошо и показывает не слишком большое отличие в скорости выполнения, по сравнению с аналогичным кодом без этой библиотеки (читай, оверхед не слишком велик). При этом плюсов очень много - мало весит, удобна, привычна на данный момент многим js-кодерам. Удобный инструмент.

Да и вообще, разницы нет, использовать, или нет. Только зачастую лишняя трата времени. Ведь не важно, используется библиотека, или нет, если речь идет о каком-нибудь сайте, например. Важно чтобы работало и быстро. И делалось быстро. Все остальное для кодосектантов.

Это вы абсолютно не правы. Анимацию я в гробу видал делать на jquery. Если мы конечно говорим про анимацию, а не складывание, раскладывание одного дива. Шустрая анимации сейчас возможна только на чистом js под конкретный браузер.
Управление DOM, хватает и стандартных средств, а запросы на сервер 20 строчек. Я ещё jquery не знал, а ajax-ом пользовался вовсю.

jquery это querySelectorAll. Они пытаются наворотить сейчас и вылезут из маленького размера, а тогда она уже нафиг не нужна.

делаем запрос который удаляет список записей и deferred не нужен. Он для каких-то сложных случаев, я таких не знаю.

Андрей Параничев, а какие минусы?

Я бы сказал более специфических.
Допустим есть такая ситуация: интерфейс подбора тур. путевки.

Кликнули на выбор страны, послали запрос, но отобразили пользователю полученный результат, затем послали еще какой-то запрос (к примеру выбор города), выполнили тоже самое.
Затем пользователь решил нажать кнопку "оплатить", тут то мы смотрим если предыдущие запросы все выполнены без ошибок то выполняется callback (переводим пользователя на интерфейс оплаты) или fallback если где-то был косяк.

Я может быть совсем от жизни отстал, но мне всегда казалось что для этой ситуации вообще deferred не нужен. Можно решать по разному такую задачу, но даже если решать подобным образом достаточно свойства в котором хранить true, false.

или я чего-то недопонял тут: