petehunt/gist:7618353

## gistfile1.txt
First of all, I have an experimental branch with React that lets you use compile CSS animations just-in-time with our reconciliation system and use those instead of pure JS. So I recognize that they should be supported.

In my experience CSS transitions and animations work fine for things that will always animate fully and will never have the animation changed. A good example is a fade out when deleting a list item.

I've just found that in my own work most animations are tied with direct user touch manipulation (like animating out the left nav w/ parallax and opacity) which requires frame-by-frame responsiveness to touch events and inertia calculations based on the user's touch velocity. It's impossible to do this without doing frame-by-frame.

Your skepticism is definitely warranted and I complain to browser vendors whenever I see them about this. In my experience, modern (1 year old) phones can do this with minimal jank but there can still be issues. Assuming you're already avoiding reflows, here are the three main sources of jank:

1. Image decoding

This one is a *killer*. Whenever you load in an image it blocks the UI thread as it is decoded and painted and there's nothing you can do about it. I got around it by building a web worker JPEG image decoder and then incrementally painting to a canvas, but it was really slow. Once the decoded images are cached in texture memory they're fast, but there's a limited about of texture memory so you can't load too many images. Please complain to your local browser vendor about this.

2. Garbage collection

This one is overrated. I have seen dropped frames from it but if you're somewhat careful about object allocations it's not so bad.

3. Doing too much stuff in JS

Most JS apps aren't doing too much -- they're basically updating a few data models based on user behavior and hitting the server. In case your JS app is doing more you could use a web worker to offload this work.

My example has a component called StaticContainer which will block updates to all components that aren't currently animating. This is a great feature of React since it'll prevent you from accidentally messing up the animation if you need to do more work in a child component. That is: imagine you were doing crazy expensive computation in the frosted glass content page. During the animation React would pause that work until the animation completes.
	First of all, I have an experimental branch with React that lets you use compile CSS animations just-in-time with our reconciliation system and use those instead of pure JS. So I recognize that they should be supported.

	In my experience CSS transitions and animations work fine for things that will always animate fully and will never have the animation changed. A good example is a fade out when deleting a list item.

	I've just found that in my own work most animations are tied with direct user touch manipulation (like animating out the left nav w/ parallax and opacity) which requires frame-by-frame responsiveness to touch events and inertia calculations based on the user's touch velocity. It's impossible to do this without doing frame-by-frame.

	Your skepticism is definitely warranted and I complain to browser vendors whenever I see them about this. In my experience, modern (1 year old) phones can do this with minimal jank but there can still be issues. Assuming you're already avoiding reflows, here are the three main sources of jank:

	1. Image decoding

	This one is a killer. Whenever you load in an image it blocks the UI thread as it is decoded and painted and there's nothing you can do about it. I got around it by building a web worker JPEG image decoder and then incrementally painting to a canvas, but it was really slow. Once the decoded images are cached in texture memory they're fast, but there's a limited about of texture memory so you can't load too many images. Please complain to your local browser vendor about this.

	2. Garbage collection

	This one is overrated. I have seen dropped frames from it but if you're somewhat careful about object allocations it's not so bad.

	3. Doing too much stuff in JS

	Most JS apps aren't doing too much -- they're basically updating a few data models based on user behavior and hitting the server. In case your JS app is doing more you could use a web worker to offload this work.

	My example has a component called StaticContainer which will block updates to all components that aren't currently animating. This is a great feature of React since it'll prevent you from accidentally messing up the animation if you need to do more work in a child component. That is: imagine you were doing crazy expensive computation in the frosted glass content page. During the animation React would pause that work until the animation completes.