Ну, там не так много к нему. Или, действительно, все, что было до этого, случилось долгое время назад.
.addEventListener был около тех пор, пока CSS имеет. Вот как долго DOM-Level2 был с нами (~ 13 лет, я думаю).
Это был не вопрос о том, как JS получил более продвинутый, это был вопрос о том, как JS-писатели не.
Программисты Я знаю, кто пишет JS как «второстепенную» или «третичную» роль STILL использовать inline-обработчики. Прошло более десяти лет, поскольку это была особенно хорошая идея.
Что касается «ненавязчивого», это не обязательно связано непосредственно с прослушивателями событий.
Это, если вы собираетесь каким-либо образом взаимодействовать с пользователем, но это скорее вопрос разделения проблем, так же, как мы больше не стиляем элементы типа <p><font color=red>red text</font></p>.
Возможно, одна из причин, что DOM-0 обработки событий (например, button.onclick = function() {}) вывесили вокруг так долго, и по-прежнему видим очень частое использование, из-за войны между Microsoft, attachEvent и W3C в addEventListener.
Если вы хотите поддерживать кросс-браузерные события в IE6-8, вы используете jQuery (или другую библиотеку), вы вручную создаете функции управления событиями, чтобы поддерживать как .attachEvent для IE, так и .addEventListener для все остальные, или вы непосредственно используете свойства события (.onclick = function() {}). Они пользуются поддержкой практически всех браузеров, используемых сегодня.
Они имеют ущерб только имея одну назначаемую функцию (что приводит к уродливым обработке, если вам нужно добавить больше из них):
(function() {
var button = document.getElementById("button"),
old_func = button.onclick;
button.onclick = function (e) {
e = e || window.event;
doStuff();
if (old_func) { old_func(); }
}
}());
... А теперь представьте себе 8 различных программистов добавления слушателей к той же кнопке, путь.
Что касается барботирования против захвата ...
Это никогда не было битвой (пост-Netscape).
Поддерживаемый Microsoft пузырь, W3C поддерживает оба. Никто на самом деле не использует захват для чего-либо, потому что очень мало раз вы хотите узнать о событии, прежде чем оно на самом деле произойдет, и до того, как цель даже знает, что это происходит (и поскольку единственный способ использовать захват должен был использовать addEventListener, что означает что ваше мероприятие не будет работать в IE ...)
Какой jQuery, представленный на столе, не был «новым» событием или «лучшими» событиями - то, что он сделал, разрешалось для каждого браузера для каждого события.
Много библиотек AJAX было это в качестве основной цели: нормализовать различия между addEventListener и attachEvent (которая была решена проблема, прежде, чем JQuery), а также между XMLHttpRequest и ActiveXObject("MSXML2.XMLHTTP.6.0"), (опять же, решил предварительно JQuery).
jQuery только что был любимцем толпы, и Resig сделал с ним что-то хорошее (в то время как пользователи jQuery сделали с ним некоторые ужасные вещи, заставив Resig и друзей быть супер-человеческими до идиотского DOM-обхода и делегирование событий, а остальное).
Некоторые из нас стали лучше с делегацией событий и т. П. В течение последних 6 лет, поскольку люди, подобные Дугласу Крокфорду и Николаю Закасу, занимали правление социальной сферы, пишут хорошие книги и великие беседы о профессиональный, высокопроизводительный JS.
И за последние несколько лет больше людей вступили в дизайн шаблонов, которые видны на других языках, которые видят использование предприятия.
Вещи, подобные обещаниям/отсрочкам/фьючерсам (/$.when) - будущее JS-engineering, когда речь идет о асинхронном программировании на стороне клиента для веб-приложений.
Это не означает, что он будет выглядеть на 100%, как сегодня, но это означает, что поддержание прямых событий DOM является решаемой проблемой - поддержание их в соответствии со всеми асинхронными вещами, которые могут произойти в любой момент, в любом виджетах на странице ...
... вот где обещания пригождаются.
Затем у вас есть модераторы/наблюдатели для обеспечения безопасности и развязки межмодульной связи.
Это могут быть «персонализированные события» или «эмитенты» ... ... или «издатель/подписчики».
Вещи, которые вы можете слушать и действовать.
Они могут быть вызваны действительными событиями браузера или могут быть вызваны в коде.
Опять же, jQuery не изобретал и не совершенствовал это, но любое событие, которое вы подписываете в jQuery, делает одну из этих вещей под капотом.
То же самое с $.ajax - на самом деле это не используется с событиями DOM, оно проходит Promises вокруг, на которое вы можете подписаться. Единственными DOM-событиями, которые он использует, являются те, которые фактически извлекают данные с сервера. После этого все это обычае.
В последние несколько лет мы совершили огромные прыжки с точки зрения того, что может сделать JS, и как мы обрабатываем взаимодействие и асинхронность.
Немного из того, что имело какое-либо отношение к достижениям в том, как addEventListener стал лучше, или как jQuery помог нам преодолеть разрыв между IE8 и остальными браузерами.
Вы просите небольшую диссертацию. Я думаю, вам нужно сделать свой вопрос гораздо более кратким и сосредоточенным, чтобы один человек мог ответить в разумном размере, чтобы соответствовать формату Q & A StackOverflow. Какие любопытные вещи вам нужно знать? – jfriend00
Я просто пытаюсь понять, как механизм обработки событий Javascript эволюционировал с годами, а именно, как фреймворк вроде jQuery изменил способ обработки событий. Какие улучшения он привнес в таблицу? – testndtv
[Quirksmode.org имеет очень хорошее представление о событиях] (http://quirksmode.org/js/introevents.html), который охватывает большинство ваших вопросов. – Bergi