RUVDS.com corporate blog
Website development
JavaScript
jQuery
Comments 88
+2
Все зависит от масштаба приложения.
Чем приложение меньше, тем меньше смысла грузить немаленький jQuery, соответственно верно и обратное.

Я помню веб, когда все боролись за минимальный объем передаваемых клиенту данных, т.к. скорость никакая.
Т.е. понимая, что главная страница хабра грузит мне 12 Мб, то меня это немного печалит, т.к. тенденция такова, что некоторые сайты могут лего загрузить 50 и 100.
+4
Думаю, считать кучу картинок и контента хабра в сумме с JS кодом не совсем корректно в эти 12 Мб.
0
Понятное дело. Я в общем и целом веду к тому, что сейчас есть сайты, где полезной информации на пару килобайт, а к тебе прилетает десятки мегабайт трафика.
0

JavaScript-а там больше 2mb. И 500kb JS намного критичнее чем 5mb картинок. Потому что вы можете подключиться к хорошему WiFi, а к хорошему процессору уже никак.


В идеале (наверное кто-то это уже даже сделал) разбить JQuery на функции и импортить только то что реально нужно, как сделали с Lodash.

0
Как-то вы лихо связали объем JavaScript-а с CPU.
Каким образом кол-во кода говорит об аппетитах к CPU?
0

Потому что JS (даже который не выполняется) требует ресурсов CPU для того что бы его распарсить. И если это синхронный скрипт размещенный в хеде, то пока вы его не распарсите, вы ничего не увидите. Эта проблема не очень актуальна для декстопов, а вот для мобильных телефонов не первой свежести встает в полный рост. Подробнее можно почитать тут.
Ну и заодно моя статться тут

0
Я понимаю, что на парсинг тратятся ресурсы CPU, как и на рендер страницы. Это, конечно, больше связано с ограничениями мобильных браузеров, многие из которых уже решены или планируются в ближайшем будущем.
В любом случае, информация интересная, спасибо.
+1
Сейчас веб другой. Проблема с десятками мегабайт картинок на странице решается не сжатием, а lazyload. И это ппц.
+4

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

0
Да, сейчас веб другой. Страничка в браузере может занимать 500 мб памяти
+2
Чем приложение меньше, тем меньше смысла грузить немаленький jQuery

Насколько я понимаю, они со временем выпиливают слой совместимости с совсем уж древними браузерами, и как следствие размер библиотеки уменьшается со временем. Ради интереса посмотрел, текущая версия (3.4.1) занимает 86 kb и это ещё без gzip. По текущим реалиям будет точнее называть его "пренебрежимо маленький jQuery".

+1
текущая версия (3.4.1) занимает 86 kb и это ещё без gzip
В jQuery 4 собираются выкинуть Sizzle и станет еще меньше (по моим оценкам на 17.5Кб).
0
используем jqLite, он вшит по умолчанию в AngularJS и как бы живем, не тужим)
+3

Я не люблю jQuery в основном из-за кода, который она обычно порождает и из-за того, ч то если ты опечатаешься в селекторе, всё просто молча перестаёт работать.


В ванилле ошибки в селекторах будут видны сразу, но в остальном это будут точно такое же императивные спагетти. А когда прикинешь, чего стоит написать красивую и фичастую делегацию событий (кстати, YMNJQ не предлагает для этого ровно ничего), то сразу становится проще взять библиотеку. А если берешь библиотеку, то уж не лучше ли взять ту, которую все знают и которую отлично вылизали за больше чем 10 лет разработки.

+3

Не понял чем опечатка в селекторе отличается в jQ и ваниле — оба варианта вернут что-то у чего можно будет проверять длину
Плюс не считаю что jQ что-то порождает, она как оружие, может защищать а может убивать, вопрос в том, в чьих руках она находится

+1
оба варианта вернут что-то у чего можно будет проверять длину

Если забыть такую проверку, то в ванилле все упадет с эксепшеном. jQuery эти проблемы просто "проглатывает".


