Які емпіричні технічні причини не використовувати jQuery? [зачинено]

74

Контекст: Мене вражає кількість розробників інтерфейсів, які цілий день зламують HTML, Javascript та CSS, і які ігнорують такі інструменти, як jQuery ( або інші еквівалентні допоміжні фреймворки ), і відмовляються їх використовувати. Я не кажу про гуру JavaScript, я говорю про них щодня в траншеях розробників виробництва Джо. Я отримую багато аргументів, які більше нагадують виправдання чи особисті думки, які, на мою думку, не мають жодних технічних достоїнств, я хочу переконатися, що чогось не пропускаю.

Питання: Які емпіричні технічні причини не використовувати jQuery?

Я не шукаю релігійних чи догматичних аргументів чи суб'єктивних думок "як якісь інші рамки кращі", розгляньте jQuery солом'яного чоловіка для всіх порівнянних основ у питанні.

javascript  jquery  frameworks 
31
Я справді думаю, що jQuery робить деяких людей тупішими, серйозно, вони вважають, що jQuery - це мова програмування, а javascript - це фреймворк ... Незабаром вони запитають, як додати два числа за допомогою jQuery.
40
Як додати 2 числа за допомогою jQuery?
— В'язень ZERO
17
var one = $("<div/>").data("add", 1); var two = $("<div>").data("add", 2); console.log(one.data("add")+two.data("add"));
— Юсаф Халик
1
Я цілком визнаю, що використання jQuery краще, ніж ванільний JS, але я думаю, кожен веб-розробник повинен знати і розуміти, що насправді робить jQuery перед його використанням, і як реалізувати те, що він хоче, без jQuery. Я думаю, що багато програмістів не знають чистого синтаксису JavaScript на відміну від jQuery, і тому вони роблять типові помилки.
— шеф

Відповіді:

129

Оновлення 2015:

У цій відповіді з 2011 року я говорю про такі бібліотеки, як jQuery, YUI або Prototype. Сьогодні в 2015 році це міркування все ще застосовується до таких фреймворків, як Angular, React або Ember. За ці 4 роки технологія надзвичайно прогресувала, і хоча я бачу значно менше упереджень до React або Angular, ніж до jQuery або YUI, таке саме мислення - хоча і в меншій мірі - все ще присутнє сьогодні.

Оновлення 2016:

Настійно рекомендую статтю, опубліковану кілька днів тому:

  • Чому jQuery? Майкл С. Mikowski, автор програм, утворять єдиний веб - книги

Ця стаття в основному є дуже детальною відповіддю на саме це питання. Якби він був доступний, коли я писав відповідь нижче - я б точно його процитував.

Оригінальна відповідь:

Я відповім про jQuery, але це ті самі аргументи, які я чув проти використання YUI, Prototype, Dojo, Ext та деяких інших. Основні аргументи, які я чув:

  1. розмір файлу , який насправді становить 84,6 КБ у випадку з jQuery 3.2.1 - можливо, менший за логотип на середньому веб-сайті і може бути поданий із CDN Google, який, ймовірно, вже є в кеші більшості ваших відвідувачів. Оскільки використання jQuery завжди означає менший розмір ваших власних файлів JavaScript, це насправді може означати менший завантаження, навіть якщо це ще не в кеші браузера.

  2. швидкість - написання чистого JavaScript може бути швидшим, але написання портативного JavaScript здається неможливим для більшості людей. Веб-сайт, який працює швидше, але працює не в кожному популярному браузері, марний у реальному світі. Окрім того, jQuery використовує кілька досить важких оптимізацій, щоб насправді бути шалено швидкими і продовжує ставати ще швидшими з кожним випуском, тому насправді не так просто писати швидший код вручну для чогось іншого, крім тривіальних прикладів. (*)

  3. "інтелектуальна власність" - компанія боїться використання чужого коду - хоча насправді jQuery є відкритим і безкоштовним програмним забезпеченням, яке використовується скрізь від блогу вашої бабусі до Amazon, від Twitter до Bank of America, від Google до Microsoft - якщо вони можуть використовувати його тоді будь-яка компанія може ним скористатися.

  4. Я не пам’ятаю, щоб будь-який інший аргумент був серйозно використаний.

(*) Ось тривіальний приклад: getElementById ('someid') проти jQuery ('# someid')

Чи швидше використовувати getElementById? Так. І звичайно, кожен завжди перевіряє батьківський вузол, щоб зловити, коли Blackberry 4.6 повертає вузли, яких більше немає в документі, так? jQuery робить. І всі розглядають випадок, коли IE та Opera повертають елементи за іменем, а не за ідентифікатором, так? jQuery робить. Якщо ви цього не зробите, тоді ваш код не переноситься, і ви вводите тонкі помилки, які дуже важко знайти. А getElementById - це найтривіальніший приклад, який можна було б знайти - навіть не запускайте мене з подій та AJAX та DOM ...

