search

aaronc / freactive

High-performance, pure Clojurescript, declarative DOM library
http://documentup.com/aaronc/freactive
Eclipse Public License 1.0
387 stars 27 forks source link

Clarification on JS based animations #24

Open martinklepsch opened 9 years ago

martinklepsch commented 9 years ago

Maybe I was the only one but I'd suggest to add a small note to the animation documentation that JS based animations can be just as good (and better) than CSS based animations.

I wasn't aware of this until today and so the animation stuff in freactive seemed surprising to me.

I read these two articles, which helped me understand the differences between the two approaches. https://developers.google.com/web/fundamentals/look-and-feel/animations/css-vs-javascript http://css-tricks.com/myth-busting-css-animations-vs-javascript/

Also according to these articles GPU acceleration is only utilised when transform3d/matrix3d is used, skimming the code it seems freactive doesn't use them. Did you not see a need for them?

(I hope all my observations about freactive's animation part are correct, forgive me if not :)

aaronc commented 9 years ago

Hi Martin,

So probably clarifying confusion about JS animations and documenting what props get GPU acceleration would be useful in the docs. Regarding transform3d/matrix3d, freactive lets you animate any attribute or style property so you can use them if you like. freactive's animation support at its core is really very general - it doesn't proscribe too much how you do your animations.

From a framework level, freactive only does 3 small but significant things to support animations:

  1. make it easy to efficiently bind to an attribute or style property
  2. have built-in lifecycle callbacks (the API for this is still being finalized) and support for user defined callbacks (currently it will trigger callbacks when data-state is bound and changes) - this allows places to start freactive's built-in animations, 3rd party JS animations andCSS animations by adding/removing classes/changing data state
  3. expose the requestAnimationFrame timestamp as a reactive atom for efficient triggering of tweens - this is the basis of the built-in "easer"

So, if you want, you can just use the easer wrapper in an rx and bind it to the transform style property, maybe something like this:

[:div {:style {:transform (rx (str "translate3d(" (* @easer some-value) "," (* @easer another-value) ", 1.0)"))}}]

We can add convenience functions to wrap all of these things and probably create a utility libraries with features similar to what GSAP provides. I think the most important thing is having this efficient declarative way to bind to style props and some way to trigger animations on requestAnimationFrame (the easer and freactive.dom/frame-time). Hopefully this allows the flexibility to build what one desires...

Does this clarify things a little?