jQuery без рамок

[боян]преждевременная оптимизация корень всех зол[/боян]
фреймворки существуют для упрощения и ускорения _разработки_. а скорость создания всплывающего окошка _совершенно_ не важна. поэтому надо выкинуть оба говнокода и применить шаблонизацию.

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

относительно «Нативного кода», хотел бы обратить внимание топикстартера на новый синтаксис jQuery 1.4 и на очевидную потерю скорости от использования inline styles

Если уж решились использовать фреймворк, то и надо использовать его.

Расплата за это — снижение скорости и размер.
Плюсы — снижение времени на разработку, приемственность кода и кроссбраузерность.

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

Так что лучше либо использовать все плюшки jq либо писать на чистом js если нужна скорость.

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

а цель любого приложения — это скорость выполнения и правильность результатов

Удивительные вещи!

Не хватает тестов.

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

1)

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). Это может выйти боком. Могу пошарить ссылку на статью Дугласа Крокфорда, где подробно расписано почему.
Не надо расширять прототип $ :) Даже если плагина с таким названием пока не существует, не факт, что это название не захочет занять ваш сосед (наверняка, если это делаете вы, то это делает и он)