GSAP vs Motion: Which should you use?
Ready to migrate? Check out our simple GSAP to Motion migration guide.
When deciding which JavaScript animation library to trust for your project, two libraries often get mentioned because of their feature set and popularity: Motion (formerly Framer Motion) and GSAP (formerly GreenSock).
Both can create stunning animations, but they have fundamental differences. This guide compares Motion and GSAP on adoption, licensing, performance, and features (complete with full comparison table), to help you decide which is right for your project.
Adoption
Before delving into the libraries themselves, it's helpful to see what other developers are choosing. For modern applications, npm is a great measure of a library's adoption and momentum.
Here, the numbers are clear: Motion is growing exponentially, making it the most-used and fastest-growing animation library in the ecosystem. It even just passed 10 million downloads per month.

Licensing
Motion is fully independent and MIT open source. It's supported by a mix of incredible industry-leading sponsors like Framer, Figma and Vercel, as well as sales from Motion+.
GSAP, by contrast, is closed source and owned and funded by Webflow. While it can be used for free in many projects, its license contains a critical restriction: You're prohibited from using GSAP in any tool that competes with Webflow. Furthermore, its license states that Webflow can terminate it at its discretion.
With Motion, you have a guarantee of freedom. That MIT license is irrevocable. You will never be forced to remove and replace your animation library because of a business decision made by another company. This provides the stability and peace of mind that professional development teams require.
Motion's independence and self-sufficiency means we work with a broad base of users and companies, creating a library that works for the whole web, rather than the interests of a single company.
Performance
Performance is more than just smooth animations. It's about providing a flawless 120fps, faster start-up times, and minimal bundle sizes. This is where Motion's modern architecture provides an advantage.
Hardware accelerated animations
You might already know that for best animation performance you should stick to animating opacity
, transform
, filter
and clipPath
, because these styles can be rendered entirely on the GPU.
But when animating with Motion, these values can enjoy an extra performance boost using "hardware accelerated" animations. This means the animations themselves also run entirely the GPU - separate from the JavaScript running on your CPU.
This means if your website or app is performing heavy work, animations remain smooth.
To illustrate, in the following example the ball on the left is animated with Motion, and the ball on the right by a traditional animation library. Press the "Block JavaScript" button to block JS execution for two seconds:
In the majority of browsers, the left ball will continue animating at 60/120fps, even as the website becomes unresponsive. Traditional animation libraries like GSAP will pause and stutter where Motion remains perfectly smooth.
What's more, Motion can even perform hardware accelerated scroll animations. Because browsers render all scroll on the GPU, JS-based scroll animations are always slightly out-of-sync. Not so with Motion.
const animation = animate(element, { opacity: [0, 1] }) scroll(animation)
Start-up time
Two animate any two values, they have to be mixable. Think, two numbers, or two colors. But what if we want to perform an animation where we don't even know the initial value? Or we do - but it's a value like height: auto
, or a color defined in a CSS variable like var(—my-color)
?
To make these values mixable, the library first needs to measure them. But measuring something that's just been rendered forces a layout or style calculation. These are slow.
To solve this, Motion introduced deferred keyframe resolution. This ensures we batch all measurements into a single operation, drastically reducing style and layout calculations.
In benchmarks, Motion is 2.5x faster than GSAP at animating from unknown values, and 6x faster at animating between different value types.

