4 ms·

What if cucumber and jQuery had a baby?

52 points by tswicegood 15y ago

MostAwesomeDude 15y ago
This burns my eyes almost as badly as Fructose. Fructose, if you're not aware of it, is a C# application that translates Ruby to PHP. (http://www.fructoselang.org/ http://www.fructoselang.org/)
3am 15y ago
I'm in QA - what niche does this fill for you? The reason that I ask is that usually DSLs and other user acceptance tools exist to allow non-programmers to design tests. That is why cucumber's Gherkin is not in a Ruby syntax, and why robot and FitNesse use html tables. And further, they generally operate at an integration level, which is why the have hooks in for like Selenium frequently. I think the project is cool, but I do wonder where you see it fitting in. A way to make jsunit tests more readable and cleaner? EDIT: Let me add that I love it whenever QA topics make it to HN. I know QA is usually a post-seed funding activity, and that's a shame (in my biased opinion).
- timmaah 15y ago
  I don't think this has anything to do with QA or testing. Just another way to write javascript inspired by the cucumber DSL.
  - 3am 15y ago
    Cucumber is a BDD tool. That stands for Behavior Drive Design, which is what the 'when X expect Y' format is. It's intrinsically a testing tool, where the user acceptance tests are described in a BDD format. It's a subset of TDD.
    - timmaah 15y ago
      You are correct in that cucumber is a testing tool... What is in that repo on github "whenever.js" is not for testing and is not BDD for js or jquery. The author implemented a dsl like cucumber to allow creation of behavior in javascript.
      - 3am 15y ago
        Fair enough - I'll call it a failure of imagination for me, then. I saw a DSL that had a BDD syntax for javascript, and thought it was meant to be some form of testing tool. We all have our cognitive blinders :)
- kragen 15y ago
  I don't know, it could be cool as a way to put the scripting of the user interface into a language that less technical people could understand and experiment with. Hopefully you aren't writing thousands of pages of this stuff (instead you should find a way to put together abstractions that reduce the amount of code that has to be written at this level) but it would be great to have a lot of the scripting of a UI be 10 or 30 or 100 pages of stuff that reads just like English. That's my thought, anyway.
  - 3am 15y ago
    No, I agree completely. My gripe is that the DSL is JS with a fluent interface. You need a DOM context in order to make JS work (unless I'm mistaken) which is why you have tests that drive the browser like Selenium. So you are going to write Javascript in order to drive some other tool that interacts with the AUT. Anyway, it's neat, and I'm not trying to discourage anyone.
blhack 15y ago
If you're as confused as I am, "cucumber", in this case, is referring to a testing framework for ruby, not a vegetable. https://github.com/cucumber/cucumber/wiki/ https://github.com/cucumber/cucumber/wiki/ a side note: am I just totally out of touch with things? "Fructose", "Cucumber", "Coffeescript", "V8"?
- sneak 15y ago
  One explanation: Totally out of touch. Another explanation: Modern-day web developers are obsessed with branding, and mistakenly think that a clever (read: opaque) name and good logo are just as important as utility value. This probably started with jwz/Mozilla. Sometimes it works.
  - Confusion 15y ago
    The utility value of cucumber, coffeescript and V8, to a great many people -- perhaps not to you -- is pretty much undeniable.
seliopou 15y ago
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!
jsavimbi 15y ago
There's a political complaint about the lack of semi colons in the script and its subsequent breakage in minification. Otherwise, I like it. From a QA perspective, it's been my experience that no matter how much you simplify the DSL for the business user, it's always a pain to get them up and running and if you have a TDD point of view, you'll be much more successful, especially when engaging in a project that is very DOM-manipulation heavy.
- 3am 15y ago
  _THIS_ It's hard to dumb it down enough for a non-technical user to do anything useful (in which case their tests are frequently invalid in a functional sense even though they're syntactically valid). But by that point you've usually dumbed it down far past the level a competent QA engineer should work at.
- paulca 15y ago
  Happy to accept a pull request that adds semi-colons. I'm not particularly fussed!
  - aaronblohowiak 15y ago
    sent
    - paulca 15y ago
      merged!
  - jsavimbi 15y ago
    Thanks! I think the complainer will be silenced.
