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.