Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
Не понимаю смысла таких статей. Каждой задаче — свой инструмент.
jQuery — очень хорошая библиотека, ускоряющая процесс разработки, имеющая кучу плагинов.
jQuery — очень хорошая библиотека, ускоряющая процесс разработки, имеющая кучу плагинов.
Согласен, всему свой инструмент. Эта статья направлена на разъяснение что не нужно использовать jQuery как the ultimate фреймворк для управления самолетом, и приготовления кофе. Эта классная низкоуровневая библиотека с кучей расширений и не более.
Не надо использовать библиотеку как фремворк, а надо использовать библиотеку как библиотеку… Вам всё ещё кажется что статья нужна? :)
Да конечно, я же описал выше почему. Если вам кажется что статья вам лично ничего не дает или сводится к тому что вы говорите, просто не читайте ее как вы не читаете статьи которые вас не интересуют.
Одно дело когда просто не интересно, другое дело когда статья разжигает очередной никому ненужный холивар на пустом месте. Не нравится как работает jQuery? Не вижу ссылок https://github.com/jquery/jquery
Холивал пытаетесь разжечь вы. В статье не говорится что jquery гумно и что все кто его использует ослы. В статье есть два ключевых аспекта, первый в том что время jquery прошло и он попросту изжил себя так что хватит его притягивать за все что можно и второй аспект в том что jquery не всеобъемлющий, а всего навсего библиотека. Эта статья выражение моей точки зрения, если кто-то ей ущемлен или оскорблен, ваше дело, это не было сутью статьи.
В статье есть два ключевых аспекта, первый в том что время jquery прошло и он попросту изжил себя так что хватит его притягивать за все что можно
Покажите, где указано, что она себя изжила.
Есть что jquery пытается угодить всем, есть призыв за использование «стандартов», против привычного функционала.
Каждой задаче — свой инструмент.А то мы не знали.
Не понимаю смысла таких статей.В статье обрисован круг задач, для решения которых jquery не нужен.
jQuery — очень хорошая библиотека, ускоряющая процесс разработки, имеющая кучу плагинов.Спасибо, кэп! :)
ИМХО в данный момент основной проблемой jQuery является обилие плагинов, которые без допиливания напильником сложно использовать с webpack/common.js, покуда они цепляются на неймспейс jQuery, что портит всю идею. Но эта проблема появилась не так давно, да и не такая уж и большая проблема (многие плагины сейчас обзаводятся совместимостью, что не может не радовать). Второй проблемой я вижу то, что очень часто тянут эту библиотеку ради того, чтобы повесить одно событие или один раз спрятать элемент, что является пустой тратой ресурсов. Однако если у вас достаточно большой проект — jQuery очень полезен, порой — не заменим, даже если вы используете крупные фреймворки (что уж тут говорить, jQuery тянет за собой angular (правда jQuery light, но не суть), backbone и многие другие).
jQuery — большой, превосходный, но все же один из многочисленных инструментов, и его, как и все другие, нужно использовать с умом.
P.S. Конкретно по статье: тема интересная, но в статье совсем не раскрыта — не показано, когда его нужно использовать, когда он избыточен. Поэтому статья и выглядит бесполезной.
P.P.S. «Наверное, вам уже приходилось слышать замечания такого рода, и, скорее всего, вы чувствуете себя вполне вольготно, используя jQuery.» — о грамматике принято писать в личку, но у вас во всей статье одни и те же ошибки, ужасно режущие глаз прямо с первого предложения с 5-ю ошибками. Посему вспоминается отличное правило: «не используйте сложносочиненные предложения, вводные слова и прочие обороты, потому что все равно не знаете правил расстановки знаков препинания». Ну или вставляйте текст перед публикацией в Word хотя бы.
jQuery — большой, превосходный, но все же один из многочисленных инструментов, и его, как и все другие, нужно использовать с умом.
P.S. Конкретно по статье: тема интересная, но в статье совсем не раскрыта — не показано, когда его нужно использовать, когда он избыточен. Поэтому статья и выглядит бесполезной.
P.P.S. «Наверное, вам уже приходилось слышать замечания такого рода, и, скорее всего, вы чувствуете себя вполне вольготно, используя jQuery.» — о грамматике принято писать в личку, но у вас во всей статье одни и те же ошибки, ужасно режущие глаз прямо с первого предложения с 5-ю ошибками. Посему вспоминается отличное правило: «не используйте сложносочиненные предложения, вводные слова и прочие обороты, потому что все равно не знаете правил расстановки знаков препинания». Ну или вставляйте текст перед публикацией в Word хотя бы.
Angular не тянет с собой jQuery, а jQuery Light вообще не совместим с настоящим jQuery и сделан ради «чтобы было» (на самом деле несложной работы через Директивы, там даже поиска по классам нет). Мало того — у Angular сам принцип работы с DOM в корне отличается от работы с DOM через jQuery и поэтому если вам нужно работать с DOM через Angular в стиле jQuery — значит большая вероятность, что вы делаете что-то не так.
Работая с Angular я очень часто сталкиваюсь с тем, что очень мало готовых плагинов не завязанных под jQuery.
Сейчас у меня большой проект на Angular и там нет jQuery совсем.
Работая с Angular я очень часто сталкиваюсь с тем, что очень мало готовых плагинов не завязанных под jQuery.
Сейчас у меня большой проект на Angular и там нет jQuery совсем.
Backbone, справедливости ради, тоже не сказать, что тянет с собой jQuery. Если не использовать Backbone.View, то остальное работает без нее.
С jQuery есть две проблемы. Первая — это легаси-методы, типа prependTo и unwrap. Сначала шаблонизаторы, потом байндинги сделали прямые манипуляции с DOM ненужными, слава богу. Вторая — мелкие, но многочисленные архитектурные недочеты, типа God Object, кривые вещи в некоторых API и т.д. Zepto, являясь полным клоном, эти проблемы никак не решает, а с разделением jQuery на 1.x и 2.x имеет смысл использовать ее только разве ради поддержки тач-событий.
С другой стороны, в jQuery есть масса удобных вещей, для которых пока нет и не предвидится нативных аналогов — навскидку .closest и .index. С третьей стороны — наверняка stand-alone аналоги всему или почти всему есть в npm.
С другой стороны, в jQuery есть масса удобных вещей, для которых пока нет и не предвидится нативных аналогов — навскидку .closest и .index. С третьей стороны — наверняка stand-alone аналоги всему или почти всему есть в npm.
Очередная статья на тему «не используйте JQ», если не путаю, их уже на хабре больше 3х и каждая практически не отличается содержанием. Только по-моему не имеет смысла, т.к. ситуация несколько иная:
Проблема не в том, что ей пользуются, т.к. не видят аналогичных возможностей ванилы, а статья показывает, мол, смотрите, уже можно и без Jq вот так писать. Проблема в том, что те, кто используют — просто не умеют иначе. На подсознании уже у ребят подключение jq идёт первым делом, а дальше уже гугл, плагины и прочее. А то, что 30% jq реализовано в css, 60% в нативе, а остальная часть в ES15+ — это же надо учить, надо заморачиваться.
Проблема не в том, что ей пользуются, т.к. не видят аналогичных возможностей ванилы, а статья показывает, мол, смотрите, уже можно и без Jq вот так писать. Проблема в том, что те, кто используют — просто не умеют иначе. На подсознании уже у ребят подключение jq идёт первым делом, а дальше уже гугл, плагины и прочее. А то, что 30% jq реализовано в css, 60% в нативе, а остальная часть в ES15+ — это же надо учить, надо заморачиваться.
Как люди начинают использовать jQuery? У меня это произошло после поиска «JS post request», где мне выдало jquery + как менять элементы на странице через тот же jquery.
Мои фломастеры мне говорят, что из всей статьи единственный полезный момент (для меня, опять же), это http://blog.garstasio.com/you-dont-need-jquery/, где показаны простейшие реализации отдельных элементов на JS, что избавит от надобности отдавать юзеру jquery, если надо сделать пару-тройку функций.
Теперь замена на zepto:
19кб больше… как-нибудь переживем. Что еще?
Итого: 19 кб экономии и без поддержки «чего-то там» в старых браузерах?
Вердикт: может даже и быть. Но пока множество галерей, чатов и прочих свистоперделок использует jquery, и причем работает на старых системах, переезд на новуюфреймворк библиотеку будет не скоро.
- динамически менять контент (работая на get/post c rest api)
- анимация и няшки
- плагины, которые требуют jquery
Мои фломастеры мне говорят, что из всей статьи единственный полезный момент (для меня, опять же), это http://blog.garstasio.com/you-dont-need-jquery/, где показаны простейшие реализации отдельных элементов на JS, что избавит от надобности отдавать юзеру jquery, если надо сделать пару-тройку функций.
Теперь замена на zepto:
94K Apr 28 2015 jquery-1.11.3.min.js
33K Dec 17 12:51 jquery-1.11.3.min.js.gz
83K Apr 28 2015 jquery-2.1.4.min.js
29K Dec 17 12:51 jquery-2.1.4.min.js.gz
25K Jun 16 2015 zepto.min.js
10K Dec 17 12:51 zepto.min.js.gz
19кб больше… как-нибудь переживем. Что еще?
Zepto stays lean by not attempting to fix ancient 'browsers'
Итого: 19 кб экономии и без поддержки «чего-то там» в старых браузерах?
Вердикт: может даже и быть. Но пока множество галерей, чатов и прочих свистоперделок использует jquery, и причем работает на старых системах, переезд на новую
Ну вообще все эти свистоперделки, по задумке, как раз должны работать на zepto без проблем. Зато получаете меньший вес и поддержку тач-событий — обе плюшки важны для мобилок.
Так тач-события есть и в jquery https://api.jquerymobile.com/category/events/ (tap, swipe, taphold, swipeleft, swiperight).
В zepto, судя по оффсайту добавили «doubleTap», «swipeUp», «swipeDown». А «longTap» это аналог "taphold".
В zepto, судя по оффсайту добавили «doubleTap», «swipeUp», «swipeDown». А «longTap» это аналог "taphold".
У любого человека который тесно связан с фрондэндом есть несколько этапов развития.
— Когда человек пишет на jquery все
— Когда человек начинает задумываться над jquery
— Когда человек пытается переписать jquery
— Когда осознает что можно жить и без него
— Опционально написать об этом статью
— И когда наконец-то осознает, что jquery это отличная либа, которая хоть и прилично весит, и довольно медленная, но решает целую кучу проблем, особенно в типовых задачах
— Когда человек пишет на jquery все
— Когда человек начинает задумываться над jquery
— Когда человек пытается переписать jquery
— Когда осознает что можно жить и без него
— Опционально написать об этом статью
— И когда наконец-то осознает, что jquery это отличная либа, которая хоть и прилично весит, и довольно медленная, но решает целую кучу проблем, особенно в типовых задачах
И какие же проблемы решает JQ? Вот представьте, что я обычный фронт-эндер, но ничего не знаю о JQ, максимум использую либу вроде кнокаута для разделения логики и представления. Убедите меня использовать JQuery для какой-либо задачи, где оно будет проще с Jquery, чем без него?
P.S. Если по теме — у меня немного другая стадия — я просто не использую его, т.к. не знаю задач, где он облегчит жизнь.
P.S. Если по теме — у меня немного другая стадия — я просто не использую его, т.к. не знаю задач, где он облегчит жизнь.
P.P.S:
— Ajax? Мне проще написать «await fetch('...')», вместо "$.ajax(...)".
— Анимации? Мне проще написать «trasition: opacity .3s ease», вместо "$(...).fadeIn".
— Управление данными DOM элемента? Мне проще написать «value = 42» (указав в шаблоне куда вставлять переменную value), вместо "$(...).text(42);"
Больше я не представляю зачем оно нужно, увы.
— Ajax? Мне проще написать «await fetch('...')», вместо "$.ajax(...)".
— Анимации? Мне проще написать «trasition: opacity .3s ease», вместо "$(...).fadeIn".
— Управление данными DOM элемента? Мне проще написать «value = 42» (указав в шаблоне куда вставлять переменную value), вместо "$(...).text(42);"
Больше я не представляю зачем оно нужно, увы.
Сильно облегчает жизнь если требуется поддержка большинства браузеров. Конечно многие сайты этого не требуют, но когда серьезный проект это очень важно.
Кейворд «await» должен был вам сказать, что в пример я привожу ES'16, а использование ES'16 подразумевает использование babel прослойки для отката, которая реализует все стандартные объекты, кроме проксей. Единственное «но» — это экспериментальные фичи, вроде Fetch API (крайне рекомендую хотя бы полистать его доки, в своё время я впал в экстаз смотря на это чудо), но это так же исправляется строкой «npm install whatwg-fetch» (К слову, оно уже работает на современных браузерах). В сумме оно (рантайм) весит примерно столько же, но значительное преимущество в том, что через 2-3 года эти прослойки можно просто отключить, не трогая и строчки кода.
Как это решает проблему поддержки ie7-8-9, и прочих проблемных вещей?
Поддержку IE9 решает, а остальные даже гугл, вк и прочие, боюсь что больше половины сайтов в интернете не поддерживают (Например http://habrahabr.ru/post/201174/ прошу обратить внимание, что новость двухлетней давности).
Боюсь спросить, а на кой вам поддержка ИЕ8?
Боюсь спросить, а на кой вам поддержка ИЕ8?
Гугл поддерживает, но не официально. Когда делаешь проект не для себя, или не корпоративного уровня, где можно всех пересадить на любой браузер, тогда это не актуально.
Но даже в этом случае, спорить с тем, что jquery упрощает работу с DOM, ajax, для кого-то анимациями, эвентами и добавляет сахара.
В конечном итоге jQuery это либа, а не фреймворк и не указывает тебе что делать. И я могу сказать что написал много приложений с ангуляром, и даже в этом случае jQuery мне очень помогал. И дело совсем не в неправильности архитектуры.
С мобильных приложениях и сайтах стараюсь не использовать jQuery, раньше заменял на zepto, но последние год-два и от него отказался. Но это только потому что у мобильных браузеров нет IE<9
Но даже в этом случае, спорить с тем, что jquery упрощает работу с DOM, ajax, для кого-то анимациями, эвентами и добавляет сахара.
В конечном итоге jQuery это либа, а не фреймворк и не указывает тебе что делать. И я могу сказать что написал много приложений с ангуляром, и даже в этом случае jQuery мне очень помогал. И дело совсем не в неправильности архитектуры.
С мобильных приложениях и сайтах стараюсь не использовать jQuery, раньше заменял на zepto, но последние год-два и от него отказался. Но это только потому что у мобильных браузеров нет IE<9
Я до сих пор не понимаю зачем при наличии декларативного подхода (ангулар) требуется ярая императивщина (jquery)? Можно пример пожалуйста? Может я просто не сталкивался с такими ситуациями, хотя и писал довольно серьёзные проекты.
Вы хотите сказать что пишите серьезные веб проекты довольствуясь только jQuery? Я не троллоло, просто пытаюсь понять вашу точку зрения.
Не понимаю как вы читаете. Я все хорошо и понятно написал. Повторю еще раз — в случае работы с ангуляром jQuery бывает не лишним.
Из вышеописанного не понятно или вы так считаете в глобально-космическом плане или же вы в реальных проектах, день за днем мешаете(я не в негативной стезе) оба подхода. Но не суть важно. Если это так, я вас не понимаю. Из опыта могу сказать что мне уже приходилось быть в схожих ситуациях, когда в проекте на knockout просто позарез нужен какойнить плюшко-плагин jquery и PO просто на гумно исходится лишь бы плюшка была в продакшене. Но я всегда выходил сухим из воды, аккуратно оборачивая всю сантехнику jQ в расширения knockout. Насколько мне известно вы можете сделать тоже самое при помощи директив angular, хотя я могу и ошибаться.
Чаще всего так и происходит. Всякие календарики, кастомные селекты, кастомные инпуты с автодоплнением и т.д. И проблема в общем-то не в том, что аналогов чисто на ангуляре нет. Они есть, только не всегда подходят, особенно если у тебя не SPA, а страницы которые генерируются на сервере. Тогда можно сделать плагин и как декларативную директиву так и просто как плагин. Так же приятно использовать $.ajax просто потому что привык. Ну и немного сахара.
Неправильно вы смотрите на ситуацию, спрос рождает предложение и популярные вещи априори не могут быть бесполезными. Это как раз результат рожениц кода. Значит у вас нет таких задач.
Спасибо, я вот к этой стадии только стремлюсь. Если бы был один, то давно бы уже улетел на планету где jquery нет и не нужно. Я не понимаю как человек видевший все достоинства MV* для разработки крупных и средних веб-приложений может откатиться назад и нежно укладывать jquery-based код в модуль паттерны. Я почему-то в последнее время только с такими и имею дело.
В статье имеется уклон в сторону «используйте нативный javascript». Выскажу мнение со своей колокольни. Я ни в коем случае не против знания чистого javascipt, просто как-то так получается, что в основном занимаюсь проектами, где уже используется jquery.
И заменить 1 символ на 25. На главной Хабра обращение к $ встречается 44 раза. А сколько будет в подключаемых скриптах?
Сделать функцию-обертку? Идем дальше.
«Зачем нам нужно так усложнять себе жизнь?»
Последнее особенно весело, если кто-то так назначил обработчик где-нибудь в main.js и не проверил на null, при этом unknown_id является known на 99% страниц, а unknown он только на некоторых и при определенных условиях.
Да, еще при изменении селектора с «id» на «class» мне надо не забыть поменять нативную функцию.
Здесь полностью согласен, такое бывает. Но для проектов среднего уровня, где не требуется серьезная работа с фронтендом, jQuery неплохой выбор.
Можно легко заменить селектор типа $('div, span, article'); на document.querySelectorAll('div, span, article');
И заменить 1 символ на 25. На главной Хабра обращение к $ встречается 44 раза. А сколько будет в подключаемых скриптах?
Сделать функцию-обертку? Идем дальше.
$('button').bind('click', function(e){});$('button').bind('click', function(e){});
// 41 байт
console.log(document.querySelectorAll('button').forEach)
// undefined
// хм
// можно сделать так (83 байт)
for(var v of document.querySelectorAll('button')) {
v.onclick = function() {}
}
// или так (144 байт)
nodes = Array.prototype.slice.call(document.querySelectorAll('button'), 0);
nodes.forEach(function(v, i) {
v.onclick = function() {}
});
// или с оберткой в виде функции $ (73 байта)
$('button').forEach(function(v, i) {
v.onclick = function() {}
});
«Зачем нам нужно так усложнять себе жизнь?»
И так, иногда обертка, иногда нет, а иногда специальная обертка
document.getElementById('some_id') возвращает Element
document.getElementsByClassName('some_class') возвращает HTMLCollection[...]
document.querySelectorAll('#some_id') возвращает NodeList[...]
document.getElementById('unknown_id') возвращает null
Последнее особенно весело, если кто-то так назначил обработчик где-нибудь в main.js и не проверил на null, при этом unknown_id является known на 99% страниц, а unknown он только на некоторых и при определенных условиях.
Да, еще при изменении селектора с «id» на «class» мне надо не забыть поменять нативную функцию.
Я видел кучу больших проектов которые превращались в одно большое блюдо спагетти на клиентской стороне
Здесь полностью согласен, такое бывает. Но для проектов среднего уровня, где не требуется серьезная работа с фронтендом, jQuery неплохой выбор.
И заменить 1 символ на 25.
Минификаторы.
Минификаторы переименовывают системные функции (document.querySelectorAll)?
Эм. Дайтедва ссылку плиз. Видимо я динозавр совсем дремучий…
Эм. Дайте
А зачем им их переименовывать? Делаются алиасы. Вы никогда минифицированного кода не видели?:)
Я пока не встречал минификаторов делающих алиасы для системных функций. Видимо вот
поэтому
И, я не говорю, что это невозможно — я вообще-то попросил ссылку на такой умный минификатор.
И, насчет «видел» — чтобы далеко-то не ходить… С текущей страницы скрипт, минифицированный:
http://habracdn.net/habr/javascripts/1450359574/assets/global_main.js
поэтому
И, я не говорю, что это невозможно — я вообще-то попросил ссылку на такой умный минификатор.
И, насчет «видел» — чтобы далеко-то не ходить… С текущей страницы скрипт, минифицированный:
http://habracdn.net/habr/javascripts/1450359574/assets/global_main.js
Минификаторам можно и помочь, например, вот так: github.com/remy/min.js/blob/master/src/%24.js#L33. Если честно, я был уверен, что с обилием современных средств разбора AST минификаторы давно бороздят просторы вселенной и так далее.
В любом случае я бы не тревожился насчет 25 байт вместо одного. А в случае с повторами они эффективно сожмутся gzip.
В любом случае я бы не тревожился насчет 25 байт вместо одного. А в случае с повторами они эффективно сожмутся gzip.
Селекторы сейчас уже не являются тем локомотивом, который тащит jQuery. Их действительно можно и использовать нативные.
Чуть более сложный случай — это крайне нужные функции addClass, removeClass и так далее. Их нативная реализация пока еще не повсеместно поддерживается, увы. А полноценные фолбеки там довольно громоздки. Впрочем, прекрасно можно использовать Zepto, который легче в несколько раз.
Но и это неглавное. Главное — это огромный пул плагинов, которые привязаны к jQuery. И сначала библиотека дала взлететь им, теперь они не дают тонуть библиотеке. Иногда плагин заводится в связке с Зепто, иногда удается заставить их работать небольшим допиливанием кода. Но не всегда. Примеры из практики — галереи Fotorama, Slick привязаны именно к Джейквери. Я пытался модифицировать их внутри так, чтобы подружить с Зепто, но быстро это не получилось. Нужно либо тратить много времени, либо забить, либо выбрать другие галереи.
Чуть более сложный случай — это крайне нужные функции addClass, removeClass и так далее. Их нативная реализация пока еще не повсеместно поддерживается, увы. А полноценные фолбеки там довольно громоздки. Впрочем, прекрасно можно использовать Zepto, который легче в несколько раз.
Но и это неглавное. Главное — это огромный пул плагинов, которые привязаны к jQuery. И сначала библиотека дала взлететь им, теперь они не дают тонуть библиотеке. Иногда плагин заводится в связке с Зепто, иногда удается заставить их работать небольшим допиливанием кода. Но не всегда. Примеры из практики — галереи Fotorama, Slick привязаны именно к Джейквери. Я пытался модифицировать их внутри так, чтобы подружить с Зепто, но быстро это не получилось. Нужно либо тратить много времени, либо забить, либо выбрать другие галереи.
Давно выпилили jQuery. В Ангуляровских проектах он точно не нужен
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хватит использовать jQuery, вы способны сделать лучше без него