Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification on JS based animations #24

Open
martinklepsch opened this issue Nov 28, 2014 · 1 comment
Open

Clarification on JS based animations #24

martinklepsch opened this issue Nov 28, 2014 · 1 comment

Comments

@martinklepsch
Copy link

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
Copy link
Owner

aaronc commented Nov 28, 2014

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants