JQuery - хорошие части?

Ответ 1

Я определенно говорю

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

• не использовать .each() или $.each() неактивно. Иногда это может помочь, поскольку оно вводит замыкание, но часто достаточно простого цикла.

• единственный способ узнать, будет ли сложная селекторная строка или набор цепочечных вызовов функций быстрее, - это проверить все подходы.

• использовать делегирование событий при привязке одного и того же обработчика событий к более чем трем элементам (я увижу, могу ли я выкопать ресурс для более чем трех элементов, я, кажется, помню статью, в которой сравнивались прямые привязки и делегирование по нескольким различным факторам и нашел более трех, чтобы быть волшебными числами).

• Прежде всего, не беспокойтесь о производительности, если это не проблема. 200 мс по сравнению с 300 мс, кто будет знать разницу? 200 мс по сравнению с 1000 мс, возможно, время, чтобы посмотреть на оптимизацию:)

• быть максимально конкретным с помощью ваших селекторов и помогать тем бедным старым версиям IE.

Ответ 2

Wow, я просто не могу поверить, что никто не упомянул о хранении объектов в переменных для будущего использования.

Рассмотрим этот сценарий.
У вас есть сложное меню, в котором вы собираетесь написать 100 строк jQuery для.

ОЧЕНЬ ОЧЕНЬ Я вижу что-то вроде

$(".menu").fadeIn("slow");
$(".menu li").each(bla bla);
$(".menu li").hover(more bla bla);
if($(".menu").attr('id') == 'menu1') {some hoo ha}

Если вы собираетесь повторно использовать элемент в jQuery, ВСЕГДА сохраните его в переменной. Также общепринятой практикой является добавить знак доллара ($) перед именем переменной, чтобы указать объект jQuery.

var $menu = $(".menu"); // store once and reuse a million times
var $menu_item = $("li", $menu); // same here

$menu.fadeIn("slow");
$menu_item.each(bla bla);
$menu_item.hover(more bla bla);
if($menu.attr('id') == 'menu1') {some hoo ha}

Ответ 3

Некоторые из ваших вопросов сосредоточены на производительности.

Как правило, jQuery не может работать лучше, чем базовый Javascript. jQuery не взаимодействует напрямую с браузером или операционной системой; он просто предоставляет оболочку вокруг встроенных функций Javascript. Таким образом, при абсолютном минимуме вызов функции jQuery приводит к накладным расходам дополнительного вызова функции.

Во многих случаях jQuery действительно делает довольно тяжелый подъем, чтобы получить результат, когда написанный вручную "чистый" Javascript может избежать этой работы.

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

Итак, лучший ответ на ваши вопросы о производительности: не беспокойтесь об этом. Если вы столкнулись с проблемой производительности, тогда рассмотрите jQuery как одну из возможных целей оптимизации.

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

Ответ 4

В настоящее время основным правилом с javascript является то, что он имеет злобное время выполнения (на не-точных современных браузерах), но dom access/manipulation является сумасшедшим медленным. Чем быстрее выполняется время работы JS, тем больше DOM становится узким местом.

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

как побочная заметка, идиоматический jquery использует javascript правильно. Благодарите за компоновку функций над ООП, используйте закрытие для инкапсуляции, не смешивайте обработчики javascript (или запрещаете небо, блоки script) в своем html и рассматривайте объекты как мешки для имущества, которые вы можете прикреплять или отделять вещи по своему усмотрению.

Ответ 5

Я не эксперт, но я узнал пару вещей.

Не злоупотребляйте атрибутами HTML, это означает, что вы не сохраняете свои предполагаемые изображения перевернутого изображения в rel/rev, вместо этого используйте фоновое изображение. Это также помогает с выполнением рулонов в IE, поскольку IE не нравится, когда вы изменяете атрибут src на лету.

Также hover-intent очень полезно использовать вместо того, чтобы просто использовать .hover:)

Ответ 6

Мои два цента: не стоит недооценивать силу команды jQuery (Resig an Co.) - их намерение не просто привести вас к успеху в производительности. При этом здесь: когда вы используете селектор (который является запросом в jQuery), не забудьте использовать [context].

Итак, скажем, у вас есть table с 243 строками --- и вы не отметили каждый tr id (потому что вы классные). Таким образом, вы щелкаете, скажем, button в строке с событием. Событие для button должно искать текущую строку для виджета select. Внутренности события click() могут иметь следующие строки:

var tr = $(this).closest('tr'); //where $(this) is your button
$('td select', tr).css('color', 'red');

Таким образом, в последней строке выполняется поиск элементов select в контексте строки таблицы (tr). Этот поиск означает, что он быстрее, чем поиск всей таблицы (или всей страницы) для id или чего-то подобного.

Здесь также подразумевается, что я доверяю команде jQuery, что их реализация метода jQuery.closest() выполняется быстро и эффективно. Пока у меня нет причин не доверять.