You can pull this up on an iPhone 4S or newer (it uses the same technique with tons of allocations but doesn't really drop frames): http://petehunt.github.io/react-touch
The secret sauce is that you can animate CSS transforms every requestAnimationFrame without breaking out of React's natural data flow.
So we declaratively express the UI as a function of a single float which represents the scroll position (i.e. how open/shut the nav is or what position in the photo viewer you're at).
When we do that, we can use the excellent Zynga Scroller touch gesture physics engine (reverse engineered from iOS) to do the touch gesture stuff, then we can declaratively rotate, fade and translate everything as a function of this float.
Code is on github! And is actually in a reusable library!
I'm also super interested in this combination. However, on my new moto x, the photo scroller drops to ~45 fps and looks pretty chunky.
I also noted that you say the demos work best iPhone 5 on iOS 7, but unclear if you meant in contrast to earlier iPhones, or in contrast to Android, or both. Have you looked at all at the perf issues on Android?
The FPS drop on the photo scroller is likely due to jpeg decoding and painting on the main thread (I thought this was fixed in Blink but maybe not). Try "warming it up" by scrolling through all of the images a few times so the decoded jpegs get cached. I think this is the biggest perf problem on the Web today.
The reason Android may "feel" sluggish while reporting good FPS is because Android simply has a huge problem with touch event latency in the browser that you can't get around. This is where iOS really kicks Android's ass, at least on the web.
So the reason I limited to iPhone 5 and iOS 7 was because I can guarantee the touch latency and that the images fit in texture memory. Maybe they don't on the moto x.
The point of rebuilding scrolling is to get the scroll position every frame so you can update the UI (ie rotate a photo or fade the left nav). You don't get scroll events during momentum scrolls so you have to rebuild it.
Yes, what about them? Have they been measured to be a problem with this approach?
If anything, it leads so colletions of objects of small lifetimes, that are quickly collected by the GC.