Pull to refresh

Comments 64

Спасибо за ссылку на презентацию разработчика jQuery.

По jQuery масса сведений в Интернете, дорогая книга ни к чему

Я даже больше скажу: всё, что необходимо знать о jQuery можно прочитать на официальном сайте jQuery. Причём, написано там хорошо: я, никогда не изучавший английский, а только нахватавшийся в интернете слов, уверенно понимаю документацию.

Только из вашего комментария узнал что появились новые версии jQuery.
А я из вашего о вашем существовании :)
Не нужно хоронить jQuery раньше времени.
Кто же его хоронит? Наоборот считаю что он живее всех живых.
Скорее Реакт умрёт чем jQuery, хотя и даже в этом случае — уйдут годы. :)

Просто удивительно — вроде бы и смотрю новостные источники каждый день, но нигде небыло анонса что jQuery обновился.
Больше всего бесит не сам факт использования, а использование либо наряду с другими абстракциями над DOM, либо наряду с прямой работой с DOM.
UFO just landed and posted this here
Я прошу прощения, но какой jQuery, React же на дворе. Причем даже не столько React как конкретный инструмент, сколько React как новая и прорывная концепция построения клиент-сайда (например, у Angular соответствующая часть базируется на похожих принципах).
Рекомендую иногда выглядывать в реальный мир. Это примерно как сказать — «простите, но какой бензин? ведь Тесла уже...»
И что? Не достиг же ещё.
Но главное в другом — а зачем их вообще противопоставлять?
UFO just landed and posted this here
Я реально не понимаю, что вы мне пытаетесь доказать.
Ничего не имею против Ангуляра, Реакта и ещё кучи всего, но всё это не отменяет того медицинского факта, что jQuery держит свою рыночную нишу и успешно решает проблемы тысяч людей. И доля этой ниши хоть и снизилась в последнее время, всё равно ещё очень велика и ещё долго останется таковой.
А так:
https://www.google.com/trends/explore?q=jQuery,AngularJS,%2Fm%2F012l1vxv
?

https://habrahabr.ru/post/308148/
Не удивительно, что хипстота из хэлооувордщиков сразу бросается в тренд, который затем ещё и растет.
Вот именно, что React — это в корне новый подход, ради него придётся все старые сайты переделывать.

Чтобы добавить красивую анимашку на классический портал, JQuery — идеальный вариант (хотя сейчас актуальнее анимашки в CSS, влияние JQuery можно свести к минимуму)
Если посмотреть крутые, качественные карусели и им подобные вещи, то они практически все до сих пор на jQuery. Хотя чисто технически их уже вполне можно наваять на ванильном JS.
Я как-то спросил у автора одной такой библиотеки, а не хочет ли он избавиться от jQuery-зависимости. Он ответил мне буквально следующее: «это большие и ничем не оправданные трудозатраты».
Потому что для всяких просто сайтов jQuery по-прежнему стандарт де-факто. Уж очень большая экосистема накопилась. Это просто, это удобно. Это дает хорошую кроссбраузерность. Это может поправить-дописать любой фрилансер. Не нужно разворчивать адовое рабочее окружение, чтобы вставить какой-нибудь новый слайдер.
Вот для сложных веб-приложений — да, нужно использовать что-то более прогрессивное.
Что React, что Angular это же framework'и, а jQuery библиотека, как это вообще можно сравнивать?
Напрямую их не нужно сравнивать, верно. Штука в том, то react-подход (ну или как он называется по-научному) практически полностью убирает необходимость работы с DOM — что напрямую, что через прослойку с более удобным API типа 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 и далее по списку. Зачем это всё в вышеописанном случае?! Если разрабатывается серьезное веб-приложение — вопросов нет. Но для простых случаев это просто никому не нужный геморрой, который никто не хочет оплачивать.
Вообще разные задачи. Jquery в первую очередь для работы с DOM. Его синтаксис для работы с элементами переняли многие другие библиотеки (тот же ангулар или cheerio на бэкэнде).
React тоже в первую очередь для работы с DOM.
Зачем вы усложняете код примера? Достаточно написать так:

document.querySelector('h2').style.display = 'none';

И этот код прекрасно работает в IE8.
style.display — да, конечно, намного лучше.
Но там речь шла о втором элементе h2, так что таки querySelectorAll('h2')[1]
В примере нужно убрать не первый элемент h2 а второй, поэтому вот так:
document.querySelectorAll('h2')[1].style.display = 'none';

и согласитесь что уже и не так элегантно и просто это выглядит как в jQuery.
Согласен, я это даже не пытался оспорить. Ничего не имею против jQuery как таковой. Применимость jQuery зависит от задачи.
А так?
document.querySelector('h2:nth-child(2)').style.display = 'none'; 

Это совсем другой селектор.

UFO just landed and posted this here
Я голосовал за бумажную книгу, т.к. сам люблю именно бумажные книги. По мне, инфа быстре усваивается, когда есть просто бумага, когда нет отвлекающих факторов в виде всяких извещений-оповещений и просто заманчивых иконок. Чем больше хороших книг, тем лучше.

Хотя сам я JQuery уже пользовался, тупо нашёл примеры на форумах и впилил на сайт :) В этом плане всё легко и понятно (JQuery для простоты-интуитивности, видимо, и создан). А глубже копать неохота, есть куча готовых библиотек, в которых достаточно только стили сменить. Так что сам покупать книги по JQuery не стану.
jQuery сейчас выглядит так же уродливо как обычный DOM API.
Не забывайте, что есть куча форков JQuery совместимых специально урезанных библиотек без редкоиспользуемых функций.