Оновлення:

Насправді є четвертий результат запитання, чому хтось не хоче використовувати jQuery. Я забув внести його до цього списку, оскільки це насправді не відповідь, а відсутність будь-якої відповіді. Коментар я отримав вчора нагадав мені про це. Це навряд чи буде додано до списку «технічна причина» , але може бути цікава тим не менше , і на самому справі може бути найбільш поширеною реакцією.

Однак, я особисто підозрюю, що це головна причина всіх цих реакцій, - це те, що, на мою думку, є найбільшою перешкодою для прогресу в галузі інформатики: "Я не хочу користуватися нею, тому що ніколи не робив, тому вона повинна не бути таким важливим ".

Колись це була реакція на оптимізацію асемблерів, компіляторів, структурованого програмування, мов вищого рівня, збору сміття, об’єктно-орієнтованого програмування, закриття чи майже всього, що ми зараз сприймаємо як належне - і сьогодні це бібліотеки AJAX. Можливо, колись ніхто не згадає, що колись ми колись взаємодіяли з необробленим DOM API на рівні програми, як зараз ніхто не пам’ятає, що колись ми писали програми, використовуючи необроблені, не прикрашені, незрозумілі шістнадцяткові числа .

— RSP
джерело
3
Занадто багато людей на підприємстві не розуміють ліцензування з відкритим кодом. Вони знають, що GPL є інфекційним, і його слід уникати у всьому програмному забезпеченні, яке може потрапити у продукт. Тоді багато хто з них грає в безпеці, забороняючи будь-яке використання відкритого коду в будь-якому місці бізнесу, побоюючись зараження GPL.
— Майкл Діллон,
23
Тому я завжди кажу, що Microsoft використовує jQuery, і це остання компанія на Землі, яка ризикує використовувати все, що загрожує їхній дорогоцінній інтелектуальній власності.
— rsp
6
Це дуже якісна відповідь, і час, який ви витратили на її написання, оцінений!
4
Ви забули фактичну головну причину, яка полягає в продуктивності. jQuery дуже повільний у порівнянні з власним JS при маніпулюванні DOM - це загальновідомий факт. Це не помітно в невеликих програмах, але додає явної дрібниці взаємодіям у великих веб-програмах. Крім того, ви помиляєтесь щодо розміру файлу. Рідко я буду писати стільки власних JS, що перевищує кількість коду у всій бібліотеці jQuery плюс моєму додатку. Ви упереджені. jQuery корисний для створення більшості веб-сайтів та прототипів веб-додатків, але існує випадок, щоб не використовувати його: Крім того, у nodeJS немає DOM.
— Бенні,
2
До легких для розуміння шістнадцяткових чисел існували плагіни . Станом на липень 2010 року ще є принаймні одна серія IBM 402
— Елліотт Фріш,
23

jQuery виражає все в DOM-орієнтованій парадигмі, що може ввести в оману і не вимагає потреби виражати речі в шаблоні програми.

Багато розробників заводить програмування в кут із цим DOM-орієнтованим шаблоном і врешті-решт усвідомлюють, що вони не створили нічого розширюваного чи багаторазового.

Ребекка Мерфі чудово написала свій власний перехід на Dojo від jQuery - публікація в блозі більше стосується того, чому не jQuery, а чому Dojo.

— філвінкл
джерело
3
Цікавий момент щодо орієнтованої на DOM парадигми, але моє запитання включає не бажання нічого використовувати , включаючи Dojo.
Зверніть увагу, що якщо у вас є час, ви можете побачити презентацію Ребекки jsconfeu вартою (і, можливо, більш відповідною до ваших поточних інтересів): jsconfeu.blip.tv/file/4308069
— Кен Франкейро
1
Я включив посилання на її публікацію в блозі, оскільки вона розповідає про те, чому не jQuery проти того, чому вона обрала Dojo. Основними моментами є причини, про які я доклав вище. Особисто я вважаю, що невикористання фреймворку в наші дні випливає з незнання, гордості чи обох.
— philwinkle
дякую за додаткове посилання, це схоже на продуманий твір, я його обов'язково прочитаю
18

Однією з причин не використовувати фреймворк - і це надзвичайний випадок - є написання коду, що вбудовується, для іншого веб-сайту, наприклад, банера. Довільне вставлення якоїсь складної бібліотеки чи іншої призведе до забруднення простору імен та потенційного злому чужого сайту. Не те, що я б не поклав руку на те, щоб деякі рекламодавці все-таки спробували сміття, що смокче ставок, але я відступаю ...

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

Окрім цього, я не можу придумати виправданої причини, щоб не робити.

