In the DOM a special event occurs on an <input> or <textarea> element known as the
change event  . The
change event gives a developer the ability to catch input changes. However, it falls short when instant feedback is needed because it will only trigger once the input has lost focus. Immediate feedback could be handled using the
keyup events. Those events are costly (happening often and requires the code to keep state to know of changes actually occurring) and are potentially buggy due to extra logic needed.
With the advent of HTML5’s ubiquity (IE9+) there are new events that solve the input problem. One of them is the
input event  . This event is intended to trigger on input, which delivers immediately after the user takes an action. The event triggers on any change including cut, paste, drag and keyboard interactions. When it works, it simplifies the interactions with forms and text editing.
In the HTML4.01 world, an example app could have a form that wants to show password strength. It’s easy enough to use an
onChange handler, but then the user would only see the meter update once the field loses focus, often by submitting the form. To counter that behavior, an
onKeyup handler is attached to catch the keyboard events as they type. This however means paste events would not fire, or JS value events (like those from a password manager). So it still isn’t going to always work and the
keyup is going to fire for pointless things like cursor movement via arrow keys.
In HTML5 then, the same example is implemented with the single
onInput handler. Each of these cases are handled exactly as expected and when expected. Unless the user is using IE9 which unfortunately does not trigger
onInput during deletion events like backspace, delete, cut or drag  .