вопрос в том, в чьих руках она находится

Да-да, все так говорят. Но почему-то у всех получается спагетти. Потому что нет никакого способа как-то это структурировать и обеспечить повторное использование, кроме jQueryUI-плагинов, а ими никто не пользуется.

+1

querySelector возвращает null и может вызвать эксепшен, но querySelectorAll (это какраз то что используется в jQ) возвращает NodeList и тут эксепшен может и не прийти, да, но он и ваниле не прийдет =) это надо иметь в виду и всё будет ок


Структурирование и повторное использование возможно на основе плагинов


это же библиотека, на ней можно сделать всё, вопрос в том, как далеко ты готов зайти =)


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


Иногда тебе не нужен реакт, а хватит джиквери, но чаще и она не нужна

+2
это же библиотека, на ней можно сделать всё, вопрос в том, как далеко ты готов зайти =)

Ну проблема в том, что когда заходишь достаточно далеко, то у тебя получается свой, маленький и глючный Knockout или Backbone. Тогда надо было сразу брать эти библиотеки:)


Ну и да, под каждую задачу нужно выбирать подходящий инструмент, а не ругать отвертку что она плохо забивает гвозди
Иногда тебе не нужен реакт, а иногда хватит и джиквери, но чаще и она не нужна

Речь как раз о тех случаях, когда условный реакт не нужен (или недоступен).

0
querySelectorAll (это какраз то что используется в jQ) возвращает NodeList и тут эксепшен может и не прийти, да, но он и ваниле не прийдет

С каких это пор эксепшен не прийдет? В любом случае прийдет.
0

Можно пример? Я рассматривал вариант с форичем, строка пропускается, ошибок нет

0
Не пойму о чем Вы, человек выше написал о не правильном селекторе, при чем тут форич?
А вот и пример:
document.querySelectorAll('.');
0
Только что проверил, он проглотил, только вот внутри уже сам JQuery выдал «Syntax error», что тоже как то странно, вот к примеру другой, более подходящий, пример:

document.querySelectorAll('>');
+4
Я не люблю jQuery в основном из-за кода, который она обычно порождает и из-за того, ч то если ты опечатаешься в селекторе, всё просто молча перестаёт работать.

Прям в точку, меня это тоже постоянно раздражает, если есть ошибка, то ее как минимум нужно вывести, можно обработать, и пойти дальше, но не уведомить программиста об этом, это какое то кощунство.
+4
Но самый первый пример на этом сайте демонстрирует вескую причину jQuery использовать. Там строка простого кода на jQuery заменяется на 10 строк обычного JS!


Конкретно вот этот вот аргумент — так себе. В этом примере на 10 строк используется XMLHttpRequest, вместо которого сегодня смело можно использовать fetch.
+6
круто! вместо одной надоевшей библиотечки можно собрать кучу полифиллов
+4
Ну да. Они будут себе лежать, и никому не мешать. А через пару лет их можно будет выкинуть не меняя код. Взамен вы получаете полноценный, чистый js.
+1
С одной стороны да, а с другой полифиллы можно загружать только при необходимости
window.fetch || document.write('<script src="fetch.js"><\/script>');
и со временем эта необходимость будет только падать.
0
звучит разумно, как и комментарий @ vlreshet, я сам большой поборник всяких оптимизаций и чистоты.

