I guess a follow on point is that unlike Hypertalk where the implementation is written in a DSL, whenever.js is just a way of _describing_ an implementation.
Everything else is plain javascript, and you can use whatever language features you want within the definition functions.
It may turn out to be too verbose, but in terms of my motivation, and conciseness vs. verbosity, the goal was to achieve:
1) conciseness of expression of intent ... I feel that this is the most important thing to get accross
2) conciseness of implementation logic: having chainable condition statements would hopefully lose a lot of if...else... conditionals within implementation logic
3) conciseness of conceptual mapping of the bound element to its name, eg. 'The "New Post" link" vs. "a#new-post" ...
Again, this is all just an argument from motivation rather than experience. It may turn out that this was a really, really bad idea.
Given that I really don't have any practical experience using whenever.js (it's literally days old) my "argument", is that jQuery tends to be very syntax heavy.
... 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!
Here's what you can do without using whenever that addresses your issue, and possibly others'. As far as I can tell what people don't like is the inlined function. You can get rid of that and be descriptive about what's going on, all without the use of whenever:
whenever("Click Me!").is('clicked').then('change it to "clicked"')
turns into:
var cbs = {};
cbs.setClickedText = function() { $(this).text('Clicked!'); };
$('a#click-me').click(cbs.setClickedText);
Yep, I've played around with tons of approaches to this problem : your solution is where I started. It's probably totally ok, but there was something about it that just didn't sit right with me.
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.
For the record: this was a thought experiment that I made on the plane home from TXJS last week and was just something I wondered if I could do.
The reference to cucumber is really only a nod to inspiration for the given / when / then syntax, and the emphasis of speccing behavior in plane English.
I've also been fascinated by the idea of writing executable English as implementation logic, and since JS allows object labels to be strings, why not make full descriptive sentences.
I haven't used this for anything useful or practical (it's days old) ... but I'm hoping it will be a neat way to spec and as someone mentioned document the behaviour of my app and to try and try to separate the intent of what I'm writing from the implementation.
