Когда использовать Vanilla JavaScript против jQuery?

Я заметил, что, наблюдая/пытаясь ответить на общие вопросы jQuery, есть определенные практики, использующие javascript вместо jQuery, которые фактически позволяют вам писать меньше и делать... ну ту же сумму. А также может принести пользу производительности.

Конкретный пример

$(this) vs this

Внутри события click, ссылающегося на объекты с кликами id

JQuery

$(this).attr("id");

Javascript

this.id;

Существуют ли другие распространенные практики? Там, где некоторые операции Javascript можно было бы сделать проще, без добавления jQuery в микс. Или это редкий случай? (из ярлыка jQuery, требующего больше кода)

РЕДАКТИРОВАТЬ: Хотя я ценю ответы на jQuery против простой производительности javascript, я на самом деле ищу гораздо более количественные ответы. При использовании jQuery экземпляры, где было бы лучше (удобочитаемость/компактность) использовать простой javascript вместо использования $(). В дополнение к примеру, который я дал в моем первоначальном вопросе.

Ответ 1

  • this.id (как вы знаете)
  • this.value (только для большинства типов ввода. Только те проблемы, которые я знаю, являются IE, когда <select> не имеет свойств value, установленных на его элементах <option> или радиовводах в Safari.)
  • this.className, чтобы получить или установить полное свойство "class"
  • this.selectedIndex против <select>, чтобы получить выбранный индекс
  • this.options против <select>, чтобы получить список элементов <option>
  • this.text против <option>, чтобы получить его текстовое содержимое
  • this.rows против <table>, чтобы получить набор элементов <tr>
  • this.cells против <tr>, чтобы получить его ячейки (td и th)
  • this.parentNode, чтобы получить прямой родительский
  • this.checked, чтобы получить проверенное состояние checkbox Спасибо @Tim Down
  • this.selected, чтобы получить выбранное состояние option Спасибо @Tim Down
  • this.disabled, чтобы получить отключенное состояние input Спасибо @Tim Down
  • this.readOnly, чтобы получить состояние readOnly input Спасибо @Tim Down
  • this.href для элемента <a>, чтобы получить его href
  • this.hostname для элемента <a>, чтобы получить домен его href
  • this.pathname для элемента <a>, чтобы получить путь к его href
  • this.search для элемента <a>, чтобы получить запрос от href
  • this.src в отношении элемента, в котором он имеет значение src

... Я думаю, вы поняли идею.

Бывают моменты, когда производительность имеет решающее значение. Например, если вы много раз выполняете что-то в цикле, вы можете захотеть перекопать jQuery.

В общем случае вы можете заменить:

$(el).attr('someName');

с:

Выше было плохо сформулировано. getAttribute не является заменой, но он извлекает значение атрибута, отправленного с сервера, и его соответствующий setAttribute установит его. Необходимо в некоторых случаях.

Присвоения ниже сокрыты. См. этот ответ для лучшего лечения.

el.getAttribute('someName');

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

Скажите, что у вас была ситуация, когда была получена страница, где вам нужно развернуть все теги определенного типа. JQuery очень коротко и просто:

$('span').unwrap();  // unwrap all span elements

Но если их много, вы можете сделать небольшой собственный DOM API:

var spans = document.getElementsByTagName('span');

while( spans[0] ) {
    var parent = spans[0].parentNode;
    while( spans[0].firstChild ) {
        parent.insertBefore( spans[0].firstChild, spans[0]);
    }
    parent.removeChild( spans[0] );
}

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

Может показаться, что у меня бесконечный цикл с внешним while из-за while(spans[0]), но поскольку мы имеем дело с "живым списком", он обновляется, когда мы делаем parent.removeChild(span[0]);. Это довольно замечательная функция, которую мы упускаем при работе с Array (или Array-подобным объектом).

Ответ 2

Правильный ответ заключается в том, что при использовании jQuery вместо "обычного старого" родного JavaScript вы всегда будете получать штраф за производительность. Это потому, что jQuery является библиотекой JavaScript. Это не какая-то причудливая новая версия JavaScript.

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

Обучение jQuery не заменяет изучение JavaScript. Вы должны иметь прочную основу в последнем, чтобы вы полностью понимали, что знание первого облегчает вам жизнь.

- Отредактировано для включения комментариев -

Как быстро комментируют комментарии (и я согласен со 100%), приведенные выше утверждения относятся к эталонному коду. "Самостоятельное" решение JavaScript (предполагая, что оно хорошо написано) будет превосходить решение jQuery, которое выполняет одно и то же почти в каждом случае (я бы хотел увидеть пример в противном случае). jQuery ускоряет время разработки, что является существенным преимуществом, которое я не имею в виду для преуменьшения. Это облегчает легко читаемый, простой в использовании код, который больше, чем некоторые разработчики могут создавать самостоятельно.

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

