насколько я понимаю, делаем два запроса и ставим общий обработчик, который сработает после завершения обоих. Вроде того: 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.

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

JQuery - это тот же JavaScript
 

JQ - это тот же JavaScript, разница лишь в том, что готовые функции можно использовать n-раз, набрав всего пару строчек, а не копипастить весь код несколько раз.

да, это какое-то использование не по назначению или слишком сложное решение

т.е. без jquery функцию невозможно самому написать?

x-yuri,
Минусом jQuery является то, что он не диктует то, каким образом нужно писать код на клиенте. Api для создания плагинов не подходит для того, чтобы реализовывать какие-то свои модули в рамках одного проекта (нет смысла). Просто весь код подряд в одном JS файле тоже - поскольку один скрипт может (должен) содержать скрипты, которые могут появляться на разных страницах. Банальный пример, есть две страницы: gallery.html и comments.html, подключается один скрипт. Ну вы понимаете, роутинга нет, нужно что-то придумывать самому. Проблемы тут, по сути, нет, написать самому просто. Но сам факт того, что jQuery не диктует того, как нужно писать код, использующий эту библиотеку, это минус. Не слишком "фреймворкно".

Дефферед нужен там, где интерфейс реально завязан на JavaScript и где постоянно используются callback. Чем больше callback'ов у вас есть, тем больше требуется библиотека, вроде deffered. На сервере (в node.js) без неё вообще тяжко, потому что бывает ситуация, когда нужно сделать две записи в БД, записать файл, записать кеш, выдать результат клиенту, так получается, что один запрос может породить 12-20 вызовов в цепочке, и каждому нужно передать callback.

На клиенте тоже бывает часто такое, но опять же в "очень JS" приложениях, где все действия и взаимодействия идут через сервер. Например, при заходе - авторизация, загрузка данных пользователя, отправка состояния локального, подзагрузка изображений, установка прослушивания канала comet-сервера или websocket подключения. И все эти действия должны идти друг за другом, например. Можно конечно все разбить и через внутренние события решить, но цепочкой легче, учитывая, что она позволяет перехватить err параметр в любом вызове.

Gozar,
Во-первых, кодосектанство. Во-вторых, управление DOM стандартными средствами неудобно, излишне избыточно по синтаксису, требует отдельных доработок для кросс-браузерности даже не уровне такой банальщины, как установка обработчиков событий и получение контекста событий. Не говоря уже обо всем остальном. И кто будет поддерживать ваш код потом, о них подумали? Я врагу не посоветую разбираться в простынях кода "слайдеров", "аккордеонов" и других элементов, которые написаны на нативном JS, но с ужасающим кодом.

Мы говорим про манипулирование свойствами стилей элементов в таймере. Реализация в jQuery не слишком отличается от соответствующих реализаций в любых фреймворках, которые сейчас существуют. Кроме того, там прозрачно работает requestAnimationFrame.

Она весит как 10 ваших маленьких аватарок. Средняя скорость подключения к интернет в мире приближается к 1 мбит/сек. Сейчас они не пытаются ничего наворотить, код только улучшается, а нововведения минимальны и только для повышения производительности вводятся.

Распространённое заблуждение. Почему все забывают про мобильный интернет?

а ты как, кстати, поступаешь?

по поводу deferred мне сложно судить, может я просто не сталкивался с такими сложными случаями. Я не представляю, где он может на полную использоваться. По-моему чего-то такого должно хватить:

new Chain()
    .add(function(NEXT) {
        new Request({..., onSuccess: function(){ NEXT(); }})
    })
    .add(function(NEXT) {
        new Request({..., onSuccess: function(){ NEXT(); }, onFailure: function() {...}})
    })
    .go();

такую вещь можно передавать между вызовами и дополнять, если понадобиться, хотя у меня такой необходимости не возникало.

по поводу jquery, она ж все равно решает лишь небольшую часть проблем кросс-браузерности, а плагины тоже бывает надо допиливать, причем они не всегда на такие допиливания рассчитаны. От меня, например, как-то хотели lightbox переделать, причем не меняя кода плагина. Пришлось менять его по таймауту, т.е. я ждал пока закончиться анимация (setTimeout(<время анимации>, ...)) и потом вносил изменения. Да и баги бывают как в самом jquery, так и в плагинах (я один прямо на сайте у них наблюдал). А написано оно преимущественно, как ты говоришь, на нативном js, но с ужасающим кодом. Комментарии лишь отчасти спасают. К тому же, слишком сложно. Я уверен, если повысить требования к аудитории, размер/оверхед резко уменьшиться.

думаю, зависит от того, на какую аудиторию ориентирован сайт. Если на зарубеж, там, думаю, он побыстрее будет

По поводу кодосектанства не в тему. Использование jquery не отменяет знание javascript.
...
Только об этом и думаю :), но это ещё не означает что я буду писать код в котором может разобраться любой, включая дураков.

Андрей Параничев, по поводу качества нет желания спорить, все вижу своими глазами открыв исходный код.

isNaN: function( obj ) {
	return obj == null || !rdigit.test( obj ) || isNaN( obj );
},

