HN Theater @HNTheaterMonth

I worked on this with Cheng Lou a while back.

Just to preemptively address a criticism: yes, this does frame-by-frame animation in JavaScript, eschewing CSS animations. There are tricks you can use (similar to what iScroll does or did) that can leverage CSS animation, but it's likely that these won't be necessary or worth it.

The reason for this is that to truly solve animation you need to address continuous touch gestures that seamlessly transition into and out of animations (i.e. flick something, catch it with your finger mid-animation, zoom it while rotating it, then let go and have it animate out). The only way to do this is to use a programming language that can respond to events. Said another way, you should never think of animations discretely (i.e. "slide in from left") if you're thinking about building touch-based app. It won't feel natural.

My old employer has a great video about this. Detailed discussion starts here (there are two speakers that talk about it): http://youtu.be/OiY1cheLpmI?t=25m29s

⬐ tosh

Thanks a lot for the pointer Peter.

I also was sceptical at first but apparently achieving 60 fps witch this approach is possible and has the interactivity advantages you mentioned.

⬐ peterhunt

Definitely doable on desktop.

IMO, if you're doing animations on mobile web you're targeting a higher end phone anyway (since you'd be crazy to do anything fancy with mobile web on a constrained device) it's less about execution speed and more about GC at that point. If you can't hit 60fps with this technique I think we need to fix garbage collection, not use a different set of animation primitives. But lots of very smart people disagree with me.

⬐ seanmcdirmid

> Said another way, you should never think of animations discretely (i.e. "slide in from left") if you're thinking about building touch-based app. It won't feel natural.

That kind of goes against thinking of animation as tweens. Instead, you want something more physics based that can respond to touch in real time yet remain controllable enough for user interface usage; e.g. verlet and/or inverse kinematics.

⬐ AdrianRossouw

This was a big part of the promise of famo.us

⬐ peterhunt

Absolutely agree.

react-tween-state is less about the specific tweening function and more about the idea of a numeric value changing over time that can be interrupted. Instead of the standard Penner tweening functions you could just as easily substitute in some physics (like https://github.com/facebook/rebound-js). And with the DESTRUCTIVE mode of react-tween-state you can seamlessly transition between direct manipulation mode and inertia mode.

There's still a lot to do here, but I am pretty positive on the overall approach.

⬐ seanmcdirmid

Reading the github page, though, this is really about tweening with no mention of interruption. However, using Verlet (not Newtonian like rebound-js!) you can easily combine both approaches since Verlet allows you to mess with a position directly (velocity is implicit in position deltas, so really stable although less accurate).

I wrote a rejected paper about this a few years ago; it might be useful as a reference:

http://research.microsoft.com/pubs/191705/uiphysics09.pdf

I wrote that when I was doing a lot of work with WPF, whose animation/data binding system is fairly similar to what is being explored in Javascript today (with frameworks like React). But beyond data binding and canned animations, I think physics is the next step.

⬐ dandelany

Re: interruption, from the docs:

> stackBehavior (default: tweenState.stackBehavior.ADDITIVE). Subsequent tweening to the same state value will be stacked (added together). This gives a smooth tweening effect that is iOS 8's new default... The other option is tweenState.stackBehavior.DESTRUCTIVE, which replaces all current animations of that state value by this new one.

So DESTRUCTIVE is what allows interruption.

⬐ seanmcdirmid

This is not much different from WPF's animation support, and I don't think it really helps. The interruptions are still not very natural looking. It was definitely useless for Surface (the table, not the tablet) when I was doing UX prototypes for it.

⬐ peterhunt

I would love to chat with you about what you've learned working on this stuff. If you're interested, drop me an email at floydophone at gmail dot com

⬐ chenglou

Additive is a better "interruption" in a lot of cases from what I've seen. Destructive was added after the fact for completeness. What do you think?

⬐ Kiro

I recommend anyone thinking CSS animations always outperform JS animations to have a look at Velocity.js (http://julian.com/research/velocity/).

⬐ jschrf

Fire up the animation test in Chrome's timeline and view the frames. Replicate the same animation as a CSS transition. view in the timeline and report back. Hint: Pure CSS transitions are faster than JS driven ones. Not sure why so many people seem to think otherwise.

⬐ DigitalSea

Came here to say the same thing. I have done a few extensive benchmarks internally and the conclusions were exactly the same (even though you don't need benchmarks really to know there is a difference). CSS transitions/animations have less overhead than Javascript ones. I think the issue here is perceived performance vs actual performance. People assume just because it looks fast and runs fast, that it is fast, when it in-fact comes with some overhead (that might not be visible on the surface).

⬐ peterhunt

They also take longer to start. More importantly they're impossible to control.

The author Kimon Tsinteris goes into details at the Facebook Paper[1] event.

[1] - https://www.youtube.com/watch?v=OiY1cheLpmI#t=1527

⬐ ColinWright

Also submitted yesterday: https://news.ycombinator.com/item?id=7613813

There were no up-votes, and no discussion. But to be honest, who is going going to watch a 90 minute video without any kind of transcript to give a hint as to whether there's any value in it? Certainly I'm not going to spent that much time purely speculatively.