Ответ 3

Есть фреймворк, который называется... о, угадайте, что? Vanilla JS. Надеюсь, вы получите анекдот...: D Он жертвует удобочитаемостью кода для производительности... Сравнивая его с jQuery ниже, вы можете видеть, что получение элемента DOM на ID почти 35X Быстрее.:)

Итак, если вам нужна производительность, вам лучше попробовать Vanilla JS и сделать свои собственные выводы. Возможно, вы не столкнетесь с JavaScript, зависающим графическим интерфейсом браузера или блокировкой потока пользовательского интерфейса во время интенсивного кода, например внутри цикла for.

Vanilla JS - это быстрая, легкая кросс-платформенная платформа для создание невероятных мощных приложений JavaScript.

На их домашней странице есть несколько перфомансов:

enter image description here

Ответ 4

Там уже принят принятый ответ, но я считаю, что ответ, введенный непосредственно здесь, не может быть исчерпывающим в своем списке собственных методов/атрибутов javascript, которые практически гарантировали поддержку кросс-браузера. Для этого я могу перенаправить вас на quirksmode:

http://www.quirksmode.org/compatibility.html

Это, пожалуй, самый полный список того, что работает и что не работает в каком браузере в любом месте. Обратите особое внимание на раздел DOM. Его много читать, но дело не в том, чтобы читать все, а в том, чтобы использовать его в качестве ссылки.

Когда я начал серьезно писать веб-приложения, я распечатал все таблицы DOM и повесил их на стену, чтобы я сразу понял, что можно использовать и что требует взлома. В эти дни я просто google что-то вроде quirksmode parentNode compatibility, когда у меня есть сомнения.

Как и все остальное, суждение в основном зависит от опыта. Я бы не рекомендовал вам прочитать весь сайт и запомнить все проблемы, чтобы выяснить, когда использовать jQuery и когда использовать простой JS. Просто имейте в виду список. Это достаточно просто, чтобы искать. Со временем вы будете развивать инстинкт, когда простой JS предпочтительнее.


PS: PPK (автор сайта) также имеет очень хорошую книгу, которую я рекомендую читать

Ответ 5

Когда:

  • вы знаете, что существует неослабевающая поддержка кросс-браузера для того, что вы делаете, и
  • не нужно вводить значительно больше кода и
  • это не значительно менее читаемо, и
  • вы достаточно уверены, что jQuery не будет выбирать различные реализации на основе браузера для достижения лучшей производительности, а затем:

используйте JavaScript. В противном случае используйте jQuery (если можете).

Изменить. Этот ответ применяется как при выборе использования jQuery в целом, так и для его исключения, а также при выборе использования ванильного JS внутри jQuery. Выбор между attr('id') и .id зависит от JS, а выбор между removeClass('foo') и .className = .className.replace( new Regexp("(?:^|\\s+)"+foo+"(?:\\s+|$)",'g'), '' ) зависит от jQuery.

Ответ 6

Ответы других были сосредоточены на широком вопросе "jQuery vs. plain JS". Судя по вашему OP, я думаю, вы просто задавались вопросом, когда лучше использовать vanilla JS, если вы уже выбрали использовать jQuery. Ваш пример - прекрасный пример того, когда вы должны использовать vanilla JS:

$(this).attr('id');

Как медленнее, так и (по-моему) менее читабельным, чем:

this.id.

Это медленнее, потому что вам нужно развернуть новый объект JS, чтобы получить атрибут jQuery. Теперь, если вы собираетесь использовать $(this) для выполнения других операций, то непременно сохраните этот объект jQuery в переменной и действуйте с ним. Тем не менее, я столкнулся со многими ситуациями, когда мне нужен атрибут из элемента (например, id или src).

Существуют ли другие распространенные практики как это? Где определен Javascript операции могут быть выполнены проще, без приведения jQuery в микс. Или это редкий случай? (из jQuery "ярлык", фактически требующий больше кода)

Я думаю, что наиболее распространенным случаем является тот, который вы описываете в своем посте; люди обертывают $(this) в объект jQuery без необходимости. Я чаще всего вижу это с помощью id и value (вместо этого используя $(this).val()).

Изменить: Здесь статья, объясняющая, почему использование jQuery в случае attr() происходит медленнее. Исповедь: украл его из тега wiki, но я думаю, что стоит упомянуть о нем.

Изменить еще раз.. Учитывая последствия чтения/производительности при прямом доступе к атрибутам, я бы сказал, что хорошим правилом можно, по возможности, попытаться использовать this.<attributename>. Вероятно, есть некоторые случаи, когда это не будет работать из-за несогласованности браузера, но, вероятно, лучше попробовать это сначала и вернуться к jQuery, если он не работает.

Ответ 7

