Motion vs Framer Motion vs GSAP: Web Animation Libraries 2026

If you built anything with Framer Motion between 2020 and 2024, you knew the deal: install framer-motion from npm, slap an animate prop on a motion.div, and get buttery layout animations that would have taken days to hand-roll. It was the default React animation library, and for good reason. Then Matt Perry extracted the core engine, dropped the Framer branding, and shipped Motion as a standalone, framework-agnostic animation library. That single move rewrote the competitive map.

At roughly the same time, GreenSock made GSAP completely free for all use cases, including commercial projects. The licensing model that had kept teams away from GSAP for years evaporated overnight. Suddenly the three strongest options for web animation in 2026 are Motion (the spiritual successor to Framer Motion), legacy Framer Motion (still installed in thousands of production apps), and GSAP (now free, still the most powerful timeline engine on the web).

This article is the comparison I wish I had when we were evaluating animation libraries for three simultaneous client projects last quarter. I will cover bundle size, API design, React integration, scroll-triggered animations, layout animations, SVG support, mobile performance, and the practical question of when you should pick each one. No hedging. If you want a broader look at how we evaluate frontend tooling for startups, our ShadCN vs Mantine vs Chakra comparison covers the same philosophy applied to component libraries.

Motion is what Framer Motion becomes when you remove the Framer dependency and rethink the API for a world beyond React. The core engine weighs roughly 17 KB gzipped, which is less than half what GSAP ships. It supports React, Vue, vanilla JavaScript, and any framework that can mount DOM elements. But let's be honest: the React integration is where Motion shines brightest, because that is where the API was born and battle-tested across millions of production apps.

The declarative API is Motion's killer feature. You describe the target state and Motion figures out how to get there. A basic fade-in is one prop: animate={{ opacity: 1 }}. A spring-based scale animation is two props. A staggered list entrance is a parent variant plus a children variant. You never touch requestAnimationFrame. You never calculate intermediate values. You never clean up event listeners on unmount. The library handles all of it, and it handles it correctly even when React's concurrent renderer re-orders commits.

Layout animations deserve their own paragraph because they are genuinely hard to replicate with any other library. When you add the layout prop to a motion component, Motion uses the FLIP technique (First, Last, Invert, Play) to animate between layout states automatically. Reorder a list, toggle a sidebar, expand a card into a modal: Motion calculates the geometric diff and animates it at 60fps. GSAP can do FLIP animations too, but you write significantly more code and you manage the measurement cycle yourself.

The scroll-triggered animation API, whileInView, landed in the Framer Motion era and carried forward into Motion. It is simple, performant, and covers 90% of the scroll animation use cases that marketing sites need. For the other 10%, Motion exposes a lower-level useScroll hook that gives you scroll progress as a motion value you can pipe into any animated property. It uses Intersection Observer under the hood, which means it stays off the main thread until the element enters the viewport.

Where Motion falls short: complex sequenced timelines. If you need twelve elements to animate in a precise choreographed sequence with overlapping start times, easing curves per segment, and the ability to scrub back and forth, Motion's timeline API works but feels clunky compared to GSAP. You end up chaining delays and using orchestration props (staggerChildren, delayChildren) that get unwieldy past five or six steps. Motion is a declarative tool, and declarative tools trade precision for convenience.

Framer Motion is not dead. It still receives maintenance updates, and the npm package (framer-motion) still works fine in production React apps. But new feature development has moved to Motion, and the API surface is slowly diverging. If you have an existing app running framer-motion 10 or 11, the question is not whether to panic. It is whether the migration cost is worth the gains.

The migration path from framer-motion to motion is straightforward for most projects. The core API is nearly identical. You change your import from "framer-motion" to "motion/react", update a few renamed props, and run your test suite. Perry designed the transition to be low-friction because he knew the install base was enormous. In our experience, a medium-sized Next.js app with 40 to 60 animated components takes about a day to migrate, including QA.

The gains you get from migrating: a smaller bundle (Motion tree-shakes more aggressively than framer-motion did), framework-agnostic utilities you can share between React and non-React code, and access to the newer scroll animation primitives that will not be backported. The gains you do not get: a noticeable runtime performance difference. Both libraries use the same animation engine under the hood. If your Framer Motion animations run at 60fps today, they will run at 60fps on Motion too.

My recommendation: if you are starting a new project, use Motion. If you have an existing project on Framer Motion that works well, migrate when you have a natural window, like a major version bump or a redesign sprint. Do not migrate just for the sake of it. The cost is low, but the urgency is also low. Spend that engineering time on features your users will notice.