— годинниковий механізм
джерело
1
це хороша відповідь, про яку ще ніхто не думав
1
Це. Тільки що зіткнувся зі сторінкою, мені довелося виконати технічне обслуговування, де JQuery 1.4.4 завантажувався як тег JS, а JQuery 1.3.x завантажувався за допомогою CDN від Google та альтернативного простору імен (так що метод $ () - став приблизно таким як $ jq ()).
— cthulhu
stackoverflow.com/questions/693174/… => не тільки при вбудовуванні коду на інший веб-сайт, але і в інших механізмах, що підтримують javascript.
— ribamar
11

розмір файлу - але насправді, крім цього, це абсолютне послання для міжплатформенних відмінностей між javascript та браузером. Ви повинні мати кілька поважних причин, щоб не хотіти цього у своєму наборі інструментів (або бути ідіотом-розробником фундаменталістів).

— jpea
джерело
1
так, ці дуже вагомі причини - це те, що я шукаю ...
12
Якщо я можу додати певного балансу до Вашого коментаря "фундаменталістський ідіот-розробник" , враховуйте той факт, що є також багато фундаменталістських ідіотів jQuery . Це ті, хто настійно рекомендує використовувати jQuery абсолютно в будь-якій ситуації, в тому числі, коли вам потрібно лише 5 рядків javascript.
— user113716
Я не можу проголосувати за це. Стислий jQuery становить 29 кб - трохи менше, ніж більшість зображень, - і якщо він подається з CDN (див. Docs.jquery.com/Downloading_jQuery ), він дуже добре кешується .
2
Ніщо не схоже на хорошу, дуже суб'єктивну думку, щоб підпалити коментарі :) - для тих, хто використовує jQuery лише для зручності селекторів, вони також можуть спробувати движок селектора, який він використовує, Sizzle - набагато менший - sizzlejs.com
— jpea
1
@jpea: Пінти це зроблять. ; o) Чудова порада щодо використання Sizzle.
— user113716
7
  • Вони не можуть виправдати розмір файлу (хоча це, мабуть, менше, ніж сценарій, який не використовує надані абстракції).
  • Вони не хочуть покладатися на сторонні інструменти.
  • Їхній бізнес не хоче керувати жодними бібліотеками (з якихось причин).
  • Їхній бізнес не хоче запускати будь-який код JavaScript, не написаний їх працівниками.
— Алекс
джерело
Деякі з цих моментів нагадують мені про те, як я думав про ці рамки 5 років тому, коли вони були ще молодими. У той час я не знав майже достатньо, щоб зрозуміти, скільки речей вони рятують кодерів від регулярної роботи, і я, природно, подумав: "Чому б просто не зробити те, що мені потрібно, сам?" Цікаво, як ви думаєте, які шанси на те, що деякі компанії все ще так думають через 5 років? Здебільшого, якщо розмір файлу чи IP насправді не викликає занепокоєння, я б сказав, що вони роблять собі серйозну погану послугу.
— Ken Franqueiro
2
@Ken Franqueiro Я бачив це тут, на Stack Overflow. Хтось запитав про те, щоб робити щось без jQuery, а потім хтось запитав, чому б не використовувати jQuery? , на що запитувач відповів, що наша компанія не може використовувати сторонні бібліотеки . Може бути , вони працюють для НАСА, і нові космічні дослідження машини використовують JavaScript (агов, це є всюди: P)
— Alex
2
час комусь знайти нову роботу!
5
  • Навчання: Насправді кодувати все і дізнаватися більше. (Замість використання попередньо закодованих матеріалів)
  • Розмір: jQuery має ТОНИ функцій, які можуть вам не знадобитися, навіщо змушувати користувача завантажувати стільки коду, якщо він не буде використовуватися?
  • Альтернативи: на даний момент існує десятки більш потужних, добре структурованих веб-фреймворків.
  • Гнучкість: хоча jQuery дійсно гнучкий, можливо, вам знадобиться щось, чого він не забезпечує.
— JCOC611
джерело
1
"Щоб насправді кодувати все і дізнатися більше". - Це працює для студентів, але якщо ви хлопець, який повинен зробити JS для нового веб-сайту Massive Inc, ви повинні мати можливість взяти на себе відповідальність за ваш вибір використання Barebones JS, власного фреймворку, який незмінно намагається наслідувати деякі існуючих фреймворків та мають розуміння та досвід для запобігання та виправлення помилок сумісності браузерів, які вже є у JQuery та подібних бібліотек. Подивіться відповідь RSP на хороший приклад.
— cthulhu
4