Kolyaj,
Мобильный интернет вообще ни к чему в "обычном" интернете не приспособлен. Даже к картинкам тем же. Так что тут вообще сложно говорить. Для мобильного интернета нужны мобильные версии сайтов, если речь не про 3G.

vflash,
И что? Вы знаете о проблеме использования функции isNaN? Если нет, давайте разбираться вместе:

isNaN(null); // false
isNaN(""); // false
isNaN(false); // false
isNaN("Infinity"); // false
isNaN("     "); // false

Я думаю вопрос снят?

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

Речь конечно идет не о периоде, когда вы осваиваете JavaScript, когда полезно знать, как все работает "внутри". А когда вы уже понимаете все это и вам нужен конкретный результат.

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


А что не так с этими примерами? Почему они должны возвращать true, им разве NaN передаётся?

Kolyaj,
Достаточно быстрый, чтобы использовать библиотеку в 100Кб. Во всяком случае, я так считаю. К тому же средние скорости из статистики же взяты, а не с потолка. Только недавно на хабре была статья про это.

Ей нужно передавать неопределенное значение, которое возможно/невозможно интерпретировать, как Nubmer. После приведения оно проверяется на NaN. Но проверка не строгая, отсюда " " проходит, как не NaN, а значит, по логике, Number. Но это же не так, во всяком случае в тех местах, где она используется в jQuery. Отсюда и дополнительные проверки, в примере, приведенном vflash.

Андрей Параничев,
при таком раскладе "00000000000000000" тоже не число, и ' 00012343' тоже. мне вообще то не понравился регексп, который непойми где определен и стоит ли его там использовать ради зашиты от дураков.

нативный isNaN() расчитан на работу с числами.


библиотеки нужны. и было-бы хорошо если на javascript.ru имелась бы приличная коллекция самых востребованных вещей.


.

vflash,
Нативный isNaN() не строгий. Для внутренних нужд jQuery необходим строгий isNaN(), отсюда и регулярка. И это не от дураков скорее, эта проверка ведь срабатывает при парсинге свойств стилей тех же самых, в т.ч. возвращаемых браузером.

.each() удобен для обходя коллекций DOM элементов, получаемых через jQuery. А приведенный код, ну это просто для красоты так сделано, можно было до сделать все "напрямую", или использовать стандартный цикл, конечно, я не знаю, почему конкретно в этом месте сделали так.

Андрей Параничев,
each удобен но медлен. в IE8 вызов функции относительно медленная операция. да и в js вообше вызов функции это создание области видимости, arguments и еше всякого там. для быстрого кодинга это удобно а для библиотеки могли бы и постараться без него.

по поводу размера 233кб исходника, нехило так для маленькой библиотеки )

Андрей Параничев, а мое сообщение ты не заметил? В общем-то меня в первую очередь интересует, как ты решаешь этот вопрос:
по поводу jquery у тебя впечатления скорее всего другие. И...
а если 3G?

p.s. наткнулся на вот такую статью (только не надо судить сразу по заголовку). И вот здесь еще краткий взгляд на историю javascript неплохо получился (A brief (and partially fabricated) history of JavaScript)

vflash,
PRODUCTION (31KB, Minified and Gzipped)

Мда. Надеюсь медленная настолько, что можно пренебречь.

x-yuri
Я как-то так примерно делаю. Не слишком лаконично, зато удобно поддерживать код в будущем. Собственно текущий вид я определяю обычно или на основе url, что не самое удобное решение, либо на основе id у элемента body, который проставляется серверной частью.

Если 3G, то смысл вообще что-то оптимизировать? Скорости 3G достаточно, чтобы есть файлы целиком и даже смотреть видео на youtube в 720р.

Андрей Параничев,
а когдато была всего ~18 и без Minified .

в квери addClass переписали на циклы не по прихоти же. в событиях вроде когдато видел засилье each, а если событие весит на mousemove то эти копейки хорошо почувствуются.

когда-то про js тоже говорили что ему ненужно быть быстрым.

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

p.s. пользуясь случаем, хочу передать при... ну просто вы тут все... :) или почти все... другими словами, тестируете ли вы свой код? (это не предложение развивать здесь эту тему, если что)

Библиотеки уменьшают время разработки больших приложений, но при этом разработчик не может на 100% понимать как это работает и какие еще алгоритмы отрабатывают внутри библиотеки, что иногда может привести к совершенно непредсказуемым багам. При программинге на чистом JS разработчик всегда знает что и где он писал (если он один, конечно), и чистый JS, как правило, работает намного быстрее библиотек, хотя тут уже все зависит от коэффициента кривизны рук девелопера. Ну и не забываем о том что библиотеки несут в себе избыточный код для обеспечения поддержки старых браузеров и функционал который никак не задействован в продукте.

Взяты они из такой же абстрактной статистики как и большая часть статистики. Шум на хабре не влияет на статистику в отрасли в которой хабр не участвует.
Разговор ни о чём получается.

PHP тоже подобием jquery когда-то был ;)

По сути:
Когда качество приложения ставится на первое место выбираются те инструменты которые нужны для разработки. Иногда выбирается отсутствие jquery в основном коде и подключение её в готовый продукт, в котором нет ни одной строчки на ней и любой другой библиотеке.