GSAP (GreenSock Animation Platform) has been the most capable animation library on the web for over a decade. It predates React. It predates ES6. It predates the entire modern frontend stack, and it is still the tool that professional animation studios reach for when a project demands frame-perfect control. The 2024 licensing change, which made GSAP free for all commercial use, removed the last real barrier to adoption.

GSAP's core bundle is roughly 30 KB gzipped. That is larger than Motion's 17 KB, but GSAP packs significantly more into that weight. The timeline engine alone justifies the difference. A GSAP timeline lets you sequence dozens of tweens with precise offsets, overlapping start times, labeled markers, and the ability to scrub, reverse, pause, and restart at any point. For landing page hero animations, product demos, interactive storytelling, and anything where a designer hands you an After Effects comp and says "build this for the web," GSAP timelines are unmatched.

ScrollTrigger, GSAP's scroll animation plugin, is more powerful than Motion's scroll primitives. It supports pin-based scrolling (where an element stays fixed while the user scrolls through a section), scrub-based animations (where scroll position directly controls playback progress), snap points, and batch animations for staggered list reveals. If you have ever seen a marketing site where sections transform fluidly as you scroll, it was probably built with ScrollTrigger.

SVG animation is another area where GSAP dominates. The MorphSVG plugin can morph between arbitrary SVG paths. The DrawSVG plugin animates stroke-dashoffset for drawing effects. MotionPath lets elements follow an SVG path as a motion guide. Motion can animate SVG properties too, but it treats them as generic numeric values. GSAP understands SVG geometry natively, and the difference shows in both developer experience and output quality.

The React integration story is where GSAP stumbles. GSAP is an imperative library. You create tweens by referencing DOM elements directly, which means you need refs, useEffect cleanup, and manual lifecycle management. The official @gsap/react package provides a useGSAP hook that handles cleanup, but the mental model is still "get a ref, build a tween, clean up on unmount." It works. It is reliable. But it is verbose compared to Motion's declarative props, and it requires developers to think about the DOM in ways that React's component model tries to abstract away.

GSAP also does not have layout animations. If you want to animate an element from one position to another after a layout change, you need to use GSAP's Flip plugin, measure the before and after states yourself, and trigger the animation manually. It is powerful and flexible, but it is a lot more code than adding a layout prop to a Motion component.

Bundle size matters more in 2026 than it did three years ago. Core Web Vitals are a ranking factor. Users on mid-range Android devices notice the difference between a 50 KB and a 100 KB JavaScript payload. And animation libraries are particularly sensitive because they run code on every frame, so parse time and execution overhead compound in ways that a static utility library does not.

Here are the real numbers, measured from production builds with tree-shaking enabled:

• Motion (core): ~17 KB gzipped. If you use only basic animations (animate, whileHover, whileTap), tree-shaking drops it closer to 12 KB. Adding layout animations brings it back to 17 KB. Adding scroll primitives pushes it to around 20 KB.
• Framer Motion (legacy): ~22 KB gzipped for a comparable feature set. The larger size comes from React-specific code that Motion refactored into a separate adapter.
• GSAP (core): ~30 KB gzipped. Add ScrollTrigger and you are at 42 KB. Add MorphSVG, DrawSVG, and Flip, and you are approaching 60 KB. GSAP does not tree-shake as aggressively because the plugin architecture assumes you want the full plugin when you import it.

Runtime performance is a different story. GSAP is faster on raw tween throughput. If you are animating 500 particles simultaneously, GSAP's optimized property interpolation will deliver higher frame rates than Motion's spring resolver. This matters for WebGL-adjacent work, generative art, and data visualization with thousands of animated nodes. For typical UI animation, both libraries hit 60fps without breaking a sweat, and the bottleneck is almost always the browser's compositing pipeline, not the JavaScript animation engine.

On mobile, the picture shifts. Motion's spring-based defaults produce animations that feel native on iOS and Android because they match the physics models those platforms use. GSAP's defaults are easing-curve-based (ease, power2.out, elastic), which can feel slightly artificial on mobile unless you tune them. This is a subtle point, but it matters for apps that need to feel like native mobile experiences rather than web pages. If you are building cross-platform with React Native and want consistent animation feel, check our Skia vs Reanimated vs Moti comparison for the native side of this decision.