Безсумнівно, мені подобається jQuery, але є кілька причин не використовувати jQuery:

  1. Розмір / пропускна здатність завантаження: jQuery 1.5 зараз перевищує 200 тис. Стиснених, для деяких розмір бібліотеки занадто великий, щоб виправдати переваги.
  2. Продуктивність: Написати рідну JS завжди буде швидше, ніж абстрагуватися за бібліотекою.
  3. Додана складність: багато людей завантажують всю бібліотеку jQuery, коли їм дійсно потрібні лише кілька акуратних функцій з неї.
  4. Залежності додатків: Представлення залежностей завжди має зависання. Якщо у jQuery є помилка, ви можете налагодити та редагувати файл, але оновлення пізніше створює проблеми. Ви можете залишити помилку, але тепер ви виправляєте графік jQuery, а не ваш власний.
— Елі
джерело
6
Звичайно, для виготовлення ви завжди повинні використовувати зменшену та роздруковану версію, яка на момент написання статті становить 29 КБ. По-друге, хоча це правда, що абстракції сповільнюють роботу, я більше довіряю розробникам jQuery, ніж у багатьох випадках, і тому подібне; у програмі, яку я успадкував, доморощений сорт (що не було нічим негативним негайно) був на порядок повільнішим, ніж використання плагіна jorigors tableQorter.
— Xiong Chiamiov
Звичайно. Мені подобається jQuery, але для деяких це їх аргументи.
— Елі
3
Google, що надає jQuery через їхній CDN, означає, що якщо ви використовуєте цю версію, вона, швидше за все, вже є в локальному кеші користувачів.
3

Бо досить часто це просто непотрібно. якщо все, що я хочу зробити, це перевірити якийсь вхідний текст, або присвоїти якесь поле, тоді так само просто написати простий код javascript / dom. І jQuery насправді не допомагає в таких простих випадках, тому питання має бути, навіщо його використовувати?

Очевидно, що є багато випадків, коли це дуже корисно, але іноді люди, здається, використовують його також без реальних причин.

— jcoder
джерело
1
Насправді, навіть у таких тривіальних випадках, структура JS допомогла б. Запобігайте помилкам між браузерами такими речами, як getElementById (див. Відповідь RSP), отримуйте миттєвий доступ до попередньо побудованих валідаторів за допомогою плагіна JQuery validate тощо. Використання JQuery скорочує час розробки, а час розробки дорогий. Особливо, якщо "перевірити деякий вхід" з часом зростає, включаючи матеріали JS для всього сайту.
— cthulhu
2

Я віддав би перевагу використанню jquery для маніпулювання dom або для обходу dom, що дуже просто з jquery. Більше того, приєднати подію або делегування події настільки просто, використовуючи jquery або інший фреймворк, інакше вам доведеться писати власні вкладення подій для браузерів IE чи інших IE тощо.

Але це вимагає певного покарання за продуктивність, коли ви використовуєте $ .each замість ванільного JS для та array.push () ... інші проблеми, наприклад, якщо ви прив'яжете подію та видалите, що без від'єднання це призведе до витоку пам'яті ....

Мій висновок - використовувати лише будь-які рамки для складних маніпуляцій з куполами, а в іншому - ванільний JS

— Павло
джерело
2

Чому б не використовувати jQuery?

Я не можу придумати гарного виправдання для використання ванільного JavaScript над jQuery (крім фактору залякування вивчення чогось нового), але деякі люди віддають перевагу іншим фреймворкам JavaScript (наприклад, чудові MooTools ) через філософські відмінності між ними.

Деяким людям просто не подобається синтаксис jQuery DSL -ish, але вони усвідомлюють важливість використання надійного фреймворку JavaScript.

Особисто я люблю jQuery, але я знаю людей, які використовують інші фреймворки і не менш продуктивні.

— ЗакриттяКовбой
джерело
так, я це знаю, а як щодо інших людей, які не визнають важливості використання надійного фреймворку JavaScript, чи є у них якісь технічно обґрунтовані причини?
1
@fuzzy: емоційні причини набагато важливіші за технічні при виборі інструментів, якщо тільки ви не є одним з небагатьох технічних архітекторів, який має мандат знайти найкращий спосіб зробити щось.
— Michael Dillon
@Michael - Я в положенні, коли мене не хвилює такий тип причин, я дбаю про те, наскільки продуктивні мої люди, так само, як я не розумію, чому деякі люди наполягають на використанні NotePad на вікнах для написання всієї своєї Java коду, використання спеціальної IDE Java завжди буде більш продуктивним. Мені цікаво, наскільки продуктивні люди, і я просто хотів переконатися, що я не пропускаю жодної вагомої технічної причини, щоб не наполягати на використанні чогось на кшталт jQuery.
1
@fuzzy льодяник: Ви розумієте, що бібліотеки javascript - це лише заздалегідь написаний код javascript, так?
— user113716
1
... Такі причини, як розмір файлу, є суб’єктивними. Те, що одна людина вважає занадто великою, може вважатися цілком прийнятним для іншої. Подивіться, на що я потрапляю?
— user113716
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.