Чтобы пояснить, чем она нас привлекает в эпоху Node и ES6 (у нас в ассортименте и этого добра навалом) предлагаем познакомиться со статьей Коди Линдли, вышедшей вскоре после вышеупомянутого третьего издания
Поскольку давно не утихают разговоры о ненужности jQuery, я буквально не могу избавиться от мысли, что мы забыли основную ценность jQuery. Время о ней напомнить.
В этой статье хотелось бы всем еще раз рассказать, что же такое jQuery, поскольку сегодня она не менее актуальна, чем на момент появления. Вопрос о ее важности нужно соотнести с исходным назначением всего этого решения (то есть, самого API jQuery), а не с браузерными багами или недостающими возможностями. Если исходить из чего-то другого, то мы рискуем встать на позиции, с которых бракуется любая абстракция, которая может быть не абсолютно необходимой, но, все-таки, мощной и полезной.
Прежде чем я начну пылко отстаивать честь jQuery, давайте вернемся к ее истокам, чтобы всем стало понятно, «что» такое jQuery, и «зачем» она нужна.
Что такое jQuery?
jQuery – это библиотека JavaScript (т.e., она написана на JavaScript), предназначенная для абстрагирования, выравнивания, исправления и упрощения скриптинга при работе с узлами HTML-элементов в браузере или для работы в браузере без графического интерфейса.
Итак:
- Абстрагируется интерфейс объектной модели документа (он же DOM API).
- Выравниваются все различия реализаций DOM, существующие между браузерами.
- Исправляются известные браузерные баги, связанные с CSS и DOM.
Все это оборачивается в более простой и менее корявый API, нежели нативный API DOM – вот вам и библиотека jQuery.
Теперь позвольте объяснить, что я понимаю под “скриптингом HTML-элементов”. При помощи jQuery совершенно тривиально решаются задачи вроде «визуально скрыть второй элемент
h2 в документе .html. Код jQuery для такой задачи выглядел бы так:jQuery('h2:eq(1)').hide();Давайте немного разберем эту строку с кодом jQuery. Сначала вызывается функция
jQuery(), ей мы передаем специальный CSS-селектор библиотеки jQuery, выбирающий второй элемент h2 в HTML-документе. Затем вызывается метод jQuery.hide(), скрывающий элемент h2. Вот как прост и семантически выразителен код jQuery.Теперь сравним его с нативным DOM-кодом, который потребовалось бы написать, если бы мы не работали с jQuery.
document.querySelectorAll('h2')[1].style.setProperty('display','none');Какой вариант было бы удобнее написать? А читать, а отлаживать? Также учтите, что вышеприведенный нативный DOM-код предполагает, что все браузеры поддерживают использованные здесь методы DOM. Однако оказывается, что некоторые старые браузеры не поддерживают
querySelectorAll() или setProperty(). Поэтому вышеприведенный код jQuery вполне нормально работал бы в IE8, а нативный код DOM вызвал бы ошибку JavaScript. Но, все-таки, даже если бы обе строки кода работали повсюду, какую из них было бы проще читать и писать? Имея дело с jQuery, можно не беспокоиться о том, какой браузер что поддерживает, либо какой DOM API в каком браузере может забарахлить. Работая с jQuery, вы сможете работать быстрее решать задачи на более простом коде, и при этом не беспокоиться, так как jQuery абстрагирует за вас многие проблемы.
jQuery = JavaScript?
Поскольку jQuery повсеместно распространена, то вы, возможно, не вполне представляете, где заканчивается JavaScript и начинается jQuery. Для многих веб-дизайнеров и начинающих разработчиков HTML/CSS, библиотека jQuery — это первый контакт с языком программирования JavaScript. Поэтому jQuery иногда путают с JavaScript.
Первым делом давайте оговоримся, что JavaScript – это не jQuery и даже не сам DOM API. jQuery – это сторонняя свободная библиотека, написанная на JavaScript и поддерживаемая целым сообществом разработчиков. Кроме того, jQuery не относится к числу стандартов тех организаций (напр., W3C), которые пишут спецификации HTML, CSS или DOM.
Не забывайте, что jQuery служит прежде всего как «сахар» и используется поверх DOM API. Этот сахар помогает работать с интерфейсом DOM, который печально известен своей сложностью и обилием багов.
jQuery – это просто полезная библиотека, которой можно пользоваться при написании сценариев для HTML-элементов. На практике большинство разработчиков прибегают к ней при DOM-скриптинге, поскольку ее API позволяет решить больше задач меньшим количеством кода.
Библиотека jQuery и ее плагины используются разработчиками так широко, что такой код часто нахваливают как самые востребованные сценарии во всем Вебе.
Два краеугольных камня jQuery
Две базовые концепции, на которых основана jQuery, таковы: “найди и сделай” и “пиши меньше, делай больше.”
Две этих концепции можно развернуть и переформулировать в виде следующего утверждения: первоочередная задача jQuery заключается в организации выбора (то есть, нахождении) или в создании HTML-элементов для решения практических задач. Без jQuery для этого потребовалось бы больше кода и больше сноровки в обращении с DOM. Достаточно вспомнить рассмотренный выше пример с сокрытием элемента
h2.Следует отметить, что круг возможностей jQuery этим не ограничивается. Она не просто абстрагирует нативные DOM-взаимодействия, но и абстрагирует асинхронные HTTP-запросы (т.н. AJAX) при помощи объекта XMLHttpRequest. Кроме того, в ней есть еще ряд вспомогательных решений на JavaScript и мелких инструментов. Но основная польза jQuery заключается именно в упрощении HTML-скриптинга и просто в том, что с ней приятно работать.
Еще добавлю, что польза jQuery – не в успешном устранении браузерных багов. «Краеугольные камни» нисколько не связаны с этими аспектами jQuery. В долгосрочном отношении самая сильная сторона jQuery заключается в том, что ее API абстрагирует DOM. И эта ценность никуда не денется.
Как jQuery сочетается с современной веб-разработкой
Библиотеке jQuery уже десять лет. Она создавалась для той эпохи веб-разработки, которую мы уже безусловно миновали. jQuery не является незаменимой технологией для работы с DOM или выполнения асинхронных HTTP-запросов. Практически все, что можно сделать с jQuery, можно сделать и без нее. А если вас интересует всего лишь пара мелких простых взаимодействий с DOM в одном-двух современных браузерах, то возможно, лучше будет воспользоваться нативными DOM-методами, а не jQuery.
Однако, при любых разработках, связанных с BOM (браузерной моделью документа) или DOM, а не только с косметическими взаимодействиями, следует пользоваться jQuery. В противном случае вы станете изобретать велосипед (т.e. элементы абстракций jQuery), а потом испытывать его на всевозможных дорожках (т.e в мобильных браузерах и браузерах для ПК).
Опытные разработчики знают, что такое «стоять на плечах гигантов», и когда следует избегать излишней сложности. В большинстве случаев нам все равно не обойтись без jQuery, когда нужно в сжатые сроки выполнить нетривиальную работу, связанную с HTML и DOM.
Кроме того, даже если бы jQuery не решала ни единой проблемы с DOM или с разношерстными браузерными реализациями спецификации DOM, важность самого API ничуть бы не уменьшилась, поскольку он так удобен для HTML-скриптинга.
Причем jQuery совершенствуется, и с ее помощью программисты могут работать толковее и быстрее. Такова ситуация сегодня, так было и на момент создания библиотеки. Сказать «мне не нужна jQuery» — все равно, что утверждать «обойдусь без lo-dash или underscore.js». Разумеется, можно без них обойтись. Но об их ценности судят не по этому.
Их ценность — в API. Из-за излишней сложности разработка может замедляться. Поэтому нам и нравятся такие вещи как lo-dash и jQuery – с ними все упрощается. А поскольку jQuery облегчает выполнение сложных задач (например, писать сценарии для HTML), она не устареет.
Если вы по-прежнему сомневаетесь, нужна ли jQuery в современной веб-разработке, предлагаю посмотреть следующую презентацию от одного из разработчиков библиотеки, где он обосновывает ее нужность безотносительно наворотов современных браузеров.
Приложение – важные факты об jQuery
Наконец, перечислю некоторые важные факты, касающиеся jQuery.
- Библиотеку jQuery написал Джон Резиг (John Resig), ее релиз состоялся 26 августа 2006. Джон признавался, что написал этот код, чтобы “произвести революцию во взаимодействии JavaScript с HTML”.
- jQuery считается наиболее популярной и востребованной современной библиотекой JavaScript.
- jQuery – свободное ПО, предоставляемое по лицензии MIT.
- Существует две версии jQuery. Версия 1.x поддерживает Internet Explorer 6, 7 и 8\, а 2.x поддерживает только IE9+. Если вам требуется поддержка IE8, то придется работать с версией 1.x. Но это нормально, обе версии по-прежнему активно разрабатываются.
- Минимальная версия jQuery 2.x имеет размер 82kb. В архиве Gzip — около 28k.
- Минимальная версия jQuery 1.x имеет размер 96kb. В архиве Gzip — около 32k.
- Исходный код jQuery доступен на Github.
- На основе исходного кода с Github можно создать собственную версию jQuery.
- jQuery можно установить при помощи менеджера пакетов bower или npm (т.e.
$ bower install jquery or npm install jquery). - У jQuery есть официальная сеть CDN, в которой можно взять различные версии jQuery.
- jQuery имеет простую архитектуру на основе плагинов, поэтому любой желающий может добавлять в нее собственные методы.
- jQuery обладает обширным набором плагинов. Можно приобрести высококачественные плагины для enterprise-разработки (напр. Kendo UI) или воспользоваться не менее классными бесплатными (напр. Bootstrap).
- jQuery можно разбить на категории (в соответствии с разбиением документации API ).
- ajax
- attributes
- callbacks object
- core
- CSS
- data
- deferred object
- dimensions
- effects
- events
- forms
- internals
- manipulation
- miscellaneous
- offset
- properties
- selectors
- traversing
- utilities
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (63)
Zenitchik
19.08.2016 18:26+8По jQuery масса сведений в Интернете, дорогая книга ни к чему
Я даже больше скажу: всё, что необходимо знать о jQuery можно прочитать на официальном сайте jQuery. Причём, написано там хорошо: я, никогда не изучавший английский, а только нахватавшийся в интернете слов, уверенно понимаю документацию.
kykint
19.08.2016 19:02+7Существует две версии jQuery
Я может быть уже в будущем, но как же jQuery 3.0 и 3.1?ollisso
19.08.2016 21:16+6Только из вашего комментария узнал что появились новые версии jQuery.
zooks
20.08.2016 00:41+2А я из вашего о вашем существовании :)
Не нужно хоронить jQuery раньше времени.ollisso
20.08.2016 15:59+1Кто же его хоронит? Наоборот считаю что он живее всех живых.
Скорее Реакт умрёт чем jQuery, хотя и даже в этом случае — уйдут годы. :)
Просто удивительно — вроде бы и смотрю новостные источники каждый день, но нигде небыло анонса что jQuery обновился.
VolCh
19.08.2016 19:46-6Больше всего бесит не сам факт использования, а использование либо наряду с другими абстракциями над DOM, либо наряду с прямой работой с DOM.
PerlPower
19.08.2016 21:32+4Как узнать что веб-технология устарела? Про нее написали бумажную книгу.
Как узнать, что книга по технологии устарела?Книга существует.Эту книгу начинают рекламировать на хабре.
DmitryKoterov
19.08.2016 21:37-6Я прошу прощения, но какой jQuery, React же на дворе. Причем даже не столько React как конкретный инструмент, сколько React как новая и прорывная концепция построения клиент-сайда (например, у Angular соответствующая часть базируется на похожих принципах).
dom1n1k
19.08.2016 21:59+11Рекомендую иногда выглядывать в реальный мир. Это примерно как сказать — «простите, но какой бензин? ведь Тесла уже...»
karser
19.08.2016 22:48Так выгляните, тренд AngularJS через год настигнет JQuery.
dom1n1k
19.08.2016 22:54+8И что? Не достиг же ещё.
Но главное в другом — а зачем их вообще противопоставлять?
DenimTornado
19.08.2016 23:04+15Это нынче модно) Реакт, Ангуляр… Кто-то кричит как это круто и как всякие Жиквари плохо и прошлый век. А кто-то делает качественный приложения и выбирает в каждом конкретном случае наиболее подходящую технологию.
karser
19.08.2016 23:22-6Здесь разница декларативного/императивного подхода.
P.S: Это такой тонкий троллинг с вашей стороны?
dom1n1k
19.08.2016 23:30+7Я реально не понимаю, что вы мне пытаетесь доказать.
Ничего не имею против Ангуляра, Реакта и ещё кучи всего, но всё это не отменяет того медицинского факта, что jQuery держит свою рыночную нишу и успешно решает проблемы тысяч людей. И доля этой ниши хоть и снизилась в последнее время, всё равно ещё очень велика и ещё долго останется таковой.
G-M-A-X
20.08.2016 15:40А так:
https://www.google.com/trends/explore?q=jQuery,AngularJS,%2Fm%2F012l1vxv
?
https://habrahabr.ru/post/308148/
Trixon
21.08.2016 22:54Не удивительно, что хипстота из хэлооувордщиков сразу бросается в тренд, который затем ещё и растет.
LifeKILLED
20.08.2016 08:41+2Вот именно, что React — это в корне новый подход, ради него придётся все старые сайты переделывать.
Чтобы добавить красивую анимашку на классический портал, JQuery — идеальный вариант (хотя сейчас актуальнее анимашки в CSS, влияние JQuery можно свести к минимуму)dom1n1k
20.08.2016 14:01+4Если посмотреть крутые, качественные карусели и им подобные вещи, то они практически все до сих пор на jQuery. Хотя чисто технически их уже вполне можно наваять на ванильном JS.
Я как-то спросил у автора одной такой библиотеки, а не хочет ли он избавиться от jQuery-зависимости. Он ответил мне буквально следующее: «это большие и ничем не оправданные трудозатраты».
Потому что для всяких просто сайтов jQuery по-прежнему стандарт де-факто. Уж очень большая экосистема накопилась. Это просто, это удобно. Это дает хорошую кроссбраузерность. Это может поправить-дописать любой фрилансер. Не нужно разворчивать адовое рабочее окружение, чтобы вставить какой-нибудь новый слайдер.
Вот для сложных веб-приложений — да, нужно использовать что-то более прогрессивное.
Dimensi
20.08.2016 10:54Что React, что Angular это же framework'и, а jQuery библиотека, как это вообще можно сравнивать?
DmitryKoterov
20.08.2016 13:03-2Напрямую их не нужно сравнивать, верно. Штука в том, то 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-подход — это язык высокого уровня. Такие аналогии.dom1n1k
20.08.2016 14:11+5А реальная практика такова.
В мире есть миллионы «просто сайтов» — не приложений, а сайтов с менюшкой, страничками и статьями. И туда нужно добавить, например, слайдер, чтобы фоточки перелистывал. Подключается jQuery, несколько строк кода, немного возни со стилями, и оно работает. Это может сделать очень недорого любой фрилансер буквально в блокноте и браузере.
Теперь новые фреймворки. Поставь и настрой ноду, gulp, babel, webpack и далее по списку. Зачем это всё в вышеописанном случае?! Если разрабатывается серьезное веб-приложение — вопросов нет. Но для простых случаев это просто никому не нужный геморрой, который никто не хочет оплачивать.
Finesse
20.08.2016 01:50Зачем вы усложняете код примера? Достаточно написать так:
document.querySelector('h2').style.display = 'none';
И этот код прекрасно работает в IE8.
PavlovM
20.08.2016 06:49style.display — да, конечно, намного лучше.
Но там речь шла о втором элементе h2, так что таки querySelectorAll('h2')[1]
vitnibel
20.08.2016 10:54В примере нужно убрать не первый элемент h2 а второй, поэтому вот так:
document.querySelectorAll('h2')[1].style.display = 'none';
и согласитесь что уже и не так элегантно и просто это выглядит как в jQuery.Finesse
20.08.2016 10:56Согласен, я это даже не пытался оспорить. Ничего не имею против jQuery как таковой. Применимость jQuery зависит от задачи.
ya-est
20.08.2016 11:44-1А так?
document.querySelector('h2:nth-child(2)').style.display = 'none';DenimTornado
20.08.2016 13:36+1А так, вы выберите h2 элемент, если он является вторым ребёнком внутри родителя и уж точно не второй из коллекции h2 элементов.
LifeKILLED
20.08.2016 08:34-2Я голосовал за бумажную книгу, т.к. сам люблю именно бумажные книги. По мне, инфа быстре усваивается, когда есть просто бумага, когда нет отвлекающих факторов в виде всяких извещений-оповещений и просто заманчивых иконок. Чем больше хороших книг, тем лучше.
Хотя сам я JQuery уже пользовался, тупо нашёл примеры на форумах и впилил на сайт :) В этом плане всё легко и понятно (JQuery для простоты-интуитивности, видимо, и создан). А глубже копать неохота, есть куча готовых библиотек, в которых достаточно только стили сменить. Так что сам покупать книги по JQuery не стану.
Alexufo
20.08.2016 12:04+3Не забывайте, что есть куча форков JQuery совместимых специально урезанных библиотек без редкоиспользуемых функций.
Например, http://zeptojs.com — 10kb в gzip. Это если там «ну зачем тянуть слона ради...»dom1n1k
20.08.2016 14:04К огромному сожалению, далеко не все jQuery-плагины из коробки заводятся с Zepto. А ведь в плагинах там основной смысл.
Сейчас вот не помню точно, но кажется Owl Carousel мне удалось подружить с Zepto небольшой доработкой напильником. А вот ту же Фотораму — не получилось, уж слишком много там накручено внутри.
kykint
20.08.2016 23:30Используйте jquery.slim ( https://jquery.com/download/#jquery ) — в чем проблема то?
bioforge
20.08.2016 12:11+2Нативная работа с 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') }
alex_blank
20.08.2016 16:54+1Я в одном из своих проектов отказался от jQuery именно по той причине, что он «проглатывал» ошибки доступа. Это только для спагетти-проектов подходит.
То есть, если я вижу в коде, что
if (h2)— это подразумевает, что возможна такая ситуация, когда h2 не будет. И стоит задаться вопросом — почему. На самом деле, это исключение, а не правило. JQuery же возводит в абсолют такой паттерн — подразумевая, что элемента, с которым мы работаем, может не быть.
Это так же неправильно, как если бы язык программирования не выбрасывал null pointer exception при доступе к несуществующему свойству, а молча это проглатывал. Вы бы тогда охренели отлаживать код, потому что совершенно непонятно было бы, почему он не работает — хотя делает вид что работает.
Radiocity
20.08.2016 16:59+1Разработка не должна сводиться лишь к нахождению решения попроще. Основное условие успеха — это наличие логики и аргументации при выборе правильного инструментария.
Например, jQuery имеет большую базу готовых решений, охватывает широкий спектр браузеров, приводит код к единому синтаксису. Однако, использует для обработки селекторов библиотеку Sizzlejs (а там не один десяток условных операторов), значительно замедляет производительность в проекте. Необходимо поддерживать ie8 (вполне реальное требование), следовательно нет смысла писать костыли, потому что это потребует много трудочасов на тестирование и внедрение. Выбор очевиден.Пикачу.
samizdam
20.08.2016 13:08+1В своё время пользовался этой книгой, изданием 2009 года, Символ-Плюс.
Хорошее пособие, на тот момент реально помогло разобраться в предмете.
Об актуальности её сейчас, судить не буду, т.к. благополучно ушёл из зоопарка в сторону бэк-енд, чему тихо радуюсь.
monolithed
20.08.2016 16:49+3<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?
Безусловно, что можно придумать какой-нибудь метаязык, который и такую запись сократит до минимального набора символов, но зачем…
PaulMaly
21.08.2016 22:31А теперь напишите это с поддержкой ослика)) Хотя бы 9+. И вы с удивление обнаружите, что код уже не так красив и лаконичен.
monolithed
22.08.2016 23:22+1Не вижу причин чтобы этот код не работал в IE9.
PaulMaly
23.08.2016 15:37Ну ну )))) Can I use classList
PaulMaly
23.08.2016 15:43Другое дело, используя реактивные библиотеки для клиентского рендеринга, прямая работа с DOM вообще отсутствует и тогда можно писать что-то вроде ( RactiveJS ):
<div class="foo {{ isVisible && 'bar' }}"> <div>1</div> <div>2</div> </div>
$$el.toggle('isVisible');
Но это уже совсем другая история…monolithed
23.08.2016 17:26Хм. значит на MDN некорректная информация. Но это не так важно, ведь есть достойный полифил.
В любом случае, если разработчик по каким-то причинам предпочел выбрать стандартное API (пусть даже с полифилами), а не jQuery, то наверняка на это есть причины. А какие причины это уже другой вопрос. Это может какой-то движок селекторов, виджет или какая-то другая задача где требуется высокая производительность выборки.
Лично для меня использовать jQuery когда есть всякие «реакты-шмакты» неприемлемо.PaulMaly
23.08.2016 17:52Что-то не нашел я на MDN отметки что в IE 9 работает classList, так что навряд ли там опечатка. Полифил тоже замечательный и его безусловно можно применять (и нужно в случае вашего примера).
Но суть ведь не в этом. Вы написали 2 строчки кода и вам уже понадобился подключить полифил, а что будет на 1000 строках кода? В этом смысле jQuery — это всего лишь набор полифилов на все случае жизни и удобный апи. Лично я в свое время начал использовать jQuery именно потому, что кол-во самописных workaround'ов стало привышать порог терпимости.
Лично для меня использовать jQuery когда есть всякие «реакты-шмакты» неприемлемо.
Последние года 3 я использую RactiveJS как основу для построения изоморфных веб-приложений. Но и для JQuery все еще остается место, потому что за годы его популярности на его основе написано очень много крутых плагинов и другого добра, которые никто переписывать не будет, а не использовать их глупо.
Благо RactiveJS, не смотря на всю его реактивность, вполне себе удачно «дружится» с плагинами jQuery с помощью встроенных в RactiveJS декораторов.monolithed
23.08.2016 18:14+1Что-то не нашел я на MDN отметки что в IE 9 работает classList, так что навряд ли там опечатка.
Упс, это моя невнимательность. 8.0 это Chrome, а не IE, даже не знаю почему мне так показалось :D
serf
21.08.2016 00:41Оно было нужно во времена палеолита, для абстрагирования от разного поведения браузеров, теперь оно не нужно.
molnij
21.08.2016 02:01+1А что, произошла революция и все браузеры стали вести себя одинаково?
Mithgol
22.08.2016 02:13Не нужно, но полезно, так как у jQuery API более краткий и мощный.
Пример — метод «on».serf
22.08.2016 12:28Я согласен что jQuery можно использовать когда человек понимает как оно работает и когда он может сделать то же самое без jQuery. Но часто бывает что jQuery просто используется, без понимания сути и последствий.
PsyHaSTe
22.08.2016 14:53Любопытно, почему разработчики браузеров не скооперировались с разработчиками jQuery чтобы имплементировать в нативе jQuery. Не обязательно дословно переносить, но ведь очевидно, если нативным синтаксисом никто не пользуется, а jQuery пользуются, значит нативный синтаксис нужно выкидывать на помойку (условно, просто пометить как obsolete), и запилить новый jQuery-подобный. Да, в jQuery не все можно сделать, но ведь можно просто jQuery расширить теми вещами, которые в нем нельзя сделать на данный момент…
EtnoLover
Спасибо за ссылку на презентацию разработчика jQuery.