[Перевод] Рассказ о том, почему я до сих пор использую jQuery
Многие, когда речь заходит о jQuery, говорят так: «Просто пользуйтесь обычным JavaScript. Библиотека jQuery вам не нужна». Что тут сказать? Я не нуждаюсь во многих вещах, но, несмотря на это, хорошо, когда они есть. Так и jQuery. Я в этой библиотеке не нуждаюсь, но её, определённо, приятно иметь под рукой.
Сайты наподобие You might not need jQuery (YMNJQ) продвигают идею, в соответствии с которой от jQuery очень легко избавиться. Но самый первый пример на этом сайте демонстрирует вескую причину jQuery использовать. Там строка простого кода на jQuery заменяется на 10 строк обычного JS!
Большинство API JavaScript, в особенности те из них, которые нацелены на работу с DOM, оскорбляют мои эстетические чувства. Это — если мягко выразить моё к ним отношение. Если же говорить прямо, то я думаю, что эти API — полный кошмар. Например, конструкция el.insertAdjacentElement('afterend', other), безусловно, работает. Но куда приятнее выглядит $(el).after(other). Хотя мне никогда особо не нравился внешний вид функции $(), она несравненно лучше, чем то, что дают нам стандартные API для работы с DOM. Я знаю о том, что вместо $() можно использовать нечто вроде jQuery(sel) или window.jq = jQuery. Но программирую я не в безвоздушном пространстве. Поэтому предпочитаю пользоваться стандартными приёмами. Не знаю, хорошо это или плохо, но стандартом при использовании jQuery стала конструкция $().
Попытайтесь быстро вспомнить о том, как получить элемент-сосед другого элемента средствами DOM. Что для этого использовать — nextSibling или nextElementSibling? А в чём разница? А какие браузеры поддерживают тот или иной метод? Пока вы пытаетесь это вспомнить и заглядываете на MDN, проверяя себя, я, пользуясь jQuery, просто пишу next() или prev().
Выполнение многих обычных операций реализовано в JavaScript-API неудобно. Я мог бы привести тут целый список таких операций, но за меня это отлично сделано на странице YMNJQ.
Для решения различных простых задач средствами JS нужны вспомогательные функции. И на сайте YMNJQ, опять же, можно найти немало примеров. Использование jQuery представляет собой стандартный способ включения в код проектов таких вспомогательных функций. При этом программисту не нужно каждый раз, когда ему что-то подобное понадобится, выхватывать куски кода из первых подвернувшихся под руку ответов на Stack Overflow.
Хотя в наши дни проблемы совместимости браузеров потеряли былую остроту, они всё ещё актуальны. Особенно — для тех, кто не относится к лагерю разработчиков, считающих, что если что-то работает в 85% браузеров, то им это подходит. Кстати, вот материал о том, почему Hello CSS не использует CSS-переменные.
Следует ли всегда пользоваться jQuery? Нет, конечно нет. Любая дополнительная зависимость — это рост сложности проекта и рост объёма его кода. Но jQuery — библиотека не такая уж и большая. Стандартная сборка, минифицированная и сжатая, занимает 30 Кб. Кастомная сборка без ajax и без редко используемых возможностей — это 23 Кб. А сборка, в которой вместо SizzleJS используется querySelector, занимает всего 17 Кб. Меня, для решения множества задач, вполне устраивает и стандартная сборка размером 30 Кб, и оптимизированная, размером 17 Кб.
Тут можно посмотреть на то, сколько усилий приложено к тому, чтобы убрать jQuery из Bootstrap и перейти на обычный JS.
Разработчики написали собственные вспомогательные функции. Им пришлось отказаться от поддержки IE, так как такую поддержку оказалось очень сложно реализовать. Они сделали несовместимым API («мы всё сломали») и потратили на всё это полтора года. Не могу сказать, что то, что получилось, намного лучше того, что было.
Я понимаю причины перевода Bootstrap на обычный JS. Например, разработчики хотят использовать Bootstrap с Vue.js, или ещё с чем-то подобным. А Vue.js и jQuery в одном проекте — это уже малость перебор. Я — большой сторонник сокращения объёмов ненужного кода в вебе (вот и вот — пара материалов об этом). Но тут я предлагаю смотреть на ситуацию с прагматичной и реалистичной точки зрения. Неужели включение в Bootstrap 17 Кб кода jQuery — это так плохо? Когда я говорю, что для просмотра сайтов вроде Medium или New York Times нужно загрузить больше мегабайта JavaScript-кода, меня, защищая сложившуюся ситуацию, спрашивают о том, не сижу ли я на какой-нибудь 56-килобитной модемной линии. Мегабайт JS — это нормально. Неужто 17 Кб jQuery — это неподъёмная ноша?
Существуют и веские причины jQuery не использовать. Например, jQuery не нужна в том случае, если вы пишете код, которым вы хотите поделиться с другими, или если вы создаёте какую-нибудь маленькую функцию. Но зачем выворачиваться наизнанку только ради того, чтобы не пользоваться jQuery? Зачем все эти усилия, если можно просто написать $()? Я не думаю, что jQuery стоит использовать везде и всегда, но и не считаю правильным фанатичный отказ от jQuery.
Хочу отметить, что я не женат на jQuery. Я с удовольствием буду пользоваться чем-то вроде «jQuery light» — некой библиотекой, которая перекрывает недостатки стандартных API, давая программисту что-то более приятное. Сайт YMNJQ рекомендует, кроме прочих, библиотеки bonzo и $dom, предназначенные для решения разных задач. Но многие из них, как кажется, давно не поддерживаются. Кроме того, многие уже знают jQuery. Зачем менять jQuery на что-то другое без веских причин?
Многие читатели могут задаться вопросом о том, что я, в русле этого материала, могу сказать по поводу Vue.js, React и других современных фреймворков. Но цель этой статьи — сопоставить обычный JavaScript и jQuery, а не предлагать сообществу «Грандиозную общую теорию фронтенд-разработки».
Учитывая вышесказанное, я полагаю, что могу обнаружить совсем немного причин использовать обычный JS там, где можно воспользоваться jQuery. Это так преимущественно из-за того, что я хочу создавать быстрые страницы и использовать при этом простейшие рабочие конструкции. При этом я стремлюсь к тому, чтобы мои страницы смогло бы просмотреть как можно большее количество пользователей Сети. Опыт подсказывает мне, что кратчайшим путём к достижению этой цели служат шаблоны, сгенерированные на сервере, которые слегка, в стиле «прогрессивного улучшения», приправлены JavaScript. Если сравнить такие проекты с чем-то, в чём используется нечто более сложное, то оказывается, что их часто бывает проще разрабатывать. Такие проекты обычно быстрее, в них обычно меньше ошибок, а в ходе работы над ними вентилятор ноутбука не издаёт шум, способный разбудить весь дом.
Означает ли это, что современные веб-фреймворки и мощные библиотеки — это всегда плохо? Нет, не означает. Очень немногое достойно того, чтобы «всегда» называться плохим или хорошим. Но использовать фреймворк — значит идти на некие компромиссы (это, конечно, справедливо и для jQuery).
В целом, веб мне видится средой для просмотра документов, а не чем-то вроде операционной системы. И «документный подход» хорош не только для обычных сайтов, но и для многих «веб-приложений» (что бы так ни называли).
Уважаемые читатели! Пользуетесь ли вы jQuery?
