Неужели jQuery вреден?

Неужели jQuery вреден?

Прежде чем начать, позвольте сказать, что мы считаем, что библиотека jQuery сделала очень много для развития Интернета. Она дала разработчикам возможность делать вещи, которые раньше были немыслимы, и подтолкнула производителей браузеров к реализации подобных вещей естественным способом (без jQuery у нас, вероятно, не было бы сейчас такого метода, как document.querySelectorAll). При этом jQuery по-прежнему необходима тем, кто не может зависеть от вкусностей, которые у нас есть на сегодняшний день, а вынужден поддерживать такие реликты прошлого, как IE8 или же еще что похуже.

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

Возможно, вам и в самом деле не нужна эта библиотека...

Безусловно, это не первая статья, в которой затрагивается вопрос о том, как много из того, что делает jQuery, можно делать средствами самого браузера. Поэтому не будем тратить время на повторение того, что уже написано другими. Чтобы изучить историю этого вопроса достаточно ввести в поисковик запрос "вам не нужен jQuery", и вы получите массу материалов.

Также не будем тратить время на обсуждение размеров файла или того, насколько быстрее работают родные методы браузеров. Об этом тоже уже говорилось ранее.

... но и это не самая главная причина не использовать jQuery сегодня

Чтобы избежать расширения прототипов нативных элементов, jQuery использует свои собственные объекты-обертки. Дело в том, что в прошлом расширение нативных объектов было большим табу не только из-за потенциальных коллизий, но и из-за утечек памяти в старых IE.

Таким образом, при выполнении, например, команды $("div") возвращается не ссылка на элемент или набор NodeList, а объект jQuery. Это означает, что объект jQuery имеет совершенно иные методы, чем ссылка на элемент DOM, массив с элементами или любой тип NodeList. Тем не менее, эти нативные объекты все время появляются в реальном коде. Насколько бы jQuery ни пытался абстрагироваться от них, вам всегда приходится иметь с ними дело, даже если вы просто оборачиваете их в конструкцию $(). Например, контекст обратного вызова в jQuery методе .bind() является ссылкой на элемент HTML, а не на набор jQuery. Не говоря уже о том, что часто нужно использовать код от нескольких источников - одни из них предполагают использование jQuery, а другие нет. Следовательно, вы получаете код, в котором перемешаны объекты jQuery, нативные элементы и наборы NodeList. И вот здесь и начинается настоящая вакханалия.

Если разработчик следовал соглашению об именах, по которому переменные содержат объекты jQuery (с добавлением знака доллара) и нативные элементы, это будет меньшей из проблем (люди часто забывают придерживаться таких соглашений, но давайте возьмем идеальные условия). В большинстве же случаев такие соглашения соблюдается довольно редко, и это приводит к тому, что код невероятно трудно понять всякому, кто не участвовал в его написании. И внесение любой правки влечет за собой дополнительные ошибки и эксперименты ("О, это не объект jQuery, я должен обернуть его в $()!" или "О, это не элемент, я должен использовать ячейку массива [0], чтобы получить элемент!"). Чтобы избежать подобной путаницы, разработчики, которые вносят изменения в код, часто в качестве защиты в конце концов все подряд оборачивают в $(), в результате во всем коде одна и та же переменная будет проходить через $() много раз. По этой же причине становится особенно трудно реорганизовать jQuery из указанного кода. По сути вы запираете себя со всех сторон.

Но даже если все соглашения об именах были соблюдены, вам не удастся иметь дело только с объектами jQuery. Часто необходимо использовать нативный метод DOM или вызывать функцию из скрипта, который не полагается на jQuery. И вот вскоре преобразования в объекты jQuery и обратно будут повсюду, загромождая ваш код.

И кроме этого, если вы будете добавлять свой код в какую-нибудь кодовую базу, вы придете к тому, что вам придется обернуть каждый элемент или ссылку на список узлов в конструкцию $(), потому что вам не известно, какой ввод вы получите. Таким образом, вы оказываетесь запертыми не только в данный момент, но и весь будущий код, который вы пишете для той же кодовой базы, будет сильно ограничен.

Возьмите любой случайный скрипт с использованием jQuery, который вы не писали сами, и попробуйте переписать его так, чтобы убрать jQuery. Будьте уверены, что вашей главной проблемой будет не то, как преобразовать функциональность в нативный API, а понять, что здесь вообще происходит.

Прагматичный путь к чистому JS

Конечно, сегодня многим библиотекам требуется jQuery, и, если полностью избегать jQuery, то можно почувствовать себя на какой-то цифровой диете. Однако это не означает, что вы обязаны использовать все это сами. В будущем, когда появятся хорошие альтернативы jQuery, все эти библиотеки могут быть заменены.

При этом, большинство библиотек написаны таким образом, что они не требуют, чтобы переменная $ была псевдонимом jQuery. Просто вызовите jQuery.noConflict(), чтобы освободить переменную $, и используйте ее где угодно.

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

А помимо всего этого, если вам действительно нравится jQuery API, но вы хотите избежать раздувания кода, обратите внимание на библиотеку Zepto.