Почему некоторые люди утврерждают что плохо использовать jQuery?

Question

[Ibishka]

Плохо ли использовать jQuery? Проект например интернет магазин при использовании чистого javascript будет более привлекательнее для заказчика или при входе в офис или с использоанием jQuery?

Comments

[Дмитрий]

Бессмысленный вопрос и обсуждения его бессмысленны. Есть множество библиотек, lodash например, и по каждой из них будет одинакового уровня бессмысленности холливар - можно с ней а можно без нее, кому как нравится.

[Сергей delphinpro]

Это люди, которые впервые написали hello world на vue/react
Или люди, которые работают с крупными проектами на мейнстимовом стеке.

Поэтому, нет, — использовать jquery не плохо.

А заказчику вообще по барабану, на чем вы пишете. Ему главное, чтобы вы бизнес-задачу решили и в дальнейшем у него не было проблем с поддержкой этого кода.

[Алекс Глебов]

Нет смысла ругать стандарт, который используется в 99,99% если верстка не spa.
И которому нет замены.
От лапши помогут избавиться ооп и паттерны, jq не про это, это всего лишь абстракция над неудобным dom api.
https://habr.com/ru/company/ruvds/blog/455509/

Answer 1

[Сергей Горностаев]

Во-первых, jQuery родилась во времена, когда каждый браузер реализовывал JS и DOM API по-своему, её основным назначением было сглаживать эти различия. В наше время это преимущество библиотеки уже утеряно. Во-вторых, jQuery не соответствует основному вызову современности - сложной кодовой базе. В развитом фронте код, использующий jQuery, быстро превращается в трудно сопровождаемую лапшу. Поэтому для простого фронта чаще стали использовать ванильный JS, а для сложного фреймворки типа React, Angular и Vue.

Comments

[Сергей delphinpro]

Чем выгоден ванильный жс на простом фронте, по сравнению с jquery? Я не понял этого момента.

[Сергей Горностаев]

Сергей delphinpro, понятнее становится, если подойти к вопросу с другой стороны: Чем jQuery выгоднее по сравнению с ванилькой? А почти ничем. Получаемые выгоды настолько мизерны, что не оправдывают дополнительных загружаемых килобайт и снижения производительности. Впрочем, тоже не очень значительных.

[Северное Сияние]

Сергей delphinpro,

Чем выгоден ванильный жс на простом фронте, по сравнению с jquery?

стандартизацией

[Сергей delphinpro]

Сергей Горностаев, Нет, не становится. Я все еще не понял, почему код на jquery превращается в лапшу, а ванилька — нет.
Вам не кажется, что вопрос организации кода лежит за пределами выбора библиотеки/фреймворка?

Северное Сияние, стандартизацией чего? Если уж хотите подискутировать, то выражайте свою мысль подробнее.

[Сергей Горностаев]

Сергей delphinpro, лапша - это из во-вторых, а там идёт сравнение с использованием фреймворков. Именно они помогают избегать лапши.

[Сергей delphinpro]

Сергей Горностаев, нет, не помогают. наговнокодить лапши на условном вью так же легко, как и без него.

[dom1n1k]

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

Кстати, часто случается смешная ситуация, когда люди используют jQuery сами того не зная :) Например, подрубают какой-нибудь vue-slick и думают, что они такие модные и всех обманули. А оно само через зависимости притянулось. Чесслово, это реальные случаи, не придумываю.

[profesor08]

dom1n1k,

То что ванильный JS может полностью и безболезненно заменить jQuery - это миф

Зачем мне писать на jQuery, если я могу писать на ваниле, а после обработки через babel, мой код будет весить мизер и работать везде?

[yarovikov]

profesor08, зачем писать километровые конструкции на js, если можно быстро и безболезненно их наваять на jquery, особенно со всякими ajax и пр? Не накидываю, просто интересно.

[dom1n1k]

profesor08, можете, но... Во-первых, гораздо более многословно - там где jQuery нужна одна строка кода, ванила потребует несколько. Во-вторых, нужно помнить гораздо больше нюансов - ну-ка, какой процент нынешних разрабов навскидку скажет мне разницу между Node и Element? Или между NodeList и HTMLCollection?

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