Но грязный исполнитель внутри меня пожевал прилипшую сигару и хриплым голосом спросил
— а что там насчет часов? время на эти таски оплатят?
+1
Иногда лучше где-то напрячься, выкроить время из других тасков, и сделать что-то по-человечески, чем идти строго по пути «а это оплатят?» и страдать восемь часов в день.
0
Я не старадю от использования JQuery никоим образом. Основной недостаток ее — из-за универсальности она может тормозить больше нативного кода. Ну и надо понимать где это применять, если это страница, куда будут идти миллионы пользователей в день — это одно, а если это специфическая страница в админке. куда будут заходить раз в неделю — это совсем другое…
Так что вопрос лиш в адекватности инструмента решаемой задаче.
-2
Недостаток Jquery еще и в том, что вместе с ней подключается еще штук 5 всяких funcybox и прочих галерей и попапов, ~80% кода которых не используется и висят якорем. Хотя практически весь используемый функционал плагинов можно уместить в срипт в 20-30kb, вместо 100-200.
0
Качество over 90% полифилов таково, что у многих разработчиков на них стойкая аллергия как на класс. Многие «полифилы» делают не то и не так (ну вот автору лень было читать стандарт, он лучше знает, как должно быть), и при этом тормозят даже там, где их «услуги» не требуются (тут была пару месяцев назад весёлая статья на тему).
Особенно в этом плане отличается babel с его preset-env, который пихает в код непонятно что непонятно зачем.
0
А Vue.js и jQuery в одном проекте — это уже малость перебор.

Почему кстати?
Vue 1.0 вполне отлично уживался с jQ, даже код красивый был.
Про v.2 не знаю, из за виртуального DOMа не возникают проблемы?
0

Если во вью вам нужен jquery да и в целом манипуляции с дом напрямую — вы делаете что-то не так.

+3
Наконец-то кто это сказал! И я, конечно, про последний авторский абзац :)
+3

как бы мы не стремились к перфекционизму, но "реальность полна разочарований". И бизнес требует решений здесь и сейчас, но денег нет, и надо держаться. Без бэкендеров жить нельзя, а фронт… фронт в немалой степени благодаря наличию jQ вполне становится подъёмен, понятен и сопровождаем при постоянной текучке кадров и использовании труда фрилансеров. Так что из наименьших зол — этот уровень абстракции как раз помогает избежать боли и страданий и хоть как-то крутиться. Ни разу не относя это к оправданиям, но если бы не эти спасительные 30кб, то я даже боюсь представить во что бы превратились наши и без того кучи метров говнокода без картинок в лендосах, написанные по сути бэкендерами, не от хорошей жизни, но… быть высокодоходным топом с кучей фронтендеров везёт не всем.

+1
Я бы еще не оставил без внимания тот факт, что если забыть написать какую-то проверку в ванильном js, то все приложение может остановится, в то время как jQuery продолжит работу. jQuery экономит время на тестах и написании этих самых проверок, так как возвращает более предсказуемый результат. jQuery также удобно использовать когда хочешь быстро написать какую-то фичу, а потом уже работать над деталями или написанием под чистый js…
-1
1 мес разработки. 
Dev. — На кой нам тут Vue, хватит и JQ.
6 мес разработки.
Заказчик: — Мы хотим отчеты, графики, панельки и чтоб все выезжало, крутилось и вертелось.
Dev. — Ок, у нас есть Vue, тока надо переписать JQ.
+3
Юзаю JQ с 2010 года по сегодняшний день — проблем вообще не знаю. Никаких других более легких и функциональных альтернатив нет и не будет. И потом… да камон люди :) проекты на фрилансе, которые нужно жарить как пирожки по быстрому с jq просто на ура летят.
+1
Подключаешь VueJS из CDN (точно так же как подключается jquery), и погнал. Код чище, проще, понятнее. Проекты на фрилансе точно так же можно пилить.
+4
Попросят тебя сделать slideToggle элемента… я посмотрю как ты будешь это делать на своем VueJS, вернее нет..., не посмотрю т.к я пропишу просто $(element).slideToggle() и забуду об этой задаче и пойду дальше, а ты и дальше будешь «городить огород».
0
В 2019ом году делать анимации на jQuery и гордиться этим…
«Он и нафиг не нужон нам, Vue этот ваш, сто лет без него жили и еще сто проживем»
0
Ой, да блин, делов то) Вот. Можно сказать, из коробки фича. Ты же не считал что на современном фреймворке ну никак не продумали возможность анимаций появления/исчезновения?
0
Слушай, не позорься, серьезно. Изучи получше, что такое jquery и что он делает. Ты хотя бы элементарно понимаешь разницу между фреймворком и библиотекой? В каких случаях, что нужно применять?