This is great for user experience, and also great for performance scores like Interaction to Next Paint (INP).
Bundle size
Motion is built with a modern, modular architecture. If your bundler supports tree-shaking (like Vite, Rollup or Webpack), you only ever include the code you actually use. GSAP's older architecture, by contrast, means that importing any part of the library includes all of it.
This, combined with Motion's focus on leveraging native browser APIs, results in a significantly smaller footprint.
Library | Size |
---|---|
| 2.6kb |
| 18kb |
GSAP | 23kb |
A smaller bundle means a faster site load and a better user experience, especially on mobile devices. With Motion, you can deliver stunning animations with a minimal performance cost.
Features
Of course, performance means little if a library can't deliver the features you need. While there is plenty of overlap, both libraries have unique strengths.
React & Vue APIs
Motion provides a first-class, declarative API that is a natural extension of React and Vue. Animations are defined directly in your components via props, keeping your code clean, readable and easy to maintain.
<motion.div animate={{ x: 100 }} />
GSAP, by contrast, uses an imperative model. While it has a useGSAP
hook to help integrate into React's lifecycles, it still requires using refs. Mixing its imperative API into React's declarative components leads to more verbose and error-prone code.
const container = useRef() useGSAP(() => { gsap.to(".box", { x: 100 }) }, { scope: container }) return ( <div ref={container}> <div className="box"></div> </div> );
Furthermore, Motion for React and Vue features an industry-leading layout animation engine, which goes far beyond the FLIP animations in GSAP.
Full feature comparison table
This table compares Motion's mini and full-size animate
functions functions with GSAP's gsap
object.
Key
✅ Supported
❌ Not supported
⏩ Support relies on modern browser features
🚧 In development
⚠ Partial support
⚛️ React/Vue only
|
| GSAP | |
---|---|---|---|
Core bundlesize (kb) | 2.6 | 17 | 23.5 |
General | |||
MIT license | ✅ | ✅ | ❌ |
Accelerated animations | ✅ | ✅ | ❌ |
❌ | ✅ (+15kb) | ❌ | |
❌ | ✅ (+15kb) | ❌ | |
Values | |||
Individual transforms | ❌ | ✅ | ✅ |
✅ | ❌ | ✅ | |
✅ | ❌ | ⚠ (20) | |
✅ | ✅ | ✅ | |
✅ | ✅ | ❌ | |
To/from CSS | ✅ | ❌ | ❌ |
Animate CSS | ✅ ⏩ | ✅ | ✅ |
Simple keyframes syntax | ✅ | ✅ | ✅ |
Wildcard keyframes | ✅ | ✅ | ❌ |
Relative values | ❌ | ❌ | ✅ |
Output | |||
Element styles | ✅ | ✅ | ✅ |
Element attributes | ❌ | ✅ | ✅ |
Custom animations | ❌ | ✅ | ✅ |
Options | |||
Duration | ✅ | ✅ | ✅ |
Direction | ✅ | ✅ | ✅ |
Repeat | ✅ | ✅ | ✅ |
Delay | ✅ | ✅ | ✅ |
End delay | ✅ | ❌ | ✅ |
Repeat delay | ❌ | ✅ | ✅ |
Stagger | |||
Stagger | ✅ (+0.1kb) | ✅ (+0.1kb) | ✅ |
Min delay | ✅ | ✅ | ✅ |
Ease | ✅ | ✅ | ✅ |
Grid | ❌ | ❌ | ✅ |
Layout | |||
Animate layout | ❌ | ✅ | ⚠ (FLIP) |
Transform-only | ❌ | ⚛️ | ❌ |
Scale correction | ❌ | ⚛️ | ❌ |
Timeline | |||
Timeline | ✅ (+0.6kb) | ✅ | ✅ |
Selectors | ✅ | ✅ | ✅ |
Relative offsets | ✅ | ✅ | ✅ |
Absolute offsets | ✅ | ✅ | ✅ |
Start of previous | ✅ | ✅ | ✅ |
Percentage offsets | ❌ | ❌ | ✅ |
Label offsets | ✅ | ✅ | ✅ |
Segment stagger | ✅ | ✅ | ✅ |
Segment keyframes | ✅ | ✅ | ❌ |
Controls | |||
Play | ✅ | ✅ | ✅ |
Pause | ✅ | ✅ | ✅ |
Finish | ✅ | ✅ | ✅ |
Reverse | ❌ | ❌ | ✅ |
Stop | ✅ | ✅ | ✅ |
Playback rate | ✅ | ✅ | ✅ |
Easing | |||
Linear | ✅ | ✅ | ✅ |
Cubic bezier | ✅ | ✅ | ✅ |
Steps | ✅ | ✅ | ✅ |
Spring | ✅ (+1kb) | ✅ | ❌ |
Spring physics | ❌ | ✅ | ❌ |
Inertia | ❌ | ✅ | ✅ |
Custom easing | ✅ ⏩ | ✅ | ✅ |
Events | |||
Complete | ✅ | ✅ | ✅ |
Cancel | ✅ | ✅ | ✅ |
Start | ❌ | ✅ | ✅ |
Update | ❌ | ✅ | ✅ |
Repeat | ❌ | ❌ | ✅ |
Path | |||
Motion path | ✅ ⏩ | ✅ ⏩ | ✅ (+9.5kb) |
❌ | ✅ (+Flubber) | ✅ | |
Path drawing | ✅ | ✅ | ✅ |
Scroll | |||
✅ (+0.5kb) | ✅ (+0.5kb) | ✅ (+12kb) | |
✅ (+2.5kb) | ✅ (+2.5kb) | ✅ (+12kb) | |
Hardware accelerated | ✅ | ✅ | ❌ |
Extra Features | |||
AnimateNumber | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
Cursor | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
Split Text | ✅ (Motion+) | ✅ (Motion+) | ✅ |
Ticker | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
Typewriter | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
View animations | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
Conclusion
Both Motion and GSAP are powerful, production-ready libraries capable of creating stunning, award-winning animations. The best choice depends entirely on the priorities of your project and team.
When to use Motion?
You should choose Motion if your priority is overall performance, a smaller bundle size, and a modern developer experience. Its use of native browser APIs, first-class React/Vue support, and truly open-source MIT license make it the definitive choice for building fast, modern web applications.
When to use GSAP?
You might still prefer GSAP if your project requires intricate, timeline-sequenced animations on non-React sites. Its maturity and long history mean it is a reliable, if more traditional, choice.
When deciding which JavaScript animation library to trust for your project, two libraries often get mentioned because of their feature set and popularity: Motion (formerly Framer Motion) and GSAP (formerly GreenSock).
Both can create stunning animations, but they have fundamental differences. This guide compares Motion and GSAP on adoption, licensing, performance, and features (complete with full comparison table), to help you decide which is right for your project.
Adoption
Before delving into the libraries themselves, it's helpful to see what other developers are choosing. For modern applications, npm is a great measure of a library's adoption and momentum.
Here, the numbers are clear: Motion is growing exponentially, making it the most-used and fastest-growing animation library in the ecosystem. It even just passed 10 million downloads per month.

