We'll respond shortly.
We’ll come to ElementalJS a little later but first I wanted to describe the problem it’s trying to solve.
The listeners and callbacks pattern works well for small applications where the entire file fits on your screen. After that it can be difficult to track down where the handlers are for certain events. It can be even more difficult when trying to debug in a browser console when you’re trying to find the handler for that interaction in question.
This approach tries to embrace the simplicity of binding listeners to DOM events but tries to organise it in such a way to make it scalable and maintainable as the client side code grows.
Here instead of the script looking and binding to events across the whole DOM, an element is passed to a function where it can work on a local scale. There will still be listeners, but with the scope of the parent element the functions will be more tightly focused.
By adding a behaviour through the markup, this means that when looking at some HTML, you can see the behaviours that have been loaded for a particular element and it’s children. This can be useful when attempting to find a callback from a DOM action as typically there will be behaviours wrapped around the HTML.
In a Rails project, or something which supports an asset pipeline, these behaviours are best suited to single files per behaviour. Naming a file the same as the behaviour name also increases discoverability in a codebase. For example, the Foo.Bar behaviour is located in foo/bar.js.
Spaghetti code perhaps, but sort of like finding a message within your alphabetti spaghetti.
The section on separation of concerns on Wikipedia covers this concern well. This pattern is quite clearly encouraging the use of putting behaviour into the presentation which is shown to reduce maintainability. So what’s different this time around?
Using this pattern we are not expressively stating what events to fire upon (e.g. onclick or onchange), we are just defining a behaviour that wraps this element. One of the concerns addressed in the separation of concerns section in the Wikipedia article is ease of development but by defining small behaviours they can be easily separated into their own files, have more of a single responsibility and therefore should be easier to test.
What about unobtrusive HTML?
You can use this right now by using ElementalJS. You can either download the source, or if you’re using Rails theres a handy gem which wraps the file and puts it straight into your asset pipeline. Check out more over at the ElementalJS repository.