Нам всегда хотелось написать пост из серии ” N может оказаться вредным”
Но, прежде чем мы начнем свои рассуждения, хотелось бы уточнить, мы думаем, что JQuery внес огромнейший вклад в развитие веба. Он предоставил разработчикам возможность делать такие вещи, о которых раньше нельзя было даже помыслить, а также подтолкнул создателей браузеров реализовывать их (если бы не было JQuery, нам пришлось обходиться без document.querySelectorAll ). Но сегодня JQuery прежнему необходим только тем, кто не может пользоваться новыми продуктам, и тем, кому приходиться работать с “реликвиями”, вроде IE8 или с чем похуже.
Тем не менее, этих бедняг меньшинство. Есть куча разработчиков, которым нет необходимости работать со старыми браузерами, формирующими небольшую долю рынка. И давайте не забывать о тех, кто не является веб-профессионалами: студенты и ученые не только продолжают пользоваться старыми версиями браузеров, но и часто останавливаются на каком-нибудь одном!
Вы возможно полагаете, что в научном сообществе принято пользоваться современными веб-новинками. Однако, именно там JQuery особенно популярен. Почему? Потому, что научное сообщество с ним знакомо, и быть может у них нет времени или заинтересованности следить за новинками. Они не знают зачем нужен JQuery и просто продолжают им пользоваться.
Хотя, это даже не самые основные причины, по которым я стараюсь избегать JQuery.
Да, возможно вам он действительно не очень-то и нужен...но это даже не самая главная причина, чтобы не использовать данный фреймворк.
Чтобы избежать распространения нативных элементов-прототипов, JQuery использует свои собственные враперы. Раньше распространение нативных объектов не осуществлялось, не столько из-за возможных коллизий, сколько из-за возможной утечки памяти в старых версиях IE. Поэтому, то, что вы получаете, когда прописываете $ (“div”), это не ссылка на элемент, или на NodeList, это объект JQuery. Последнее означает, что объект JQuery располагает иными методами,чем ссылки на элемент DOM, массивы или любой тип NodeList. Тем не менее, нативные объекты появляются в коде – и даже несмотря на то, что JQuery пытается их избегать, вам придется с ними сталкиваться, даже если, вы “обернете” указанные объекты в $ (). Например, если функция вызывается с помощью .bind () , это отсылка к элементу HTML, а не к библиотеке JQuery. Не говоря уже о том, что часто используется код из разных источников – некоторые из них взаимодействуют с JQuery, а другие нет. Таким образом, в конечном итоге вам придется работать с кодом, состоящим из объектов JQuery, нативных элементов и нодлистов. А вот здесь и начинаются проблемы .
Если разработчик следовал соглашению о присвоении имен, в соответствии с которым переменные, содержащие объекты JQuery (перед именем таких переменных ставится знак доллара), и которые содержат нативные элементы, то это вызовет меньшее количество проблем (люди часто забывают следовать подобным соглашениям, но давайте предположим, что мы живем в идеальном мире).
Однако в большинстве случаев данное соглашение не соблюдается, поэтому в результате код понять практически невозможно, особенно тем, кто видит его впервые. Каждое последующе редактирование влечет за собой множество проб и ошибок (“О, это не объект JQuery, мне нужно обернуть его в $ ()” или “О, это не элемент, мне нужно использовать [0], чтобы получить элемент”). Чтобы избежать подобной путаницы, разработчики часто решают проблему, оборачивая что-либо в $ (), и таким образом данная переменная будет проходить через $ () огромное количество раз. Так что, по сути, вы попадаете в собственную ловушку.
Даже если соглашение о присвоении имен соблюдается, вы не можете работать только с объектами JQuery. Вам часто придется использовать нативный DOM или вызывать функцию из скрипта, который не зависит от JQuery. И таким образом, необходимость конвертирования “из” и “в” объекты JQuery, просто напросто сделает ваш код громоздким.
Кроме того, когда вы добавляете код к определенной кодовой базе вам приходить оборачивать каждый элемент или ссылку нодлиста с помощью $ (), и это при том, что вы даже не знаете каков будет результат подобных действий. Таким образом, не только вы попадаете в эту “ловушку”, но и весь ваш будущий код.
Возьмите любой чужой скрипт, взаимодействующий с JQuery,и попытайтесь преобразовать его так, чтобы JQuery был ему не нужен. Попробуйте. И вы увидите, что вашим главным вопросом будет не то, как же преобразовать функциональность, чтобы использовать родные API, а “что же, черт возьми, происходит?”
Прагматичный путь к использованию JS
Конечно, многим библиотекам сегодня необходим JQuery, и, как я недавно писала, если вам удастся его избежать, то вы почувствуете себя диджитал-веганом. Тем не менее, это не означает, что вам все же придется использовать JQuery. Библиотеки могут меняться, по мере появления хороших и доступных альтернатив.
Кроме того, большинство библиотек написаны таким образом, что им не требуются $ переменная, чтобы ссылаться на JQuery. Просто установите jQuery.noConflict (), чтобы вернуть переменную $ и иметь возможность назначать ее там, где вы посчитаете нужным. Например, я часто устанавливаю эти вспомогательные функции, вдохновившись командной строкой API:
// Returns first element that matches CSS selector {expr}.
// Querying can optionally be restricted to {container}’s descendants
function $(expr, container) {
return typeof expr === "string"? (container || document).querySelector(expr) :
expr || null;
}
// Returns all elements that match CSS selector {expr} as an array.
// Querying can optionally be restricted to {container}’s descendants
function $$(expr, container) {
return [].slice.call((container || document).querySelectorAll(expr));
}Мы надеемся, что необходимость набирать JQuery вместо $ каждый раз, когда вы используете этот прием, возможно заставит вас подумать дважды об использовании данного фреймворка без крайней необходимости, хотя мы можем и ошибаться.
Также, если вам очень нравится JQuery API, но вы не хотите загромождать код, рассмотрите возможность использования Zepto.
Высоких конверсий!