Licensing
Motion is fully independent and MIT open source. It's supported by a mix of incredible industry-leading sponsors like Framer, Figma and Vercel, as well as sales from Motion+.
GSAP, by contrast, is closed source and owned and funded by Webflow. While it can be used for free in many projects, its license contains a critical restriction: You're prohibited from using GSAP in any tool that competes with Webflow. Furthermore, its license states that Webflow can terminate it at its discretion.
With Motion, you have a guarantee of freedom. That MIT license is irrevocable. You will never be forced to remove and replace your animation library because of a business decision made by another company. This provides the stability and peace of mind that professional development teams require.
Motion's independence and self-sufficiency means we work with a broad base of users and companies, creating a library that works for the whole web, rather than the interests of a single company.
Performance
Performance is more than just smooth animations. It's about providing a flawless 120fps, faster start-up times, and minimal bundle sizes. This is where Motion's modern architecture provides an advantage.
Hardware accelerated animations
You might already know that for best animation performance you should stick to animating opacity
, transform
, filter
and clipPath
, because these styles can be rendered entirely on the GPU.
But when animating with Motion, these values can enjoy an extra performance boost using "hardware accelerated" animations. This means the animations themselves also run entirely the GPU - separate from the JavaScript running on your CPU.
This means if your website or app is performing heavy work, animations remain smooth.
To illustrate, in the following example the ball on the left is animated with Motion, and the ball on the right by a traditional animation library. Press the "Block JavaScript" button to block JS execution for two seconds:
In the majority of browsers, the left ball will continue animating at 60/120fps, even as the website becomes unresponsive. Traditional animation libraries like GSAP will pause and stutter where Motion remains perfectly smooth.
What's more, Motion can even perform hardware accelerated scroll animations. Because browsers render all scroll on the GPU, JS-based scroll animations are always slightly out-of-sync. Not so with Motion.
const animation = animate(element, { opacity: [0, 1] }) scroll(animation)
Start-up time
Two animate any two values, they have to be mixable. Think, two numbers, or two colors. But what if we want to perform an animation where we don't even know the initial value? Or we do - but it's a value like height: auto
, or a color defined in a CSS variable like var(—my-color)
?
To make these values mixable, the library first needs to measure them. But measuring something that's just been rendered forces a layout or style calculation. These are slow.
To solve this, Motion introduced deferred keyframe resolution. This ensures we batch all measurements into a single operation, drastically reducing style and layout calculations.
In benchmarks, Motion is 2.5x faster than GSAP at animating from unknown values, and 6x faster at animating between different value types.

This is great for user experience, and also great for performance scores like Interaction to Next Paint (INP).
Bundle size
Motion is built with a modern, modular architecture. If your bundler supports tree-shaking (like Vite, Rollup or Webpack), you only ever include the code you actually use. GSAP's older architecture, by contrast, means that importing any part of the library includes all of it.
This, combined with Motion's focus on leveraging native browser APIs, results in a significantly smaller footprint.
Library | Size |
---|---|
| 2.6kb |
| 18kb |
GSAP | 23kb |
A smaller bundle means a faster site load and a better user experience, especially on mobile devices. With Motion, you can deliver stunning animations with a minimal performance cost.
Features
Of course, performance means little if a library can't deliver the features you need. While there is plenty of overlap, both libraries have unique strengths.
React & Vue APIs
Motion provides a first-class, declarative API that is a natural extension of React and Vue. Animations are defined directly in your components via props, keeping your code clean, readable and easy to maintain.
<motion.div animate={{ x: 100 }} />
GSAP, by contrast, uses an imperative model. While it has a useGSAP
hook to help integrate into React's lifecycles, it still requires using refs. Mixing its imperative API into React's declarative components leads to more verbose and error-prone code.
const container = useRef() useGSAP(() => { gsap.to(".box", { x: 100 }) }, { scope: container }) return ( <div ref={container}> <div className="box"></div> </div> );
Furthermore, Motion for React and Vue features an industry-leading layout animation engine, which goes far beyond the FLIP animations in GSAP.
Full feature comparison table
This table compares Motion's mini and full-size animate
functions functions with GSAP's gsap
object.
Key
✅ Supported
❌ Not supported
⏩ Support relies on modern browser features
🚧 In development
⚠ Partial support
⚛️ React/Vue only
|
| GSAP | |
---|---|---|---|
Core bundlesize (kb) | 2.6 | 17 | 23.5 |
General | |||
MIT license | ✅ | ✅ | ❌ |
Accelerated animations | ✅ | ✅ | ❌ |
❌ | ✅ (+15kb) | ❌ | |
❌ | ✅ (+15kb) | ❌ | |
Values | |||
Individual transforms | ❌ | ✅ | ✅ |
✅ | ❌ | ✅ | |
✅ | ❌ | ⚠ (20) | |
✅ | ✅ | ✅ | |
✅ | ✅ | ❌ | |
To/from CSS | ✅ | ❌ | ❌ |
Animate CSS | ✅ ⏩ | ✅ | ✅ |
Simple keyframes syntax | ✅ | ✅ | ✅ |
Wildcard keyframes | ✅ | ✅ | ❌ |
Relative values | ❌ | ❌ | ✅ |
Output | |||
Element styles | ✅ | ✅ | ✅ |
Element attributes | ❌ | ✅ | ✅ |
Custom animations | ❌ | ✅ | ✅ |
Options | |||
Duration | ✅ | ✅ | ✅ |
Direction | ✅ | ✅ | ✅ |
Repeat | ✅ | ✅ | ✅ |
Delay | ✅ | ✅ | ✅ |
End delay | ✅ | ❌ | ✅ |
Repeat delay | ❌ | ✅ | ✅ |
Stagger | |||
Stagger | ✅ (+0.1kb) | ✅ (+0.1kb) | ✅ |
Min delay | ✅ | ✅ | ✅ |
Ease | ✅ | ✅ | ✅ |
Grid | ❌ | ❌ | ✅ |
Layout | |||
Animate layout | ❌ | ✅ | ⚠ (FLIP) |
Transform-only | ❌ | ⚛️ | ❌ |
Scale correction | ❌ | ⚛️ | ❌ |
Timeline | |||
Timeline | ✅ (+0.6kb) | ✅ | ✅ |
Selectors | ✅ | ✅ | ✅ |
Relative offsets | ✅ | ✅ | ✅ |
Absolute offsets | ✅ | ✅ | ✅ |
Start of previous | ✅ | ✅ | ✅ |
Percentage offsets | ❌ | ❌ | ✅ |
Label offsets | ✅ | ✅ | ✅ |
Segment stagger | ✅ | ✅ | ✅ |
Segment keyframes | ✅ | ✅ | ❌ |
Controls | |||
Play | ✅ | ✅ | ✅ |
Pause | ✅ | ✅ | ✅ |
Finish | ✅ | ✅ | ✅ |
Reverse | ❌ | ❌ | ✅ |
Stop | ✅ | ✅ | ✅ |
Playback rate | ✅ | ✅ | ✅ |
Easing | |||
Linear | ✅ | ✅ | ✅ |
Cubic bezier | ✅ | ✅ | ✅ |
Steps | ✅ | ✅ | ✅ |
Spring | ✅ (+1kb) | ✅ | ❌ |
Spring physics | ❌ | ✅ | ❌ |
Inertia | ❌ | ✅ | ✅ |
Custom easing | ✅ ⏩ | ✅ | ✅ |
Events | |||
Complete | ✅ | ✅ | ✅ |
Cancel | ✅ | ✅ | ✅ |
Start | ❌ | ✅ | ✅ |
Update | ❌ | ✅ | ✅ |
Repeat | ❌ | ❌ | ✅ |
Path | |||
Motion path | ✅ ⏩ | ✅ ⏩ | ✅ (+9.5kb) |
❌ | ✅ (+Flubber) | ✅ | |
Path drawing | ✅ | ✅ | ✅ |
Scroll | |||
✅ (+0.5kb) | ✅ (+0.5kb) | ✅ (+12kb) | |
✅ (+2.5kb) | ✅ (+2.5kb) | ✅ (+12kb) | |
Hardware accelerated | ✅ | ✅ | ❌ |
Extra Features | |||
AnimateNumber | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
Cursor | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
Split Text | ✅ (Motion+) | ✅ (Motion+) | ✅ |
Ticker | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
Typewriter | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
View animations | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
Conclusion
Both Motion and GSAP are powerful, production-ready libraries capable of creating stunning, award-winning animations. The best choice depends entirely on the priorities of your project and team.
When to use Motion?
You should choose Motion if your priority is overall performance, a smaller bundle size, and a modern developer experience. Its use of native browser APIs, first-class React/Vue support, and truly open-source MIT license make it the definitive choice for building fast, modern web applications.
When to use GSAP?
You might still prefer GSAP if your project requires intricate, timeline-sequenced animations on non-React sites. Its maturity and long history mean it is a reliable, if more traditional, choice.
When deciding which JavaScript animation library to trust for your project, two libraries often get mentioned because of their feature set and popularity: Motion (formerly Framer Motion) and GSAP (formerly GreenSock).
Both can create stunning animations, but they have fundamental differences. This guide compares Motion and GSAP on adoption, licensing, performance, and features (complete with full comparison table), to help you decide which is right for your project.
Adoption
Before delving into the libraries themselves, it's helpful to see what other developers are choosing. For modern applications, npm is a great measure of a library's adoption and momentum.
Here, the numbers are clear: Motion is growing exponentially, making it the most-used and fastest-growing animation library in the ecosystem. It even just passed 10 million downloads per month.