Например, http://zeptojs.com — 10kb в gzip. Это если там «ну зачем тянуть слона ради...»
К огромному сожалению, далеко не все jQuery-плагины из коробки заводятся с Zepto. А ведь в плагинах там основной смысл.
Сейчас вот не помню точно, но кажется Owl Carousel мне удалось подружить с Zepto небольшой доработкой напильником. А вот ту же Фотораму — не получилось, уж слишком много там накручено внутри.
Нативная работа с DOM уже позволяет сделать многое, но с 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 при доступе к несуществующему свойству, а молча это проглатывал. Вы бы тогда охренели отлаживать код, потому что совершенно непонятно было бы, почему он не работает — хотя делает вид что работает.

UFO just landed and posted this here
В своё время пользовался этой книгой, изданием 2009 года, Символ-Плюс.
Хорошее пособие, на тот момент реально помогло разобраться в предмете.
Об актуальности её сейчас, судить не буду, т.к. благополучно ушёл из зоопарка в сторону бэк-енд, чему тихо радуюсь.
А теперь напишите это с поддержкой ослика)) Хотя бы 9+.
Не понял, что Вы имели в виду.
Сорри, только что заметил. Мобильный клиент Хабра подлагивает и «отвечает» не на те комментарии. Задолбал уже. Мой изначальный коммент адресован сюда
Что конкретно вам не понятно? Это я к тому, что в реальном мире ваш код, приведенный в комментарии, будет не таким красивым и лаконичным.
<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?
Безусловно, что можно придумать какой-нибудь метаязык, который и такую запись сократит до минимального набора символов, но зачем…
А теперь напишите это с поддержкой ослика)) Хотя бы 9+. И вы с удивление обнаружите, что код уже не так красив и лаконичен.
Не вижу причин чтобы этот код не работал в IE9.
Другое дело, используя реактивные библиотеки для клиентского рендеринга, прямая работа с DOM вообще отсутствует и тогда можно писать что-то вроде ( RactiveJS ):

<div class="foo {{ isVisible && 'bar' }}">
    <div>1</div>
    <div>2</div>
 </div>


$$el.toggle('isVisible');


Но это уже совсем другая история…
Хм. значит на MDN некорректная информация. Но это не так важно, ведь есть достойный полифил.
В любом случае, если разработчик по каким-то причинам предпочел выбрать стандартное API (пусть даже с полифилами), а не jQuery, то наверняка на это есть причины. А какие причины это уже другой вопрос. Это может какой-то движок селекторов, виджет или какая-то другая задача где требуется высокая производительность выборки.
Лично для меня использовать jQuery когда есть всякие «реакты-шмакты» неприемлемо.
Что-то не нашел я на MDN отметки что в IE 9 работает classList, так что навряд ли там опечатка. Полифил тоже замечательный и его безусловно можно применять (и нужно в случае вашего примера).

Но суть ведь не в этом. Вы написали 2 строчки кода и вам уже понадобился подключить полифил, а что будет на 1000 строках кода? В этом смысле jQuery — это всего лишь набор полифилов на все случае жизни и удобный апи. Лично я в свое время начал использовать jQuery именно потому, что кол-во самописных workaround'ов стало привышать порог терпимости.

Лично для меня использовать jQuery когда есть всякие «реакты-шмакты» неприемлемо.

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

Благо RactiveJS, не смотря на всю его реактивность, вполне себе удачно «дружится» с плагинами jQuery с помощью встроенных в RactiveJS декораторов.
Что-то не нашел я на MDN отметки что в IE 9 работает classList, так что навряд ли там опечатка.
Упс, это моя невнимательность. 8.0 это Chrome, а не IE, даже не знаю почему мне так показалось :D
Оно было нужно во времена палеолита, для абстрагирования от разного поведения браузеров, теперь оно не нужно.
А что, произошла революция и все браузеры стали вести себя одинаково?
В целом тренд такой есть, остальные проблемы решаются полифилами
В достаточной для того степени да.
Не нужно, но полезно, так как у jQuery API более краткий и мощный.

Пример — метод «on».
Я согласен что jQuery можно использовать когда человек понимает как оно работает и когда он может сделать то же самое без jQuery. Но часто бывает что jQuery просто используется, без понимания сути и последствий.
Также, как и фреймворки на php.

А jQuery хотя бы удобный. :)
А jQuery хотя бы удобный. :)
Для своей цели — работы с DOM — да удобный, но не более того.
Мне кажется нет такого веб разработчика, который бы не задумывался об этом)))

так для своей цели он и предназначен. мне понравилась концепция работы с множествами вместо отдельных объектов (ссылка на SQL).

Любопытно, почему разработчики браузеров не скооперировались с разработчиками jQuery чтобы имплементировать в нативе jQuery. Не обязательно дословно переносить, но ведь очевидно, если нативным синтаксисом никто не пользуется, а jQuery пользуются, значит нативный синтаксис нужно выкидывать на помойку (условно, просто пометить как obsolete), и запилить новый jQuery-подобный. Да, в jQuery не все можно сделать, но ведь можно просто jQuery расширить теми вещами, которые в нем нельзя сделать на данный момент…
Sign up to leave a comment.