You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 :)
The text was updated successfully, but these errors were encountered:
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:
make it easy to efficiently bind to an attribute or style property
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
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:
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...
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 :)
The text was updated successfully, but these errors were encountered: