Многие, когда речь заходит о jQuery, говорят так: «Просто пользуйтесь обычным JavaScript. Библиотека jQuery вам не нужна». Что тут сказать? Я не нуждаюсь во многих вещах, но, несмотря на это, хорошо, когда они есть. Так и jQuery. Я в этой библиотеке не нуждаюсь, но её, определённо, приятно иметь под рукой.Сайты наподобие You might not need jQuery (YMNJQ) продвигают идею, в соответствии с которой от jQuery очень легко избавиться. Но самый первый пример на этом сайте демонстрирует вескую причину jQuery использовать. Там строка простого кода на jQuery заменяется на 10 строк обычного JS!
Большинство API JavaScript, в особенности те из них, которые нацелены на работу с DOM, оскорбляют мои эстетические чувства. Это — если мягко выразить моё к ним отношение. Если же говорить прямо, то я думаю, что эти API — полный кошмар. Например, конструкция
el.insertAdjacentElement('afterend', other), безусловно, работает. Но куда приятнее выглядит $(el).after(other). Хотя мне никогда особо не нравился внешний вид функции $(), она несравненно лучше, чем то, что дают нам стандартные API для работы с DOM. Я знаю о том, что вместо $() можно использовать нечто вроде jQuery(sel) или window.jq = jQuery. Но программирую я не в безвоздушном пространстве. Поэтому предпочитаю пользоваться стандартными приёмами. Не знаю, хорошо это или плохо, но стандартом при использовании jQuery стала конструкция $().Попытайтесь быстро вспомнить о том, как получить элемент-сосед другого элемента средствами DOM. Что для этого использовать —
nextSibling или nextElementSibling? А в чём разница? А какие браузеры поддерживают тот или иной метод? Пока вы пытаетесь это вспомнить и заглядываете на MDN, проверяя себя, я, пользуясь jQuery, просто пишу next() или prev().Выполнение многих обычных операций реализовано в JavaScript-API неудобно. Я мог бы привести тут целый список таких операций, но за меня это отлично сделано на странице YMNJQ.
Для решения различных простых задач средствами JS нужны вспомогательные функции. И на сайте YMNJQ, опять же, можно найти немало примеров. Использование jQuery представляет собой стандартный способ включения в код проектов таких вспомогательных функций. При этом программисту не нужно каждый раз, когда ему что-то подобное понадобится, выхватывать куски кода из первых подвернувшихся под руку ответов на Stack Overflow.
Хотя в наши дни проблемы совместимости браузеров потеряли былую остроту, они всё ещё актуальны. Особенно — для тех, кто не относится к лагерю разработчиков, считающих, что если что-то работает в 85% браузеров, то им это подходит. Кстати, вот материал о том, почему Hello CSS не использует CSS-переменные.
Следует ли всегда пользоваться jQuery? Нет, конечно нет. Любая дополнительная зависимость — это рост сложности проекта и рост объёма его кода. Но jQuery — библиотека не такая уж и большая. Стандартная сборка, минифицированная и сжатая, занимает 30 Кб. Кастомная сборка без ajax и без редко используемых возможностей — это 23 Кб. А сборка, в которой вместо
SizzleJS используется querySelector, занимает всего 17 Кб. Меня, для решения множества задач, вполне устраивает и стандартная сборка размером 30 Кб, и оптимизированная, размером 17 Кб.Тут можно посмотреть на то, сколько усилий приложено к тому, чтобы убрать jQuery из Bootstrap и перейти на обычный JS.
Разработчики написали собственные вспомогательные функции. Им пришлось отказаться от поддержки IE, так как такую поддержку оказалось очень сложно реализовать. Они сделали несовместимым API («мы всё сломали») и потратили на всё это полтора года. Не могу сказать, что то, что получилось, намного лучше того, что было.
Я понимаю причины перевода Bootstrap на обычный JS. Например, разработчики хотят использовать Bootstrap с Vue.js, или ещё с чем-то подобным. А Vue.js и jQuery в одном проекте — это уже малость перебор. Я — большой сторонник сокращения объёмов ненужного кода в вебе (вот и вот — пара материалов об этом). Но тут я предлагаю смотреть на ситуацию с прагматичной и реалистичной точки зрения. Неужели включение в Bootstrap 17 Кб кода jQuery — это так плохо? Когда я говорю, что для просмотра сайтов вроде Medium или New York Times нужно загрузить больше мегабайта JavaScript-кода, меня, защищая сложившуюся ситуацию, спрашивают о том, не сижу ли я на какой-нибудь 56-килобитной модемной линии. Мегабайт JS — это нормально. Неужто 17 Кб jQuery — это неподъёмная ноша?
Существуют и веские причины jQuery не использовать. Например, jQuery не нужна в том случае, если вы пишете код, которым вы хотите поделиться с другими, или если вы создаёте какую-нибудь маленькую функцию. Но зачем выворачиваться наизнанку только ради того, чтобы не пользоваться jQuery? Зачем все эти усилия, если можно просто написать
$()? Я не думаю, что jQuery стоит использовать везде и всегда, но и не считаю правильным фанатичный отказ от jQuery.Хочу отметить, что я не женат на jQuery. Я с удовольствием буду пользоваться чем-то вроде «jQuery light» — некой библиотекой, которая перекрывает недостатки стандартных API, давая программисту что-то более приятное. Сайт YMNJQ рекомендует, кроме прочих, библиотеки bonzo и $dom, предназначенные для решения разных задач. Но многие из них, как кажется, давно не поддерживаются. Кроме того, многие уже знают jQuery. Зачем менять jQuery на что-то другое без веских причин?
Многие читатели могут задаться вопросом о том, что я, в русле этого материала, могу сказать по поводу Vue.js, React и других современных фреймворков. Но цель этой статьи — сопоставить обычный JavaScript и jQuery, а не предлагать сообществу «Грандиозную общую теорию фронтенд-разработки».
Учитывая вышесказанное, я полагаю, что могу обнаружить совсем немного причин использовать обычный JS там, где можно воспользоваться jQuery. Это так преимущественно из-за того, что я хочу создавать быстрые страницы и использовать при этом простейшие рабочие конструкции. При этом я стремлюсь к тому, чтобы мои страницы смогло бы просмотреть как можно большее количество пользователей Сети. Опыт подсказывает мне, что кратчайшим путём к достижению этой цели служат шаблоны, сгенерированные на сервере, которые слегка, в стиле «прогрессивного улучшения», приправлены JavaScript. Если сравнить такие проекты с чем-то, в чём используется нечто более сложное, то оказывается, что их часто бывает проще разрабатывать. Такие проекты обычно быстрее, в них обычно меньше ошибок, а в ходе работы над ними вентилятор ноутбука не издаёт шум, способный разбудить весь дом.
Означает ли это, что современные веб-фреймворки и мощные библиотеки — это всегда плохо? Нет, не означает. Очень немногое достойно того, чтобы «всегда» называться плохим или хорошим. Но использовать фреймворк — значит идти на некие компромиссы (это, конечно, справедливо и для jQuery).
В целом, веб мне видится средой для просмотра документов, а не чем-то вроде операционной системы. И «документный подход» хорош не только для обычных сайтов, но и для многих «веб-приложений» (что бы так ни называли).
Уважаемые читатели! Пользуетесь ли вы jQuery?
Комментарии (82)
k12th
10.06.2019 14:02Я не люблю jQuery в основном из-за кода, который она обычно порождает и из-за того, ч то если ты опечатаешься в селекторе, всё просто молча перестаёт работать.
В ванилле ошибки в селекторах будут видны сразу, но в остальном это будут точно такое же императивные спагетти. А когда прикинешь, чего стоит написать красивую и фичастую делегацию событий (кстати, YMNJQ не предлагает для этого ровно ничего), то сразу становится проще взять библиотеку. А если берешь библиотеку, то уж не лучше ли взять ту, которую все знают и которую отлично вылизали за больше чем 10 лет разработки.
toptalo
10.06.2019 15:42Не понял чем опечатка в селекторе отличается в jQ и ваниле — оба варианта вернут что-то у чего можно будет проверять длину
Плюс не считаю что jQ что-то порождает, она как оружие, может защищать а может убивать, вопрос в том, в чьих руках она находитсяk12th
10.06.2019 15:56оба варианта вернут что-то у чего можно будет проверять длину
Если забыть такую проверку, то в ванилле все упадет с эксепшеном. jQuery эти проблемы просто "проглатывает".
вопрос в том, в чьих руках она находится
Да-да, все так говорят. Но почему-то у всех получается спагетти. Потому что нет никакого способа как-то это структурировать и обеспечить повторное использование, кроме jQueryUI-плагинов, а ими никто не пользуется.
toptalo
10.06.2019 16:31-1querySelector возвращает null и может вызвать эксепшен, но querySelectorAll (это какраз то что используется в jQ) возвращает NodeList и тут эксепшен может и не прийти, да, но он и ваниле не прийдет =) это надо иметь в виду и всё будет ок
Структурирование и повторное использование возможно на основе плагинов
это же библиотека, на ней можно сделать всё, вопрос в том, как далеко ты готов зайти =)
Ну и да, под каждую задачу нужно выбирать подходящий инструмент, а не ругать отвертку что она плохо забивает гвозди
Иногда тебе не нужен реакт, а хватит джиквери, но чаще и она не нужна
k12th
10.06.2019 16:45это же библиотека, на ней можно сделать всё, вопрос в том, как далеко ты готов зайти =)
Ну проблема в том, что когда заходишь достаточно далеко, то у тебя получается свой, маленький и глючный Knockout или Backbone. Тогда надо было сразу брать эти библиотеки:)
Ну и да, под каждую задачу нужно выбирать подходящий инструмент, а не ругать отвертку что она плохо забивает гвозди
Иногда тебе не нужен реакт, а иногда хватит и джиквери, но чаще и она не нужнаРечь как раз о тех случаях, когда условный реакт не нужен (или недоступен).
WanSpi
10.06.2019 17:31querySelectorAll (это какраз то что используется в jQ) возвращает NodeList и тут эксепшен может и не прийти, да, но он и ваниле не прийдет
С каких это пор эксепшен не прийдет? В любом случае прийдет.toptalo
10.06.2019 17:47Можно пример? Я рассматривал вариант с форичем, строка пропускается, ошибок нет
WanSpi
10.06.2019 17:38+1Я не люблю jQuery в основном из-за кода, который она обычно порождает и из-за того, ч то если ты опечатаешься в селекторе, всё просто молча перестаёт работать.
Прям в точку, меня это тоже постоянно раздражает, если есть ошибка, то ее как минимум нужно вывести, можно обработать, и пойти дальше, но не уведомить программиста об этом, это какое то кощунство.
Perlovich
10.06.2019 14:35Но самый первый пример на этом сайте демонстрирует вескую причину jQuery использовать. Там строка простого кода на jQuery заменяется на 10 строк обычного JS!
Конкретно вот этот вот аргумент — так себе. В этом примере на 10 строк используется XMLHttpRequest, вместо которого сегодня смело можно использовать fetch.
Finesse
11.06.2019 03:44Не смело, зависит от проекта. Только 90% посетителей поддерживают его, а в России только 80%: https://caniuse.com/#feat=fetch
Shugich
11.06.2019 06:50Решается небольшим полифилом: https://github.com/github/fetch
Zoolander
11.06.2019 11:06+1круто! вместо одной надоевшей библиотечки можно собрать кучу полифиллов
vlreshet
11.06.2019 11:21Ну да. Они будут себе лежать, и никому не мешать. А через пару лет их можно будет выкинуть не меняя код. Взамен вы получаете полноценный, чистый js.
mobi
11.06.2019 11:22+1С одной стороны да, а с другой полифиллы можно загружать только при необходимости
и со временем эта необходимость будет только падать.window.fetch || document.write('<script src="fetch.js"><\/script>');Zoolander
11.06.2019 11:37звучит разумно, как и комментарий @ vlreshet, я сам большой поборник всяких оптимизаций и чистоты.
Но грязный исполнитель внутри меня пожевал прилипшую сигару и хриплым голосом спросил
— а что там насчет часов? время на эти таски оплатят?vlreshet
11.06.2019 12:57Иногда лучше где-то напрячься, выкроить время из других тасков, и сделать что-то по-человечески, чем идти строго по пути «а это оплатят?» и страдать восемь часов в день.
4tlen
11.06.2019 13:01Недостаток Jquery еще и в том, что вместе с ней подключается еще штук 5 всяких funcybox и прочих галерей и попапов, ~80% кода которых не используется и висят якорем. Хотя практически весь используемый функционал плагинов можно уместить в срипт в 20-30kb, вместо 100-200.
vanxant
11.06.2019 12:58Качество over 90% полифилов таково, что у многих разработчиков на них стойкая аллергия как на класс. Многие «полифилы» делают не то и не так (ну вот автору лень было читать стандарт, он лучше знает, как должно быть), и при этом тормозят даже там, где их «услуги» не требуются (тут была пару месяцев назад весёлая статья на тему).
Особенно в этом плане отличается babel с его preset-env, который пихает в код непонятно что непонятно зачем.
Rastishka
10.06.2019 15:36А Vue.js и jQuery в одном проекте — это уже малость перебор.
Почему кстати?
Vue 1.0 вполне отлично уживался с jQ, даже код красивый был.
Про v.2 не знаю, из за виртуального DOMа не возникают проблемы?xakepmega
12.06.2019 07:19Если во вью вам нужен jquery да и в целом манипуляции с дом напрямую — вы делаете что-то не так.
Marwin
10.06.2019 22:58+2как бы мы не стремились к перфекционизму, но "реальность полна разочарований". И бизнес требует решений здесь и сейчас, но денег нет, и надо держаться. Без бэкендеров жить нельзя, а фронт… фронт в немалой степени благодаря наличию jQ вполне становится подъёмен, понятен и сопровождаем при постоянной текучке кадров и использовании труда фрилансеров. Так что из наименьших зол — этот уровень абстракции как раз помогает избежать боли и страданий и хоть как-то крутиться. Ни разу не относя это к оправданиям, но если бы не эти спасительные 30кб, то я даже боюсь представить во что бы превратились наши и без того кучи метров говнокода без картинок в лендосах, написанные по сути бэкендерами, не от хорошей жизни, но… быть высокодоходным топом с кучей фронтендеров везёт не всем.
Get-Web
10.06.2019 23:04+1Я бы еще не оставил без внимания тот факт, что если забыть написать какую-то проверку в ванильном js, то все приложение может остановится, в то время как jQuery продолжит работу. jQuery экономит время на тестах и написании этих самых проверок, так как возвращает более предсказуемый результат. jQuery также удобно использовать когда хочешь быстро написать какую-то фичу, а потом уже работать над деталями или написанием под чистый js…
Wladgaint
10.06.2019 23:381 мес разработки.
Dev. — На кой нам тут Vue, хватит и JQ.
6 мес разработки.
Заказчик: — Мы хотим отчеты, графики, панельки и чтоб все выезжало, крутилось и вертелось.
Dev. — Ок, у нас есть Vue, тока надо переписать JQ.
al6dy
10.06.2019 23:38Юзаю JQ с 2010 года по сегодняшний день — проблем вообще не знаю. Никаких других более легких и функциональных альтернатив нет и не будет. И потом… да камон люди :) проекты на фрилансе, которые нужно жарить как пирожки по быстрому с jq просто на ура летят.
vlreshet
11.06.2019 11:23Подключаешь VueJS из CDN (точно так же как подключается jquery), и погнал. Код чище, проще, понятнее. Проекты на фрилансе точно так же можно пилить.
al6dy
12.06.2019 00:55Попросят тебя сделать slideToggle элемента… я посмотрю как ты будешь это делать на своем VueJS, вернее нет..., не посмотрю т.к я пропишу просто $(element).slideToggle() и забуду об этой задаче и пойду дальше, а ты и дальше будешь «городить огород».
YemSalat
12.06.2019 07:16В 2019ом году делать анимации на jQuery и гордиться этим…
«Он и нафиг не нужон нам, Vue этот ваш, сто лет без него жили и еще сто проживем»
vlreshet
12.06.2019 11:09Ой, да блин, делов то) Вот. Можно сказать, из коробки фича. Ты же не считал что на современном фреймворке ну никак не продумали возможность анимаций появления/исчезновения?
al6dy
13.06.2019 00:59+1Слушай, не позорься, серьезно. Изучи получше, что такое jquery и что он делает. Ты хотя бы элементарно понимаешь разницу между фреймворком и библиотекой? В каких случаях, что нужно применять?
У тебя, что называется — «каша в голове» в перемешку с максимализмом и ты не понимаешь элементарно, где потолок, а где пол. Другими словами ты пытаешься гонять на заточенном под треки спортивном болиде по городу, где удобнее и правильнее ездить на обычном городском авто. Может так тебе станет понятнее (вроде в профиле мотиками увлекаешься должен провести параллель).
Возвращаясь к slideToggle я показывал удобство и продуманность в таким мелочах — одна строчка и не нужно ничего думать — и все. В vue отведена добрая часть страницы на это решение (и то через классы, а если я не хочу использовать классы?), неужели не можешь понять?YemSalat
13.06.2019 08:29Возвращаясь к slideToggle я показывал удобство и продуманность в таким мелочах — одна строчка и не нужно ничего думать — и все.
В самом простом случае — одна строчка. Но стоит хоть немного усложнить задачу и вам придется городить велосипеды.
Например, если вам надо будет анимировать элементы при сортировке списка товаров — то количество кода на jquery будет уже гораздо больше чем на vue.
Фреймворки создаются для того чтобы решать стандартные задачи простыми способами.
Да, на jquery можно быстро и просто «налабать» и залить на прод по фтп. Но как-нибудь откроешь такой проект, слепленный из разрозненных кусков кода на jquery, с кучей заплаток в виде плагинов — и руки захочется оторвать этим горе-разработчикам.
vlreshet
13.06.2019 12:57«Не позорься» — мощнейшая аргументация.
Аналогии — тоже полная херня. Спортивный болид по городу будет тяжело управляться, не везде проедет, дорого стоит, картошку не перевезёшь. Что из этого относится к Vue? Тяжеловесный? Нет. Требует каких-то особых скиллов? Нет. Где-то «не проедет»? Ну да, на IE6 не запустишь. Только для сложных решений? Да нет, хоть формочку на два инпута им обрабатывай. Итого — снова «мощнейший» аргумент.
Возвращаясь к slideToggle я показывал удобство и продуманность в таким мелочах — одна строчка и не нужно ничего думать
Вот это вот «и не нужно ничего думать» — и проблема в jQuery. Не нужно думать, просто бабахни ещё один $ и какую-то функцию. Надо вот тут анимацию? Ну сюда ещё строчечку, ай как ловко всё продумали. А вот там тоже анимация? Ну сейчас туда ещё привяжемся. В итоге — тормозящая лапша, с кучей дублирования кода. Зато ничего думать не надо, и без классов, да.
Остальное отлично сказал YemSalat чуть выше, не вижу смысла повторяться.al6dy
13.06.2019 16:15-1
Конечно аналогия херня, ты даже читать не умеешь :), как же ты вообще работаешь!!! Бедные твои клиенты.
stardust_kid
11.06.2019 00:34+1Автор исходит из ложной посылки, что jQuery — это абсолютное зло. На самом деле Коран не запрещает использовать эту либо, или любую другую в качестве слоя абстракции над методами управления DOM. Другое дело, что jQuery будет очень неэффективен, если попытаться написать на нем сложную логику. А для маркетингового лендоса самое то.
edogs
11.06.2019 03:12jquery уже достаточно взрослая либа являющаяся уже по сути языком чуть более высокого уровня чем javascript. Смысла не использовать примерно ноль, все равно как отказаться скажем от python/mysql и вернуться к си/файлБД ради «экономии места на сервере».
Размер пренебрежительно мал на фоне нынешних мегабайтных сайтов, так еще и нередко она уже предзагружена по cdn у юзера, а если нет — загружается один раз.
По уму лучше включили бы ее уже в браузеры, пусть даже в разных версиях, и вопрос был бы снят совсем.
androidovshchik
11.06.2019 05:29По уму лучше включили бы ее уже в браузеры, пусть даже в разных версиях, и вопрос был бы снят совсем.
Сильно сказано
RedComrade
11.06.2019 08:04jquery не только не дает профита лично мне, например при манипуляции атрибутами в svg картинках(в IE11и иже с ним), но и создает проблемы известные как blackhole SVG instance trees, другой момент что jquery снижает порог входа, как всепростительность у PHP, и порождает кучу плохих решений, но наверное эта проблема актуальна лишь на мелких сайтах, поэтому на всех собеседованиях прошу написать ajax запрос без jquery, хотя бы псевдокод
ilya_1986
11.06.2019 11:44+1А насколько часто вы манипулируете атрибутами в svg? Просто интересно, у мня вот пока такой необходимости не возникало.
k12th
11.06.2019 12:00У меня недавно возникла такая проблема, когда я делал мини-игру, а в движке только jQuery. Но это первый раз за 12 лет фронтендерства, обычно я манипулирую SVG из Vue или чего-нибудь такого:)
vlreshet
11.06.2019 11:29+1Топил, и буду топить за переход на Vue взамен jQuery. У Vue есть киллер-фича — он может работать без вебпаков, сборщиков, и т.д. Подключил его точно так же как jQuery — и он готов к работе. Плюсы — НАМНОГО понятнее код. Проблема jQuery в том, что HTML и JS отвязаны друг от друга, всё шевелится только на id и классах. В итоге мы видим отдельно HTML, отдельно JS, и надо как-то в голове держать что тут, чёрт побери, происходит, почему вон тот блок прячется, и откуда вот там появилась картинка. Vue же позволяет прямо видеть логику работы. У нас не где-то там по какому-то условию срабатывает .show(), а чётко видно: «v-if='condition'». Можно не заглядывая в js понять суть. Видишь кнопку — видишь на ней v-on:click, и не надо искать по id где там какой обработчик на неё навесили. Плюсы, в общем, можно перечислять очень долго.
Единственный кейс когда можно оправдать jQuery — это анимации. Вот тут да. Хотя, опять таки, решается сторонними библиотеками вроде Anime.JS.
namikiri
11.06.2019 12:45Vue — фреймворк, jQuery — библиотека. В этом вся разница.
vlreshet
11.06.2019 12:55Кроме терминов «фреймворк» «библиотека» — в чём разница? И первое и другое подключается одним файлом. И первое и второе нужно изучить для использования. И первое и второе задаёт «архитектуру» страницы (jQuery — заставляет обмазывать всё айдишниками и классами. Vue — заставляет использовать атрибуты). В чём же разница?
norguhtar
11.06.2019 21:20Чтобы нормально писать приложение на Vue увы придется использовать webpack и прочее. Иначе не возможно внятно структурировать код и использовать .vue файлы
vlreshet
12.06.2019 11:11Если писать полноценное SPA — то да, придётся. В иных случаях однофайлового подключения хватает. Прямо сейчас у меня проект на Laravel плюс такой способ. Изначально там был jquery, теперь вот перекочевал на ву. Компоненты, при желании, тоже можно использовать, хотя и не так удобно как однофайловые, да.
P.S. чтобы структурировать код в «урезанном» варианте Vue — можно использовать несколько корневых точек на странице. Например, на блок комментариев — один экземпляр ву, а на меню сверху — второй. Тогда не возникает проблемы с огромной data и кучей методов. На производительность практически не влияет.
smarthomeblog
11.06.2019 12:24У авторов была прекрасная статья — Переход с jQuery на Vue.js. ИМХО путь, описанный в ней, более перспективный в плане замены jQuery
PaulZi
11.06.2019 15:12Плюс в jQuery что он прост, чтобы заменить его чистым JS, надо искать кучу полифиллов, и все они подключаются по разному и имеет разное качество исполнения.
namelesss
11.06.2019 15:52ИМХО, реальная проблема jQuery в том, что порог входа настолько низкий, что люди могут писать вполне рабочие приложения толком не освоив JavaScript.
Сам юзаю jQuery там, где нужно быстро что-то сделать, буквально в пару часов/дней, сдать и забыть.
На основном проекте перевожу с jQuery на Vue.js и чистый JavaScript.
VolCh
11.06.2019 16:23-1Смотря какие возможности jQuery использовать. За ajax и Differed я в наше время руки бы отрывал :)
sumanai
11.06.2019 21:59А сборка, в которой вместо SizzleJS используется querySelector, занимает всего 17 Кб.
Есть у кого гайд по такой сборке?
justboris
11.06.2019 23:20Например, конструкция 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.
justboris
11.06.2019 23:54А вообще удивительно как jQuery до сих пор держит реноме простой и компактной библиотеки, хотя там внутри накручено много всего странного:
- Кастомные обертки над событиями
- Даже нативный движок селекторов все равно содержит много строк
- Монструозная регулярка, для авто-расстановки суффикса
pxдля нас, где надо - Даже взятие атрибута там выливается в много кода
Это какой-то синдром утенка, когда-то давно с нее начинали и теперь не можем отвязаться, хотя оверхеда там больше чем пользы
PaulZi
12.06.2019 10:54Обёртка над кастомными событиями используются в jQuery, потому что даже в 18 Edge есть весьма нелепый баг.
sumanai
12.06.2019 01:26Например, конструкция el.insertAdjacentElement('afterend', other), безусловно, работает. Но куда приятнее выглядит $(el).after(other)
Есть же Node.insertBefore. Не надо утрировать и пугать неосведомленных читателей.
Вас не смущает, что Before и After это разные положения? А Node.insertAfter не существует.
Вот такие не консистенции и отваживают от написание на ванили.
то можно просто добавить себе шорткатов
И изучать их от проекта к проекту?justboris
12.06.2019 09:11Вас не смущает, что Before и After это разные положения?
Упс, пропустил что там after. По своему опыту могу сказать, что и необходимости в нем особой не было. Для создания сортируемых списков insertBefore справляется прекрасно, а для всего остального – лучше использовать appendChild, а не вставлять что-то в середину.
И изучать их от проекта к проекту?
Что вы имеете в виду? Что изучать, с ними вроде и так все понятно.
sumanai
12.06.2019 15:44Что вы имеете в виду? Что изучать, с ними вроде и так все понятно.
Эти кастомные обёртки могут разниться от проекта к проекту. И чтобы не писать свои такие же, нужно прочитать код и запомнить используемые. Но так никто не делает, потому что используют инструменты фреймворка или jQuery.justboris
12.06.2019 18:49Если у вас меньше сотни строк джаваскрипта, то это нестрашно, все и так на виду.
А если больше, то есть намного лучшие решения для организации кода, чем jQuery
VolCh
12.06.2019 16:28Что вы имеете в виду? Что изучать, с ними вроде и так все понятно.
Одни используют обёртки, другие не используют, третьи приходят на проект и пишут свои… В коде кавардак
justboris
12.06.2019 18:55Это было предложение для маленьких скриптов.
Если там много манипуляций с dom, то, наверное, лучше переписать на декларативный фреймворк (Vue какой-нибудь), а не приукрашивать спагетти-код короткими методами из jQuery
UrbanRider
Все зависит от масштаба приложения.
Чем приложение меньше, тем меньше смысла грузить немаленький jQuery, соответственно верно и обратное.
Я помню веб, когда все боролись за минимальный объем передаваемых клиенту данных, т.к. скорость никакая.
Т.е. понимая, что главная страница хабра грузит мне 12 Мб, то меня это немного печалит, т.к. тенденция такова, что некоторые сайты могут лего загрузить 50 и 100.
helgihabr
Думаю, считать кучу картинок и контента хабра в сумме с JS кодом не совсем корректно в эти 12 Мб.
UrbanRider
Понятное дело. Я в общем и целом веду к тому, что сейчас есть сайты, где полезной информации на пару килобайт, а к тебе прилетает десятки мегабайт трафика.
Drag13
JavaScript-а там больше 2mb. И 500kb JS намного критичнее чем 5mb картинок. Потому что вы можете подключиться к хорошему WiFi, а к хорошему процессору уже никак.
В идеале (наверное кто-то это уже даже сделал) разбить JQuery на функции и импортить только то что реально нужно, как сделали с Lodash.
helgihabr
Как-то вы лихо связали объем JavaScript-а с CPU.
Каким образом кол-во кода говорит об аппетитах к CPU?
inoyakaigor
Тут связь прямая. Вот тут, например, подробно расписано
Drag13
Потому что JS (даже который не выполняется) требует ресурсов CPU для того что бы его распарсить. И если это синхронный скрипт размещенный в хеде, то пока вы его не распарсите, вы ничего не увидите. Эта проблема не очень актуальна для декстопов, а вот для мобильных телефонов не первой свежести встает в полный рост. Подробнее можно почитать тут.
Ну и заодно моя статться тут
helgihabr
Я понимаю, что на парсинг тратятся ресурсы CPU, как и на рендер страницы. Это, конечно, больше связано с ограничениями мобильных браузеров, многие из которых уже решены или планируются в ближайшем будущем.
В любом случае, информация интересная, спасибо.
inoyakaigor
Вот это было бы идеальным решением
0x131315
Сейчас веб другой. Проблема с десятками мегабайт картинок на странице решается не сжатием, а lazyload. И это ппц.
vladkorotnev
И в итоге на мобильнике после окончания трафика на скорости 33кб/с любуешься не на сайт, а на набор пустых квадратов (ибо вебфонты тоже не грузятся).
OlegTar
Да, сейчас веб другой. Страничка в браузере может занимать 500 мб памяти
Source
Насколько я понимаю, они со временем выпиливают слой совместимости с совсем уж древними браузерами, и как следствие размер библиотеки уменьшается со временем. Ради интереса посмотрел, текущая версия (3.4.1) занимает 86 kb и это ещё без gzip. По текущим реалиям будет точнее называть его "пренебрежимо маленький jQuery".
mobi