У тебя, что называется — «каша в голове» в перемешку с максимализмом и ты не понимаешь элементарно, где потолок, а где пол. Другими словами ты пытаешься гонять на заточенном под треки спортивном болиде по городу, где удобнее и правильнее ездить на обычном городском авто. Может так тебе станет понятнее (вроде в профиле мотиками увлекаешься должен провести параллель).

Возвращаясь к slideToggle я показывал удобство и продуманность в таким мелочах — одна строчка и не нужно ничего думать — и все. В vue отведена добрая часть страницы на это решение (и то через классы, а если я не хочу использовать классы?), неужели не можешь понять?
+1
Возвращаясь к slideToggle я показывал удобство и продуманность в таким мелочах — одна строчка и не нужно ничего думать — и все.

В самом простом случае — одна строчка. Но стоит хоть немного усложнить задачу и вам придется городить велосипеды.
Например, если вам надо будет анимировать элементы при сортировке списка товаров — то количество кода на jquery будет уже гораздо больше чем на vue.
Фреймворки создаются для того чтобы решать стандартные задачи простыми способами.
Да, на jquery можно быстро и просто «налабать» и залить на прод по фтп. Но как-нибудь откроешь такой проект, слепленный из разрозненных кусков кода на jquery, с кучей заплаток в виде плагинов — и руки захочется оторвать этим горе-разработчикам.
0
«Не позорься» — мощнейшая аргументация.
Аналогии — тоже полная херня. Спортивный болид по городу будет тяжело управляться, не везде проедет, дорого стоит, картошку не перевезёшь. Что из этого относится к Vue? Тяжеловесный? Нет. Требует каких-то особых скиллов? Нет. Где-то «не проедет»? Ну да, на IE6 не запустишь. Только для сложных решений? Да нет, хоть формочку на два инпута им обрабатывай. Итого — снова «мощнейший» аргумент.

Возвращаясь к slideToggle я показывал удобство и продуманность в таким мелочах — одна строчка и не нужно ничего думать
Вот это вот «и не нужно ничего думать» — и проблема в jQuery. Не нужно думать, просто бабахни ещё один $ и какую-то функцию. Надо вот тут анимацию? Ну сюда ещё строчечку, ай как ловко всё продумали. А вот там тоже анимация? Ну сейчас туда ещё привяжемся. В итоге — тормозящая лапша, с кучей дублирования кода. Зато ничего думать не надо, и без классов, да.

Остальное отлично сказал YemSalat чуть выше, не вижу смысла повторяться.
-4
image

Конечно аналогия херня, ты даже читать не умеешь :), как же ты вообще работаешь!!! Бедные твои клиенты.
0
Бедные твои клиенты.
То-то дело твои клиенты, которым ты «жаришь как пирожки по быстрому» проекты на jQuery. Во они рады будут, когда следующий разработчик скажет что там легче все переписать, чем добавить несколько новых фич.
+2
Автор исходит из ложной посылки, что jQuery — это абсолютное зло. На самом деле Коран не запрещает использовать эту либо, или любую другую в качестве слоя абстракции над методами управления DOM. Другое дело, что jQuery будет очень неэффективен, если попытаться написать на нем сложную логику. А для маркетингового лендоса самое то.
+3
jquery уже достаточно взрослая либа являющаяся уже по сути языком чуть более высокого уровня чем javascript. Смысла не использовать примерно ноль, все равно как отказаться скажем от python/mysql и вернуться к си/файлБД ради «экономии места на сервере».
Размер пренебрежительно мал на фоне нынешних мегабайтных сайтов, так еще и нередко она уже предзагружена по cdn у юзера, а если нет — загружается один раз.
По уму лучше включили бы ее уже в браузеры, пусть даже в разных версиях, и вопрос был бы снят совсем.
0
По уму лучше включили бы ее уже в браузеры, пусть даже в разных версиях, и вопрос был бы снят совсем.

