Целью этого тематического исследования является сравнение производительности Javascript и стоимости выбора jQuery в качестве решения любой проблемы .

Почему именно jQuery? Это самая используемая библиотека Javascript в мире и одновременно наиболее критикуемая.

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

Что ж, я должен признать: я использовал его много и, как многие разработчики JavaScript, я начал использовать его еще до Vanilla Javascript.

Сила ванили

Нет, это не другая библиотека, это просто простой Javascript без дополнительных библиотек. Для взаимодействия с DOM (объектной моделью документа) он использует API, стандартизованный W3C.

Поскольку веб-браузеры могут понимать только простой JS, каждая интерфейсная библиотека должна использовать его для внутренних целей.

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

Но сколько кода упаковано? Что ж, на самом деле намного и даже больше, чем вам нужно.

Движок jQuery

Как библиотека, jQuery создана для предоставления набора полезных функций для управления DOM.

Ядром библиотеки является механизм выбора . Таким образом, мы можем выбирать и запрашивать любой элемент и даже создавать новые!

Чтобы это стало возможным, jQuery должен выполнить массу операций, чтобы понять, что вы ищете. За кулисами он запускает движок под названием Sizzle, который содержит более 2000 строк кода.

Этот факт подводит нас к сути: если вы знаете, какие манипуляции вам нужны, зачем позволять jQuery выполнять тонну операций вместо того, чтобы выполнять их простым вызовом API на простом JS?

Пример из практики

«Хорошо, jQuery не самый быстрый, но действительно ли он влияет на производительность?»

Чтобы ответить на этот вопрос, я поместил Vanilla Javascript и последнюю версию jQuery (3.3.1.min) рядом.

Задание

Задача требовала поместить 10.000 новых элементов с классом внутри целевого элемента. 10.000 элементов могли показаться преувеличением, но цель была немного напрягать участников.

тестовый код jQuery

Распространенный (и наихудший) способ выполнить задачу:

for(let i = 0; i < 10000; i++) {
   $('#target').append($('<div />').addClass('test-div'));
}

Тестовый код Vanilla JS

Правильный способ выполнить задачу на простом Javascript:

const c = document.createDocumentFragment();
for(let i = 0; i < 10000; i++) {
   const e = document.createElement('div');
   e.className = 'test-div';
   c.appendChild(e);
}
document.getElementById('target').appendChild(c);

Вы можете заметить странный метод в первой строке:

document.createDocumentFragment();

Что это? Mozilla резюмирует это для меня:

DocumentFragments - это узлы DOM. Они никогда не являются частью основного дерева DOM. Обычный вариант использования - создать фрагмент документа, добавить элементы к фрагменту документа, а затем добавить фрагмент документа в дерево DOM. В дереве DOM фрагмент документа заменяется всеми его дочерними элементами.

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

Но, возможно, я мог бы подробнее рассказать об этом в другой статье.

Инструмент

Чтобы измерить производительность, я запускаю свои скрипты в инструменте Chrome Profiler.

Полученные результаты

Как и следовало ожидать, Vanilla выполнил задачу за 18,99 мс, тогда как jQuery выполнил это за 195,89 мс. В десять раз быстрее.

Глядя на временную шкалу, мы также можем увидеть большую разницу в вызове стека для оценки скрипта.

Почему jQuery медленнее?

Давайте подробно рассмотрим вызов стека:

Как было сказано ранее, jQuery завершает набор операций для выполнения задачи.

В разделе Стек скриптов показаны все операции и время, затраченное на их выполнение.

Мы ясно видим, что для добавления узла в DOM требуется всего лишь один вызов Vanilla, который напрямую взаимодействует с DOM API, тогда как jQuery запускает множество операций (стек был слишком длинным, чтобы соответствовать изображению). Разница очевидна:

  • Ваниль: 4 мс
  • jQuery: 95,3 мс

Vanilla Javascript почти в 25 раз быстрее, чем jQuery при добавлении.

Кто-то мог сказать:

"Это всего лишь меньше 200 мс, кого это волнует ???"

Это зависит. Бывают ситуации, когда веб-приложениям необходимо постоянно обновлять dom (например, анимацию), и такая «микрооптимизация» может существенно повлиять на предотвращение мусора. .

Джанк - это любое заикание, дрожание или просто остановка, которую пользователи видят, когда сайт или приложение не успевают за частотой обновления.

Заключение

И что теперь? Следует ли избегать jQuery в каждом проекте?

Не совсем. Цель этой статьи - помнить, что проще не всегда означает лучше, а использование «уровней абстракции» может повлиять на производительность.

У jQuery есть гигантское сообщество, которое постоянно работает с командой jQuery над улучшением выпуска библиотеки за выпуском. Некоторые функции, такие как интеграция с AJAX или бесконечная коллекция плагинов, превосходны и готовы к использованию.

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

Взвесьте все за и против и выберите подходящий инструмент для работы.