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

[FEATURE] Improved feature comparison chart/explanation #2956

Open
StevenStavrakis opened this issue Dec 21, 2024 · 4 comments
Open

[FEATURE] Improved feature comparison chart/explanation #2956

StevenStavrakis opened this issue Dec 21, 2024 · 4 comments
Labels
feature New feature or request

Comments

@StevenStavrakis
Copy link

Is your feature request related to a problem? Please describe.
Maybe this is a me problem, but I'm not sure I fully understand the feature comparison chart at: https://motion.dev/docs/feature-comparison

I've done a lot of web animation work with GSAP, and I'm not sure what some of the terms being compared mean. Take "Individual transforms." I honestly couldn't tell you what that is supposed to mean, mostly because the mini package doesn't support it, but it does support complex transform interpolation. Then, in the same stroke, mini supports to/from CSS functions, but hybrid doesn't. I don't know how you could have any meaningful web animations without "individual transforms."

Then, the "hybrid" model doesn't at least have feature parity with its "mini" counterpart. Seeing as at no point in the "quick start" section is it mentioned that mini/hybrid are installed separately, I'm guessing that they are part of a larger package and that if you use the functionality of one or the other, it is bundled.

Since I don't know what "individual transforms" is supposed to mean outside of the basic functionality of any animation library--transforming an element--then there is almost going to be no way to use mini and hybrid separately. If that is the case, then you will pretty much always be using 19.5 kb.

Describe the solution you'd like
I see for some of the features, there are links to demos. It would be nice if the demos included mini instead of Anime.js so that each feature can be evaluated by what it does. Additionally, it would be good to provide a tooltip description of some of the unexplained features or, better, a link to the documentation showing how it works. For example, I know what "relative values" means because I use GSAP frequently. But if someone is new to animation, it is not exactly clear what that means or why it is useful.

Describe alternatives you've considered
Just use a different animation library that explains its features.

Additional context
N/a

@StevenStavrakis StevenStavrakis added the feature New feature or request label Dec 21, 2024
@mattgperry
Copy link
Collaborator

I think some tooltips are a good idea.

“Individual transforms” - I tend to use “independent” transforms so I can amend this. It means animating like x:200 and rotate:360 with different easing curves or at different times. CSS/Waapi don’t support this whereas JS animation libraries tend to.

@mattgperry
Copy link
Collaborator

On the idea that mini supports a couple things that hybrid doesn’t. Actually a new version of Anime.js is coming with WAAPI support and it’ll be the same story there.

This is a bit of a in-depth explanation so no worries if it’s not of interest.

Perhaps to reduce confusion I can share less about what it can do. For example JS animation libraries tend not to support “rotate(360deg)” to “translateX(100px) scale(2)” - this is complex transform interpolation. Whereas CSS/WAAPI do support this.

The mini version supports this too, because it’s based on WAAPI.

However interrupting an animation like this can be done in two ways, one is commiting the current state to the DOM and then reading it back out. This is the slow way, and this is how the mini version interrupts a complex transform interpolation.

The fast way is the way the hybrid function does it. Which is quietly spin up a headless JS animation with the same options and sample that for animation.currentTime. No writes/reads required. The drawback is it only works for values that are also animated by the JS animation. So although you have the benefit of WAAPI in terms of performance you are limited by the capabilities of the lowest common denominator.

Now in the reverse case, where the JS animation supports something that WAAPI doesn’t, like repeatDelay, we just use the JS animation. So it could be that we add the slow method of interruption in order to support the reverse case - where WAAP supports something we cant or don’t do in JS, like complex transform interpolation, named colors, animating between CSS functions etc. This would prevent the slight Venn diagram situation of the two functions at the cost of a little file size overhead.

@StevenStavrakis
Copy link
Author

RE: hybrid vs mini, I think there is confusion about what to use and when. The quick start section of the docs does not mention using either hybrid or mini. I'm assuming that means that it looks at what is used and puts the relevant files into the build at build time.

If that is the case, then it is a sort of "feature roulette." If you only use mini functionality, you'll have a smaller bundle at build time.

Do I understand correctly?

@mattgperry
Copy link
Collaborator

I suspect it’s the feature comparison that causes this confusion. The animate function docs explain what the difference is - the hybrid function includes support for more values, animation sequences and independent transforms. If you don’t use these features then you can opt to use the mini version.

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

No branches or pull requests

2 participants