Good article but one thing to be careful of here is that if you just apply this pattern everywhere then you can end up in a situation where every view is decoupled from every other view and there are way more events in the system than there need to be. This happens more frequently than you would think.
In the example given of a date picker this is fine as you can easily see that you might want to re-use the date picker somewhere else. But there are often circumstances where a subview could never be re-used outside of it's parent view. For example suppose I have a main calendar view with subviews showing appointments. The subviews need to inform the main view when the user changes an appointment time so that the main view can re-layout all the subviews.
In this case there is no need for the main view to listen for events from subviews. The code will be much simpler and easier to debug if the subview just makes a call to the main view directly (the subview should be constructed with a pointer to the main view). When I look at code in the subview I don't have to guess who may be listening to the event, I can see the call directly. It also means that other views apart from the main view cannot randomly listen sub-view events as a 'quick fix' for some bug.
The point is that javascript tends to lead one down an event driven route. But you should only use events if you want to decouple things. Cohesion is also very important in design because it makes things simpler and more encapsulated. You need to decide what the boundaries of your component are. In this case I want the calendar to be the component, not it's subviews. So within the calendar I will make direct function calls, there are less events in the system and it is easier to think about and debug.
But suppose you want to re-use the sub-view in another component, you would then need to clone the functionality and satisfy/remove all the directly coupled invocations.
This is where you have to decide how much coupling to introduce to balance comprehension vs future needs of the project
indeed, it's a matter of juggling competing maintainability considerations and there are cases where it can make sense to couple components tightly.
that said, in practice our UIs contain relatively few one-off components, and it often requires less dev friction simply to use the standard event pattern than to weigh borderline cases to shave off a little indirection at the cost of tighter coupling. the problem of "too many events in the system" is avoided by letting complicated components handle events from their own subviews and not just blindly bounce everything down to a global mediator. e.g. if no other views have to know about the 4 dropdowns and slider within MyWidget (and they usually don't), then MyWidget can handle all those subview events itself and simply present a single unified 'i've been updated' event for other consumers. essentially narrow the public apis between different actors in the overall system.
The point is that javascript tends to lead one down an event driven route. But you should only use events if you want to decouple things. Cohesion is also very important in design because it makes things simpler and more encapsulated. You need to decide what the boundaries of your component are. In this case I want the calendar to be the component, not it's subviews. So within the calendar I will make direct function calls, there are less events in the system and it is easier to think about and debug.