Почему говорят что jquery не нужен?

Здравствуйте, в последнее время все чаще слышу что jquery не нужен, прошлый век и тд
Объясните пожалуйста почему?
что изменилось за последние лет 5, что он вдруг стал больше не нужен?
Что тогда является современной заменой jquery?
Ощущение что что то пропустил
Сколько не писал на js, Jquery Всегда облегчал и у меньшал код
Почему он становвиться не нужным?
  • Вопрос задан
  • 11327 просмотров
Решения вопроса 1
@dmitry_pacification
Трудности рождают прорыв
Так говорят скорее всего потому, что не понимают что на самом деле jQuery дает. Можно написать все на чистом js, но jq вразы ускоряет разработку. Соответственно люди которые кричат против jq и получают деньги за часы работы заинтересованы в том, чтобы делать по дольше задачу и получить больше денег.
Такой себе способ раздобыть немножно монет и понимания работы чистого js. ))
Я пытался реализовать на js обычную кнопку "наверх", и плавный переход по лендинку вверх и в низ. Чесн скажу, я задолбался. Я знаю что на jq я решу это быстро и спокойно, на на нейтиве - это изобретения велосипеда с 0
Ответ написан
Пригласить эксперта
Ответы на вопрос 10
ThunderCat
@ThunderCat
{PHP, MySql, HTML, JS, CSS} developer
Скрипач не нужен, родной (с)
Аргументы против jq:
- современные браузеры достаточно хорошо поддерживают единый синтаксис современного екмаскрипт(native js)(на самом деле нет).
- сторонняя библиотека, работает медленнее чем натив и в основном состоит из с-сахара (тоже не совсем правда)
- тащить еще один ресурс весом от 64 кб до 200 кб, еще и со сторонних ресурсов замедляет загрузку( правда, но бред)
Аргументы за:
- Современные браузеры как и всегда один другого "ровнее", всегда есть косяки и "нюансы", на которые еще и попадаешь обычно в самый неподходящий момент, в жк обычно все работает одинаково везде, ну или лучше чем в нативе.
- В жк реализована куча плюшек в 1 функцию которые в нативе занимают "многабукав", не каждый начинающий напишет их правильно, да и профи не все напишут оптимально, уверен что в большинстве случаев написанный нативом функционал будет хуже аналога из жк.
- размер мин пакета жк 64 кб, и все они лежат на быстрых цдн серверах. Думаю это последнее что может повлиять на скорость загрузки страницы.
- есть ОГРОМНОЕ количество скриптов написанных с учетом жк, не использовать их глупо, писать свой велосипед - вообще только в целях обучения(не берем крайние случаи когда плагин писал упоротый пингвин).
- Синтаксис и краткость записи - вообще вне конкуренции.
- Старые браузеры никто не отменял, часто заказчик требует чтобы работало в ие8, натив не канает или доставляет море анального удовольствия.
Вывод: Если ты крут в жс, еще и работаешь в ангуларе/ещечетамдляфронта и тебе нужно сделать 2 действия в очень современных браузерах - jquery не нужен, и ты это сам знаешь. Если слова ангулар, вуе и проч для тебя не больше чем шум листвы за окном, а навесить плагинов и эффектов нужно - jquery наше все.

UPD: для всех кто там отписался а ля "в связи (...), исчезновением проблемы совместимости со старыми IE (что и было основным назначением jQuery)." - свежачок
Ответ написан
iCoderXXI
@iCoderXXI
React.JS/FrontEnd engineer
jQuery был хорош, но ничто не стоит на месте. Раньше фронтенд никто особо не воспринимал всерьез. Все считали, что фронтенд - это несколько скриптов, которые принципиально погоды не делают. Все изменилось с ростом популярность SPA, в т.ч. и благодаря бурному развитию JS.

В любом приложении очень важно прозрачно и понятно управлять состоянием, очень желательно делать это централизованно. Былой подход с участием jQuery делает это невозможным. Кто угодно может менять что угодно на странице, когда угодно, и приложение об этом ничего не знает без очень хитровыдуманных методов. Например в первом ангуляре для этого постоянно бегал по элементам и проверял что там изменилось, это называется "грязные проверки" (dirty checking). Мягко говоря это ни разу не оптимальный способ контроля состояния, но, на тот момент, вариантов особо не было.

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