Licensing
Motion is fully independent and MIT open source. It's supported by a mix of incredible industry-leading sponsors like Framer, Figma and Vercel, as well as sales from Motion+.
GSAP, by contrast, is closed source and owned and funded by Webflow. While it can be used for free in many projects, its license contains a critical restriction: You're prohibited from using GSAP in any tool that competes with Webflow. Furthermore, its license states that Webflow can terminate it at its discretion.
With Motion, you have a guarantee of freedom. That MIT license is irrevocable. You will never be forced to remove and replace your animation library because of a business decision made by another company. This provides the stability and peace of mind that professional development teams require.
Motion's independence and self-sufficiency means we work with a broad base of users and companies, creating a library that works for the whole web, rather than the interests of a single company.
Performance
Performance is more than just smooth animations. It's about providing a flawless 120fps, faster start-up times, and minimal bundle sizes. This is where Motion's modern architecture provides an advantage.
Hardware accelerated animations
You might already know that for best animation performance you should stick to animating opacity
, transform
, filter
and clipPath
, because these styles can be rendered entirely on the GPU.
But when animating with Motion, these values can enjoy an extra performance boost using "hardware accelerated" animations. This means the animations themselves also run entirely the GPU - separate from the JavaScript running on your CPU.
This means if your website or app is performing heavy work, animations remain smooth.
To illustrate, in the following example the ball on the left is animated with Motion, and the ball on the right by a traditional animation library. Press the "Block JavaScript" button to block JS execution for two seconds:
In the majority of browsers, the left ball will continue animating at 60/120fps, even as the website becomes unresponsive. Traditional animation libraries like GSAP will pause and stutter where Motion remains perfectly smooth.
What's more, Motion can even perform hardware accelerated scroll animations. Because browsers render all scroll on the GPU, JS-based scroll animations are always slightly out-of-sync. Not so with Motion.
const animation = animate(element, { opacity: [0, 1] }) scroll(animation)
Start-up time
Two animate any two values, they have to be mixable. Think, two numbers, or two colors. But what if we want to perform an animation where we don't even know the initial value? Or we do - but it's a value like height: auto
, or a color defined in a CSS variable like var(—my-color)
?
To make these values mixable, the library first needs to measure them. But measuring something that's just been rendered forces a layout or style calculation. These are slow.
To solve this, Motion introduced deferred keyframe resolution. This ensures we batch all measurements into a single operation, drastically reducing style and layout calculations.
In benchmarks, Motion is 2.5x faster than GSAP at animating from unknown values, and 6x faster at animating between different value types.

