Какие эмпирические технические причины не использовать jQuery?
Контекст: меня поразило количество разработчиков, которые взломали HTML, Javascript и CSS в течение всего дня и которые игнорируют такие инструменты, как jQuery (или другие эквивалентные вспомогательные среды) и отказываются их использовать. Я не говорю о гуру JavaScript, я говорю в окопах каждый день разработчиков продюсер Джо. Я получаю много аргументов, которые больше похожи на оправдания или личные мнения, которые, как мне кажется, не имеют каких-либо технических достоинств, я хочу убедиться, что я что-то не упустил.
Вопрос: Каковы некоторые технические эмпирические причины не использовать JQuery?
Я не ищу религиозных или догматических аргументов или субъективных мнений "как какая-то другая структура лучше", считаю jQuery соломенным человеком для всех сопоставимых систем в этом вопросе.
10 ответов
Обновление 2015:
В этом ответе от 2011 года я говорю о библиотеках, таких как jQuery, YUI или Prototype. Сегодня, в 2015 году, эти рассуждения все еще применимы к таким фреймворкам, как Angular, React или Ember. За эти 4 года технология значительно продвинулась, и, хотя я вижу значительно меньше предубеждений против React или Angular, чем против jQuery или YUI, тот же тип мышления - хотя и в меньшей степени - все еще присутствует сегодня.
Обновление 2016:
Я настоятельно рекомендую статью, опубликованную несколько дней назад:
- Почему jQuery? Майкл С. Миковский, автор книги "Одностраничные веб-приложения"
Эта статья в основном очень подробный ответ на этот вопрос. Если бы он был доступен, когда я писал ответ ниже - я бы определенно процитировал его.
Оригинальный ответ:
Я отвечу о jQuery, но это те же аргументы, которые я слышал против использования YUI, Prototype, Dojo, Ext и некоторых других. Основные аргументы, которые я услышал:
размер файла, который на самом деле составляет 84,6 КБ в случае jQuery 3.2.1 - вероятно, меньше, чем логотип на среднем веб-сайте, и его можно обслуживать из CDN Google, который, вероятно, уже находится в кеше большинства ваших посетителей. Поскольку использование jQuery всегда означает меньший размер ваших собственных файлов JavaScript, это может фактически означать меньшую загрузку, даже если она еще не находится в кэше браузера.
Скорость - написание чистого JavaScript может быть быстрее, но написание переносимого JavaScript кажется невозможным для большинства людей. Сайт, который работает быстрее, но не работает на всех популярных браузерах, бесполезен в реальном мире. Кроме того, jQuery использует несколько довольно тяжелых оптимизаций, чтобы на самом деле быть чертовски быстрыми, и с каждым выпуском становится все быстрее, поэтому на самом деле не так просто написать более быстрый код вручную для чего-либо, кроме тривиальных примеров.(*)
"интеллектуальная собственность" - компания напугана, используя чужой код, - хотя на самом деле jQuery - это бесплатное программное обеспечение с открытым исходным кодом, которое используется везде, от блога вашей бабушки до Amazon, от Twitter до Bank of America, от Google до Microsoft - если они могут используйте это, тогда любая компания может использовать это.
Я не могу вспомнить, чтобы какой-то другой аргумент использовался всерьез.
(*) Вот тривиальный пример: getElementById('someid') против jQuery('#someid')
Использование getElementById быстрее? Да. И, конечно, каждый всегда проверяет parentNode, чтобы ловить, когда Blackberry 4.6 возвращает узлы, которых больше нет в документе, верно? JQuery делает. И каждый обрабатывает случай, когда IE и Opera возвращают элементы по имени, а не по идентификатору, верно? JQuery делает. Если вы этого не сделаете, то ваш код не переносим, и вы вводите тонкие ошибки, которые может быть очень трудно найти. И getElementById - самый тривиальный пример, который только можно найти - даже не заводите меня на события, AJAX и DOM...
Обновить:
На самом деле есть четвертый результат: почему кто-то не хочет использовать jQuery. Я забыл поместить его в этот список, потому что это не ответ, а отсутствие ответа. Комментарий, который я получил вчера, напомнил мне об этом. Вряд ли это "техническая причина", которую следует добавить в список, но, тем не менее, она может быть интересной и фактически может быть самой распространенной реакцией.
Однако лично я подозреваю, что главной причиной всех этих реакций является то, что я считаю самым большим препятствием на пути прогресса в информатике: "Я не хочу использовать это, потому что никогда не делал, поэтому оно должно не так важно."
Когда-то это была реакция на оптимизацию ассемблеров, компиляторов, структурного программирования, языков высокого уровня, сборки мусора, объектно-ориентированного программирования, замыканий или почти всего, что мы сейчас принимаем как должное - и сегодня это библиотеки AJAX. Возможно, однажды никто не вспомнит, что когда-то мы когда-то вручную взаимодействовали с необработанным DOM API на уровне приложений, как сейчас, никто не помнит, что когда-то мы писали программы, используя необработанные, неукрашенные, непостижимые шестнадцатеричные числа.
jQuery выражает все в DOM-центричной парадигме, которая может вводить в заблуждение и не требует никакой необходимости выражать вещи в шаблоне приложения.
Многие разработчики загоняют себя в угол с помощью этого DOM-ориентированного паттерна и в конце концов понимают, что они не создали ничего расширяемого или повторно используемого.
Ребекка Мерфи написала о своем собственном переходе на Dojo из jQuery - пост в блоге больше о том, почему не jQuery, а о том, почему Dojo.
Одна из причин не использовать фреймворк - а это крайний крайний случай - заключается в написании встраиваемого кода для другого сайта, такого как баннер. Произвольная вставка какой-либо сложной библиотеки или другой будет загрязнять пространство имен и потенциально нарушать чей-либо сайт. Не то чтобы я в любом случае не позволил бы рекламодателям попробовать эту грязную пыль, но я отвлекся...
Я не одобряю добавление фреймворка, когда он уже есть и в равной степени способен. Я вижу это слишком часто, и это моя домашняя ненависть, я вижу это как необоснованное раздувание. Это совсем другой вопрос.
Кроме этого я не могу придумать оправданную причину не делать этого.
Размер файла - но на самом деле, помимо этого, это абсолютная божья коровка для кроссплатформенных различий между JavaScript и браузером. У вас должны быть очень веские причины не хотеть этого в своем наборе инструментов (или быть идиотом-фундаменталистом-разработчиком).
- Они не могут оправдать размер файла (хотя это, вероятно, меньше, чем сценарий, который не использует предоставленные абстракции).
- Они не хотят полагаться на сторонние инструменты.
- Их бизнес не хочет запускать какие-либо библиотеки (по тем или иным причинам).
- Их бизнес не хочет запускать какой-либо код JavaScript, написанный не их сотрудниками.
- Обучение: на самом деле кодировать все и учиться больше. (Вместо того, чтобы использовать предварительно закодированный материал)
- Размер: jQuery имеет множество функций, которые могут вам не понадобиться. Зачем заставлять пользователя загружать так много кода, если он не будет использоваться?
- Альтернативы: на данный момент существуют десятки более мощных, хорошо структурированных веб-фреймворков.
- Гибкость: хотя jQuery действительно гибкий, вам может понадобиться то, что он не предоставляет.
Конечно, мне нравится jQuery, но есть несколько причин не использовать jQuery:
- Размер загрузки / пропускная способность: в jQuery 1.5 теперь более 200 КБ без сжатия, для некоторых размер библиотеки слишком велик, чтобы оправдать выгоду.
- Производительность: написание нативного JS всегда будет быстрее абстрагирования от библиотеки.
- Дополнительная сложность: многие люди скачивают всю библиотеку jQuery, когда им действительно нужны лишь несколько полезных функций.
- Зависимости приложений: введение зависимостей всегда имеет свои проблемы. Если в jQuery есть ошибка, вы можете отладить и отредактировать файл, но позднее обновление приводит к проблемам. Вы можете оставить ошибку, но теперь вы зависите от расписания jQuery для исправления, а не от своего.
Потому что довольно часто это просто не нужно. если все, что я хочу сделать, это проверить ввод данных или выделить поле, то так же просто написать простой код javascript / dom. И jQuery не очень помогает в таких простых случаях, поэтому возникает вопрос: зачем его использовать?
Очевидно, что есть много случаев, когда это очень полезно, но иногда люди, кажется, используют его также без реальной причины.
Я бы предпочел использовать jquery для манипулирования dom или обхода dom, что действительно легко сделать с помощью jquery . Более того, присоединение события или делегирования события так просто с помощью jquery или другой инфраструктуры, иначе вам придется написать пользовательское вложение события для браузеров IE или не IE и т. Д.
Но он имеет некоторое снижение производительности, когда вы используете $.each вместо vanilla JS for и array.push()... другие проблемы, например, если вы связываете событие и удаляете его без отмены привязки, это приведет к утечке памяти....
Мой вывод только использовать любые рамки для сложных манипуляций с домом, а остальное использовать vanilla JS
Почему бы не использовать JQuery?
Я не могу найти хорошего оправдания для использования ванильного JavaScript над jQuery (кроме фактора запугивания при изучении чего-то нового), но некоторые люди предпочитают другие JavaScript-фреймворки (например, превосходные MooTools) из-за философских различий между ними.
Некоторым людям просто не нравится DSQ -ish-синтаксис jQuery, но они осознают важность использования надежной платформы JavaScript.
Лично я люблю jQuery, но я знаю людей, которые используют другие фреймворки и не менее продуктивны.