Without UI events we’d be totally lost on the client-side — it is only via User Interface Events that we can know what the user wants to do. User-initiated events such as “click”, “mouseover” and “mousemove” are absolutely essential to upholding a user-centred experience and I want to make it clear that my quarrel is not with these types of events. Any event that gives us information about users’ intentions is a good event.

I feel that there are bad events too though — events that we feel we must utilise just because they exist — and we feel we must build into our APIs just because event-driven design dictates absolute submission to this way of thinking.

DOM mutation events

Every single time I’ve ever considered using a DOM-mutation event I’ve subsequently discovered that the problem can be better solved by re-architecting the codebase. The DOM2 mutation events aren’t well supported in less capable browsers but offer an interesting opportunity — to listen for document mutation such as attribute changes, node insertion and node removal.

This sounds cool and I’m sure your mind was buzzing with ideas when you first heard about these events, but have you actually encountered a situation where utilising these events is the only viable solution? If so, I’d love to hear it.

Programmatic events

This is where I lose all sense of comprehension. The premise is a mechanism that allows you to be notified when changes occur to your program — i.e. your objects, arrays and functions. I’m talking about the likes of Object.prototype.watch, IE’s onPropertyChange and a tonne of other new implementations (e.g.) that seem to perpetuate a dangerous disconnect of cogs that should be working together.

It seems pointless — it’s akin to starting your car, and then being notified by the car that you just started the car… an entirely redundant notification.

var a = abstraction.Array(1,2,3);
// > Abstraction says: "You just changed the array"
// > Me says: "OH RLY"

Left hand, meet right hand!

Events exist so that processes outside the scope of your code can communicate with your code and let you know when certain things occur. Events typically operate up the abstraction chain — you listen for events from lower-level abstractions. I feel that the “outside the scope of your code” aspect is central to the whole concept of events and is why they make so much sense in a browser-scripting environment. The browser listens to events from the operating system and forwards certain events to the DOM where we can listen for them. It’s a simple fluid concept that works!

There’s a lot of hype surrounding event-driven programming/design at the moment and it seems that we’re approaching a risky threshold, where events are used just because they can be, and not because they should be.

If you’re creating an app, and it requires a great deal of client-side functionality, then you’re going to need to interface with the DOM to listen for events and apply certain changes. This is what JavaScript is all about. You write the logic layer of code (your own personal API) and then you write the implementation code that utilises the logic layer. You have authored two distinct layers of abstraction. That’s pretty much the gist of what we do.

What’s approaching, it seems, is an era of haphazard juggling of third-party scripts, multiple abstractions, multiple APIs and consequently, dozens of events. No need to write a consistently encapsulated logic layer — you can just bung these plugins/modules/classes into the app… To heck with maintenance, clean and consistent abstractions, intuitive APIs, self-documenting code and all sense of originality.

I’m not questioning events in general, and I will admit that they can be very helpful to make two scripts work together, but as I mentioned, I feel there’s a threshold where it becomes simply foolish…

Thanks for reading! Please share your thoughts with me on Twitter. Have a great day!