What's cool, I think, is the chaining of predicates. That's useful in general, and should be a totally different library.
eg. jQuery('a#click-me').click(function(){ $(this).text('Clicked!') })
... there's a lot of cognitive work going on here. Not only am I parsing javascript, as a coder, I'm parsing the CSS of the selector, and creating a mental model of the anonymous function. It's not to say that this is necessarily a bad thing, just that there's a lot of extra syntax to handle.
whenever("Click Me!").is('clicked').then('change it to "clicked"')
...reads without all of the extra syntax, but it still remains valid javascript.
> you'd have to look at three different places to understand what the code is _actually_ doing
This is a fair point, but I would argue that for most code you read, there's typically nowhere to go to find out the _intent_, which for me is really the most important thing. I think it's fascinating to be able to have "executable intent" ...
... but since I don't really have any real world experience using this, I can't really back up my arguments with any real data ... just the motivations I had to write this!
whenever("Click Me!").is('clicked').then('change it to "clicked"')
var cbs = {};
cbs.setClickedText = function() { $(this).text('Clicked!'); };
$('a#click-me').click(cbs.setClickedText);In eyeballs.js, for examples, I explored doing all of the binding via the html elements themselves, eg:
<a href="#" data-bind="posts#new">New Post</a>
which would map to a pre-defined posts controller new action.
whenever.js is just another exploration along the same theme. Again, I'm not arguing that it's better or worse: just my motivations for making it.
No thanks.
The other benefit is the documentation (in DSL form) you get. It's always nice to have concise descriptions of your application's behaviour.