В каких-то простых страничках с парой-тройкой функций jQuery даже сегодня может быть актуален, особенно если приложить усилия и делать грамотно.

Но что-то чуть более сложное уже требует совершенно иного подхода.
Ответ написан
@ncer
Frontend
На мой взгляд ответ на это вопрос во многом упирается в требования и задачи бизнеса для которого и делается сайт/приложение.

Бизнес полностью завязанный на онлайн (например, Airbnb, Booking, какие-то CRM-системы и любые системы использующие Big Data) требует как минимум:
  • максимальной стабильности проектируемой системы
  • отсюда компонентный подход (как известно в HTML пока нет чистых компонентов, стандарт Web Components еще пишется) и как следствие стройную и понятную архитектуру приложения
  • максимальный контроль за состоянием компонентов
  • максимальную расширяемость компонентов


Все это трудно сделать на jQuery. jQuery просто манипулирует DOM узлами, но он их не контролирует и ничего об их состоянии не знает и не запоминает.

Для бизнеса, у которого сайт - лишь площадка для рекламы и маркетинга своего оффлайн бизнеса, все эти фронтендные ноухау по барабану. Ему главное, чтобы было красиво, быстро и недорого. И здесь jQuery на своем месте.

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

Нет ничего постыдного писать таким способом и зарабатывать свои $5. Кто не согласен, пусть засунет своё мнение в комментарий. Я люблю повторять фразу, что все framework’и служат 2 целям, делать из миллиардного проекта, проект на миллион, и из проекта за $100 — проект на пару миллионов. Пользуетесь тем что эффективнее сэкономит ваше время и деньги.
Ответ написан
SynCap
@SynCap
Делаю интернет с 1998 года
Зона применения jQuery стала несколько уже, не стала меньше.
Забывать про него пока рано.
Да, благодаря тому же jQuery, "подрос" сам JS.
Да, для сложных клиентских приложений придуманы фреймворки, но даже используя их, иногда проще что-то делать с jQuery.
И да, подключить jQuery ради одного селектора сегодня уже нет необходимости, ка не было ее и 15 лет назад, когда jQuery только родился.
Для каждого инструмента - свое применение, профессионала отличает правильный выбор инструмента и грамотное его использование.
Уверен - jQeury еще поживет. Не знаю насколько долго, но в ближайшие 2-3 года ему еще найдется применение.
Ответ написан
DIITHiTech
@DIITHiTech
Fullstack javascript developer
Потому что основная цель JQ была обход серьезной несовместимости разных браузеров и предоставление унифицированного api, теперь это уже не актуально в 99%, а актуальных плюшек в ней не осталось. Единственное оправдание ее использования в наши дни- обильное использование уже написанного кода, который требует ее.
Ну а насчет $.ajax это я читаю исправно каждые пару месяцев как аргумент, хоть коллекционируй, так вот для программиста одна-две "лишних" строчки погоду не делают, за то гибкость, быстрота и функциональность и не тащишь всякий шлак в проект. Кроме того, есть куча микробиблиотек для этого весом до 1кб, хотя в большинстве случаев fetch хватает
Ответ написан
zooks
@zooks
Frontend и Django
"Не нужен" в связи с появлением современных фреймворков, усовершенствованием JS, исчезновением проблемы совместимости со старыми IE (что и было основным назначением jQuery).

Также с jQuery появляются лишние зависимости. К примеру, проект написан на чистом JS, но стоит задача подключить лайтбоксы. Смотрим последнюю версию Fancybox — автор не осилил JS и поэтому приходится подключать лишний мусор.

Но он никуда не денется. Просто останется инструментом для быстрого прототипирования типа Bootstrap.
Ответ написан
@marsdenden
ну кто-то считает, что и российские машины не нужны, однако нашу Ниву теперь китайцы покупают, да еще и в два раза дороже, чем мы.
Все зависит от потребностей.
И один нюанс - лучше грузить не со сторонних ресурсов, а со своего сервера - буквально вчера наткнулся на сайт, который выдал что-то вроде "$ not reference" - то есть тупо не смог подгрузить и все! конечному юзеру облом ))
Ответ написан
Кратко: веб-приложения стали сложнее и изменилась парадигма о том как лучше писать фронт

Более подробно есть в этой статье
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы