Thanks!

Very cool demo.

But why have events on requests with :upon and events on elements with :listen ?

we wanted to highlight the distinction between device-based UI input and callbacks for object state, although these are often both referred to as "events" in other javascript libraries. Internally they are two different classes (UserEvent and CodeEvent) and it's conceivable that a single object will need to react to both.

@colin miller,

User-interaction events use :listen, while code-initiated events use :upon.

This reflects on one of the problems we ran into while tearing MooTools limb from limb to include in Redshift: one of the core beliefs of MooTools seems to be that every possible action that could reasonably be associated with a given method name should be made available through that method name - this leads to methods like "set" which can do essentially anything you can imagine, with an absurdly complex argument-wrangling structure.

This makes it not only difficult to remember how to use the method correctly (a similar problem exists in Rails, with, for example, form helper arguments), but also creates a mind-breaking exercise in trying to follow the code down to where something actually takes place.

We could munge the methods :upon and :listen and differentiate them by treating an event that falls into the predetermined set of "user events" differently than a "code event" with an arbitrary name; this would move the :upon/:listen distinction deeper into the code, but not remove it. Rather than hiding that distinction from the developer, though, we believe that following even your own code becomes much easier when you recognize that events initiated by user interactions and events initiated by your objects running their :fire method are fundamentally different animals.

Very enjoyable video. Is there matching TDD support? Or how are you guys testing your Ruby->JS? Or I could go read the code I guess... :)

I'm a Python guy, but let me tell you, what you guys are doing is way amazing. What you need next (right after the TDD) is a firebug plugin to interact with Red and Redshift directly, as a sort of in-browser interpreter (the way they have it for JS). It seems daunting, but I'm sure it's doable. I think.