Если вы в основном обеспокоены производительностью, ваш основной пример попадает в гвоздь по голове. Вызов jQuery излишне или избыточно, IMHO, вторая основная причина медленной производительности (первая из которых - плохой обход DOM).

Это не пример того, что вы ищете, но я так часто вижу, что он упоминает: один из лучших способов ускорить работу ваших сценариев jQuery - это кеширование объектов jQuery и/или использование цепочки:

// poor
$(this).animate({'opacity':'0'}, function() { $(this).remove(); });

// excellent
var element = $(this);
element.animate({'opacity':'0'}, function() { element.remove(); });

// poor
$('.something').load('url');
$('.something').show();

// excellent
var something = $('#container').children('p.something');
something.load('url').show();

Ответ 8

Я обнаружил, что между JS и JQ существует совпадение. Код, который вы показали, является хорошим примером этого. Честно говоря, лучшей причиной использования JQ над JS является просто совместимость с браузером. Я всегда склоняюсь к JQ, даже если я могу что-то сделать в JS.

Ответ 9

Это мой личный взгляд, но поскольку jQuery - это JavaScript, я думаю, что теоретически он не может работать лучше, чем vanilla JS.

Но практически он может работать лучше, чем рукописный JS, поскольку один написанный вручную код может быть не таким эффективным, как jQuery.

Нижняя строка - для небольших вещей я склонен использовать vanilla JS, для интенсивных проектов JS мне нравится использовать jQuery, а не изобретать колесо - это также более продуктивно.

Ответ 10

Список прямых свойств первого ответа this как элемент DOM достаточно полный.

Вам также может быть интересно узнать некоторые другие.

Если это документ:

  • this.forms, чтобы получить HTMLCollection существующих форм документа,
  • this.anchors, чтобы получить HTMLCollection всех HTMLAnchorElements с name,
  • this.links, чтобы получить HTMLCollection всех HTMLAnchorElement с href,
  • this.images, чтобы получить HTMLCollection всех HTMLImageElement s
  • и то же самое с устаревшими апплетами как this.applets

Когда вы работаете с document.forms, document.forms[formNameOrId] получает так называемую или идентифицированную форму.

Если это форма:

  • this[inputNameOrId], чтобы получить указанное имя или идентифицированное поле

Если это поле формы:

  • this.type, чтобы получить тип поля

При изучении селекторов jQuery мы часто пропускаем обучение уже существующим свойствам HTML-элементов, которые так быстро доступны.

Ответ 11

$(this) отличается от this:

Используя $(this), вы гарантируете, что прототип jQuery передается на объект.

Ответ 12

Как обычно, я опаздываю на эту вечеринку.

Это не была дополнительная функциональность, из-за которой я решил использовать jQuery, столь привлекательным, как это было. Ведь ничто не мешает вам писать свои собственные функции.

Это был факт, что было так много трюков, чтобы учиться при модификации DOM, чтобы избежать утечек памяти (я говорю о вас IE). Чтобы иметь один центральный ресурс, который управлял всеми такими проблемами для меня, написанными людьми, которые были намного лучше JS-кодировщиками, чем когда-либо, будет постоянно пересматриваться, пересматриваться и проверяться, отправляется ли Бог.

Я предполагаю, что этот тип попадает под аргумент поддержки/абстракции браузера.

И, конечно же, jQuery не исключает использования прямого JS, когда вам это нужно. Я всегда чувствовал, что двое, похоже, работают вместе.

Конечно, если ваш браузер не поддерживается jQuery или вы поддерживаете низкую среду (более старый телефон?), тогда большой файл .js может быть проблемой. Помните, когда jQuery был крошечным?

Но обычно разница в производительности не вызывает беспокойства. Он должен быть достаточно быстрым. Когда Gigahertz циклов процессора тратится впустую каждую секунду, меня больше интересует производительность моих кодеров, единственных ресурсов разработки, которые не удваиваются в мощности каждые 18 месяцев.

Это говорит о том, что я сейчас изучаю проблемы доступности и, по-видимому,.innerHTML - это немного неважно. jQuery, конечно, зависит от .innerHTML, так что теперь я ищу структуру, которая будет зависеть от несколько утомительных методов, которые разрешены. И я могу представить, что такая структура будет работать медленнее, чем jQuery, но пока она будет работать достаточно хорошо, я буду счастлив.

Ответ 13

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

Фактически, на самом деле Google не разрешает jQuery ни в одном из своих кодов (или React, потому что он принадлежит Facebook), о котором вы, возможно, не знали, пока интервьюер не сказал: "Извините, но вы не можете использовать jQuery, это не утвержденный список в корпорации XYZ". Ванильный JavaScript работает абсолютно везде, каждый раз и никогда не даст вам этой проблемы. Если вы полагаетесь на библиотеку, вы получаете скорость и легкость, но теряете универсальность.

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