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

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

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

$(this) против this

Внутри события клика, ссылающегося на идентификатор кликаемых объектов

JQuery

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

Javascript

this.id;

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

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

• this.id (как вы знаете)
• this.value(для большинства типов ввода. Единственные проблемы, которые мне известны, это IE, когда свойства a <select>не valueустановлены на его <option>элементах, или радиовходы в Safari.)
• this.className получить или установить целое свойство класса
• this.selectedIndexпротив, <select>чтобы получить выбранный индекс
• this.optionsпротив, <select>чтобы получить список <option>элементов
• this.textпротив, <option>чтобы получить его текстовое содержание
• this.rowsпротив, <table>чтобы получить коллекцию <tr>элементов
• this.cellsпротив, <tr>чтобы получить его клетки (тд и т)
• this.parentNode чтобы получить прямой родитель
• this.checkedчтобы получить проверенное состояние checkbox Спасибо @Tim Down
• this.selectedчтобы получить выбранное состояние option Спасибо @Tim Down
• this.disabledчтобы получить отключенное состояние input Спасибо @Tim Down
• this.readOnlyчтобы получить состояние input ReadOnly Спасибо @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]);. Это довольно изящная функция, которую мы упускаем при работе с массивом (или объектом, похожим на массив).

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

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

Изучение jQuery не заменит изучение JavaScript. У вас должна быть прочная основа в последнем, чтобы вы в полной мере оценили то, что знание первого облегчает вам задачу.

- Отредактировано, чтобы охватить комментарии -

Поскольку комментарии быстро указывают (и я согласен со 100%), приведенные выше утверждения относятся к бенчмаркингу. «Нативное» решение JavaScript (при условии, что оно хорошо написано) превзойдет решение jQuery, которое выполняет то же самое почти в каждом случае (я хотел бы увидеть пример в противном случае). JQuery ускоряет время разработки, что является значительным преимуществом, которое я не хочу преуменьшать. Он обеспечивает легкий для чтения, легкий для понимания код, который некоторые разработчики могут создавать самостоятельно.

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

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

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

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

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

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

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

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

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

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

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

Когда:

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

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

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

Ответы других были сосредоточены на широком вопросе «JQuery против простого 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()случае медленнее. Исповедь: украл ее из тега вики, но я думаю, что стоит упомянуть вопрос.

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

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

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

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

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

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

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

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

Когда это документ:

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

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

Когда это форма:

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

Когда это поле формы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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