Javascript Event handling history [closed]

Question

While I do understand Javascript event handling in bits and pieces, I wanted to understand the complete history behind it, like how event handling was actually implemented (may be using it within the markup like <a onClick="callFunc()"> )

And how it later got updated to something else like calling it from JS (unobtrusive JS)

to how it is implemented now using jQuery ?

I just wanted to understand the advantages at each stage and things like event bubbling/capturing, etc

Answer 1

Well, there's not much to it. Or, really, anything that there was to it happened a LONG time ago.

.addEventListener has been around for as long as CSS has. That's how long DOM-Level2 has been with us (~13 years, I think).

It wasn't a question of how JS got more advanced, it was a question of how JS-writers didn't.

Programmers I know, who write JS as a "secondary" or "tertiary" role STILL use inline-handlers. It's been more than a decade since that was a particularly good idea.

As for "unobtrusive", that's not necessarily related directly to event-listeners.
It is, if you intend to interact with a user in any way, but it's more a question of separating concerns, the same way we no longer style elements like <p><font color=red>red text</font></p>.

Perhaps a part of the reason that DOM-0 event-handlers (like button.onclick = function () {}) have hung around so long, and still see very frequent use, is because of the war between Microsoft's attachEvent and W3C's addEventListener.

If you want to support cross-browser events in IE6-8, you're either using jQuery (or another library), you're writing event-management functions by hand, to support both .attachEvent for IE and .addEventListener for everyone else, or you're using event-properties directly (.onclick = function () {}). They have the benefit of being supported by practically every single browser in use today.
They have the detriment of only having one assignable function (which leads to ugly handling if you need to add more of them):

(function () {
    var button = document.getElementById("button"),
        old_func = button.onclick;

    button.onclick = function (e) {
        e = e || window.event;
        doStuff();
        if (old_func) { old_func(); }
    }
}());

...now imagine 8 different programmers adding listeners to the same button that way.

As for bubbling versus capture...
This was never really a battle (post-Netscape).
Microsoft supported bubble, W3C supports both. Nobody really uses capture for anything, because there are very few times you want to know about an event before it actually happens, and before the target even knows it's happening (and because the only way to use capture was to be using addEventListener, which means that your event won't work on IE...)

What jQuery brought to the table wasn't "new" events or "better" events -- what it did was allowed for cross-browser events to be programmed by everyone.
A lot of the AJAX libraries had this as a primary goal: to normalize the differences between addEventListener and attachEvent (which was a solved problem, before jQuery), and between XMLHttpRequest and ActiveXObject("MSXML2.XMLHTTP.6.0"), (again, solved pre-jQuery).

jQuery has just been a crowd-favourite, and Resig has done some good stuff with it (while jQuery users have done some horrible stuff with it, forcing Resig and friends to be super-human to idiot-proof DOM-traversal and event-delegation and the rest).

Some of us have gotten better with event-delegation, and the like, over the past ~6 years, as people like Douglas Crockford and Nicholas Zakas took the reigns of the social-sphere, writing good books and great talks on professional, high-performance JS.

And over the past few years, more people have stepped into design patterns which are seen in other languages which see enterprise-use.

Things like promises/deferreds/futures ($.Deferred/$.when) are the future of JS-engineering, when talking about client-side asynchronous programming for web-apps.

That's not to say that it'll look 100% like it does today, but it IS to say that keeping DOM events straight is a solved problem -- keeping them in-line with all of the async stuff which might happen at any time, in any widget on the page...
...that's where Promises come in handy.

Then you have moderators/observers for keeping inter-module communication safe and decoupled.
These might be "custom-events", or might be "emitters"... ...or "publisher/subscribers".
Things that you can listen to and act on.
They might be triggered by actual browser-events, or they might be triggered in code.

Again, jQuery didn't invent or perfect this, but any event you subscribe to in jQuery is doing one of these things under the hood.

Same with $.ajax -- it's not really using DOM events, it's passing Promises around, which you can subscribe to. The only DOM events it uses are the ones to actually retrieve the data from the server. After that, it's all custom.

In the last few years, we've made huge leaps in terms of what JS can do, and how we handle interaction and asynchronicity.

Little of that has had anything to do with advances in how addEventListener has gotten better, or how jQuery helped us bridge the gap between IE8 and the rest of the browsers.