Jérémy Lal

Another example where browserify-lite fails: https://github.com/kriskowal/asap/blob/master/package.json#L20

Hello again, [email protected] somewhat now provides a way to carry on a state object along the calls. This allows stuff like `.load().wait('ready').html(cb).unload().load().wait('idle')` to work. Checkout webkitgtk for an example usage.

I've removed suspicious uses of setTimeout - i don't see why there would be performance issues. Here's some example of a (simple) state machine https://github.com/kapouer/node-webkitgtk/blob/master/webkitgtk.js#L28

Hi, cool, thank you. I agree to the merge. The state machine is a simple thing actually, and it allows https://github.com/kapouer/node-webkitgtk/commit/b129601a5e56e664d0b916362b86e50772f5aedf to take care of the order in which methods...

Agreed - the semantic is wrong, but it's actually very useful - you are assured the last handler get the error. I like that tradeoff very much.

Maybe adding a tail function like: ``` obj .method1() .methodError() .notactuallycalled() .finished(function(err) { // the error that happened in methodError // the method "notactuallycalled" is not called console.error(err); }); ```

if that allows to define a "catchall" method on the chainable object instance, that's good enough. BTW i can't think of any other meaningful scenario... maybe simply allowing a custom...

I'm not so fund of the catchall method. To me, chainable without callback is like a one method call: `.call(that).or().do(it, cb)` has the same semantics as `.allinone(that, it, cb)` Not...

Not necessarily right... what i explain is that chainable API comes with different semantics than plan old methods. Either it's chainable API or it falls down to another category -...

With that you catch the error all right, but not in the place you usually do. Usually you get errors in a callback, not in a listener. My point is...