Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
[боян]преждевременная оптимизация корень всех зол[/боян]
фреймворки существуют для упрощения и ускорения _разработки_. а скорость создания всплывающего окошка _совершенно_ не важна. поэтому надо выкинуть оба говнокода и применить шаблонизацию.
фреймворки существуют для упрощения и ускорения _разработки_. а скорость создания всплывающего окошка _совершенно_ не важна. поэтому надо выкинуть оба говнокода и применить шаблонизацию.
Вашей статье не хватает цели (основной мысли), которую она должна донести читателям и структурности. Получилось нечто вроде " можно и на jQuery, но на JavaSscript примерно так-же но еще и быстрее, а вообще это только инструменты, не хотите не используйте, а еще тут есть реиспользование, но я его расположил между двумя частями про скорость работы, поэтому вы его все равно не запомните". Попробуйте вынести вопросы реиспользования в отдельную статью с более подробными примерами, а performance как-то оправдать и показать его важность (что само по себе трудная задача) в отдельной статье.
Поддерживаю. И хочу узнать у автора какова цель этой статьи? Какую проблему попытались освятить и разъяснить? Что нового хотели донести до читателей? и т.п.
По-моему, проблема сразу видна — «Фреймворк вытесняет язык сам по себе». И проблема, на самом деле, очень актуальна. Вы пробовали искать в гугле что-нибудь про javascript? Всевозможные форумы и т.п. ресурсы давно забиты ответами в стиле «Using jQuery you can do… », даже если вопрос состоит, к примеру, к вытаскиванию значения из текстового поля.
> «Фреймворк вытесняет язык сам по себе»
— почему это плохо?
— почему это плохо?
Хотя бы потому, что у нативной реализации меньше проблем с переносимостью
Это точно про js?
Все зависит от конкретной задачи. Если изначально стоит цель написать переносимый код (например это какая-та библиотека), то было бы глупо ориентировать его на конкретный фреймворк.
А если просто реализовать задачу как можно быстрее, зачем с нуля реализовывать обработчики событий, назначение прозрачности и прочую кроссбраузерную фигню, так сказать писать свой недофреймворк, если уже есть готовый, протестированный и к тому же поддерживаемый коммьюнити. Оптимизацию можно провести позже, когда уже будет видно, где узкие места.
А если просто реализовать задачу как можно быстрее, зачем с нуля реализовывать обработчики событий, назначение прозрачности и прочую кроссбраузерную фигню, так сказать писать свой недофреймворк, если уже есть готовый, протестированный и к тому же поддерживаемый коммьюнити. Оптимизацию можно провести позже, когда уже будет видно, где узкие места.
Для начинающих осваивать js (да и любой другой язык, который «вытесняется фреймворком»), по-моему, да. Полно js-«программистов», которые без jquery (extjs, ...) простейшую валидацию написать не смогут, или ruby/python-«программистов», которые без рельс/джанго «hello, %username%» не напишут. А ведь при разработке на заказ может быть требование, например, не использовать FOSS.
тогда уж быстрее всего будет не использовать jQuery;
но времени на разработку уйдёт, конечно, много, зато результат будет стоящий
но времени на разработку уйдёт, конечно, много, зато результат будет стоящий
относительно «Нативного кода», хотел бы обратить внимание топикстартера на новый синтаксис jQuery 1.4 и на очевидную потерю скорости от использования inline styles
А где можно почитать про «очевидную потерю скорости от использования inline styles »?
И Вы имеете ввиду что классы надо использовать или просто что прям при создании с помощью нового синтаксиса стили прописывать?
Если первое, то тут обратная точка зрения
И Вы имеете ввиду что классы надо использовать или просто что прям при создании с помощью нового синтаксиса стили прописывать?
Если первое, то тут обратная точка зрения
отнюдь, как я понял, sky_lord как раз и говорит о том, что правильно делать не $('#foobar').hide(), а $('#foobar').addClass('hide'), а в css:
.hide {
display:none
}
что применение элементу класса «hide», у которого внутри написано «display: none», вызывает reflow, а не redraw в отличие от применения инлайнового стиля с тем же самым «display: none».
class -> reflow
inline -> redraw
А redraw раза в три-четыре (в моем конкретном случае) быстрее, чем reflow,
Я бы, конечно, про это ещё почитал, так как не совсем ясно именно наличие
у которого внутри написано «display: none».
вдогонку. почитать про то, что добавить класс(в котором прописаны стили) быстрее, чем через js поменять стиль можно тут
действительно, sky_lord'a обременяет как ни странно reflow и думаю тут можно про это почитать(статья четырехлетней давности, сейчас все было должно уже измениться; вкратце, мобильные устройства очень нагружает работа с dom)
так же reflow может быть менее выгодным в случае сложных селекторов и изменений, которые коснутся детей элемента.
с другой стороны, практика показывает, что reflow быстрее redraw, да и сами инлайн стили никак не вписываются в современную концепцию ненавязчивого(unobtrusive) javascript'а
так же reflow может быть менее выгодным в случае сложных селекторов и изменений, которые коснутся детей элемента.
с другой стороны, практика показывает, что reflow быстрее redraw, да и сами инлайн стили никак не вписываются в современную концепцию ненавязчивого(unobtrusive) javascript'а
Если уж решились использовать фреймворк, то и надо использовать его.
Расплата за это — снижение скорости и размер.
Плюсы — снижение времени на разработку, приемственность кода и кроссбраузерность.
А делая микс из простого js и фреймворка вы таким образом ставите под сомнение цель, ради которой вы и используете фреймворк.
Так что лучше либо использовать все плюшки jq либо писать на чистом js если нужна скорость.
Расплата за это — снижение скорости и размер.
Плюсы — снижение времени на разработку, приемственность кода и кроссбраузерность.
А делая микс из простого js и фреймворка вы таким образом ставите под сомнение цель, ради которой вы и используете фреймворк.
Так что лучше либо использовать все плюшки jq либо писать на чистом js если нужна скорость.
используйте фреймворки, о скорости должен заботится браузер :)
В последнем примере ничего не понял.
> Оба примера хороши: первый — изящный, второй — быстрый.
Что значит быстрый? Срабатывает за 5ms вместо 7ms? А смысл?
> Оба примера хороши: первый — изящный, второй — быстрый.
Что значит быстрый? Срабатывает за 5ms вместо 7ms? А смысл?
а цель любого приложения — это скорость выполнения и правильность результатовУдивительные вещи!
Не хватает тестов.
Что вам дадут таблички с результатами чьих-то тестов, кроме слепой веры, либо недоверия?
Скачайте исходники jQuery и разберитесь как он делает то или иное действие. Преимущества либо недостатки станут яснее и эти знания будут для вас гораздо полезнее, чем чьи-то таблицы с цыфрами.
Скачайте исходники jQuery и разберитесь как он делает то или иное действие. Преимущества либо недостатки станут яснее и эти знания будут для вас гораздо полезнее, чем чьи-то таблицы с цыфрами.
первый тезис автора. ради справедливости модифицировал:
для фаерфокса еще справедлива конструкция for each...in (введена в javascript 1.6, некроссбраузерна)
результаты следующие($.each, for, for each):
Firefox 3.6.8: 18ms 23ms 14ms
Chrome 6.0.472.51beta: 10ms 19ms —
Opera 10.61:4ms 1ms —
IE8*:16ms 16ms —
* (в промежуточных циклах выдавал иногда 0ms, хотя контрольная сумма в итоге совпала)
ps. вместо for (var i = 0, l = a.length; i < l; i++) можно смело использовать for (var i = 0; i < a.length; i++) — современные интерпретаторы сами оптимизируют, зато код получается менее громоздким
$.each(a, function (i)и заменил вывод в консоль на последовательное сложение 10000 эл-тов псевдослучайно сгенерированного целочисленного массива(от 1 до 10). пять проходов.
{
console.log(a[i]);
});
для фаерфокса еще справедлива конструкция for each...in (введена в javascript 1.6, некроссбраузерна)
результаты следующие($.each, for, for each):
Firefox 3.6.8: 18ms 23ms 14ms
Chrome 6.0.472.51beta: 10ms 19ms —
Opera 10.61:4ms 1ms —
IE8*:16ms 16ms —
* (в промежуточных циклах выдавал иногда 0ms, хотя контрольная сумма в итоге совпала)
ps. вместо for (var i = 0, l = a.length; i < l; i++) можно смело использовать for (var i = 0; i < a.length; i++) — современные интерпретаторы сами оптимизируют, зато код получается менее громоздким
На самом деле соглашусь с тем, что автор не вполне четко донес свою мысль. Сама по себе скорость Javascript в отрыве от задач, естественно, никому не важна. И да — преждевременная оптимизация это зло, грех и ересь. :-)
Но не стоит забывать что сейчас появляется все больше устройств и пользователей, которые работают не с компьютера. И если на Phenom2 многогигагерцовой частоты 7ms вместо 5ms — это фигня, конечно, то на всяких мобильных девайсах и различных встроенных решениях, которые работают на слабеньких ARM'ах или тем более MIPS'ах, разница между скоростью любого фреймворка (не обязательно jQuery), отягощенного грузом совместимостей с IE/FF2 и пытающегося объять необъятное, и нативным Javascript — огромна.
Вообще, это все крайне забавно, но на новом уровне повторяется классическая история одного байта. Только теперь уже не с ассемблером, а с Javascript (что само по себе ни в какие ворота не лезет). Одни люди навешивают «рюшечки» через jQuery и знать ничего не хотят о скорости, а другие вынуждены помнить, что применение элементу класса «hide», у которого внутри написано «display: none», вызывает reflow, а не redraw в отличие от применения инлайнового стиля с тем же самым «display: none». А redraw раза в три-четыре (в моем конкретном случае) быстрее, чем reflow, а значит окно появится на экране не через 1800-2000 ms, а в пределах 500ms (числа вполне реальные — именно столько у меня выдает Опера работающая на 400Мгц MIPS'овом SoC'е), что совершенно радикальным образом влияет на юзабельность интерфейса и его отзывчивость. :-)
Поэтому на месте автора я бы привел конкретных примеров, где скорость Javascript имеет значение, а на месте критиков не спешил бы закидывать автора тухлыми помидорами только потому, что у вас нет опыта разработки под что-нибудь кроме настольных компов. :-)
Но не стоит забывать что сейчас появляется все больше устройств и пользователей, которые работают не с компьютера. И если на Phenom2 многогигагерцовой частоты 7ms вместо 5ms — это фигня, конечно, то на всяких мобильных девайсах и различных встроенных решениях, которые работают на слабеньких ARM'ах или тем более MIPS'ах, разница между скоростью любого фреймворка (не обязательно jQuery), отягощенного грузом совместимостей с IE/FF2 и пытающегося объять необъятное, и нативным Javascript — огромна.
Вообще, это все крайне забавно, но на новом уровне повторяется классическая история одного байта. Только теперь уже не с ассемблером, а с Javascript (что само по себе ни в какие ворота не лезет). Одни люди навешивают «рюшечки» через jQuery и знать ничего не хотят о скорости, а другие вынуждены помнить, что применение элементу класса «hide», у которого внутри написано «display: none», вызывает reflow, а не redraw в отличие от применения инлайнового стиля с тем же самым «display: none». А redraw раза в три-четыре (в моем конкретном случае) быстрее, чем reflow, а значит окно появится на экране не через 1800-2000 ms, а в пределах 500ms (числа вполне реальные — именно столько у меня выдает Опера работающая на 400Мгц MIPS'овом SoC'е), что совершенно радикальным образом влияет на юзабельность интерфейса и его отзывчивость. :-)
Поэтому на месте автора я бы привел конкретных примеров, где скорость Javascript имеет значение, а на месте критиков не спешил бы закидывать автора тухлыми помидорами только потому, что у вас нет опыта разработки под что-нибудь кроме настольных компов. :-)
Честно говоря я огромнейшие благодарен автору текущего топа, а так же автору топа: Правила эффективного использования jQuery, но все же мне кажется что суть обоих тем не отражает ключевую информацию.
Хотелось бы иметь наглядную инструкцию в которой бы было описана последовательность запиписей от самого быстрого к самому медленному.
Если брать за основу Правила эффективного использования jQuery — то судя по каментам было допущено много ошибок, а на самом деле та или иная запись не так уж и быстрая.
Получается так себе конфуз, в начале автор темы говорит правильно так, а потом как видно из каментов, все совершенно иначе. Кому верить?
Лично для меня, как разработчика который начинает вникать в тонкости JQuery, подобного рода информация на вес золота, и нет желания учить делать не правильно.
В идеале я, да и уверен что и не только я, был бы безумнейшие благодарен за шпоргалку в стиле: Шпаргалка по API jQuery 1.4 где было бы расписано по-полочка какое обращение к элементу страницы быстрее от остальных.
Что же касается текущего топа, так конечный смысл размыт. Непонятно в каких случаях что использовать. Или чистый JS или JQuery.
Понятно что есть уникальные ситуации которые требуют соответствующего подхода, но есть стандартные ситуации когда использовать JS целесообразнее нежели JQ, и наоборот. Узнать про такие ситуации хотелось бы.
+ некоторые ньюансы в каких случаях и когда тот или иной подход работает быстрее в отличие от остальных
Кстати по теме. Скорость работы Fоr быстре по сравнению с Each, но не всегда. Вот тут детализированный прув.
Хотелось бы иметь наглядную инструкцию в которой бы было описана последовательность запиписей от самого быстрого к самому медленному.
Если брать за основу Правила эффективного использования jQuery — то судя по каментам было допущено много ошибок, а на самом деле та или иная запись не так уж и быстрая.
Получается так себе конфуз, в начале автор темы говорит правильно так, а потом как видно из каментов, все совершенно иначе. Кому верить?
Лично для меня, как разработчика который начинает вникать в тонкости JQuery, подобного рода информация на вес золота, и нет желания учить делать не правильно.
В идеале я, да и уверен что и не только я, был бы безумнейшие благодарен за шпоргалку в стиле: Шпаргалка по API jQuery 1.4 где было бы расписано по-полочка какое обращение к элементу страницы быстрее от остальных.
Что же касается текущего топа, так конечный смысл размыт. Непонятно в каких случаях что использовать. Или чистый JS или JQuery.
Понятно что есть уникальные ситуации которые требуют соответствующего подхода, но есть стандартные ситуации когда использовать JS целесообразнее нежели JQ, и наоборот. Узнать про такие ситуации хотелось бы.
+ некоторые ньюансы в каких случаях и когда тот или иной подход работает быстрее в отличие от остальных
Кстати по теме. Скорость работы Fоr быстре по сравнению с Each, но не всегда. Вот тут детализированный прув.
1)
Запустите в IE, потом запустите в любом другом браузере. Забудьте про for..in. Юзайте $.each
2)
<table>
<tr><td id=«t1»>1</td></tr>
<tr><td id=«t2»>2</td></tr>
</table>?
<script>
$("#t1").html('changed')
</script>
Сделайте то же самое на нативном JS для IE. А теперь забудьте про нативный JS.
для тех, кто не знает, в Jscript нельзя применять свойство innerHTML для ячеек таблиц
3)
Совет для портируемости кода — создайте объект и кладите ваши часто используемые функции в него (в качестве методов). А вообще в обычное время хватает и простого замыкания, в котором и свои глобальные переменные есть.
Не надо гадить глобальными переменными.
Не надо расширять прототипы стандартных объектов (в т.ч. DOM). Это может выйти боком. Могу пошарить ссылку на статью Дугласа Крокфорда, где подробно расписано почему.
Не надо расширять прототип $ :) Даже если плагина с таким названием пока не существует, не факт, что это название не захочет занять ваш сосед (наверняка, если это делаете вы, то это делает и он)
var a = [1,null, undefined, 4];
for (e in a) {
alert(a[e]);
}
Запустите в IE, потом запустите в любом другом браузере. Забудьте про for..in. Юзайте $.each
2)
<table>
<tr><td id=«t1»>1</td></tr>
<tr><td id=«t2»>2</td></tr>
</table>?
<script>
$("#t1").html('changed')
</script>
Сделайте то же самое на нативном JS для IE. А теперь забудьте про нативный JS.
для тех, кто не знает, в Jscript нельзя применять свойство innerHTML для ячеек таблиц
3)
Совет для портируемости кода — создайте объект и кладите ваши часто используемые функции в него (в качестве методов). А вообще в обычное время хватает и простого замыкания, в котором и свои глобальные переменные есть.
Не надо гадить глобальными переменными.
Не надо расширять прототипы стандартных объектов (в т.ч. DOM). Это может выйти боком. Могу пошарить ссылку на статью Дугласа Крокфорда, где подробно расписано почему.
Не надо расширять прототип $ :) Даже если плагина с таким названием пока не существует, не факт, что это название не захочет занять ваш сосед (наверняка, если это делаете вы, то это делает и он)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
jQuery без рамок