This is great for user experience, and also great for performance scores like Interaction to Next Paint (INP).
Bundle size
Motion is built with a modern, modular architecture. If your bundler supports tree-shaking (like Vite, Rollup or Webpack), you only ever include the code you actually use. GSAP's older architecture, by contrast, means that importing any part of the library includes all of it.
This, combined with Motion's focus on leveraging native browser APIs, results in a significantly smaller footprint.
Library | Size |
---|---|
| 2.6kb |
| 18kb |
GSAP | 23kb |
A smaller bundle means a faster site load and a better user experience, especially on mobile devices. With Motion, you can deliver stunning animations with a minimal performance cost.
Features
Of course, performance means little if a library can't deliver the features you need. While there is plenty of overlap, both libraries have unique strengths.
React & Vue APIs
Motion provides a first-class, declarative API that is a natural extension of React and Vue. Animations are defined directly in your components via props, keeping your code clean, readable and easy to maintain.
<motion.div animate={{ x: 100 }} />
GSAP, by contrast, uses an imperative model. While it has a useGSAP
hook to help integrate into React's lifecycles, it still requires using refs. Mixing its imperative API into React's declarative components leads to more verbose and error-prone code.
const container = useRef() useGSAP(() => { gsap.to(".box", { x: 100 }) }, { scope: container }) return ( <div ref={container}> <div className="box"></div> </div> );
Furthermore, Motion for React and Vue features an industry-leading layout animation engine, which goes far beyond the FLIP animations in GSAP.
Full feature comparison table
This table compares Motion's mini and full-size animate
functions functions with GSAP's gsap
object.
Key
✅ Supported
❌ Not supported
⏩ Support relies on modern browser features
🚧 In development
⚠ Partial support
⚛️ React/Vue only
|
| GSAP | |
---|---|---|---|
Core bundlesize (kb) | 2.6 | 17 | 23.5 |
General | |||
MIT license | ✅ | ✅ | ❌ |
Accelerated animations | ✅ | ✅ | ❌ |
❌ | ✅ (+15kb) | ❌ | |
❌ | ✅ (+15kb) | ❌ | |
Values | |||
Individual transforms | ❌ | ✅ | ✅ |
✅ | ❌ | ✅ | |
✅ | ❌ | ⚠ (20) | |
✅ | ✅ | ✅ | |
✅ | ✅ | ❌ | |
To/from CSS | ✅ | ❌ | ❌ |
Animate CSS | ✅ ⏩ | ✅ | ✅ |
Simple keyframes syntax | ✅ | ✅ | ✅ |
Wildcard keyframes | ✅ | ✅ | ❌ |
Relative values | ❌ | ❌ | ✅ |
Output | |||
Element styles | ✅ | ✅ | ✅ |
Element attributes | ❌ | ✅ | ✅ |
Custom animations | ❌ | ✅ | ✅ |
Options | |||
Duration | ✅ | ✅ | ✅ |
Direction | ✅ | ✅ | ✅ |
Repeat | ✅ | ✅ | ✅ |
Delay | ✅ | ✅ | ✅ |
End delay | ✅ | ❌ | ✅ |
Repeat delay | ❌ | ✅ | ✅ |
Stagger | |||
Stagger | ✅ (+0.1kb) | ✅ (+0.1kb) | ✅ |
Min delay | ✅ | ✅ | ✅ |
Ease | ✅ | ✅ | ✅ |
Grid | ❌ | ❌ | ✅ |
Layout | |||
Animate layout | ❌ | ✅ | ⚠ (FLIP) |
Transform-only | ❌ | ⚛️ | ❌ |
Scale correction | ❌ | ⚛️ | ❌ |
Timeline | |||
Timeline | ✅ (+0.6kb) | ✅ | ✅ |
Selectors | ✅ | ✅ | ✅ |
Relative offsets | ✅ | ✅ | ✅ |
Absolute offsets | ✅ | ✅ | ✅ |
Start of previous | ✅ | ✅ | ✅ |
Percentage offsets | ❌ | ❌ | ✅ |
Label offsets | ✅ | ✅ | ✅ |
Segment stagger | ✅ | ✅ | ✅ |
Segment keyframes | ✅ | ✅ | ❌ |
Controls | |||
Play | ✅ | ✅ | ✅ |
Pause | ✅ | ✅ | ✅ |
Finish | ✅ | ✅ | ✅ |
Reverse | ❌ | ❌ | ✅ |
Stop | ✅ | ✅ | ✅ |
Playback rate | ✅ | ✅ | ✅ |
Easing | |||
Linear | ✅ | ✅ | ✅ |
Cubic bezier | ✅ | ✅ | ✅ |
Steps | ✅ | ✅ | ✅ |
Spring | ✅ (+1kb) | ✅ | ❌ |
Spring physics | ❌ | ✅ | ❌ |
Inertia | ❌ | ✅ | ✅ |
Custom easing | ✅ ⏩ | ✅ | ✅ |
Events | |||
Complete | ✅ | ✅ | ✅ |
Cancel | ✅ | ✅ | ✅ |
Start | ❌ | ✅ | ✅ |
Update | ❌ | ✅ | ✅ |
Repeat | ❌ | ❌ | ✅ |
Path | |||
Motion path | ✅ ⏩ | ✅ ⏩ | ✅ (+9.5kb) |
❌ | ✅ (+Flubber) | ✅ | |
Path drawing | ✅ | ✅ | ✅ |
Scroll | |||
✅ (+0.5kb) | ✅ (+0.5kb) | ✅ (+12kb) | |
✅ (+2.5kb) | ✅ (+2.5kb) | ✅ (+12kb) | |
Hardware accelerated | ✅ | ✅ | ❌ |
Extra Features | |||
AnimateNumber | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
Cursor | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
Split Text | ✅ (Motion+) | ✅ (Motion+) | ✅ |
Ticker | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
Typewriter | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
View animations | ⚛️ (Motion+) | ⚛️ (Motion+) | ❌ |
Conclusion
Both Motion and GSAP are powerful, production-ready libraries capable of creating stunning, award-winning animations. The best choice depends entirely on the priorities of your project and team.
When to use Motion?
You should choose Motion if your priority is overall performance, a smaller bundle size, and a modern developer experience. Its use of native browser APIs, first-class React/Vue support, and truly open-source MIT license make it the definitive choice for building fast, modern web applications.
When to use GSAP?
You might still prefer GSAP if your project requires intricate, timeline-sequenced animations on non-React sites. Its maturity and long history mean it is a reliable, if more traditional, choice.