anodari 15y ago
Someone knows if there is a relationship between this or BDD and a rule engine used by expert systems?
rsanheim 15y ago
If it's a painful as cucumber, I would stay far away.
paulca 15y ago
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.
hitonagashi 15y ago
:(. Using Whenever and Whenever (ruby cron gem) together will make my head pop.
asnyder 15y ago
Reminds me of Hypertalk and Metatalk. I personally don't like such verbose syntax, but many do. It's usually used in marketing languages to non-developer professionals, however, in the end, I feel it becomes way more verbose and complicated than if you used the conventional concise approach. I used to joke that when using one of these scripting languages you would have to start your statements with "please" and end with "thank you".
- paulca 15y ago
  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.
- paulca 15y ago
  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.

52 points by tswicegood 15y ago

This burns my eyes almost as badly as Fructose. Fructose, if you're not aware of it, is a C# application that translates Ruby to PHP. (http://www.fructoselang.org/ http://www.fructoselang.org/)

3am 15y ago

I'm in QA - what niche does this fill for you? The reason that I ask is that usually DSLs and other user acceptance tools exist to allow non-programmers to design tests. That is why cucumber's Gherkin is not in a Ruby syntax, and why robot and FitNesse use html tables. And further, they generally operate at an integration level, which is why the have hooks in for like Selenium frequently. I think the project is cool, but I do wonder where you see it fitting in. A way to make jsunit tests more readable and cleaner? EDIT: Let me add that I love it whenever QA topics make it to HN. I know QA is usually a post-seed funding activity, and that's a shame (in my biased opinion).

timmaah 15y ago
I don't think this has anything to do with QA or testing. Just another way to write javascript inspired by the cucumber DSL.
- 3am 15y ago
  Cucumber is a BDD tool. That stands for Behavior Drive Design, which is what the 'when X expect Y' format is. It's intrinsically a testing tool, where the user acceptance tests are described in a BDD format. It's a subset of TDD.
  - timmaah 15y ago
    You are correct in that cucumber is a testing tool... What is in that repo on github "whenever.js" is not for testing and is not BDD for js or jquery. The author implemented a dsl like cucumber to allow creation of behavior in javascript.
    - 3am 15y ago
      Fair enough - I'll call it a failure of imagination for me, then. I saw a DSL that had a BDD syntax for javascript, and thought it was meant to be some form of testing tool. We all have our cognitive blinders :)
kragen 15y ago
I don't know, it could be cool as a way to put the scripting of the user interface into a language that less technical people could understand and experiment with. Hopefully you aren't writing thousands of pages of this stuff (instead you should find a way to put together abstractions that reduce the amount of code that has to be written at this level) but it would be great to have a lot of the scripting of a UI be 10 or 30 or 100 pages of stuff that reads just like English. That's my thought, anyway.
- 3am 15y ago
  No, I agree completely. My gripe is that the DSL is JS with a fluent interface. You need a DOM context in order to make JS work (unless I'm mistaken) which is why you have tests that drive the browser like Selenium. So you are going to write Javascript in order to drive some other tool that interacts with the AUT. Anyway, it's neat, and I'm not trying to discourage anyone.

blhack 15y ago

If you're as confused as I am, "cucumber", in this case, is referring to a testing framework for ruby, not a vegetable. https://github.com/cucumber/cucumber/wiki/ https://github.com/cucumber/cucumber/wiki/ a side note: am I just totally out of touch with things? "Fructose", "Cucumber", "Coffeescript", "V8"?

sneak 15y ago
One explanation: Totally out of touch. Another explanation: Modern-day web developers are obsessed with branding, and mistakenly think that a clever (read: opaque) name and good logo are just as important as utility value. This probably started with jwz/Mozilla. Sometimes it works.
- Confusion 15y ago
  The utility value of cucumber, coffeescript and V8, to a great many people -- perhaps not to you -- is pretty much undeniable.

seliopou 15y ago

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!

jsavimbi 15y ago

There's a political complaint about the lack of semi colons in the script and its subsequent breakage in minification. Otherwise, I like it. From a QA perspective, it's been my experience that no matter how much you simplify the DSL for the business user, it's always a pain to get them up and running and if you have a TDD point of view, you'll be much more successful, especially when engaging in a project that is very DOM-manipulation heavy.

3am 15y ago
_THIS_ It's hard to dumb it down enough for a non-technical user to do anything useful (in which case their tests are frequently invalid in a functional sense even though they're syntactically valid). But by that point you've usually dumbed it down far past the level a competent QA engineer should work at.
paulca 15y ago
Happy to accept a pull request that adds semi-colons. I'm not particularly fussed!
- aaronblohowiak 15y ago
  sent
  - paulca 15y ago
    merged!
- jsavimbi 15y ago
  Thanks! I think the complainer will be silenced.

anodari 15y ago

Someone knows if there is a relationship between this or BDD and a rule engine used by expert systems?

rsanheim 15y ago

If it's a painful as cucumber, I would stay far away.

paulca 15y ago

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.

hitonagashi 15y ago

:(. Using Whenever and Whenever (ruby cron gem) together will make my head pop.

asnyder 15y ago

Reminds me of Hypertalk and Metatalk. I personally don't like such verbose syntax, but many do. It's usually used in marketing languages to non-developer professionals, however, in the end, I feel it becomes way more verbose and complicated than if you used the conventional concise approach. I used to joke that when using one of these scripting languages you would have to start your statements with "please" and end with "thank you".

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