Чтоб не было недопониманий, я подчеркну, что я не против ванильного JS и не агитирую за jQuery, как "лучший" вариант. Я против мифа и нигилизма, которые сопровождают jQuery последние пару-тройку лет - мол, ванила уже полностью всё заменяет, а кто не согласен, тот лошара. Не заменяет, там куча нюансов. Если мы решили писать на ваниле и сознательно готовы принять все её плюсы и минусы - отлично, я поддерживают стремление к оптимизации. Но не нужно мне рассказывать, что jQuery это бесполезный легаси-мусор. На нём пол-интернета работает и ещё долго будет работать.

[Сергей Горностаев]

dom1n1k, добавлю, что jQuery никуда не денется как минимум до тех пор, пока есть Bootstrap, а последний терять востребованность не собирается, похоже.

[profesor08]

dom1n1k, yarovikov, ну вот, теперь разговор пошел про кол-во строк, пора уже и cdn подключать, а то преимущество так себе.

[dom1n1k]

Причем тут cdn? Количество строк - это в первую очередь нагрузка на мозг, а уж потом на канал. Больше строк - больше нужно читать, сложнее разбираться, больше возможностей ошибиться, наговнокодить, наделать багов.

[MR27]

yarovikov,

зачем писать километровые конструкции на js, если можно быстро и безболезненно их наваять на jquery, особенно со всякими ajax и пр?

Откройте уже для себя ES6+
Там встроено уже много лет как 99% функционала, что чаще всего используется из jQuery
И занимает это ровно такой же объем кода, что и на jQuery - речь про то, что вы пишете ручками сами.
И занимает это меньший объем - речь про подтягиваемые библиотеки.

[Stalker_RED]

Юрий,

document.addEventListener('input', evt => {
  if (evt.target.matches('input, textarea')) {
    // do something
    out.textContent = evt.target.value
  }
})

https://jsfiddle.net/m9o3xatn/

ну или, чтобы ближе к вашему варианту

document
  .querySelectorAll('input, textarea')
  .forEach(el => out.textContent = el.value)

но первый способ лучше, имхо.

[dom1n1k]

Stalker_RED, первый вариант конечно правильнее, потому что делает единый обработчик, а второй размножает копии по количеству инпутов.

Только нужно учитывать, что уже на таком простом примере из трёх строк нам потребуются полифилы (если нас интересуют пользователи из реального мира). В 1 случае для matches, во 2 для forEach. Насчет сравнения читаемости кода каждый пусть судит сам.

[Stalker_RED]

Юрий, некоторым приходится поддерживать старые браузеры, ага.

[dom1n1k]

Юрий, да такой же как у всех. Если что, Array.forEach != NodeList.forEach (это к вопросу, что с ванилой нужно помнить больше нюансов).

[Пашенька]

dom1n1k, будьте любезны пример, когда в условиях реального мира в 2019 году ванильный js стал проблемой кроссбраузерности.

[batyrmastyr]

like-a-boss, fetch. Протез для него весит килобайт 40, насколько помню.

[Пашенька]

batyrmastyr, да он не упёрся, есть XMLHttpRequest

[Alendorff]

Сергей delphinpro, простой пример: представьте у вас есть массив данных, возможно полученный от апи, который нужно отрисовать на странице.
Какой код вы напишите используя jquery? Какой код вы напишите используя условный vue?
Вот мой вариант для vue:

<template>
  <div v-for="item of items" :key="item.id">
    <div>{{ item.content }}</div>
  </div>
</template>

<script>
  export default {
    data() {
      return { items: [ ... ] }
    }
  }
</script>

как эту тривиальнейшую задачу решают с jquery? Ну наверное надо будет сначала выбрать элемент, в который добавим новые ноды, потом эти ноды создать, потом вставить. Это куча работы, которую непонятно зачем делать, когда можно её не делать. Конечно программисты ленивые и, используя jquery, напишут какие-нибудь функции утилитки, чтобы можно было сократить количество скучного, повторяющегося, однообразного кода. Так люди пишут свои фреймворки вокруг jquery/vanillaJS и замыкают проект на зависимости от себя, потому что потом с этой лапшой, как бы она великолепно не была организована, никакой человек с улицы не захочет работать.

[Сергей delphinpro]

Alendorff, Я возьму любой js-шаблонизатор и сделаю ровно то же, что и на вью. Кода будет немного больше. Но если это единственный виджет с подгрузкой, то норм.
Разумеется, если подобных кейсов на сайте много, я в первую очередь рассмотрю вариант использования того же вью. Но это не дает повода говорить о том, что использование jquery плохо, он вполне решает задачи.

