Комментарии 69
Разработчики прямо таки воодушевились, ждём jQuery 1.5…
как всегда радуете)
«Обовился jQuery до версии 1.4.2»
маленькая опечаточка…
А так новость порадовала! надо обновиться
маленькая опечаточка…
А так новость порадовала! надо обновиться
FF — тормоз, но уже получше конечно.
Что-то мне подсказывает, что список внизу слева-направо надо смотреть снизу-вверх, т.е. сверху не FF 3.5, а IE 6.
Истина. Однако всё равно после IE идет именно FF.
эмм… а по-моему после ИЕ6 идет 7 и 8, а потом хром, сафари опера и самые быстрые FF 3.6 и 3.5, ведь смоллер из беттер
речь же про 1.4.2
после IE идет FF (а про IE6 конкретно я не писал)
Opera и Safari быстрее на всех версиях — факт.
после IE идет FF (а про IE6 конкретно я не писал)
Opera и Safari быстрее на всех версиях — факт.
Ie6 -> ie7 -> ie8 -> Chrome -> Safari -> Opera -> FF3.6 -> FF3.5
сравнил колорпикером с легендой, именно в такой последовательности НА ВСЕХ ВЕРСИЯХ.
сравнил колорпикером с легендой, именно в такой последовательности НА ВСЕХ ВЕРСИЯХ.
Диаграмму читаете неправильно. Самый быстрый из всех — Safari, затем Opera, потом Chrome. На всех версиях.
То что FF в самом низу диаграммы вовсе не говорит что тут «смоллер из беттер». Тут чем уже, тем быстрее, а не чем ниже.
То что FF в самом низу диаграммы вовсе не говорит что тут «смоллер из беттер». Тут чем уже, тем быстрее, а не чем ниже.
прошу прощения, а цифры слева по оси Y для кого?
Да это график такой, блин.
Там высота каждого бара определяется суммой составляющих. А ширина составляющих говорит о их «весе» (в данном случае, чем шире блок — тем больше он по времени, при проецировании на ось Y).
Т.е. на графике сумма всех скоростей во всех браузерах на энном тестовом компе у jQuery 1.3.2 что-то около 19000...20000мс. При этом IE6 (на глаз) — около 6000мс, а Safari — что то около 400-500мс, тут уже на графике этого совсем не разглядеть без штангенциркуля =).
Там высота каждого бара определяется суммой составляющих. А ширина составляющих говорит о их «весе» (в данном случае, чем шире блок — тем больше он по времени, при проецировании на ось Y).
Т.е. на графике сумма всех скоростей во всех браузерах на энном тестовом компе у jQuery 1.3.2 что-то около 19000...20000мс. При этом IE6 (на глаз) — около 6000мс, а Safari — что то около 400-500мс, тут уже на графике этого совсем не разглядеть без штангенциркуля =).
На графике действительно время всех браузеров складывается и каждый сегмент обозначает время только этого браузера. Т.е. если смотреть на первый график, Fx 3.5 примерно равен IE8, а FF 3.6 Хрому.
НЛО прилетело и опубликовало эту надпись здесь
не верю, что FF обогнал Chrome и Safari…
Я увы вижу такую последовательность:
Ie6 -> ie7 -> ie8 -> Chrome -> Safari -> Opera -> FF3.6 -> FF3.5
И как-то мне если честно непонятно как скажем хром может быть медленее FF3.5
Ie6 -> ie7 -> ie8 -> Chrome -> Safari -> Opera -> FF3.6 -> FF3.5
И как-то мне если честно непонятно как скажем хром может быть медленее FF3.5
Это на 1.3.2.
А на 1.4.2 ie6 -> ie7 -> ie8 -> ff3.5 -> ff3.6
А на 1.4.2 ie6 -> ie7 -> ie8 -> ff3.5 -> ff3.6
я может что то недопонимаю, но для чего там легенда внизу?
в легенде последовательность слева направо, взаимооднозначно соответствует «слоям» на диаграмме снизу вверх, для всех трех вариантов.
FF везде примерно равен скорости хрома (а в 1.4.2 даже чуть тормознее), для меня удивительно, но Opera и Safari показывают лучшие результаты =)
в легенде последовательность слева направо, взаимооднозначно соответствует «слоям» на диаграмме снизу вверх, для всех трех вариантов.
FF везде примерно равен скорости хрома (а в 1.4.2 даже чуть тормознее), для меня удивительно, но Opera и Safari показывают лучшие результаты =)
Не волнуйтесь, скоро Опера это исправит. *sad*
Хм, забавно. А у меня более оптимистичные результаты…
Как оказалось, в первых сборках, задолго до беты, Опера 10.5 в этом тесте была даже быстрее 10.1 процентов на 30.
Ну у меня 10,5 попрежнему быстрее 10,1… Сча из интереса прогоню тест во всех браузерах
i48.tinypic.com/ab6owk.png — Я негодую O_o
Молодцы ребята!
наверное лучший фреймворк в своем классе.
наверное лучший фреймворк в своем классе.
в каком ещё классе?
JQuery — отличный фреймворк. Но маркетинг у них точно «лучший в своем классе». 8 из 15 возможностей, которые появились в 1.4, были в mootools или с версии 1.1 (вышла на 3 года раньше), или с версии 1.2 (вышла на 18 месяцев раньше). Еще 7 или реализуются с mootools за пол-часа, или есть в плагинах. 1й нет и просто не сделаешь (это event delegation для событий focusin и focusout), но это обещают в следующем релизе (и вроде как код в репозитории уже есть).
дело не только в наличии возможностей, Но и в простоте их использования
Синтаксис всех новых фич, кстати, практически 1 в 1 как в MooTools, за исключением более коротких (другой взгляд: «менее понятных») названий методов.
А вообще согласен. В jQuery и правда удобнее работа с DOM. Что часто является решающим фактором. Нет необходимости учить и понимать js, чтобы хоть что-то написать. Для какой-нибудь мелочи — идеальный вариант, можно просто и быстро добавить эффект на страницу или что-то в этом роде. API простой и хороший.
Но для программирования все же удобнее MooTools. Как минимум это поддержка более-менее современного синтаксиса js во всех браузерах. Ну и вообще заточено все для удобства программирования (даже название — My Object Oriented Tools).
Возможно, неплохим вариантом было бы даже совместное использование урезанных версий обеих библиотек — MooTools как основы (выкинув всю работу с DOM) и jQuery как API для манипуляций с DOM (выкинув все остальное).
А вообще согласен. В jQuery и правда удобнее работа с DOM. Что часто является решающим фактором. Нет необходимости учить и понимать js, чтобы хоть что-то написать. Для какой-нибудь мелочи — идеальный вариант, можно просто и быстро добавить эффект на страницу или что-то в этом роде. API простой и хороший.
Но для программирования все же удобнее MooTools. Как минимум это поддержка более-менее современного синтаксиса js во всех браузерах. Ну и вообще заточено все для удобства программирования (даже название — My Object Oriented Tools).
Возможно, неплохим вариантом было бы даже совместное использование урезанных версий обеих библиотек — MooTools как основы (выкинув всю работу с DOM) и jQuery как API для манипуляций с DOM (выкинув все остальное).
на самом деле так и делаю, для этого и есть переименования функции JQ, жаль что в MT нет такого переименования
в MooTools это есть, называется document.id, доступно с mootools 1.2.3
mootools.net/blog/2009/06/22/the-dollar-safe-mode/
mootools.net/blog/2009/06/22/the-dollar-safe-mode/
один я не вижу разницы между
$(«table»).delegate(«td», «hover»
и
$(«table td»).live(«hover»
?
зачем нужно было ещё одну сущность вводить?
$(«table»).delegate(«td», «hover»
и
$(«table td»).live(«hover»
?
зачем нужно было ещё одну сущность вводить?
$(«table td»).live(«hover») — назначает столько обработчиков, сколько и ячеек
$(«table»).delegate(«td», «hover») — назначает один обработчик на таблицу и передает в this нужную ячейку.
$(«table»).delegate(«td», «hover») — назначает один обработчик на таблицу и передает в this нужную ячейку.
Нет. live тоже назначает один обработчик на все ячейки. Разница только в том что контекстом в первом случае назначается document. Но контекст в live можно указать в аргументах если нужно его сузить. Вот и не понятно зачем нужно 2 функции, которые делают одно и тоже.
если не трудно киньте мне ссылку почитать про то что понимается под контекстом? это тот элемент DOM, который обрабатывает событие собственно? и если можно разъясните (опять же линком) как работает эта штука: она каждый раз ворочает эту функцию на родительском элементе или она на изменения дом модели пришивает новым элементам обработчик.
api.jquery.com/live/
там даже пример есть
$('div.clickme', $('#container')[0]).live('click', function() {
// Live handler called.
});
если контекст не указать, то будет document. И судя по всему да, событие вешается на контекст а в обработчик приходит this нужного элемента.
там даже пример есть
$('div.clickme', $('#container')[0]).live('click', function() {
// Live handler called.
});
если контекст не указать, то будет document. И судя по всему да, событие вешается на контекст а в обработчик приходит this нужного элемента.
С live вариантом контекстом к которому привязано событие будет document root и после каждого hover в нём будет искаться table td.
С delegate вариантом контекстом будет table.
С delegate вариантом контекстом будет table.
При определенных условиях это дает значительный выигрыш в быстродействии.
$(«table td»).live() найдет все td и повесит на document обработчик. Сами найденные td ему не нужны, но их поиск может занять много времени.
$(«table»).delegate(«td») будет искать только table.
$(«table td»).live() найдет все td и повесит на document обработчик. Сами найденные td ему не нужны, но их поиск может занять много времени.
$(«table»).delegate(«td») будет искать только table.
может быть live со временем станет deprecated и весь смысл в этом?
Простите за ламерский вопрос, а backward compatibility осуществляется? В cms используется 1.3.2, а в своих скриптах хотелось бы последнюю использовать.
Backwards-Incompatible Changes внизу страницы
Там же ссылка на плагин оебспечивающий совместимость с версией 1.3.2
Там же ссылка на плагин оебспечивающий совместимость с версией 1.3.2
Список не полный.
Простите за ламерский вопрос, но я смотрю на это сравнение производительности и никак не могу вспомнить хотя бы один пример когда производительность вычислений на клиентской части была bottleneck-ом. Я понимаю что чем больше попугаев тем лучше но все ж таки можно услышать пару-тройку примеров когда производительность JS критична?
KO: Google wave. Пример не единственный, но, пожалуй, самый узнаваемый.
Как интересно, предыдущий оратор начал свою рeчь точь-в-точь как Вы.
Отвечая на Ваш вопрос, можно сказать, что когда речь идет об единичных элементах их выборка или анимация, скорее всего, не будут серьезной нагрузкой. Но если допустим сотня элементов таблицы, и необходима сортировка по определенным параметрам, тут уже возможны нюансы. к примеру
Отвечая на Ваш вопрос, можно сказать, что когда речь идет об единичных элементах их выборка или анимация, скорее всего, не будут серьезной нагрузкой. Но если допустим сотня элементов таблицы, и необходима сортировка по определенным параметрам, тут уже возможны нюансы. к примеру
Версия сафари и оперы не указана. Производительность оперы радует, интересно, это 10.5 с новым движком, или 10.1? Особенно радует, что опера обошла традиционно быстрый в js Chrome.
Может, тут имеет место оптимизация оперы под jquery или наоборот, jquery под оперу?
Может, тут имеет место оптимизация оперы под jquery или наоборот, jquery под оперу?
Отличный пример того, как нельзя составлять диаграмму :)
Извините за офф-топ, но если кому интересно — друг написал о jQuery в песочницу, может кому пригодится статья, то поделится инвайтом… ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
jQuery 1.4.2