I have no desire to layout everything in code (I know some people like this, I don't) so it's not very interesting to me. It would seem to require you to write your app in a completely different way. I wonder what debugging would be like with it, given that threaded code is always more painful. It might be more interesting once people release actual apps with it (outside of FB).
Full blog post announcing the framework is here: <a href="https://code.facebook.com/posts/721586784561674/introducing-asyncdisplaykit-for-smooth-and-responsive-apps-on-ios/" rel="nofollow">https://code.facebook.com/posts/721586784561674/introducing-...</a>
The flip side of something like this is that it creates a "floaty" feeling, due to delaying UI update for several runloop passes (jumping from one queue to another). Sometimes this is more acceptable but often it is not. If you played with Paper, and felt it was "floaty", now you know why. If it didn't bother you, I guess you are less sensitive to this. Not to say this library is useless, like most things, when not abused, good can come from it.
It's really neat to see facebook's iOS team releasing so much of their work. This framework is probably not going to be that relevant to tons of use-cases, but even if you'll never use it you'll probably get a lot out of looking at it closely and thinking about why it makes the decisions it does.
On Safari, the entire site seems to have no content and just re-directs to itself in a loop over and over: meta http-equiv="refresh" content="0; <a href="http://asyncdisplaykit.org"" rel="nofollow">http://asyncdisplaykit.org"</a>
Very cool! This bears quite a resemblance to the way React.js constructs a virtual DOM so that it can optimize drawing. Do you guys have a way you're benchmarking performance improvements? Are you just looking at time spent on the main thread?