Answer 2

[profesor08]

Потому что проблемы кроссбраузерности решены стандартизацией api, а проблемы старых браузеров красиво решает babel.

Answer 3

[Кирилл Горелов]

Добавлю еще момент.

Помимо всего прочего jQuery тяжелее своих аналогов. И работает медленнее чем чистый js.
Но конечно же это "медленно" для нас практический не заметно. Потому что jQuery можно сказать библиотека/фреймворк для js.

Answer 4

[Programmir]

Ничем не плохо. На jQuery можно практически всё реализовать. Я его использую. Гораздо удобнее чистого JS.

Answer 5

[xfg]

jQuery - это про императивное программирование. jQuery - это про то "как" манипулировать dom элементами. Итог - смесь dom и бизнес-логики. Это невозможно разделить.

Angular - это про декларативное программирование. В Angular мы не говорим "как", мы говорим "что" мы хотим сделать с dom и он делает это. Что позволяет отделить бизнес-логику от манипуляций с dom.

Соответственно вся эта история не про jquery vs vanilla, а про императивное vs декларативное программирование для работы с dom. Большинство этого не понимает и спорят о jquery vs vanilla, хотя всё это одно и то же, до тех пор пока у вас не появляется какая-то штука, которая меняет парадигму работы с dom с императивного на декларативный. Внутри этой штуки можно использовать хоть vanilla, хоть jquery. Без этой штуки - у вас каша, хоть с vanilla, хоть с jquery.

Собственно об этом написано в википедии:

AngularJS is built on the belief that declarative programming should be used to create user interfaces and connect software components, while imperative programming is better suited to defining an application's business logic.

Остальные фреймворки про то же самое. Это и стало причиной стремительного роста популярности javascript фреймворков.

Comments

[Антон Р.]

что мешает в императивном стиле написать свои собственные классы на js или jq не привязываясь к конкретному фреймворку?

[xfg]

Антон Р., вы можете, команда angular лишь говорит, поскольку сам html - язык декларативный, то давайте продолжим и сделаем его динамическим в такой же парадигме. Что логично, но соглашаться с этим или нет выбор каждого.

Я не знаю какой самодисциплиной необходимо обладать, чтобы делать динамический UI без подобного помошника. Как правило это заканчивается тем, что манипуляция с dom, бизнес-логика и работа с сетью - все смешивается в одну кучу, без unit тестов, без tdd. Это может быть ок, для аутсорсинговой компании или фриланса с дешевыми сайтами на CMS. Но для продуктовой компании несколько странно.

Answer 6

[Beliyadm]

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

Comments

[dom1n1k]

Нельзя так сравнивать. Гуглите по словам addy osmani cost of javascript. Если в двух словах, то скрипты обходятся намного дороже, чем картинка такого же веса.

[batyrmastyr]

dom1n1k, согласен, но у нас же есть и скрипты аналитики! А они, сволочи, в несколько раз тормознее жикверя.

[Beliyadm]

dom1n1k, Совершенно не спорю, но скрипт один на 100 кб и 10 картинок по 200 кб
Скрипт может завесить страницу и все, но картинки сожрут весь мобильный трафик за безумные деньги

Answer 7

[SagePtr]

Тем, что представляет из себя набор костылей "на все случаи жизни", которые современным браузерам нафиг не нужны, но были очень актуальны в древние времена. Это не "плохо", это "бесполезно", но не "вредно". Кому-то удобнее на ванильном js писать код и не париться с подключением лишней библиотеки, а кому-то нравится синтаксический сахар jQuery (кроме сахара в наше время эта библиотека больше никакой полезной роли не играет по сути).

Comments

[Сергей delphinpro]

То, что было актуально в древние времена, давно уже выпилили из jquery

If you need to support older browsers like Internet Explorer 6-8, Opera 12.1x or Safari 5.1+, use jQuery 1.12.

Answer 8

[АртемЪ]

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

Некоторые люди говорят что мерс 600 это хлам, он вообще не едет в отличии от уазика. Банально в двух метрах от дома застревает в грязи. А некоторые наоборот хвалят мерс. Находятся даже люди которым уазик не нравится, мол по асфальту трясет сильно.