Комментарии 88
Чем приложение меньше, тем меньше смысла грузить немаленький jQuery, соответственно верно и обратное.
Я помню веб, когда все боролись за минимальный объем передаваемых клиенту данных, т.к. скорость никакая.
Т.е. понимая, что главная страница хабра грузит мне 12 Мб, то меня это немного печалит, т.к. тенденция такова, что некоторые сайты могут лего загрузить 50 и 100.
Каким образом кол-во кода говорит об аппетитах к CPU?
Чем приложение меньше, тем меньше смысла грузить немаленький jQuery
Насколько я понимаю, они со временем выпиливают слой совместимости с совсем уж древними браузерами, и как следствие размер библиотеки уменьшается со временем. Ради интереса посмотрел, текущая версия (3.4.1) занимает 86 kb и это ещё без gzip. По текущим реалиям будет точнее называть его "пренебрежимо маленький jQuery".
Я не люблю jQuery в основном из-за кода, который она обычно порождает и из-за того, ч то если ты опечатаешься в селекторе, всё просто молча перестаёт работать.
В ванилле ошибки в селекторах будут видны сразу, но в остальном это будут точно такое же императивные спагетти. А когда прикинешь, чего стоит написать красивую и фичастую делегацию событий (кстати, YMNJQ не предлагает для этого ровно ничего), то сразу становится проще взять библиотеку. А если берешь библиотеку, то уж не лучше ли взять ту, которую все знают и которую отлично вылизали за больше чем 10 лет разработки.
Не понял чем опечатка в селекторе отличается в jQ и ваниле — оба варианта вернут что-то у чего можно будет проверять длину
Плюс не считаю что jQ что-то порождает, она как оружие, может защищать а может убивать, вопрос в том, в чьих руках она находится
оба варианта вернут что-то у чего можно будет проверять длину
Если забыть такую проверку, то в ванилле все упадет с эксепшеном. jQuery эти проблемы просто "проглатывает".
вопрос в том, в чьих руках она находится
Да-да, все так говорят. Но почему-то у всех получается спагетти. Потому что нет никакого способа как-то это структурировать и обеспечить повторное использование, кроме jQueryUI-плагинов, а ими никто не пользуется.
querySelector возвращает null и может вызвать эксепшен, но querySelectorAll (это какраз то что используется в jQ) возвращает NodeList и тут эксепшен может и не прийти, да, но он и ваниле не прийдет =) это надо иметь в виду и всё будет ок
Структурирование и повторное использование возможно на основе плагинов
это же библиотека, на ней можно сделать всё, вопрос в том, как далеко ты готов зайти =)
Ну и да, под каждую задачу нужно выбирать подходящий инструмент, а не ругать отвертку что она плохо забивает гвозди
Иногда тебе не нужен реакт, а хватит джиквери, но чаще и она не нужна
это же библиотека, на ней можно сделать всё, вопрос в том, как далеко ты готов зайти =)
Ну проблема в том, что когда заходишь достаточно далеко, то у тебя получается свой, маленький и глючный Knockout или Backbone. Тогда надо было сразу брать эти библиотеки:)
Ну и да, под каждую задачу нужно выбирать подходящий инструмент, а не ругать отвертку что она плохо забивает гвозди
Иногда тебе не нужен реакт, а иногда хватит и джиквери, но чаще и она не нужна
Речь как раз о тех случаях, когда условный реакт не нужен (или недоступен).
querySelectorAll (это какраз то что используется в jQ) возвращает NodeList и тут эксепшен может и не прийти, да, но он и ваниле не прийдет
С каких это пор эксепшен не прийдет? В любом случае прийдет.
Я не люблю jQuery в основном из-за кода, который она обычно порождает и из-за того, ч то если ты опечатаешься в селекторе, всё просто молча перестаёт работать.
Прям в точку, меня это тоже постоянно раздражает, если есть ошибка, то ее как минимум нужно вывести, можно обработать, и пойти дальше, но не уведомить программиста об этом, это какое то кощунство.
Но самый первый пример на этом сайте демонстрирует вескую причину jQuery использовать. Там строка простого кода на jQuery заменяется на 10 строк обычного JS!
Конкретно вот этот вот аргумент — так себе. В этом примере на 10 строк используется XMLHttpRequest, вместо которого сегодня смело можно использовать fetch.
Не смело, зависит от проекта. Только 90% посетителей поддерживают его, а в России только 80%: https://caniuse.com/#feat=fetch
Решается небольшим полифилом: https://github.com/github/fetch
window.fetch || document.write('<script src="fetch.js"><\/script>');Но грязный исполнитель внутри меня пожевал прилипшую сигару и хриплым голосом спросил
— а что там насчет часов? время на эти таски оплатят?
Так что вопрос лиш в адекватности инструмента решаемой задаче.
Особенно в этом плане отличается babel с его preset-env, который пихает в код непонятно что непонятно зачем.
А Vue.js и jQuery в одном проекте — это уже малость перебор.
Почему кстати?
Vue 1.0 вполне отлично уживался с jQ, даже код красивый был.
Про v.2 не знаю, из за виртуального DOMа не возникают проблемы?
Использую и других заставляю
как бы мы не стремились к перфекционизму, но "реальность полна разочарований". И бизнес требует решений здесь и сейчас, но денег нет, и надо держаться. Без бэкендеров жить нельзя, а фронт… фронт в немалой степени благодаря наличию jQ вполне становится подъёмен, понятен и сопровождаем при постоянной текучке кадров и использовании труда фрилансеров. Так что из наименьших зол — этот уровень абстракции как раз помогает избежать боли и страданий и хоть как-то крутиться. Ни разу не относя это к оправданиям, но если бы не эти спасительные 30кб, то я даже боюсь представить во что бы превратились наши и без того кучи метров говнокода без картинок в лендосах, написанные по сути бэкендерами, не от хорошей жизни, но… быть высокодоходным топом с кучей фронтендеров везёт не всем.
Dev. — На кой нам тут Vue, хватит и JQ.
6 мес разработки.
Заказчик: — Мы хотим отчеты, графики, панельки и чтоб все выезжало, крутилось и вертелось.
Dev. — Ок, у нас есть Vue, тока надо переписать JQ.
«Он и нафиг не нужон нам, Vue этот ваш, сто лет без него жили и еще сто проживем»
Возвращаясь к slideToggle я показывал удобство и продуманность в таким мелочах — одна строчка и не нужно ничего думать — и все.
В самом простом случае — одна строчка. Но стоит хоть немного усложнить задачу и вам придется городить велосипеды.
Например, если вам надо будет анимировать элементы при сортировке списка товаров — то количество кода на jquery будет уже гораздо больше чем на vue.
Фреймворки создаются для того чтобы решать стандартные задачи простыми способами.
Да, на jquery можно быстро и просто «налабать» и залить на прод по фтп. Но как-нибудь откроешь такой проект, слепленный из разрозненных кусков кода на jquery, с кучей заплаток в виде плагинов — и руки захочется оторвать этим горе-разработчикам.
Размер пренебрежительно мал на фоне нынешних мегабайтных сайтов, так еще и нередко она уже предзагружена по cdn у юзера, а если нет — загружается один раз.
По уму лучше включили бы ее уже в браузеры, пусть даже в разных версиях, и вопрос был бы снят совсем.
У меня недавно возникла такая проблема, когда я делал мини-игру, а в движке только jQuery. Но это первый раз за 12 лет фронтендерства, обычно я манипулирую SVG из Vue или чего-нибудь такого:)
Плюс в jQuery что он прост, чтобы заменить его чистым JS, надо искать кучу полифиллов, и все они подключаются по разному и имеет разное качество исполнения.
Сам юзаю jQuery там, где нужно быстро что-то сделать, буквально в пару часов/дней, сдать и забыть.
На основном проекте перевожу с jQuery на Vue.js и чистый JavaScript.
Смотря какие возможности jQuery использовать. За ajax и Differed я в наше время руки бы отрывал :)
Например, конструкция 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.
А вообще удивительно как jQuery до сих пор держит реноме простой и компактной библиотеки, хотя там внутри накручено много всего странного:
- Кастомные обертки над событиями
- Даже нативный движок селекторов все равно содержит много строк
- Монструозная регулярка, для авто-расстановки суффикса
pxдля нас, где надо - Даже взятие атрибута там выливается в много кода
Это какой-то синдром утенка, когда-то давно с нее начинали и теперь не можем отвязаться, хотя оверхеда там больше чем пользы
Обёртка над кастомными событиями используются в jQuery, потому что даже в 18 Edge есть весьма нелепый баг.
Вас не смущает, что Before и After это разные положения?
Упс, пропустил что там after. По своему опыту могу сказать, что и необходимости в нем особой не было. Для создания сортируемых списков insertBefore справляется прекрасно, а для всего остального – лучше использовать appendChild, а не вставлять что-то в середину.
И изучать их от проекта к проекту?
Что вы имеете в виду? Что изучать, с ними вроде и так все понятно.
Рассказ о том, почему я до сих пор использую jQuery