One more performance consideration: Motion runs animations on the main thread by default but offloads transform and opacity animations to the GPU via CSS transforms. GSAP does the same with its will-change management. Both libraries are smart about compositing, but neither uses the Web Animations API by default, which means neither gets true off-main-thread animation for complex property changes. For most UI work, this does not matter. For heavy animation pages that also run expensive JavaScript, it can cause jank on low-end devices.

The core philosophical difference between Motion and GSAP comes down to one question: do you describe the destination, or do you describe the journey? Motion is declarative. You tell it where to end up, and it figures out the interpolation. GSAP is imperative. You tell it exactly what to do, step by step, frame by frame if you want.

Here is a concrete example. Say you want a card to fade in, slide up 20 pixels, and scale from 0.95 to 1 when it enters the viewport. In Motion, that is a single component with three props:

• initial={{ opacity: 0, y: 20, scale: 0.95 }}
• whileInView={{ opacity: 1, y: 0, scale: 1 }}
• transition={{ duration: 0.5 }}

In GSAP with the useGSAP hook, you create a ref, build a tween inside the hook callback, configure ScrollTrigger as a plugin option, and return cleanup. It is roughly 12 to 15 lines of code for the same visual result. The GSAP version gives you more control (you can pause it, reverse it, scrub it), but the Motion version is faster to write, easier to read, and harder to break.

Now flip the scenario. You need a hero animation with a logo that draws itself via SVG stroke, text that types out letter by letter, a background gradient that shifts through three colors, and all of it synchronized to a 3-second timeline that the user can replay. Motion can technically do this, but you will fight the API. You will chain useAnimate calls, manage motion values manually, and coordinate multiple animation controls. GSAP was built for exactly this. You create a timeline, add tweens with position offsets, and the engine handles synchronization, easing, and playback control.

The practical takeaway: Motion is the better default for product UI. Navigation transitions, modal entrances, toast notifications, loading skeletons, hover effects, drag interactions. These are all declarative problems where you know the start and end states and want the library to handle the middle. GSAP is the better choice for marketing pages, landing page heroes, interactive storytelling, and any animation that a motion designer spec'd in a tool like After Effects or Rive.

A pattern we use at Kanopy Labs for projects that need both: Motion for the product shell (app chrome, navigation, component transitions) and GSAP for the marketing site (hero animations, scroll storytelling, SVG illustrations). The two libraries coexist without conflict. Motion manages React component lifecycles. GSAP manages timeline-driven sequences. They do not step on each other's toes. If your Tailwind setup is already optimized for performance, adding both libraries keeps your total animation budget under 50 KB, which is well within reason for a modern SaaS app.

After shipping production projects with all three libraries this year, here is my honest recommendation broken down by project type.

Pick Motion if: you are building a React (or Next.js, Remix, Astro) application where animation is a UI enhancement, not the main feature. You want layout animations, gesture support, spring physics, and scroll-triggered entrances without writing imperative code. You care about bundle size. You want your animation code to look like your component code. This is the right choice for 80% of SaaS products, dashboards, e-commerce apps, and content platforms. Motion is our default recommendation for new projects at Kanopy Labs.

Pick GSAP if: you are building a marketing site, portfolio, interactive experience, or any project where animation is the product. You need precise timeline sequencing. You need SVG morphing or path animation. You need ScrollTrigger's pinning and scrubbing capabilities. Your animations were designed in After Effects and need to be reproduced exactly. You are working with a dedicated motion designer who thinks in keyframes, not React props. GSAP is also the right choice for non-React projects (vanilla JS, WordPress, Webflow custom code) where Motion's React-first API is irrelevant.

Pick Framer Motion if: you already have it in production and it works. Migrate to Motion when you have a natural window, but do not treat it as urgent. The API is stable, the library is maintained, and your users cannot tell the difference.

Use both Motion and GSAP if: your product has a marketing site with heavy animation and an app with standard UI transitions. This is more common than people think. The combined bundle cost is around 47 KB gzipped, which is less than most component libraries. The two libraries serve different concerns and integrate cleanly.

One final note on team composition. Motion requires React knowledge but minimal animation expertise. Any competent React developer can write effective Motion code in a day. GSAP requires animation knowledge. The API is intuitive for people who understand easing curves, keyframes, and timeline composition, but it can feel foreign to developers who have never thought about animation as a discipline. Factor your team's strengths into the decision.

If you are building a product and need help choosing the right animation strategy, or you are migrating a legacy Framer Motion codebase to the modern stack, we have done this dozens of times. Book a free strategy call and we will walk through your specific requirements.