Каковы некоторые эмпирические технические причины не использовать jQuery?

Контекст: Меня поражает количество разработчиков, которые взломали HTML, Javascript и CSS в течение всего дня, и что игнорировать инструменты, такие как jQuery (или другие эквивалентные вспомогательные рамки) и отказаться использовать их. Я не говорю о гуру JavaScript, о которых я говорю в окопах каждый день разработчикам производства Joe. Я получаю много аргументов, которые скорее напоминают оправдания или личные мнения, которые, как я считаю, не имеют технических достоинств, я хочу убедиться, что я чего-то не упускаю.

Вопрос: Каковы некоторые эмпирические технические причины не использовать jQuery?

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

Ответ 1

Обновление 2015:

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

Обновление 2016:

Я очень рекомендую статью, опубликованную несколько дней назад:

  • Почему jQuery? Майкла С. Миковски, автора книги веб-приложений Single Pages

Эта статья в основном очень подробный ответ на этот вопрос. Если бы он был доступен, когда я писал ответ ниже, я бы определенно процитировал его.

Оригинальный ответ:

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

  • размер файла, который на самом деле составляет 84,6 КБ в случае jQuery 3.2.1 - возможно меньше логотипа на среднем веб-сайте и может быть подан из Google CDN, который, скорее всего, уже находится в кеше большинства ваших посетителей. Поскольку использование jQuery всегда означает меньший размер файлов ваших собственных файлов JavaScript, это может означать меньшую загрузку, даже если она еще не находится в кеше браузера.

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

  • "интеллектуальная собственность" - компания испугалась, используя код другого пользователя, - хотя на самом деле jQuery - это с открытым исходным кодом и бесплатное программное обеспечение, которое используется повсюду от вашего блога бабушки до Amazon, из Twitter в Bank of America, от Google до Microsoft - если они смогут его использовать, то любая компания может его использовать.

  • Я не помню, как слышал какой-либо другой аргумент, который серьезно используется.

(*) Здесь тривиальный пример: getElementById ('someid') vs. jQuery ('# someid')

Использует getElementById быстрее? Да. И, конечно, каждый всегда проверяет parentNode, чтобы поймать, когда Blackberry 4.6 возвращает узлы, которые больше не находятся в документе, не так ли? jQuery делает. И каждый обрабатывает случай, когда IE и Opera возвращают элементы по имени вместо ID, не так ли? jQuery делает. Если вы этого не сделаете, ваш код не переносится, и вы вводите тонкие ошибки, которые могут быть очень трудно найти. И getElementById - самый тривиальный пример, который можно найти - даже не заставляйте меня запускать события и AJAX и DOM...

Обновление:

На самом деле есть четвертый результат запроса, почему кто-то не хочет использовать jQuery. Я забыл поместить его в этот список, потому что это не ответ, а отсутствие ответа. comment, который я вчера получил, напомнил мне об этом. Это вряд ли является "технической причиной", которая должна быть добавлена ​​в список, но может быть интересной, тем не менее, и может быть самой общей реакцией.

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

Это была реакция на оптимизацию ассемблеров, компиляторов, структурированное программирование, языки более высокого уровня, сбор мусора, объектно-ориентированное программирование, закрытие или почти все, что мы сейчас считаем само собой разумеющимся, - и сегодня это библиотеки AJAX. Возможно, когда-нибудь никто не вспомнит, что мы когда-то использовали для ручного взаимодействия с необработанным DOM API на уровне приложений, как сейчас никто не помнит, что мы когда-то использовали для написания программ, используя необработанные, незакрашенные, неиспользуемые шестнадцатеричные числа.

Ответ 2

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

Многие разработчики завершают программирование себя в угол с этим DOM-ориентированным шаблоном и в конечном итоге понимают, что они не создали ничего расширяемого или многоразового использования.

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

Ответ 3

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

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

Кроме того, я не могу думать об обоснованной причине, чтобы не делать этого.

Ответ 4

filesize - но на самом деле, кроме того, это абсолютный бог-отправка для кросс-платформенных javascript и различий браузера. У вас должны быть некоторые очень веские причины, чтобы не хотеть этого в вашем наборе инструментов (или быть идиотом-разработчиком фундаменталистов).

Ответ 5

  • Они не могут оправдать размер файла (хотя он, вероятно, меньше script, который не использует предоставленные абстракции).
  • Они не хотят полагаться на сторонние инструменты.
  • Их бизнес не хочет запускать какие-либо библиотеки (по каким-либо причинам).
  • Их бизнес не хочет запускать какой-либо код JavaScript, не написанный их сотрудниками.

Ответ 6

В любом случае, мне нравится jQuery, но есть некоторые причины не использовать jQuery:

  • Размер/пропускная способность загрузки: jQuery 1.5 теперь нескомпрессирован более 200K, для некоторых размер библиотеки слишком велик, чтобы оправдать выгоду.
  • Производительность. Написание собственного JS всегда будет быстрее, чем абстрагирование его позади библиотеки.
  • Сложная сложность: многие люди будут загружать всю библиотеку jQuery, когда на самом деле им нужно всего лишь несколько опрятных функций.
  • Зависимости приложений. Представление зависимостей всегда имеет зависание. Если в jQuery есть ошибка, вы можете отлаживать и редактировать файл, но при обновлении позже возникают проблемы. Вы можете оставить ошибку, но теперь вы зависите от таблицы времени jQuery для исправления, а не вашего.

Ответ 7

  • На самом деле все кодировать и узнать больше. (Вместо использования предварительно закодированных материалов)
  • jQuery имеет TONS функций, которые вам просто не нужны, зачем заставить пользователя загружать так много кода, если он не будет использоваться?
  • Испытайте себя? Могу ли я победить jQuery, или, по крайней мере, могу ли я выжить с простым кодом ванили?
  • Гибкость: Altho jQuery действительно гибкий... вам может понадобиться то, что он не предоставляет...

Ответ 8

Потому что довольно часто это просто не нужно. если все, что я хочу сделать, это проверить некоторый ввод, или hilight какое-то поле, тогда он так же просто написать простой код javascript/dom. И jQuery действительно не помогает в таких простых случаях, поэтому вопрос должен быть в том, почему его использовать?

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

Ответ 9

Я бы предпочел использовать jquery для манипуляции с dom или пересечения dom, что очень просто с jquery. Более того, присоединение делегирования событий или событий настолько просто с использованием jquery или другой структуры, иначе вы должны написать собственное приложение для приложений для IE или не IE-браузеров и т.д.

Но он имеет некоторое ограничение производительности при использовании $.each вместо vanilla JS for и array.push()... другие проблемы, например, если вы привязываете событие и удаляете его без развязки, у него будет утечка памяти....

Мое заключение заключается только в использовании любых фреймворков для комплексной манипуляции с домино и использования ванили JS

Ответ 10

Почему бы не использовать jQuery?

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

Некоторым людям просто не нравится jQuery DSL - синтаксис, но они признают важность использования надежной инфраструктуры JavaScript.

Лично я люблю jQuery, но я знаю людей, которые используют другие фреймворки и не менее продуктивны.