3 ms·

Nice idea, but what does this actually do for you? If you translate the first example to straight jQuery, it's shorter, and you don't need to know about 'whenev

Nice idea, but what does this actually do for you? If you translate the first example to straight jQuery, it's shorter, and you don't need to know about 'whenever' to figure out what's going on. And even if you were familiar with 'whenever', you'd have to look at three different places to understand what the code is _actually_ doing. What's cool, I think, is the chaining of predicates. That's useful in general, and should be a totally different library.

ars 15y ago
So basically I need to program everything twice in order to do anything? And changing anything means going to three different places in the program? No thanks.
rojoca 15y ago
I can see this as a useful tool in prototyping. You can create these short DSL phrases to describe the behaviour you want, then implement as much as you need. The other benefit is the documentation (in DSL form) you get. It's always nice to have concise descriptions of your application's behaviour.
paulca 15y ago
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. 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!
- seliopou 15y ago
  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);
  - paulca 15y ago
    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.

ars 15y ago

So basically I need to program everything twice in order to do anything? And changing anything means going to three different places in the program? No thanks.

rojoca 15y ago

I can see this as a useful tool in prototyping. You can create these short DSL phrases to describe the behaviour you want, then implement as much as you need. The other benefit is the documentation (in DSL form) you get. It's always nice to have concise descriptions of your application's behaviour.

paulca 15y ago

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. 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!

seliopou 15y ago
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);
- paulca 15y ago
  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.