jQuery вважається шкідливим

Хех, мені завжди хотілося написати один з цих «Х вважається шкідливим» постів.

Перш ніж я почну, дозвольте сказати наступне: я вважаю, що jQuery справив просто неймовірне вплив на просування Web. Він дав можливість розробникам робити такі речі, які раніше вважалися неможливими. Змусив виробників браузерів реалізувати багато фічі нативно (без jQuery у нас, напевно, ніколи б не з'явився document.querySelectorAll). jQuery все ще потрібен тим, хто не може покластися на сучасні плюшки і змушений підтримувати релікти начебто IE8 або гірше.

Тим не менш, як би я не співчувала цим бідним хлопцям, вони в меншості. Сьогодні існують тонни розробників, яким потрібно підтримувати старі браузери з їх мізерною часткою на ринку. І давайте не будемо забувати тих, хто не є професійними розробниками: студенти та дослідники, їм не тільки побоку вся ця кросбраузерність, часто їм взагалі нічого не потрібно крім одного єдиного браузера! Напевно, ви очікуєте, що в академічних колах, усі з задоволенням користуються новомодними плюшками Відкритої Веб Платформи? І близько немає, jQuery там просто скрізь. Чому? Тому що jQuery — це все що вони знають, у них просто немає ні сил, ні часу стежити за новинками веба. Їм не потрібна причина, щоб використовувати jQuery, він просто повинен бути використаний. Незважаючи на цей факт, і можливість вже робити всі ці речі нативно, я все ж вважаю, що це не це основна причина уникати jQuery.

Так, швидше за все, він вам не потрібен...
Безумовно я далеко не перший, хто звертає увагу на те, що майже все, що вміє jQuery, сьогодні вміє і нативний JavaScript. Так що я не буду повторюватися і просто дам декілька посилань:

Також я не буду витрачати час, розмірковуючи про розмір файлу і про те, наскільки швидше працюють нативні методи. Це все вже не раз розжовано. Сьогодні я хочу звернути увагу на дещо інше.

… але це все ж не та причина, щоб відмовитися від його використання
Щоб уникнути розширення прототипів нативних об'єктів, 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 повністю

/>
/>


<input type=«radio» id=«vv67141»
class=«radio js-field-data»
name=«variant[]»
value=«67141» />
Так
<input type=«radio» id=«vv67143»
class=«radio js-field-data»
name=«variant[]»
value=«67143» />
Немає
<input type=«radio» id=«vv67145»
class=«radio js-field-data»
name=«variant[]»
value=«67145» />
Вже відмовився

Проголосувало 333 людини. Утрималося 86 осіб.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.