DOM Events aren't asynchronous. You can stop the bubbling on the event, or prevent default, or even just return false in a native event handler. That wouldn't be possible if the handlers executed asynchronously.
On Tue, Dec 7, 2010 at 2:47 PM, אריה גלזר <[email protected]> wrote: > This is another one of those "I know it won't be implemented but think it > should": > > Native JS events are async by nature, and it's one of the things that make > them that useful. It's also how we're used to using them. But Class events > are all synchronous. One of the important parts of events is that they allow > us to encapsulate behavior - it's a very clean way for one class to use > another. It's essentially an observer pattern, and it's a part of what makes > moo that much more useful and powerful. > The reason I find this important is that making event calls synchronous is > creating a lot of unmeasurable, untestable noise. What if by chance a heavy > function done by another class is called before mine? > > The only issue I can see here is that this might be a breaking change if > someone is using Class events to modify it's behavior, but then we can add a > fireEvent([...],async) flag or something. > I'm also posting a ticket for this, but I think it's only worth the while > if it's discussed (and I feel weird opening a discussion on the lighthouse). > > as a side note - it seems that code change is actually very very small. > > thoughts? > > -- > Arieh Glazer > אריה גלזר > 052-5348-561 > http://www.arieh.co.il > http://www.link-wd.co.il > >
