JQuery может оказаться вредным

JQuery может оказаться вредным

710

JQuery может оказаться вредным
0

 

Мне постоянно хотелось написать пост из серии ” N может оказаться  вредным”

Но, до этого чем я начну свои рассуждения, хотелось бы уточнить, я думаю, что JQuery внес огромный вклад в развитие веба. Он предоставил разработчикам возможность делать такие вещи, о которых ранее нельзя было даже помыслить, а также подтолкнул создателей браузеров реализовывать их (раз бы не было JQuery, нам пришлось  обходиться  без document.querySelectorAll ). Но сейчас JQuery прежнему необходим только тем, кто не может воспользоваться новыми продуктам,  и тем, кому приходиться работать с “артефактами”, вроде IE8 или с чем по-хуже.

Тем не наименее, этих бедняг меньшинство. Есть куча разработчиков, которым нет необходимости работать со старенькыми браузерами, формирующими  небольшую долю рынка. И давайте не забывать о тех, кто не является интернет-профессионалами: студенты и ученые не только продолжают пользоваться старыми версиями браузеров, но и  часто останавливаются на каком-нибудь одном!

Вы может быть полагаете, что в научном сообществе принято пользоваться современными интернет-новинками. Однако, именно там  JQuery особенно популярен. Почему? Поэтому, что научное сообщество с ним знакомо, и быть может у их нет времени или заинтересованности следить за новинками. Они не знают для чего  нужен JQuery и просто продолжают им пользоваться.
Хотя, это  даже не самые основные  причины, по которым я стараюсь избегать JQuery.

Да, может быть вам он действительно не очень-то и нужен…

 

Я не 1-ый человек, который указывает на то, что можно обойтись без JQuery,так что давайте не будем растрачивать лишний раз время на общие слова. Можете поглядеть следующие материалы:

  • Вам возможно не нужен JQuery
  • Для вас не нужен JQuery!
  •  Действительно ли вам нужен JQuery?
  • 10 методов писать на JS без помощи 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:

JavaScript


// 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));
}

1234567891011

// Returns first element that matches CSS selector {expr}.// Querying can optionally be restricted to {container}’s descendantsfunction $(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 descendantsfunction $$(expr, container) { return [].slice.call((container || document).querySelectorAll(expr));}

Я надеюсь, что необходимость набирать JQuery заместо $ каждый раз, когда вы используете этот прием, может быть заставит вас подумать дважды об использовании данного фреймворка без последней необходимости, хотя я могу и ошибаться.

Также, если вам  очень нравится JQuery API, но вы не желаете загромождать код, рассмотрите возможность использования Zepto.

Перевод статьи

 

www.webdesignmagazine.ru