By the time jQuery 1.7 arrived, event handling was already a major part of day-to-day front-end development. Clicks, form submissions, hover states, Ajax updates and dynamic content all relied on events, and most projects had plenty of them.
The problem was not that adding an event listener was difficult. The problem was that event code could become scattered across a project very quickly. A click handler here, a delegated event there, a plugin adding its own behaviour somewhere else. After enough additions, it was no longer obvious which code owned which interaction.
The introduction of .on() felt useful because it gave event handling a more consistent shape. Instead of several different methods for related behaviour, there was a clearer pattern for direct and delegated events.
Why Event Code Needed Tidying
On a static page, direct event binding was usually fine. The element existed when the page loaded, the event was attached and the behaviour stayed in place. Dynamic interfaces made that less reliable. If content was replaced after an Ajax request, direct listeners on the old elements disappeared with the old DOM.
Delegated events helped because the listener could sit on a stable parent element and respond to matching elements inside it. That pattern became easier to explain and repeat when the API became more consistent.
$('.results').on('click', '.result-link', function (event) {
event.preventDefault();
console.log('Result clicked');
});The Maintenance Benefit
The benefit was not only technical. It made event ownership easier to think about. If a results area owned the behaviour for result links, the event binding could live close to that module. That made the code easier to find when the interface changed later.
This became more important as websites started to feel more application-like. More elements were being added after page load, and more behaviour depended on the state of the interface. Event handling needed to be predictable rather than scattered.
Still Easy To Overuse
A cleaner event API did not remove the need for restraint. It was still possible to bind too much to the document, create broad selectors or let unrelated behaviours pile into one file. The syntax made things easier, but it did not make the structure automatic.
The useful part was not simply replacing older methods with .on(). It was using the opportunity to make event handling easier to follow, especially on pages where the DOM changed after the first load.