Comments 64
Спасибо за ссылку на презентацию разработчика jQuery.
По jQuery масса сведений в Интернете, дорогая книга ни к чему
Я даже больше скажу: всё, что необходимо знать о jQuery можно прочитать на официальном сайте jQuery. Причём, написано там хорошо: я, никогда не изучавший английский, а только нахватавшийся в интернете слов, уверенно понимаю документацию.
Существует две версии jQuery
Я может быть уже в будущем, но как же jQuery 3.0 и 3.1?
Не нужно хоронить jQuery раньше времени.
Но главное в другом — а зачем их вообще противопоставлять?
Ничего не имею против Ангуляра, Реакта и ещё кучи всего, но всё это не отменяет того медицинского факта, что jQuery держит свою рыночную нишу и успешно решает проблемы тысяч людей. И доля этой ниши хоть и снизилась в последнее время, всё равно ещё очень велика и ещё долго останется таковой.
https://www.google.com/trends/explore?q=jQuery,AngularJS,%2Fm%2F012l1vxv
?
https://habrahabr.ru/post/308148/
Чтобы добавить красивую анимашку на классический портал, JQuery — идеальный вариант (хотя сейчас актуальнее анимашки в CSS, влияние JQuery можно свести к минимуму)
Я как-то спросил у автора одной такой библиотеки, а не хочет ли он избавиться от jQuery-зависимости. Он ответил мне буквально следующее: «это большие и ничем не оправданные трудозатраты».
Потому что для всяких просто сайтов jQuery по-прежнему стандарт де-факто. Уж очень большая экосистема накопилась. Это просто, это удобно. Это дает хорошую кроссбраузерность. Это может поправить-дописать любой фрилансер. Не нужно разворчивать адовое рабочее окружение, чтобы вставить какой-нибудь новый слайдер.
Вот для сложных веб-приложений — да, нужно использовать что-то более прогрессивное.
Я очень люблю сравнивать все с языком ассемблера. В далеких 1960-х и 70-х годах (или когда?), когда только появился ассемблер, это был громадный прорыв: вместо неудобного программирования в машинных кодах стало можно писать команды для CPU в текстовых файлах, которые затем автоматически транслировались в машинный код. Потом придумали символьные метки: вместо «jmp 1234h» или «mov ax, [1234h]» стало можно писать «jmp some_label» и «mov ax, some_var», а смещение компилятор выбирал сам.
И после этого придумали «макроассемблер»: это все тот же ассемблер, но там вместо
cmp ax, 10
jne no
mov bx, 1
jmp cont
no: mov bx, 2
cont:…
стало можно писать гораздо короче и приятнее, что-то типа (там еще много подобных штук было, типа .invoke для вызова процедур и т.д.):
.if ax == 10
mov bx, 1
.else
mov bx, 2
.endif
И параллельно же развивались языки высокого уровня (Алгол, Паскаль, Си, Фортран и т.д.).
Так вот, макроассемблер — это как бы улучшение того же самого API, что дает ассемблер. Просто более короткий синтаксис над той же абстракцией. А языки высокого уровня — это совершенно другая а стракция, следующая, делающая макроассемблер не нужным в подавляющем большинстве случаев.
DOM — это ассемблер. jQuery — это макроассемблер. React-подход — это язык высокого уровня. Такие аналогии.
В мире есть миллионы «просто сайтов» — не приложений, а сайтов с менюшкой, страничками и статьями. И туда нужно добавить, например, слайдер, чтобы фоточки перелистывал. Подключается jQuery, несколько строк кода, немного возни со стилями, и оно работает. Это может сделать очень недорого любой фрилансер буквально в блокноте и браузере.
Теперь новые фреймворки. Поставь и настрой ноду, gulp, babel, webpack и далее по списку. Зачем это всё в вышеописанном случае?! Если разрабатывается серьезное веб-приложение — вопросов нет. Но для простых случаев это просто никому не нужный геморрой, который никто не хочет оплачивать.
document.querySelector('h2').style.display = 'none';
И этот код прекрасно работает в IE8.
Но там речь шла о втором элементе h2, так что таки querySelectorAll('h2')[1]
document.querySelectorAll('h2')[1].style.display = 'none';
и согласитесь что уже и не так элегантно и просто это выглядит как в jQuery.
Хотя сам я JQuery уже пользовался, тупо нашёл примеры на форумах и впилил на сайт :) В этом плане всё легко и понятно (JQuery для простоты-интуитивности, видимо, и создан). А глубже копать неохота, есть куча готовых библиотек, в которых достаточно только стили сменить. Так что сам покупать книги по JQuery не стану.
Например, http://zeptojs.com — 10kb в gzip. Это если там «ну зачем тянуть слона ради...»
Сейчас вот не помню точно, но кажется Owl Carousel мне удалось подружить с Zepto небольшой доработкой напильником. А вот ту же Фотораму — не получилось, уж слишком много там накручено внутри.
Используйте jquery.slim ( https://jquery.com/download/#jquery ) — в чем проблема то?
Например строчка:
document.querySelectorAll('h2')[1].style.setProperty('display','none');
В реальности превратиться примерно в:
var h2 = document.querySelectorAll('h2');
if ( h2 && h2[1]) {
h2[1].style.setProperty('display','none')
}
Я в одном из своих проектов отказался от jQuery именно по той причине, что он «проглатывал» ошибки доступа. Это только для спагетти-проектов подходит.
То есть, если я вижу в коде, что if (h2)
— это подразумевает, что возможна такая ситуация, когда h2 не будет. И стоит задаться вопросом — почему. На самом деле, это исключение, а не правило. JQuery же возводит в абсолют такой паттерн — подразумевая, что элемента, с которым мы работаем, может не быть.
Это так же неправильно, как если бы язык программирования не выбрасывал null pointer exception при доступе к несуществующему свойству, а молча это проглатывал. Вы бы тогда охренели отлаживать код, потому что совершенно непонятно было бы, почему он не работает — хотя делает вид что работает.
Хорошее пособие, на тот момент реально помогло разобраться в предмете.
Об актуальности её сейчас, судить не буду, т.к. благополучно ушёл из зоопарка в сторону бэк-енд, чему тихо радуюсь.
<div class="foo">
<div>1</div>
<div>2</div>
</div>
.bar div:nth-of-type(2) {
display: none;
}
let element = document.querySelector('.foo');
element.classList.toggle('bar');
Вот и зачем тут jQuery?
Безусловно, что можно придумать какой-нибудь метаязык, который и такую запись сократит до минимального набора символов, но зачем…
<div class="foo {{ isVisible && 'bar' }}">
<div>1</div>
<div>2</div>
</div>
$$el.toggle('isVisible');
Но это уже совсем другая история…
В любом случае, если разработчик по каким-то причинам предпочел выбрать стандартное API (пусть даже с полифилами), а не jQuery, то наверняка на это есть причины. А какие причины это уже другой вопрос. Это может какой-то движок селекторов, виджет или какая-то другая задача где требуется высокая производительность выборки.
Лично для меня использовать jQuery когда есть всякие «реакты-шмакты» неприемлемо.
Но суть ведь не в этом. Вы написали 2 строчки кода и вам уже понадобился подключить полифил, а что будет на 1000 строках кода? В этом смысле jQuery — это всего лишь набор полифилов на все случае жизни и удобный апи. Лично я в свое время начал использовать jQuery именно потому, что кол-во самописных workaround'ов стало привышать порог терпимости.
Лично для меня использовать jQuery когда есть всякие «реакты-шмакты» неприемлемо.
Последние года 3 я использую RactiveJS как основу для построения изоморфных веб-приложений. Но и для JQuery все еще остается место, потому что за годы его популярности на его основе написано очень много крутых плагинов и другого добра, которые никто переписывать не будет, а не использовать их глупо.
Благо RactiveJS, не смотря на всю его реактивность, вполне себе удачно «дружится» с плагинами jQuery с помощью встроенных в RactiveJS декораторов.
Пример — метод «on».
Зачем нам jQuery?