Хабрахабр

[Перевод] Рассказ о том, почему я до сих пор использую jQuery

imageМногие, когда речь заходит о jQuery, говорят так: «Просто пользуйтесь обычным JavaScript. Библиотека jQuery вам не нужна». Что тут сказать? Я не нуждаюсь во многих вещах, но, несмотря на это, хорошо, когда они есть. Так и jQuery. Я в этой библиотеке не нуждаюсь, но её, определённо, приятно иметь под рукой.

Но самый первый пример на этом сайте демонстрирует вескую причину jQuery использовать. Сайты наподобие You might not need jQuery (YMNJQ) продвигают идею, в соответствии с которой от jQuery очень легко избавиться. Это — если мягко выразить моё к ним отношение. Там строка простого кода на jQuery заменяется на 10 строк обычного JS!
Большинство API JavaScript, в особенности те из них, которые нацелены на работу с DOM, оскорбляют мои эстетические чувства. Например, конструкция el.insertAdjacentElement('afterend', other), безусловно, работает. Если же говорить прямо, то я думаю, что эти API — полный кошмар. Хотя мне никогда особо не нравился внешний вид функции $(), она несравненно лучше, чем то, что дают нам стандартные API для работы с DOM. Но куда приятнее выглядит $(el).after(other). Но программирую я не в безвоздушном пространстве. Я знаю о том, что вместо $() можно использовать нечто вроде jQuery(sel) или window.jq = jQuery. Не знаю, хорошо это или плохо, но стандартом при использовании jQuery стала конструкция $(). Поэтому предпочитаю пользоваться стандартными приёмами.

Что для этого использовать — nextSibling или nextElementSibling? Попытайтесь быстро вспомнить о том, как получить элемент-сосед другого элемента средствами DOM. А какие браузеры поддерживают тот или иной метод? А в чём разница? Пока вы пытаетесь это вспомнить и заглядываете на MDN, проверяя себя, я, пользуясь jQuery, просто пишу next() или prev().

Я мог бы привести тут целый список таких операций, но за меня это отлично сделано на странице YMNJQ. Выполнение многих обычных операций реализовано в JavaScript-API неудобно.

И на сайте YMNJQ, опять же, можно найти немало примеров. Для решения различных простых задач средствами JS нужны вспомогательные функции. При этом программисту не нужно каждый раз, когда ему что-то подобное понадобится, выхватывать куски кода из первых подвернувшихся под руку ответов на Stack Overflow. Использование jQuery представляет собой стандартный способ включения в код проектов таких вспомогательных функций.

Особенно — для тех, кто не относится к лагерю разработчиков, считающих, что если что-то работает в 85% браузеров, то им это подходит. Хотя в наши дни проблемы совместимости браузеров потеряли былую остроту, они всё ещё актуальны. Кстати, вот материал о том, почему Hello CSS не использует CSS-переменные.

Нет, конечно нет. Следует ли всегда пользоваться jQuery? Но jQuery — библиотека не такая уж и большая. Любая дополнительная зависимость — это рост сложности проекта и рост объёма его кода. Кастомная сборка без ajax и без редко используемых возможностей — это 23 Кб. Стандартная сборка, минифицированная и сжатая, занимает 30 Кб. Меня, для решения множества задач, вполне устраивает и стандартная сборка размером 30 Кб, и оптимизированная, размером 17 Кб. А сборка, в которой вместо SizzleJS используется querySelector, занимает всего 17 Кб.

Тут можно посмотреть на то, сколько усилий приложено к тому, чтобы убрать jQuery из Bootstrap и перейти на обычный JS.

Им пришлось отказаться от поддержки IE, так как такую поддержку оказалось очень сложно реализовать. Разработчики написали собственные вспомогательные функции. Не могу сказать, что то, что получилось, намного лучше того, что было. Они сделали несовместимым API («мы всё сломали») и потратили на всё это полтора года.

Например, разработчики хотят использовать Bootstrap с Vue.js, или ещё с чем-то подобным. Я понимаю причины перевода Bootstrap на обычный JS. Я — большой сторонник сокращения объёмов ненужного кода в вебе (вот и вот — пара материалов об этом). А Vue.js и jQuery в одном проекте — это уже малость перебор. Неужели включение в Bootstrap 17 Кб кода jQuery — это так плохо? Но тут я предлагаю смотреть на ситуацию с прагматичной и реалистичной точки зрения. Мегабайт JS — это нормально. Когда я говорю, что для просмотра сайтов вроде Medium или New York Times нужно загрузить больше мегабайта JavaScript-кода, меня, защищая сложившуюся ситуацию, спрашивают о том, не сижу ли я на какой-нибудь 56-килобитной модемной линии. Например, jQuery не нужна в том случае, если вы пишете код, которым вы хотите поделиться с другими, или если вы создаёте какую-нибудь маленькую функцию. Неужто 17 Кб jQuery — это неподъёмная ноша?
Существуют и веские причины jQuery не использовать. Зачем все эти усилия, если можно просто написать $()? Но зачем выворачиваться наизнанку только ради того, чтобы не пользоваться jQuery? Я не думаю, что jQuery стоит использовать везде и всегда, но и не считаю правильным фанатичный отказ от jQuery.

Я с удовольствием буду пользоваться чем-то вроде «jQuery light» — некой библиотекой, которая перекрывает недостатки стандартных API, давая программисту что-то более приятное. Хочу отметить, что я не женат на jQuery. Но многие из них, как кажется, давно не поддерживаются. Сайт YMNJQ рекомендует, кроме прочих, библиотеки bonzo и $dom, предназначенные для решения разных задач. Зачем менять jQuery на что-то другое без веских причин? Кроме того, многие уже знают jQuery.

Но цель этой статьи — сопоставить обычный JavaScript и jQuery, а не предлагать сообществу «Грандиозную общую теорию фронтенд-разработки». Многие читатели могут задаться вопросом о том, что я, в русле этого материала, могу сказать по поводу Vue.js, React и других современных фреймворков.

Это так преимущественно из-за того, что я хочу создавать быстрые страницы и использовать при этом простейшие рабочие конструкции. Учитывая вышесказанное, я полагаю, что могу обнаружить совсем немного причин использовать обычный JS там, где можно воспользоваться jQuery. Опыт подсказывает мне, что кратчайшим путём к достижению этой цели служат шаблоны, сгенерированные на сервере, которые слегка, в стиле «прогрессивного улучшения», приправлены JavaScript. При этом я стремлюсь к тому, чтобы мои страницы смогло бы просмотреть как можно большее количество пользователей Сети. Такие проекты обычно быстрее, в них обычно меньше ошибок, а в ходе работы над ними вентилятор ноутбука не издаёт шум, способный разбудить весь дом. Если сравнить такие проекты с чем-то, в чём используется нечто более сложное, то оказывается, что их часто бывает проще разрабатывать.

Нет, не означает. Означает ли это, что современные веб-фреймворки и мощные библиотеки — это всегда плохо? Но использовать фреймворк — значит идти на некие компромиссы (это, конечно, справедливо и для jQuery). Очень немногое достойно того, чтобы «всегда» называться плохим или хорошим.

И «документный подход» хорош не только для обычных сайтов, но и для многих «веб-приложений» (что бы так ни называли). В целом, веб мне видится средой для просмотра документов, а не чем-то вроде операционной системы.

Уважаемые читатели! Пользуетесь ли вы jQuery?

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть