Можно ли использовать jquery
Содержание статьи
jQuery считается вредным
Хех, мне всегда хотелось написать один из этих «Х считается вредным» постов.
Прежде чем я начну, позвольте сказать следующее: я считаю что jQuery оказал просто невероятное влияние на продвижение Web. Он дал возможность разработчикам делать такие вещи, которые ранее считались немыслимыми. Заставил производителей браузеров реализовать многие фичи нативно (без jQuery у нас наверное никогда бы не появился document.querySelectorAll). jQuery всё еще нужен тем, кто не может положиться на современные плюшки и вынужден поддерживать реликты вроде IE8 или хуже.
Тем не менее, как бы я не сочувствовала этим бедным ребятам, они в меньшинстве. Сегодня существуют уже тонны разработчиков, которым не нужно поддерживать старые браузеры с их мизерной долей на рынке. И давайте не будем забывать тех, кто не является профессиональными разработчиками: студенты и исследователи, им не только побоку вся эта кроссбраузерность, часто им вообще ничего не нужно кроме одного единственного браузера! Наверное, вы ожидаете, что в академических кругах, все с удовольствием пользуются новомодными плюшками Открытой Веб Платформы? И близко нет, jQuery там просто везде. Почему? Потому что jQuery — это всё что они знают, у них просто нет ни сил, ни времени следить за новинками веба. Им не нужна причина, чтобы использовать jQuery, он просто должен быть использован. Несмотря на этот факт, и возможность уже делать все эти вещи нативно, я всё же считаю, что это не это основная причина избегать jQuery.
Да, скорее всего, он вам не нужен…
Определенно я далеко не первая, кто обращает внимание на то, что почти всё, что умеет jQuery, сегодня умеет и нативный JavaScript. Так что я не буду повторятся и просто дам несколько ссылок:
- А нужен ли вам jQuery?
- Наверное, вам не нужен jQuery
- Вам точно не нужен jQuery!
- 10 советов как писать на JavaScript без jQuery
- …и так далее. Просто загуглите “вам не нужен jQuery” и вас завалят советами.
Также я не буду тратить время, рассуждая о размере файла и о том, насколько быстрее работают нативные методы. Это все уже не раз разжевано. Сегодня я хочу обратить внимание на кое-что другое.
… но это всё же не та причина чтобы отказаться от его использования
Чтобы избежать расширения прототипов нативных объектов, jQuery использует собственные обертки над этими объектами. В прошлом, расширять нативные объекты, считалось огромным минусом, и не столько из-за потенциальных коллизий с другими расширениями, сколько из-за постоянных утечек памяти в IE6. Так и пошло с тех пор, вызов $(‘div’) вернет нам не ссылку на элемент или список нод, а некий jQuery-объект. Это означает, что jQuery-объект содержит совершенно другие методы, чем обычная ссылка на дом-элемент или список нод.
Тем не менее, эти ссылки всё время вылазят наружу в реальных проектах. Как бы jQuery не старался абстрагироваться от них, вам все равно постоянно приходится оперировать ими, пусть даже просто оборачивая эти ссылки в $(). Например, контекст коллбэка в случае вызова метода jQuery .bind() будет ссылкой на дом элемент, а не на коллекцию jQuery. Также стоит отметить, что вы часто используете библиотеки из разных источников, некоторые из них нуждаются в jQuery, а некоторые нет. Всё это приводит к тому, что на выходе нас ждет адская смесь из нативных дом элементов, списков нод и jQuery-объектов.
Если разработчик придерживается соглашения об именовании jQuery-объектов (добавляя $ перед именем переменной) и обычных переменных содержащих ссылки на нативные элементы, то это безусловно сглаживает проблему (хотя люди имеют свойство забывать о любых конвенциях, но допустим что мы живем в идеальном мире). Как бы то ни было, в большинстве случаев, разработчики и слыхом не слыхивали о подобных конвенциях, и в результате в их коде чрезвычайно трудно разобраться незнакомым с ним людям. Каждая попытка отредактировать такой код, влечет множество ошибок в стиле «Ох, блин, это не jQuery-объект, забыл обернуть его в $()» или «Черт, тут же не дом-элемент забыл взять его через $(..)[0]». Чтобы избежать конфузов, разработчики часто заканчивают тем, что начинают вообще всё подряд оборачивать в $(), на всякий случай. Читая код после, можно увидеть, что одна и та же переменная оборачивается в $() множество раз. По той же причине, становится очень трудно, отрефакторить этот код так, чтобы он не использовал jQuery. Так что по сути получаем безвыходную ситуацию.
Даже если вы строго соблюдаете соглашение о наименовании переменных, все равно часто возникает ситуация, когда вам нужно вызвать нативный метод для дом-элемента или запустить функцию из кода, который не зависит от jQuery. И через какое-то время ваш код уже будет забит сверху донизу переводами объектов из jQuery в нативные и наоборот.
Допустим, через какое-то время, вы решите дописать еще пару фич для подобной программы и в большинстве случаев вы закончите тем, что опять обернете все новые ссылки на дом элементы и коллекции в $(). Ведь вы не всегда можете точно знать, в каком случае вам понадобиться та или иная ссылка. Так что опять она, безвыходная ситуация, которая еще и распространяется на весь будущий код!
Возьмите любой случайный скрипт с jQuery-зависимостью и попробуйте его от этой зависимости избавить. Разбежались. Вы увидите что основная ваша задача не конвертировать методы в нативные, а вообще понять что тут за ад происходит.
Прагматичный путь к чистому JS
Разумеется, сегодня многие библиотеки требуют jQuery и как я недавно твитнула, попытки полностью от него избавиться будут похожи на некое цифровое веганство. И всё же это не значит, что вам нужно продолжать пользоваться им. Библиотеки всегда могут быть заменены в будущем, когда появятся их версии не использующие jQuery.
Кроме того, многие библиотеки написаны так, что они не требуют наличия именно переменной $ как синонима jQuery. Просто вызовите jQuery.noConflict() чтобы забрать себе переменную $ и найти ей лучшее применение. Например, я часто использую эти функции-помощники, вдохновившись Command Line API:
// Возвращаем первый элемент, который соответствует CSS селектору {expr}.
// Запросы могут быть ограничены потомками {container}-а
function $(expr, container) {
return typeof expr === «string»? (container || document).querySelector(expr) : expr || null;
}
// Возвращаем все элементы которые соответствуют CSS селектору {expr} в виде массива.
// Запросы могут быть ограничены потомками {container}-а
function $$(expr, container) {
return [].slice.call((container || document).querySelectorAll(expr));
}
Кроме того, я думаю, что если вам придется каждый раз вместо $ набирать jQuery, то вы дважды подумаете, а действительно ли оно мне надо? ИМХО конечно.
Также, если вам действительно очень нравится jQuery API, но вы хотите избежать раздувания кода, подумайте об использовании Zepto.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Источник
Нужен ли вам jQuery? По полочкам. Сниппеты You Don’t Need jQuery
Всем привет, друзья! Сообщество веб-разработчиков в последнее время разрывает дикий баттхёрт относительно того, стоит ли использовать jQuery в своей работе. Одни топят за то, что нужно использовать эту библиотеку во всех проектах без исключения, другие не могут понять, что вообще происходит и продолжают делать то, что делали раньше. Третьи, чтобы не отрываться от коллектива, осваивают последний ECMAScript, всячески открещиваются от jQuery и бомбят при любом упоминании этой библиотеки. Сегодня мы разберёмся в вопросе более подробно, без крайностей и максимализма.
Поделиться
Твитнуть
Поделиться
Класснуть
Запинить
Полезные ресурсы урока:
- Сниппеты YDNjQ на Github
- Урок по редактору Visual Studio Code
- Урок по редактору Sublime Text
- Урок по созданию сниппетов для Sublime Text
В конце выпуска мы познакомимся с коллекцией сниппетов You Don’t Need jQuery, которую я подготовил для редакторов Visual Studio Code и Sublime Text. Эта коллекция послужит отличным помощником, если вы вдруг проснулись и поняли, что жизнь слишком проста и нужно писать код исключительно на ванильном JS. Кроме того, в грядущем большом курсе Джедай вёрстки 8, в качестве академического примера, мы будем верстать без использования jQuery, на чистом JS и представленная коллекция будет очень кстати.
jQuery – это самая популярная в мире JS библиотека, позволяющая значительно упростить процесс взаимодействия с элементами DOM, а также предоставляющая удобный API для работы с событиями и AJAX.
Здесь я не буду защищать ни одну из сторон, так как это бессмысленно. Это не конкуренция и сокращение «vs» (versus) ставить между jQuery и нативным JS просто некорректно. Когда надо, я использую jQuery, когда не надо, не использую. jQuery — это инструмент, созданный для того, чтобы максимально сократить время разработки. Здесь я даже не говорю о краткости записи, ведь нативный JS не стоит на месте, стандарты ES развиваются и нативный код становится короче. Дело не в этом.
Главное преимущество jQuery – это тысячи готовых плагинов и расширений, которые можно подключить к проекту и настроить всего за несколько минут. Второе важнейшее преимущество — это проверенная, оттестированная, железобетонная кроссбраузерность и поддержка всего, что может отображать веб-страницы с поддержкой JavaScript.
Но, давайте по-порядку рассмотрим все аргументы «за» и «против» использования jQuery, а затем перейдём к примерам проектов, в которых целесообразно использовать эту библиотеку.
Аргументы в пользу jQuery
- Кроссбраузерность. jQuery учитывает особенности работы со всеми возможными браузерами (с поддержкой JS, конечно-же), имеет все необходимые фолбеки и запасные варианты реализации. Ваш код будет работать везде. В противовес, НЕ использование jQuery потребует от вас больше временных затрат и усилий для написания и тестирования вашего кода.
- Вариативность. Функции jQuery включают огромное количество вариантов и возможностей использования, что делает их максимально универсальными и лаконичными. Использование ванильного JS предполагает написание намного большего количества кода, условий и проверок для реализации аналогичного функционала, даже если речь идёт о какой-то специфической задаче, где не требуется особая универсальность.
- Расширения. Тысячи готовых плагинов, расширений, примеров, сниппетов готовы к использованию. Вам не придётся писать свой велосипед для решения типовой задачи. Можно сказать, что это самое важное преимущество jQuery. Писать плагины для jQuery также легко, как писать любой другой код с использованием этой библиотеки. Именно поэтому jQuery так нравится многим веб-разработчикам. Сейчас можно найти абсолютно любой плагин, который поможет быстро решить любую задачу в условиях коммерческого проекта. А в заказной разработке, если вы фрилансер или студия, время — деньги.
- Сообщество. Огромное количество уроков, примеров кода, решений на сайтах QA. Можно очень быстро найти решение любой задачи, моментально найти ответ на любой вопрос и продолжить работу.
- Краткость записи. Нативный JS, не смотря на своё развитие, пока что не может предложить такие-же возможности краткой записи. jQuery – это простой, лаконичный код, понятный даже начинающим и довольно простой в изучении.
- CMS. Практически все популярные CMS, такие, как OpenCart, Joomla, WordPress, используют библиотеку jQuery. Это огромный плюс, ведь возможности этой библиотеки как во фронтенде, так и в бэкенде любой CMS, как правило, реализованы по максимуму и вопроса — подключать jQuery для десяти кастомных строк кода или нет, не стоит. Пользуйтесь в своё удовольствие.
Аргументы против jQuery
- Библиотека jQuery загружается в проект как дополнительный ресурс. Можно много спорить относительно того, стоит ли загружать файл, весом 100кб к проекту, чтобы написать всего 5 строчек кода, в то время, когда каждая из картинок на странице весит гораздо больше, а их там, на минуточку, могут быть сотни. Также, следует учитывать и все подключённые плагины, сниппеты и другие ресурсы, использующие jQuery, чтобы понять целесообразность подключения библиотеки.
Зачастую это главный и единственный аргумент против использования jQuery и предмет спора в сообществе. jQuery хоть и крайне маленький ресурс, однако его нерациональное использование может серьёзно пошатнуть психику кодера-перфекциониста.
Само по себе понятие «библиотека» в программировании довольно простое для понимания. В процессе работы с каким-либо языком программирования, разработчики сталкивались с определёнными задачами, однотипными проблемами, решения которых в результате были объединены в библиотеки для удобного повторного использования. Отсюда и возникают все плюсы и минусы использования библиотек. Плюс — проверенный код на любой случай жизни, минус — много того, что не используется здесь и сейчас также подтягивается в проект.
Можно услышать и некоторые другие аргументы против использования jQuery, вроде того, что эта библиотека замедляет работу браузера и работает медленнее нативного кода. Это весьма сомнительные заявления, не подкреплённые никакими фактами, экспериментальными выводами и результатами тестов. Как показывает практика, никакого негативного влияния на скорость работы браузера библиотека не оказывает, а код работает также быстро, как и нативный, ведь он, по-сути и является нативным — все функции jQuery не имеют какой-то космически-сложной структуры, которая хоть как-то влияла бы на скорость исполнения.
Использовать или не использовать jQuery?
В первую очередь, не стоит отказываться от jQuery в заказной или тиражной разработке сайтов. Эти области достаточно хорошо стандартизированы и автоматизированы. Можно получить потрясающий результат, используя популярные фреймворки, вроде Bootstrap и библиотеки, вроде jQuery, совместно с крутыми известными плагинами. Если вы видите в дизайне элементы, блоки или секции, которые проще и быстрее реализовать с использованием jQuery и плагинов, вперёд!
Вообще, jQuery можно использовать практически в любых проектах, если вы уверены, что будет задействована достаточная часть библиотеки и не используется какой-либо JS-фреймворк. Конечно, никто не запретит подключить библиотеку к проекту и написать пресловутые 5 строк кода. Осудить вас может, пожалуй, только вышеупомянутый кодер-перфекционист, если случайно заглянет в ваши исходники. Ему лучше на глаза не попадаться, чтобы не случился очередной приступ паранойи и неконтролируемого гнева. А если серьёзно, то в таких случаях библиотеку можно и не использовать, а посмотреть вариант решения задачи в сниппетах для редакторов кода, которые я подготовил к данному выпуску (см. Полезные ресурсы урока).
Кроме того, не стоит использовать jQuery, если вы планируете делать уникальный сложный проект, который будет бесконечно развиваться. Зачастую, над такими проектами работает большая команда и функционал фронтенда выходит далеко за пределы возможностей библиотеки jQuery.
В настоящее время огромное количество контентных проектов, крупных СМИ, коммерческих сайтов и многих известных ресурсов используют jQuery, так как функционал этой библиотеки достаточен и значительная его часть реализована. Это и есть основные критерии грамотного использования любого ресурса.
Коллекция сниппетов для Visual Studio Code и Sublime Text.
Для того, чтобы облегчить написание нативного JS, если до этого вы использовали только jQuery, я подготовил коллекцию сниппетов для редакторов Visual Studio Code и Sublime Text, основанную на популярных примерах You Don’t Need jQuery (см. Полезные ресурсы урока). Сниппеты устанавливаются и работают с редакторами кода штатным образом. В коде каждого сниппета есть закомментированный пример, написанный с использованием jQuery и его альтернатива в нативном исполнении:
Установка в Sublime Text
Для установки сниппетов в редактор Sublime Text достаточно скачать архив с GitHub и распаковать папку «YDNjQ — Sublime Text Snippets» в директорию «ПОЛЬЗОВАТЕЛЬ AppData Roaming Sublime Text 3 Packages User», которую можно открыть из редактора: Меню «Preferences > Browse Packages…», затем перейти в папку User:
Установка в Visual Studio Code
Процесс установки сниппетов в кодовый редактор Visual Studio Code не на много сложнее. Скачиваем тот-же самый архив с GitHub и выгружаем содержимое папки «YDNjQ — Visual Studio Code Snippets» в папку «ПОЛЬЗОВАТЕЛЬ AppData Roaming Code User snippets». Обратите внимание, что необходимо выгрузить именно содержимое папки «YDNjQ — Visual Studio Code Snippets», то-есть весь список файлов:
После установки сниппеты доступны по ключевым словам jQuery-функций. Например, «hide», «fade», «load» и т. д. Для использования в Sublime Text достаточно набрать нужное сокращение и нажать Tab, или нажав Ctrl+Shift+P, ввести ключевое слово и выбрать нужный сниппет с префиксом YDNjQ. В редакторе Visual Studio Code достаточно нажать F1 > Insert Snippet, ввести ключ сниппета и выбрать нужный.
И в заключение. Хотите использовать jQuery или какую-либо другую библиотеку в вашем проекте — используйте на здоровье. Грамотно и рационально.
Премиум уроки от WebDesign Master
Источник
Почему я до сих пор использую jQuery в 2019 году
От автора: многие люди выступают за «просто используйте vanilla JavaScript, вам не нужен jQuery». Ну, многие вещи мне не нужны, но, тем не менее, их приятно иметь. Мне не обязательно нужен JQuery в 2019 году, у него есть не только плюсы, но и минусы. Но его, конечно, приятно иметь!
Такие страницы, как You might not need jQuery, пытаются продвигать идею, что вы можете легко отказаться от jQuery, но самый простой пример того, почему — это хорошая идея использовать jQuery: одна строка обычного кода jQuery заменяет 10 строк vanilla JS!
Большая часть JavaScript API — особенно DOM API — оскорбляет мое чувство эстетики, и это просто вежливый способ сказать, что я думаю, что JavaScript — это отстой.
el.insertAdjacentElement(‘afterend’, other) несомненно работает, но $(el).after(other) на самом деле более приятно. Хотя я никогда не был большим поклонником того, как выглядит функция $(), она намного лучше, чем то, что дает нам DOM.
Простой пример: как вы получаете элемент одного уровня? Это nextSibling или nextElementSibling? Какая разница? Какие браузеры поддерживают что? Пока вы заняты тем, что пытаетесь свериться с MDN, я просто буду использовать в jQuery next() или prev().
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Узнать подробнее
Многие обычные операции в стандартных API-интерфейсах JavaScript неудобны; я мог бы привести целый список, но страница You might not need jQuery (YMNJQ) уже сделала это.
Вам по-прежнему понадобятся вспомогательные функции для различных общих задач. Опять же, на странице YMNJQ перечислены некоторые из них. Использование jQuery является стандартным способом включения этих вспомогательных функций вместо копирования / вставки их из случайных тем Stack Overflow каждый раз, когда они вам нужны.
Хотя совместимость браузеров является гораздо менее существенной проблемой , но она все еще актуальна, особенно если вы не принадлежите к типу людей «если это работает для 85% всего мира , то это достаточно хорошо для меня».
Вы всегда должны использовать JQuery? Нет, конечно нет. Добавление любой зависимости сопряжено с увеличением сложности и размера файла, но jQuery не так уж велик: сборка по умолчанию составляет 30 КБ, сжатая, пользовательская сборка без ajax и необычных вещей 23 КБ, а сборка, использующая querySelector вместо SizzleJS, составляет 17 КБ. И оригинальные 30K, и оптимизированные 17K кажутся мне вполне приемлемыми для многих целей.
Вы можете посмотреть на Bootstrap удаляет jQuery, чтобы увидеть пример того, как много усилий может потребоваться для использования vanilla JS: они написали свои собственные хелперы, пришлось отказаться от поддержки IE, так как ее было слишком сложно добавить, сделали API несовместимым («мы сломали все») и потратили на это полтора года. Если я посмотрю на конечный результат, я не могу сказать, что это намного лучше.
Я понимаю, почему они это сделали; люди хотят использовать Bootstrap с Vue.js и еще много чего, а использовать и Vue.js, и jQuery немного глупо. Я за то, чтобы уменьшить «веб-раздутие», но мы должны быть прагматичными и реалистичными. Включение ~17K jQuery действительно так плохо? Когда я упоминаю, что вам нужен более чем мегабайт JavaScript для такого сайта, как Medium или New York Times, то что, 17 КБ jQuery такое уж невыносимое бремя?
Есть несколько веских причин не использовать jQuery: если вы пишете код, который хотите использовать повторно, или если вы пишете только небольшую функцию. Но делать что-то, просто чтобы избежать jQuery? Просто используйте jQuery! «JQuery для всего», вероятно, не была такой уж хорошей идеей, но и «jQuery ни для чего» не лучше.
Я не зациклен на jQuery, и я с радостью использую «jQuery light», который соединяет JS API с чем-то более привлекательным. YMNJQ рекомендует bonzo и $dom, а также несколько других для AJAX и тому подобного, но многие из них, кажется, не поддерживаются достаточно. Кроме того, все уже знают jQuery. Зачем заменять его чем-то другим, если для этого нет веских причин?
Некоторые читатели могут задаться вопросом «а как же Vue.js, React или какой-либо другой современный фреймворк?» Цель этого поста — сравнить vanilla JavaScript с jQuery, а не предлагать Великую унифицированную теорию развития веб-интерфейса.
При этом, я думаю, есть несколько причин придерживаться простого JavaScript; прежде всего потому, что я хочу создавать быстрые веб-страницы, использовать простейший из возможных кодов и быть доступным как можно большему количеству людей. По моему опыту, сгенерированные на стороне сервера шаблоны, слегка присыпанные «прогрессивным улучшением», часто являются лучшим способом сделать это в стиле JavaScript. Зачастую это легче разрабатывается, быстрее, меньше подвержено ошибкам, и вентилятор вашего ноутбука не разбудит соседей.
Означает ли это, что эти веб-фреймворки всегда плохи? Нет, не так уж много вещей плохи «всегда» (или хороши), чаще всего это набор компромиссов (как, впрочем, и в случае jQuery).
По сути, я думаю, что Интернет — это система для просмотра документов, а не операционная система. Даже для многих «веб-приложений» (что бы вы ни имели ввиду) подход к документам работает достаточно хорошо (эта тема заслуживает отдельной публикации… может, когда-то в будущем).
Автор: Martin Tournoij
Источник: //arp242.net
Редакция: Команда webformyself.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Узнать подробнее
jQuery: основы
Изучите jQuery с нуля!
Смотреть
Источник