Сильно сказано
+2
Jquery — это typescript прошлого поколения. Очень удобная и полезная штука.
0
jquery не только не дает профита лично мне, например при манипуляции атрибутами в svg картинках(в IE11и иже с ним), но и создает проблемы известные как blackhole SVG instance trees, другой момент что jquery снижает порог входа, как всепростительность у PHP, и порождает кучу плохих решений, но наверное эта проблема актуальна лишь на мелких сайтах, поэтому на всех собеседованиях прошу написать ajax запрос без jquery, хотя бы псевдокод
+1
А насколько часто вы манипулируете атрибутами в svg? Просто интересно, у мня вот пока такой необходимости не возникало.
0

У меня недавно возникла такая проблема, когда я делал мини-игру, а в движке только jQuery. Но это первый раз за 12 лет фронтендерства, обычно я манипулирую SVG из Vue или чего-нибудь такого:)

0
Например в схеме вагонов ЖД поездов, когда пользователь выбирает себе посадочное место, насколько мне известно, небезызвестный монополист в данном деле вынужден пользоваться старыми версиями jquery, поскольку проблема остается вплоть до версии 3.1.1. Странно что кто то оценил реальную проблему в jquery дизлайком — отрицание проблемы не решение проблемы
+3
Топил, и буду топить за переход на Vue взамен jQuery. У Vue есть киллер-фича — он может работать без вебпаков, сборщиков, и т.д. Подключил его точно так же как jQuery — и он готов к работе. Плюсы — НАМНОГО понятнее код. Проблема jQuery в том, что HTML и JS отвязаны друг от друга, всё шевелится только на id и классах. В итоге мы видим отдельно HTML, отдельно JS, и надо как-то в голове держать что тут, чёрт побери, происходит, почему вон тот блок прячется, и откуда вот там появилась картинка. Vue же позволяет прямо видеть логику работы. У нас не где-то там по какому-то условию срабатывает .show(), а чётко видно: «v-if='condition'». Можно не заглядывая в js понять суть. Видишь кнопку — видишь на ней v-on:click, и не надо искать по id где там какой обработчик на неё навесили. Плюсы, в общем, можно перечислять очень долго.

Единственный кейс когда можно оправдать jQuery — это анимации. Вот тут да. Хотя, опять таки, решается сторонними библиотеками вроде Anime.JS.
+1
Кроме терминов «фреймворк» «библиотека» — в чём разница? И первое и другое подключается одним файлом. И первое и второе нужно изучить для использования. И первое и второе задаёт «архитектуру» страницы (jQuery — заставляет обмазывать всё айдишниками и классами. Vue — заставляет использовать атрибуты). В чём же разница?
0
Обычно разница в том, кто рулит кодом. Библиотека это набор методов, который писал не ты, но ты вызываешь из своего кода, чтобы добиться какого то функционала.
Фреймворк это штука, которая садится на страницу и начинает чо-та с ней делать, а ты пишешь только методы типа «если произошло это — то вызвать мой метод».
Библиотеку как правило проще заменить или переписать.
0
Да я понимаю формальную разницу между фреймворком и библиотекой. Но на практике лапшу на jQuery будет не легче переписать на %another_lib_name%, чем код на Vue на тот же реакт. То есть суть разработки не меняется — и там и там мы жёстко привязываемся к инструменту. Это на бекенде у нас интерфейсы, фабрики, и вот это вот всё. Там действительно библиотека может быть легко заменяема. На фронте же практически всегда vendor-lock. Поэтому я и уверен что с jQuery можно и нужно переходить на Vue, и то что одно это библиотека, а второе фреймворк — особой роли не играет.
+1

В чем разница между этими двумя строками?


new MyComponent().$mount('.selector') // Vue

$('.selector').myComponent() // jQuery

