paulca

I suspect you didn't read past the second paragraph.

I've been working on a refactor of this lately:

https://github.com/paulca/eyeballs.js/blob/refactor/eyeballs...

The initializer function is now 'oo' which works better all round I think. There's also a certain departure from its MVC root.

Finally, this library actually does predate Backbone. If backbone was around when I first built this, I probably would have gone ahead and used it.

Fáilte?!

Registered a new domain today that I'd like the Twitter name for ... good heads up Ross, thanks!

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.

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.

merged!

Happy to accept a pull request that adds semi-colons. I'm not particularly fussed!

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!

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.

In the UK, 10% is standard and entirely optional. 15-20+ is if you're feeling super generous.

Err the Blog had about 10,000 readers when GitHub launched and Chris and PJ already had a ton of users of their popular Rails plugins.

This was a huge audience to launch to. What advice would you give to people who want to dive in to their own company without trying to build up such a huge following before hand?

Is it madness to try to bootstrap without establishing an audience beforehand?

The value prop right now is:

1) A place to put your meeting notes. So, rather than searching through Google Docs etc. there's an implicit understanding that the objects are notes. Subtle I guess, but I'm a big fan of focussed apps as an alternative to kitchen sink apps. 2) Keeping notes collected. We're week on this right now, but I'm looking forward to being able to click on a project and seeing all my meetings/notes from that project.

—P

Hey Alex,

Awesome! Thanks for the kind words. We'll probably iterate on the homepage in the next few days: there are a few issues with it.

Let us know what you think, and what we can do to to improve.

—P

Hey,

I totally get your point about this, and I do work for one of those corporates, and I've seen the heavy use of IE6.

For us, building the app in our spare time, making IE6 allowances just wouldn't have been practical for getting the app built.

Isn't Chrome fairly easy to install with regular privileges on Windows?

—Paul