Curious to better understand what you mean—in my experience, this is not true at all. All touches / gesture handling are direct manipulation with no delays at all. All the asynchronously-prepared content is rendered in advance with a large offscreen buffer, so in general it should be done rendering before it's onscreen. In the cases where you scroll really fast and get to something that hasn't finished rendering, the alternative in a regular app architecture is to simply stutter (block the UI) until it's done rendering.

This framework can be used in very flexible ways, such as "try to render everything offscreen, but if it's going to come onscreen and hasn't finished yet, block and wait for it to be done". Even that approach will result in a much more responsive feel while ensuring that you have the same guarantees as a synchronous UI about content being finished rendering when it is visible.

Cocoapod should also be up now.

Yes, there is a broad similarity: abstracting away from performance or threading limitations of common UI building blocks. However, React has a declarative, single-directional data flow model. AsyncDisplayKit is imperative.

Declarative code is great for a lot of things, but interactivity and animations are definitely not one of them. Also, ASDisplayNode was designed to be as similar as possible to UIView (also imperative).

We don't have a benchmark suite, largely because it is so easy to use Instruments to do CPU traces and look for any chunks of main thread work that threaten frame drops.

You can use autolayout (see my NSLondon talk, which discusses this in the Q&A). However, there's no way to make autolayout run asynchronously, so you won't be able to reduce main thread stalls caused by autolayout-driven calculations.