Почему одну из них принято считать фреймворком, а вторую – библиотекой?

+1
Чтобы нормально писать приложение на Vue увы придется использовать webpack и прочее. Иначе не возможно внятно структурировать код и использовать .vue файлы
0
Если писать полноценное SPA — то да, придётся. В иных случаях однофайлового подключения хватает. Прямо сейчас у меня проект на Laravel плюс такой способ. Изначально там был jquery, теперь вот перекочевал на ву. Компоненты, при желании, тоже можно использовать, хотя и не так удобно как однофайловые, да.

P.S. чтобы структурировать код в «урезанном» варианте Vue — можно использовать несколько корневых точек на странице. Например, на блок комментариев — один экземпляр ву, а на меню сверху — второй. Тогда не возникает проблемы с огромной data и кучей методов. На производительность практически не влияет.
+1

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

0
ИМХО, реальная проблема jQuery в том, что порог входа настолько низкий, что люди могут писать вполне рабочие приложения толком не освоив JavaScript.
Сам юзаю jQuery там, где нужно быстро что-то сделать, буквально в пару часов/дней, сдать и забыть.
На основном проекте перевожу с jQuery на Vue.js и чистый JavaScript.
0

Смотря какие возможности jQuery использовать. За ajax и Differed я в наше время руки бы отрывал :)

0
А сборка, в которой вместо SizzleJS используется querySelector, занимает всего 17 Кб.

Есть у кого гайд по такой сборке?
0
Например, конструкция el.insertAdjacentElement('afterend', other), безусловно, работает. Но куда приятнее выглядит $(el).after(other)

Есть же Node.insertBefore. Не надо утрировать и пугать неосведомленных читателей.


Хотя мне никогда особо не нравился внешний вид функции $(), она несравненно лучше, чем то, что дают нам стандартные API для работы с DOM

если основное достоинство библиотеки – это лаконичное API, то можно просто добавить себе шорткатов:


var $ = document.querySelector.bind(document)
var on = function(element, event, handler) {element.addEventListener(event, handler)}

Этого с запасом хватит для базовых потребностей.


Если хочется ajax и анимаций, то есть 3кб библиотека https://blissfuljs.com/, что намного меньше заявленных 17 у минимального jQuery.

0

А вообще удивительно как jQuery до сих пор держит реноме простой и компактной библиотеки, хотя там внутри накручено много всего странного:



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

0
Например, конструкция el.insertAdjacentElement('afterend', other), безусловно, работает. Но куда приятнее выглядит $(el).after(other)

Есть же Node.insertBefore. Не надо утрировать и пугать неосведомленных читателей.

Вас не смущает, что Before и After это разные положения? А Node.insertAfter не существует.
Вот такие не консистенции и отваживают от написание на ванили.
то можно просто добавить себе шорткатов

И изучать их от проекта к проекту?
0
Вас не смущает, что Before и After это разные положения?

Упс, пропустил что там after. По своему опыту могу сказать, что и необходимости в нем особой не было. Для создания сортируемых списков insertBefore справляется прекрасно, а для всего остального – лучше использовать appendChild, а не вставлять что-то в середину.


И изучать их от проекта к проекту?

Что вы имеете в виду? Что изучать, с ними вроде и так все понятно.

0
Что вы имеете в виду? Что изучать, с ними вроде и так все понятно.

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

Если у вас меньше сотни строк джаваскрипта, то это нестрашно, все и так на виду.


А если больше, то есть намного лучшие решения для организации кода, чем jQuery

0
Что вы имеете в виду? Что изучать, с ними вроде и так все понятно.

Одни используют обёртки, другие не используют, третьи приходят на проект и пишут свои… В коде кавардак

-1

Это было предложение для маленьких скриптов.


Если там много манипуляций с dom, то, наверное, лучше переписать на декларативный фреймворк (Vue какой-нибудь), а не приукрашивать спагетти-код короткими методами из jQuery

Only those users with full accounts are able to leave comments. , please.