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

В большинстве проектов, над которыми я работал, мы использовали jQuery, как и многие другие. Когда я начал работать в 1&1 и работал над поисковым проектом web.de и gmx.net, в этом проекте производительность была важной частью программного обеспечения, поэтому я более внимательно изучил загруженные активы и задался вопросом, что мы можно избавиться. В таком случае:

«Действительно ли нам нужен jQuery?»

Я взглянул на части API, которые использовались в проекте, и был искренне удивлен результатом. В проекте использовалось всего пять вещей:

  • Выбор элемента
  • Обработка событий
  • Ajax-запросы
  • добавить-/удалитькласс
  • анимация постепенного появления/исчезновения

Итак, давайте перефразируем: мы загружаем 32 КБ в минимизированном и сжатом виде только для этих пяти вещей.

Создай сам

Хорошо, моя идея заключалась в том, чтобы создать небольшой набор утилит для решения этой проблемы. Две вещи действительно легко заменить: «add-/removeClass» и «Ajax-запросы», которые легко написать самостоятельно.

Но кое-что осталось, верно? В то время требования к качеству вынуждали меня поддерживать Internet Explorer 6, поэтому я не мог использовать классные нативные API, такие как `querySelectorAll`. Но, к счастью, мне не нужно было поддерживать все классные функции движка sizzle selector.

Выбор элемента стал проще. Мне просто нужно выбрать `document`, `window` и несколько элементов, которым я могу присвоить атрибут ID. Это довольно просто архивировать, а сложность сводится к нескольким операторам if else.

Следующим API, который нужно заменить, является механизм fadeIn/Out. Я поговорил с дизайнером, и они сказали, что это всего лишь оптический сахар, и он не должен работать в каждом браузере, и что было бы нормально, если бы он работал только для современных браузеров, поэтому мы можем пойти по пути прогрессивного улучшения, и я создал небольшой функциональность, основанная на двух классах CSS3 `.fade` и `.in`, для появления и исчезновения элементов с помощью `css-переходов`.

Сложнее всего реализовать обработку событий jQuery. Поэтому я посмотрел на использование on в проекте и попытался уменьшить сложность этого метода. Оказалось, что мы не используем много классных вещей, таких как делегирование и удаление событий. Это хорошие новости, и было бы достаточно, если бы мы реализовали метод, который обрабатывает только имя кросс-браузерного события и принимает функцию обратного вызова. Это просто, верно?

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

Вывод

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