Search the Community

As the author of GSAP I'm sometimes asked if the Web Animations API (WAAPI) will be used under the hood eventually. My responses have gotten pretty long so I thought I'd share my findings with everyone here. Hopefully this sheds light on the challenges we face and perhaps it can lead to some changes to WAAPI in the future. WAAPI is a native browser technology that's similar to CSS animations, but for JavaScript. It's much more flexible than CSS animations and it taps into the same mechanisms under the hood so that the browser can maximize performance. Overall support is has gotten pretty good but there are multiple levels to the spec, so some browsers may support only "level 1", for example. The hope is that eventually all major browsers will support WAAPI fully. Progress in that direction has been very, very slow. You could think of WAAPI almost like a browser-level GSAP with a bunch of features stripped out. This has led some to suggest that perhaps GSAP should be built on TOP of WAAPI to reduce file size and maximize performance. Ideally, people could tap into the rich GSAP API with all of its extra features while benefiting from the browser's native underpinnings wherever possible. Sounds great, right? Unfortunately, WAAPI has some critical weak spots that make it virtually impossible for GSAP to leverage it under the hood (at least in any practical manner). I don't mean that as a criticism of WAAPI. In fact, I really wanted to find a way to leverage it inside GSAP, but I'll list a few of the top reasons why it doesn't seem feasible below. To be clear, this is NOT a feature comparison or a bunch of reasons why GSAP is "better" - these are things that make it architecturally impossible (or very cumbersome) to build GSAP on WAAPI. Custom easing WAAPI only supports cubic-bezier() for custom easing, meaning it's limited to one segment with two control points. It can't support eases like Bounce, Elastic, Rough, SlowMo, wiggle, ExpoScaleEase, etc. GSAP must support all of those eases plus any ease imaginable (unlimited segments and control points - see the CustomEase page). This alone is a deal-breaker. Expressive animation hinges on rich easing options. Independent transform components The most commonly animated values are translation (x/y position), rotation, and scale (all transform-related) but you cannot control them independently with CSS or WAAPI. For example, try moving (translate) something and then halfway through start rotating it and stagger a scale toward the end: |-------- translateX() ------------| |------ rotate() ------| |---------- translateY() -----------| |-------------- scale(x,y) --------------| Animators NEED to be able to independently control these values in their animations. Additive animations (composite:"add") probably aren't an adequate solution either. It's unrealistic to expect developers to track all the values manually or assume that stacking them on top of each other will deliver expected results - they should be able to just affect the rotation (or whatever) at any time, even if there was a translate() or scale() applied previously. GSAP could track everything for them, of course, but continuously stacking transforms on top of each other seems very inefficient and I imagine it'd hurt performance (every transform is another matrix concatenation under the hood). There is a new spec being proposed for translate, scale, and rotate CSS properties which would certainly help, but it's not a full solution because you still can't control the x/y components independently, or all of the 3D values like rotationX, rotationY, z, etc. This is an essential feature of GSAP that helped it become so popular. Example See the Pen Independent Transforms Demo by GreenSock (@GreenSock) on CodePen. Custom logic on each tick Certain types of animations require custom logic on each tick (like physics or custom rounding/snapping or morphing). Most GSAP plugins rely on this sort of thing (ModifiersPlugin, for example). I'm pretty sure that's impossible with WAAPI, especially with transforms being spun off to a different thread (any dependencies on JS-based logic would bind it to the main thread). Non-DOM targets As far as I know, WAAPI doesn't let you animate arbitrary properties of generic objects, like {myProperty:0}. This is another fundamental feature of GSAP - people can use it to animate any sort of objects including canvas library objects, generic objects, WebGL values, whatever. Global timing controls I don't think WAAPI lets you set a custom frame rate. Also, GSAP's lag smoothing feature requires the ability to tweak the global time (not timeScale - I mean literally the current time so that all the animations are pushed forward or backward). As far as I know, it's impossible with WAAPI. Synchronization (transforms and non-transforms) As demonstrated in this video, one of the hidden pitfalls of spinning transforms off to another thread is that they can lose synchronization with other main-thread-based animations. As far as I know, that hasn't been solved in all browsers. We can't afford to have things getting out-of-sync. Some have proposed that GSAP could just fall back to using a regular requestAnimationFrame loop to handle things that aren't adequately supported by WAAPI but that puts things at risk of falling out of sync. For example, if transforms are running on a separate thread they might keep moving while other parts of the animation (custom properties that get applied somehow in an onUpdate) slow down or jank. Compatibility GSAP has earned a reputation for "just working" across every browser. In order to deliver on that, we'd have to put extra conditional logic throughout GSAP, providing fallbacks when WAAPI isn't available or doesn't support a feature. That would balloon the file size substantially and slow things down. That's a tough pill to swallow. WAAPI still isn't implemented in several major browsers today. And then there are the browser inconsistencies (like the infamous SVG origin quirks) that will likely pop up over time and then we'd have to unplug those parts from WAAPI and maintain the legacy raw-JS mechanisms internally. Historically, there are plenty of cross-browser bugs in natively-implemented technologies, making it feel risky to build on top of. Performance WAAPI has a performance advantage because it can leverage a separate thread whereas JavaScript always runs on the main thread, right? Well, sort of. The only time a separate thread can be used is if transforms and/or opacity are the only things animating on a particular element (or else you run into synchronization issues). Plus there's overhead involved in managing that thread which can also get bogged down. There are tradeoffs either way. Having access to a different thread is fantastic even if it only applies in certain situations. That's probably the biggest reason I wanted to leverage WAAPI originally, but the limitations and tradeoffs are pretty significant, at least as it pertains to our goals with GSAP. Surprisingly, according to my tests GSAP was often faster than WAAPI. For example, in this speed test WAAPI didn't perform as well as GSAP on most devices I tried. Maybe performance will improve over time, but for now be sure to test to ensure that WAAPI is performing well for your animations. File Size To ensure compatibility, GSAP would need all of its current (non-WAAPI) code in place for fallbacks (most browsers won't fully support WAAPI for years) and then we'd need to layer in all the WAAPI-specific code on top of that like conditional logic checking for compatible eases, sensing when the user is attempting something WAAPI can't support, tracking/stacking additive animations, etc. That means file size would actually be far worse if GSAP were built on WAAPI. Some have suggested creating a different adapter/renderer for each tech, like a WebAnimationsAdapter. That way, we could segregate the logic and folks could just load it if they needed it which is clever but it doesn't really solve the problem. For example, some plugins may affect particular CSS properties or attributes, and at some point conditional logic would have to run to say "oh, if they're using the WebAnimationsAdapter, this part won't work so handle it differently". That conditional logic generally makes the most sense to have in the plugin itself (otherwise the adapter file would fill up with extra logic for every possible plugin, bloating file size unnecessarily and separating plugin logic from the plugin itself). So then if anyone uses that plugin, they'd pay a price for that extra logic that's along for the ride. Weighing the Pros & Cons At the end of the day, the list of "pros" must outweigh the "cons" for this to work, and currently that list is quite lopsided. I'd love to find a way to leverage any of the strengths of WAAPI inside GSAP for sure, but it just doesn't seem feasible or beneficial overall. The main benefit I see in using WAAPI inside GSAP is to get the off-the-main-thread-transforms juice but even that only seems useful in relatively uncommon scenarios, and it comes at a very high price. I'm struggling to find another compelling reason to build on WAAPI; GSAP already does everything WAAPI does plus a lot more. I'm hopeful that some of the WAAPI benefits will someday be possible directly in JS so that GSAP wouldn't have to create a dependency on WAAPI to get those. For example, browsers could expose an API that'd let developers tap into that off-the-main-thread transform performance. Ideally, browsers would also fix that hacky matrix()/matrix3d() string-based API and provide a way to set the numeric matrix values directly - that'd probably deliver a nice speed boost. Please chime in if I'm missing something, though. (Contact us or post in the forums) Why use GSAP even if/when WAAPI gets full browser support? Browser bugs/inconsistencies Lots of extra features like morphing, physics, Bezier tweening, text tweening, etc. Infinite easing options (Bounce, Elastic, Rough, SlowMo, ExpoScaleEase, Wiggle, Custom) Independent transform components (position, scale, rotation, etc.) Animate literally any property of any object (not just DOM) Timeline nesting (workflow) GSDevTools Relative values and overwrite management from() tweens are much easier - you don't need to get the current values yourself Familiar API Why WAAPI might be worth a try If you don’t need broad browser support today or any of GSAP’s unique features, you could save some kb by using WAAPI Solid performance, especially for transforms and opacity Always free Again, the goal of this article is NOT to criticize WAAPI at all. I think it's a great step forward for browsers. I just wanted to explain some of the challenges that prevent us from using it under the hood in GSAP, at least as it stands today. EDIT: Brian Birtles, one of the primary authors of the WAAPI spec, reached out and offered to work through the issues and try to find solutions (some of which may involve editing the spec itself) which is great. Rachel Nabors has also worked to connect people and find solutions. Although it may take years before it's realistic to consider building on WAAPI, it's reassuring to have so much support from leaders in the industry who are working hard to move animation forward on the web. 2020 EDIT: Now Brian Birtles is the only one working on WAAPI and he does so on a volunteer basis, so further development of WAAPI has understandably slowed down in recent times.

Feature lists don't always tell the story in a way that's relevant to you as the developer/designer in the trenches, trying to get real work done for real clients. You hear about theoretical benefits of CSS animations or some fancy new library that claims to solve various challenges, but then you discover things fall apart when you actually try to use it or the API is exceedingly cumbersome. You need things to just work. .expander { cursor: pointer; font-weight: 400; position: relative; } section .card{ padding-bottom: 6px; margin-bottom: 10px; padding-left: 35px; padding-top: 6px; box-shadow: none; } .expandable-list { padding-left: 0; } .expandable-content { padding: 0; height: 0; overflow: hidden; } .expander-button { position: absolute; border-radius: 50%; background-color: #BBB; width: 15px; height: 15px; display: inline-block; vertical-align: middle; border: 1px solid #FFF; margin-top: 8px; /* vertically center with heading top: 50%; margin-top: -9px; */ left: -8px; margin-left: -18px; font-size: 0px; } .expander-plus, .expander-minus { position: absolute; background-color: #FFF; display: block; } .expander-plus { width: 1px; height: 7px; left: 6px; top: 3px; } .expander-minus { width: 7px; height: 1px; top: 6px; left: 3px; } .project-post p { font-family: "Lucida Grande", "Lucida Sans Unicode", Helvetica, Arial, Verdana, sans-serif; } .project-post h2 { padding-top: 16px; margin-bottom: 10px; } .expPoint, .project-post .expList li { font-size: 1.1em; list-style: none; line-height: normal; margin: 0px 0px 0px 8px; padding: 6px 4px 4px 20px; position:relative; border: 1px solid rgba(204,204,204,0); } .expPoint, .expContent { font-family: "Lucida Grande", "Lucida Sans Unicode", Helvetica, Arial, Verdana, sans-serif; } .expPoint:hover, .project-post .expList li:hover { background-color:white; border: 1px solid rgb(216,216,216); } .expContent { height: 0px; overflow: hidden; color: #656565; font-size: 0.9em; line-height: 150%; font-weight: normal; margin: 5px 0px 0px 0px; padding-top: 0px; } .toggle { width:6px; height:8px; position:absolute; background-image:url(/_img/toggle_arrow.gif); background-repeat: no-repeat; left: 9px; top: 12px; } .expMore { color: #71b200; text-decoration: underline; font-size:0.8em; } #featureAnimation, #featureBox { background-color:#000; border: 1px solid #333; height: 220px; overflow:hidden; line-height: normal; font-size: 80%; } #featureAnimation { position:relative; visibility:hidden; } #featureBox { position:absolute; } #featureAnimation, #featureBox, #whyGSAP, .featureTextGreen, .featureTextWhite { width: 838px; } #whyGSAP, .featureTextGreen, .featureTextWhite { text-align: center; } #whyGSAP, .featureTextGreen, .featureTextWhite { font-size:50px; position:absolute; font-family: "Lucida Grande", "Lucida Sans Unicode", Helvetica, Arial, Verdana, sans-serif; top:0; } .featureTextGreen { color:#91e600; font-weight: bold; } .featureTextWhite { color:white; font-weight:normal; } .star { position: absolute; width: 16px; height: 16px; display: none; } #browserIcons { top:64px; left: 100px; width: 92px; height: 92px; position: absolute; text-align:left; } #browserIcons img { position:absolute; } .featureTextMinor { color:#CCCCCC; font-weight:normal; font-size:20px; position:absolute; font-family: "Lucida Grande", "Lucida Sans Unicode", Helvetica, Arial, Verdana, sans-serif; visibility:hidden; } .dot { position:absolute; background-color: #91e600; } #ctrl_slider { position:absolute; width: 725px; height:10px; left:18px; top:196px; background: rgba(80,80,80,0.3); border:1px solid rgba(102,102,102,0.5); visibility:hidden; } Why GSAP? Performance Compatibility Other tools fall down in older browsers, but GSAP is remarkably compatible. Scale, rotate & move independently (impossible with CSS animations/transitions) XNJYHQLJYQEW CSS, canvas libraries, colors, beziers, etc. Total control pause(), play(), reverse(), or timeScale() any tween or sequence. GSAP The standard for HTML5 animation replay

When it comes to animation, SVG and GSAP go together like peanut butter and jelly. Chocolate and strawberries. Bacon and...anything. SVG offers the sweet taste of tiny file size plus excellent browser support and the ability to scale graphics infinitely without degradation. They're perfect for building a rich, responsive UI (which includes animation, of course). However, just because every major browser offers excellent support for displaying SVG graphics doesn't mean that animating them is easy or consistent. Each browser has its own quirks and implementations of the SVG spec, causing quite a few challenges for animators. For example, some browsers don't support CSS animations on SVG elements. Some don't recognize CSS transforms (rotation, scale, etc.), and implementation of transform-origin is a mess. Don't worry, GSAP smooths out the rough spots and harmonizes behavior across browsers for you. There are quite a few unique features that GSAP offers specifically for SVG animators. Below we cover some of the things that GSAP does for you and then we have a list of other things to watch out for. This page is intended to be a go-to resource for anyone animating SVG with GSAP. Outline Challenges that GSAP solves for you Scale, rotate, skew, and move using 2D transforms Set the transformOrigin (the point around which rotation and scaling occur) Set transformOrigin without unsightly jumps Transform SVG elements around any point in the SVG canvas Animate SVG attributes like cx, cy, radius, width, etc. Use percentage-based x/y transforms Drag SVG elements (with accurate bounds and hit-testing) Move anything (DOM, SVG) along a path including autorotation, offset, looping, and more Animate SVG strokes Morph SVG paths with differing numbers of points Tips to Avoid Common Gotchas Limitations of SVG Browser support Inspiration Awesome SVG Resources Get Started Quickly with GSAP Challenges that GSAP solves for you GSAP does the best that it can to normalize browser issues and provide useful tools to make animate SVG as easy as it can be. Here are some of the challenges that using GSAP to animate SVG solves for you: Scale, rotate, skew, and move using 2D transforms When using GSAP, 2D transforms on SVG content work exactly like they do on any other DOM element. gsap.to("#gear", {duration: 1, x: 100, y: 100, scale: 0.5, rotation: 180, skewX: 45}); Since IE and Opera don't honor CSS transforms at all, GSAP applies these values via the SVG transform attribute like: <g id="gear" transform="matrix(0.5, 0, 0, 0.5, 100, 0)">...</g> When it comes to animating or even setting 2D transforms in IE, CSS simply is not an option. #gear { /* won't work in IE */ transform: translateX(100px) scale(0.5); } Very few JavaScript libraries take this into account, but GSAP handles this for you behind the scenes so you can get amazing results in IE with no extra hassles. Set the transformOrigin (the point around which rotation and scaling occur) Another unique GSAP feature: use the same syntax you would with normal DOM elements and get the same behavior. For example, to rotate an SVG <rect> that is 100px tall by 100px wide around its center you can do any of the following: gsap.to("rect", {duration: 1, rotation: 360, transformOrigin: "50% 50%"}); //percents gsap.to("rect", {duration: 1, rotation: 360, transformOrigin: "center center"}); //keywords gsap.to("rect", {duration: 1, rotation: 360, transformOrigin: "50px 50px"}); //pixels The demo below shows complete parity between DOM and SVG when setting transformOrigin to various values. We encourage you to test it in all major browsers and devices. With MorphSVG, you can Morph <path> data even if the number (and type) of points is completely different between the start and end shapes! Most other SVG shape morphing tools require that the number of points matches. Morph a <polyline> or <polygon> to a different set of points Convert and replace non-path SVG elements (like <circle>, <rect>, <ellipse>, <polygon>, <polyline>, and <line>) into identical <path>s using MorphSVGPlugin.convertToPath(). Optionally define a "shapeIndex" that controls how the points get mapped. This affects what the in-between state looks like during animation. Simply feed in selector text or an element (instead of passing in raw path data) and the plugin will grab the data it needs from there, making workflow easier. MorphSVGPlugin is a bonus plugin for Club GreenSock members (Shockingly Green and Business Green). Tips to Avoid Common Gotchas There are some things that GSAP can't solve for you. But hopefully this part of the article can help prepare you to avoid them ahead of time! Here are some things to keep in mind when creating and animating SVGs. Vector editor/SVG creation tips: When creating an SVG in Illustrator or Inkscape, create a rectangle the same size as your artboard for when you copy elements out of your vector editor and paste them into a code editor (how-to here). How to quickly reverse the direction of a path in Illustrator (Note: If the Path Direction buttons are not visible in the attributes panel, click the upper right menu of that panel and choose 'Show All'): Open path: Select the pen tool and click on the first point of your path and it will reverse the points. Closed path: Right click the path and make it a compound path, choose menu-window-attributes and then use the Reverse Path Direction buttons. If you're morphing between elements it might be useful to add extra points yourself to simpler shapes where necessary so that MorphSVG doesn't have to guess at where to add points. You can think of masks as clip-paths that allow for alpha as well. When using masks, it's often important to specify which units to use. Use a tool like SVGOMG (or this simpler tool) to minify your SVGs before using them in your projects. Code/animation-related tips: Always set transforms of elements with GSAP (not just CSS). There are quite a few browser bugs related to getting transform values of elements which GSAP can't fix or work around so you should always set the transform of elements with GSAP if you're going to animate that element with GSAP. Always use relative values when animating an SVG element. Using something like y: "+=100" allows you to change the SVG points while keeping the same animation effect as hard coding those values. You can fix some rendering issues (especially in Chrome) by adding a very slight rotation to your tween(s) like rotation: 0.01. If you're having performance issues with your issue, usually the issue is that you have too many elements or are using filters/masks too much. For more information, see this post focused on performance with SVGs. You might like injecting SVGs into your HTML instead of keeping it there directly. You can do this by using a tool like Gulp. You can easily convert between coordinate systems by using MotionPathPlugin's helper functions like .convertCoordinates(). Technique tips/resources: You can animate the viewBox attribute (demo)! You can animate (draw) a dashed line by following the technique outlined in this post. You can animate (draw) lines with varied widths by following the technique outlined in this post. You can animate (draw) handwriting effects by following the technique outlined in this post. You can create dynamic SVG elements! You can animate (draw) a "3D" SVG path. You can fake nested SVG elements (which will be available in SVG 2) by positioning the inner SVG with GSAP and scaling it (demo). You can fake 3D transforms (which will be available in SVG 2) in some cases by either Faking the transform that you need. For example sometimes rotationYs can be replaced by a scaleX instead. Applying the transform to a container instead. If you can limit the elements within the SVG to just the ones you want to transform, this is a great approach. For example, applying a rotationY to the <svg> or <div> containing a <path> instead of applying it to the <path> itself. Limitations of SVG The current SVG spec does not account for 3D transforms. Browser support is varied. Best to test thoroughly and have fallbacks in place. Most browsers don't GPU-accelerate SVG elements. GSAP can't change that. Browser support All SVG features in this article will work in IE9+ and all other major desktop and mobile browsers unless otherwise noted. If you find any cross-browser inconsistencies please don't hesitate to let us know in our support forums. Inspiration The Chris Gannon GSAP Animation collection is great for seeing more SVG animations made with GSAP. Be sure to also check out Chris Gannon's full portfolio on CodePen and follow him on Twitter for a steady influx of inspiration. Awesome SVG Resources SVG Tutorials - MotionTricks The SVG Animation Masterclass - Cassie Evans Understanding SVG Coordinate Systems and Transformations - Sara Soueidan Improving SVG Runtime Performance - Taylor Hunt SVG tips - Louis Hoebregts A Compendium of SVG Information - Chris Coyier Making SVGs Responsive with CSS - Sara Soueidan viewBox newsletter (SVG focus) - Cassie Evans and Louis Hoebregts Get Started Quickly with GSAP Below are a few resources that will get you up and running in no time: Getting Started Guide with Video Sequence Animations like a Pro (video) GSAP Documentation

Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements. While it is backward compatible with most GSAP 2 features, some parts may need to be updated to work properly. Please see the GSAP 3 release notes for details. A post by Carl Schooff, GreenSock's "Geek Ambassador" Hot on the heels of the CSS Myth-Busting article, I'm going to take a deeper look into CSS Animations and how they fit (or don't fit) into a modern animator's workflow. This isn't about simple fades or basic transitions (CSS is great for those); Developers who use animation to tell a story or deliver rich interactivity require a very different workflow than those who are simply doing UI transitions. I'm going to show you exactly where some of the pain points are for a typical project and how they can bring your workflow to a grinding halt. Even relatively simple animations like the one below can become surprisingly cumbersome with CSS. Example of a Simple, "Story-Telling" Animation See the Pen GSAP: Full Version Complete by GreenSock (@GreenSock) on CodePen. Seriously, You guys are beating up on CSS Animations again? Really, I'm not trying to be negative for the sake of being negative. It's just that so many developers are looking for animation tools that accommodate their real-world projects and the industry seems to scream "use CSS!" even though the API doesn't adequately serve the workflow of modern animators who are building immersive experiences or animations that "tell a story". Too many people are being led down a path that results in utter frustration, or at least a lot of wasted time. And no, CSS Animations aren't "evil". In fact, sometimes they're perfectly appropriate (see the CSS Myth-Busting article for details). There are CSS fans who craft animations and proudly shout "Pure CSS! No JS!" as if the grueling effort necessary is a badge of honor. The accomplishment is indeed admirable, and we tip our hats to them. But WOW it's a lot of work and doesn't exactly lend itself to experimentation or easy edits. Quite simply, we aim to change the tide with tools like GSAP. The majority of the GSAP API has been shaped by feedback from real developers in the trenches over the course of many years. The process of animation should be fun and inspiring. Challenge! Still not convinced that GSAP is better suited for professional animators? I'm very interested to see how this animation can be built more effectively. Are you in the CSS-Purist camp? Do you prefer to trigger animations with JavaScript setTimeouts? Maybe you have another library that blows GSAP away. Dig in and build the animation I've been using with your own choice of tools. Below are some resources that should make it easy to get started. When you're done, just drop us a line in the comments or in the forums. Full storyboard showing css values for each key frame: http://codepen.io/GreenSock/pen/DzHBs Starter Pen: http://codepen.io/GreenSock/pen/EsAvF Recommended reading: Myth Busting: CSS Animations vs JavaScript (css-tricks.com guest post) Main GSAP page Jump Start: GSAP JS Cage matches: CSS3 transitions vs GSAP | jQuery vs GSAP 3D Transforms & More CSS3 Goodies Arrive in GSAP JS

Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements. While it is backward compatible with most GSAP 2 features, some parts may need to be updated to work properly. Please see the GSAP 3 release notes for details. Update: don't miss our guest post on css-tricks.com, Myth Busting: CSS Animations vs. JavaScript which provides some additional data, visual examples, and a speed test focused on this topic. Ever since CSS3 "transitions" and "animations" were introduced, they have been widely lauded as the future of animation on the web. It often seems like all the "cool kids" are talking about them. Should you jump on the bandwagon? Is JavaScript animation headed for extinction? How does the new GreenSock Animation Platform (GSAP) fare when it steps into the ring and faces off against the hyped-up tag-team of CSS3 transitions & animations? Does GSAP have the chops to hold its own? Let's find out. Ready...FIGHT! Performance One of the most common arguments in favor of CSS3 animations has been that they're hardware accelerated, thus outperform any JavaScript-based equivalent. The theory is that if you define your transitions/animations directly in css, the browser can worry about all the calculations behind the scenes and tap into hardware and native code to execute them. Sounds awesome. Unfortunately it's not quite that clean. Only certain properties are hardware-accelerated (like 3D transforms and opacity - mostly ones that don't affect document flow) and different browsers handle things differently. Plus every comparison we saw on the web pitted CSS3 transitions against jQuery, but GSAP is up to 20 times faster than jQuery. In our real-world tests, we saw drastic differences in performance among the various browsers and when tested head-to-head against GSAP, CSS3 animations were usually slower! Weird. As expected, however, 3D transforms were indeed faster under heavy stress although in most situations you'd never notice a difference. GSAP is extremely optimized. UPDATE (2015-01-05): There are some interesting (and surprising) performance implications of using CSS animations that aren't widely known. Here's a screencast that shows how Dev Tools doesn't report the overhead involved with CSS animations, some synchronization problems, and how they can drag down the main thread performance more than JS. To see a simple comparison for yourself, select the "Zepto" engine in the speed comparison because it uses CSS3 transitions for its animations, and then compare it to GSAP. Beware that the fps (frames per second) counter in the lower right corner isn't always accurate in some browsers (like recent versions of Safari) when using CSS3 transitions because requestAnimationFrame events [incorrectly] get dispatched even when the screen is clearly not being updated. So the animation may actually be running at a very jerky 10fps, yet 50+ requestAnimationFrame cycles are being triggered by the browser! This exposes another flaw in CSS3 transitions - there's no way to know when updates truly occur. There's only a "complete" event fired at the end of the transition/animation. If anyone knows how to get a more accurate fps counter in Safari while using CSS3 transitions, please let us know. Another performance issue to note in the speed comparison is the clumping that occurs with many engines (including Zepto) under heavy stress, where the stars begin pulsing out in rings instead of a nicely dispersed field. Even though GSAP was faster than CSS3 transitions in the majority of our real-world tests, it's still true that 3D transforms and opacity tweens are faster with CSS3 transitions and it's possible that browsers will be able to further tap into hardware acceleration in the future, so we'll call this round a tie. Feel free to build your own tests to see how things compare in your workflow. Performance winner: TIE Controls This is one of the major weak spots for CSS transitions (its "glass jaw" of sorts). Let's say you invest the time in writing a bunch of css for a whiz-bang animation and then you need to control the whole thing - good luck with that. It is virtually impossible. GSAP's object oriented architecture allows you to pause, resume, reverse, restart, or seek to any spot in any tween. Even adjust timeScale on the fly for slow motion or fastforward effects. Place tweens in a timeline with precise scheduling (including overlaps or gaps) and then control the whole thing just like it's a single tween. All of the easing and effects remain perfectly intact as you reverse, adjust timeScale, etc. (with CSS transitions, easing flip-flops upon reverse). You can even kill individual portions of a tween anytime (like if a tween is controlling both "top" and "left" properties, you can kill "left" while "top" continues). Put labels in a timeline to mark important spots and seek() to them anytime. Imagine trying to build the example below using CSS transitions. It would be virtually impossible. With GSAP, it's easy. In fact, all of the animation is done with 2 lines of code. Drag the scrubber, click the buttons below, and see how easy it is to control the sequenced animation. Controls winner: GSAP Tweenable Properties Both competitors can animate transforms (2D and 3D), colors, borderRadius, boxShadow, and pretty much every important property, but there's one key shortcoming of CSS - you cannot animate individual transforms distinctly! For example, try rotating an object and then halfway through that animation, start scaling it with a different ease and finish at a different time. Since all transforms (scaleX, scaleY, rotation, rotationX, rotationY, skewX, skewY, x, y, and z) are all mashed into one "transform" property, it's virtually impossible to handle them distinctly. GSAP not only works around this limitation, but it also allows you to do advanced things like animate along Bezier paths or do momentum-based motion (with ThrowPropsPlugin) or relative tweens or animate the scroll position or do directional rotation or physics-based motion, etc. Plus GSAP can animate any numeric property of any object, not just DOM elements. Do you really want to use one toolset (CSS) for animating DOM elements and then have to switch to a completely different toolset and syntax when you do canvas-based animation? GSAP handles both consistently. CSS transitions and animations just can't compete here. Tweenable properties winner: GSAP Workflow When you're creating fun and interesting animations, workflow is critical. You need to be able to quickly build sequences, stagger start times, overlap tweens, experiment with eases, leverage various callbacks and labels, and create concise code. It would be great to modularize your code by creating functions that each spit back an animation object (tween or timeline) which can be inserted into another timeline at a precise time. You need a flexible, powerful system that lets you experiment without wasting hours. GSAP wipes the floor with CSS transitions in this round. Anyone who has attempted an ambitious project with CSS3 transitions/animations will attest to the fact that they tend to get very cumbersome and verbose. Experimenting with timing and fine-tuning details can get extremely tedious especially when dealing with all the browser prefixes. GSAP CSS3 transitions = supported = unsupported Flexible object-oriented architecture that allows animations to be nested inside other animations as deeply as you want Supported Unsupported Concise code that doesn't require vendor prefixes Supported Unsupported Create sequences (even with overlapping animations) that auto-adjust as you insert/remove/change intermediate pieces of animation (makes experimenting MUCH easier) Supported Unsupported Accommodate virtually any ease including Bounce, Elastic, SlowMo, RoughEase, SteppedEase, etc. Supported Unsupported Animate things into place (backwards) with convenience methods like from() and staggerFrom() Supported Unsupported Callbacks for when an animation starts, updates, completes, repeats, and finishes reversing, plus optionally pass any number of parameters to those callbacks Supported Unsupported Place labels at specific times in a sequence so that you can seek() there (and/or insert animations there) Supported Unsupported Animate any numeric property of any JavaScript object, not just DOM elements (great for canvas-based animation). Supported Unsupported Workflow winner: GSAP Compatibility CSS transitions simply don't work in older browsers, even Internet Explorer 9. GSAP works in all browsers (although some particular features may be disabled, like 3D transforms in IE8). Once again, this round was no contest. GSAP can even do 2D transforms like rotation, scaleX, scaleY, x, y, skewX, and skewY all the way back to IE6 including transformOrigin functionality! Plus it works around scores of other browser issues so that you can focus on the important stuff. Safari's 3D transformOrigin bug? No problem. Firefox's flashing 3D elements bug? No worries. Inconsistency in IE's backgroundPosition values? GSAP has you covered. Vendor prefixes? Nah, GSAP adds 'em for you when necessary. Compatibility winner: GSAP Popularity CSS3 transitions have been talked about (and used) for years all over the web whereas GSAP is relatively new. It can't match CSS3 transitions' popularity. As clients start pushing for more aggressive animations and HTML5 games proliferate and operating systems become very JavaScript-friendly, the balance may very well shift quickly. For now, though, this round goes squarely to CSS transitions. Popularity winner: CSS3 transitions Conflict management What happens if a particular set of properties (like "left" and "top") are animating and then you need to redirect one of those to a different value (like "left" to 100px instead of 300px) using a different ease and duration? With CSS transitions, it's a very complex process. With GSAP, it's simple and automatic. In fact, there are several overwrite modes you can choose from. Conflict management winner: GSAP Support There are numerous places on the web where you can ask the community your CSS transitions-related questions, but GSAP has dedicated support forums where there's rarely a question that remains unanswered for more than 24 hours. GreenSock's forums are manned by paid staff (including the author of the platform), so you're quite likely to get solid answers there. Add to that the fact that GreenSock has a track record of being much more agile in terms of squashing bugs and releasing updates than browsers do for CSS3 transitions, so GSAP gets the upper hand here. Support winner: GSAP Expandability GSAP employs a plugin architecture, making it relatively easy to add features and custom animation properties but CSS transitions have no such equivalent. You're stuck with what the browsers decide to offer. In addition to CSSPlugin, GSAP already has plugins like ScrollToPlugin for scrolling to specific window or div scroll positions, BezierPlugin for animating along Bezier curves, ThrowPropsPlugin for momentum-based motion, and RaphaelPlugin, EaselPlugin, and KineticPlugin for those libraries (Raphael, EaselJS, and KineticJS). Plus there are physics-based plugins like Phyics2DPlugin and PhysicsPropsPlugin as well as a fun ScrambleTextPlugin for Club GreenSock members. More plugins are on their way, and you can create your own too. Expandability winner: GSAP Learning resources Again, the popularity of CSS3 transitions trumps anything GSAP could throw at it right now. There are lots of tutorials, videos, and articles about CSS3 transitions whereas GSAP is new to the game. GreenSock is being aggressive about putting together solid resources (like the Jump Start tour) and the community is crankin' out some great articles and videos too, but CSS3 transitions score the win in this round. Learning resources winner: CSS3 TRANSITIONS Price & license Both CSS3 transitions and GSAP are completely free for almost every type of usage. GSAP allows you to edit the raw source code to fix bugs (if that's something you need to do), but there's no way to edit the source code that drives CSS3 transitions. Then again, there's no special license required to use them either. If you plan to use GSAP in a product/app/site/game for which a fee is collected from multiple customers, you need the commercial license that comes with "Business Green" Club GreenSock memberships (one-off commercial projects don't require the special license). It's actually a more business-friendly license in many ways than a typical open source license that offers no warranties or backing of any kind or imposes code sharing or credit requirements. GreenSock's licensing model provides a small funding mechanism that benefits the entire user base because it empowers continued innovation and support, keeping it free for the vast majority of users. See the licensing page for details. Although there are some clear benefits of GreenSock's model, we'll give this round to CSS3 transitions because using them is technically "free" in more scenarios than GSAP. Price & license winner: CSS3 TRANSITIONS File size This is a tricky round indeed because GSAP requires inclusion of at least 1 JavaScript file whereas CSS3 transitions leverage native code in the browser, but the code you'd have to write to accomplish the same thing in CSS3 animations or transitions is often far more verbose, offsetting the kb savings. For example, let's take a relatively simple sequenced animation (see codepen or jsfiddle? GSAP code: var tl = new TimelineLite(); tl.staggerFrom('.box', 0.5, {opacity:0, scale:0, rotation:-180}, 0.3) .staggerTo('.box', 0.3, {scale:0.8}, 0.3, 0.7); This type of thing is impossible with CSS3 transitions, but it can be done with CSS3 animations as long as we give each element its own class name or ID. Let's take a look at the CSS code (see codepen or jsfiddle? Equivalent CSS3 Animation: .animated { -webkit-animation-fill-mode: both; -moz-animation-fill-mode: both; animation-fill-mode: both; -webkit-animation-duration: 1s; -moz-animation-duration: 1s; animation-duration: 1s; } @-webkit-keyframes introAnimation { 0% { -webkit-transform: scale(0) rotate(-180deg) ; opacity: 0; } 50% { -webkit-transform: scale(1) rotate(0deg) ; opacity: 1; } 70% { -webkit-transform: scale(1) rotate(0deg); } 100% { -webkit-transform: scale(0.8) rotate(0deg); } } @-moz-keyframes introAnimation { 0% { -moz-transform: scale(0) rotate(-180deg); opacity: 0; } 50% { -moz-transform: scale(1) rotate(0deg); opacity: 1; } 70%{ -moz-transform: scale(1) rotate(0deg); } 100% { -moz-transform: scale(0.8) rotate(0deg); } } @keyframes introAnimation { 00% { transform: scale(0) rotate(-180deg); opacity: 0; } 50% { transform: scale(1) rotate(0deg); opacity: 1; } 70%{ transform: scale(1) rotate(0deg); } 100% { transform: scale(0.8) rotate(0deg); } } .introAnimation { -webkit-backface-visibility: visible !important; -webkit-animation-name: introAnimation; -moz-backface-visibility: visible !important; -moz-animation-name: introAnimation; backface-visibility: visible !important; animation-name: introAnimation; } .two { -webkit-animation-delay: 0.3s; -moz-animation-delay: 0.3s; animation-delay: 0.3s; } .three { -webkit-animation-delay: 0.6s; -moz-animation-delay: 0.6s; animation-delay: 0.6s; } .four { -webkit-animation-delay: 0.9s; -moz-animation-delay: 0.9s; animation-delay: 0.9s; } .five { -webkit-animation-delay: 1.2s; -moz-animation-delay: 1.2s; animation-delay: 1.2s; } .six { -webkit-animation-delay: 1.5s; -moz-animation-delay: 1.5s; animation-delay: 1.5s; } .seven { -webkit-animation-delay: 1.8s; -moz-animation-delay: 1.8s; animation-delay: 1.8s; } .eight { -webkit-animation-delay: 2.1s; -moz-animation-delay: 2.1s; animation-delay: 2.1s; } .nine { -webkit-animation-delay: 2.4s; -moz-animation-delay: 2.4s; animation-delay: 2.4s; } As you can see, the CSS3 code is more than 10 times longer! And what if you want to have the entire sequence repeat 3 times? Good luck with that in CSS - you can set an animation-iteration-count but it only applies to each individual element, so it doesn't give us the effect we're after. And what if you want to experiment with the easing or offsets/delays or rotational values? It is quite cumbersome to say the least, even if you use sass or something like that. With GSAP, it's simple. If you only need very simple animations/transitions, CSS3 would deliver smaller file sizes, but once you start getting more aggressive and expressive with your animations, the scales shift quickly and GSAP becomes more economical. The other thing to keep in mind is that GSAP's JS file(s) are typically cached by the browser, so the savings page-to-page is much larger since the code you write on each page is far more concise. In other words, think of how much js/css the browser must actually request from the server over the course of your users' multi-page visit to your site. File size winner: TIE Flexibility Let's face it: basic tweening is pretty straightforward for any system, but it's really the details and advanced features that make a robust platform shine. GSAP crushes CSS3 transitions and animations when it comes to delivering a refined, professional-grade tool set that's truly flexible. Here are just a few of the conveniences baked into GSAP: Tween any numeric property of any object. Optionally round values to the nearest integer to make sure they're always landing on whole pixels/values. Animate along Bezier curves, even rotating along with the path or plotting a smoothly curved Bezier through a set of points you provide (including 3D!). GSAP's Bezier system is super flexible in that it's not just for x/y/z coordinates - it can handle ANY set of properties. Plus it will automatically adjust the movement so that it's correctly proportioned the entire way, avoiding a common problem that plagues Bezier animation systems. You can define Bezier data as Cubic or Quadratic or raw anchor points. Animate any color property of any JavaScript object (not just DOM elements). Define colors in any of the common formats like #F00 or #FF0000 or rgb(255,0,0) or rgba(255,0,0,1) or hsl(30, 50%, 80%) or hsla(30, 50%, 80%, 0.5) or "red". Set a custom fps (frames per second) for the entire engine (the default is 60fps). All tweens are perfectly synchronized (unlike many other tweening engines). Use the modern requestAnimationFrame API to drive refreshes or a standard setTimeout (the default is requestAnimationFrame with a fallback to setTimeout) Tons of easing options including proprietary SlowMo, RoughEase, and SteppedEase along with all the industry standards Animate css style sheet rules themselves with CSSRulePlugin Animate the rotation of an object in a specific direction (clockwise, counter-clockwise, or whichever is shortest) by appending "_cw", "_ccw", and "_short" to the value. You can tween getter/setter methods, not just properties. For example, myObject.getProp() and myObject.setProp() can be tweened like TweenLite.to(myObject, 1, {setProp:10}); and it will automatically recognize that it's a method and call getProp() to get the current value when the tween starts. Same for jQuery-style getters/setters that use a shared method like myObject.prop(). You can even tween another tween or timeline! For example, TweenLite.to(otherTween, 1, {timeScale:0.5}) would animate otherTween.timeScale to 0.5 over the course of 1 second. You can even scrub the virtual playhead of one tween/timeine with another tween by animating its "time". Flexibility winner: GSAP Conclusion Despite the hype surrounding CSS3 transitions and animations, they just aren't well-suited for professional-grade animation tasks. They did manage to win a few rounds in this match but ultimately GSAP man-handled them, sending them running from the ring like scared sissies. Of course we're slightly biased, but check out the facts for yourself. Kick the tires. Audition GSAP on your next project. See how it feels once you get past the initial learning curve. If you only need simple fades or very basic animation in modern browsers, CSS3 transitions are probably just fine. However, what happens when your client wants to do something more expressive? What if browser compatibility becomes an issue? Why not build on a solid foundation to begin with so that you don't find yourself having to rewrite all your animation code? If you want professional-grade scripted animation, look no further. To get started fast, check out our Jump Start tour. Recommended reading: Main GSAP JS page Why GSAP? A practical guide for developers Jump Start: GSAP JS jQuery vs GSAP: cage match 3D Transforms & More CSS3 Goodies Arrive in GSAP JS Speed comparison Explanation of CSS3 transitions, transforms and animations P.S. A rant about where animation logic belongs: We can't put this post to bed without mentioning a beef we've got with the whole concept of putting all your animation logic in css. Ever since the <blink> tag, there has been this tendency for browser vendors to offer developers these nifty "conveniences" that end up encouraging them to mix markup and/or style rules with behavioral logic. Is that really a good idea? One of the wonderful things about the modern web is that we've got this lovely separation between markup, presentation/styling, and behavioral logic (at least that's the goal). Should we be blurring the line like this? Isn't JavaScript the logic layer that should be handling state changes, application logic, reaction to user interaction (which often includes animation), etc.? Some may claim "But putting animation in css is great because that way if the user has JavaScript disabled, the animations still work!" Do you really think users of the modern web can turn off JavaScript and expect to browse the web with great results? Is that who you're targeting for a rich experience? And if they turned off JavaScript, might they have done so specifically to avoid annoying animations? Is it really helping to shift animation logic into css where they can't turn it off? In the web of yesteryear, animations were quite simplistic; fade this, slide that. Done. Anything more aggressive was relegated to a plugin like Flash which afforded incredible richness and complexity in terms of animation. But today, clients want that sort of expressiveness directly in the browser. It needs to work on mobile devices. It's no longer about simple fade-ins or sliding an image across the screen. CSS3 transitions fit the old mentality well, but not the new one. CSS3 animations technically provide more flexibility but they fall miserably short and they still force behavioral logic into the style layer. And to use them effectively, we still need JavaScript to at least swap classes and trigger things. From a development and debugging standpoint, when I apply a class to an element how would I know if that will trigger an animation or transition or neither? Should I have to keep bouncing back and forth between css and JS to manage behavioral logic related to animations? Maybe we're just ill-informed and there are some fantastic reasons for putting behavioral logic like animation into the css layer, but one thing seems pretty clear: the current way that developers have to build all but the simplest css animation leaves a LOT to be desired. The API is terribly limiting and clunky. Let's move the web forward. Let's make animation fun and flexible. Let's keep behavioral logic and style rules distinct. Let's leverage the incredible flexibility of JavaScript. If we've misrepresented anything here or if you want to weigh in with your opinion about where behavioral logic like animation belongs, feel free to post your comment below. If you're someone who has attempted an aggressive animation task with CSS3 transitions/animations as well as GSAP, we'd love to hear how you felt they compared.

The ease-y way to find the perfect ease Easing allows us to add personality and intrigue to our animations. It's the magic behind animation, and a mastery of easing is essential for any skilled animator. Use this tool to play around and understand how various eases "feel". Some eases have special configuration options that open up a world of possibilities. If you need more specifics, head over to the docs. Notice that you can click the underlined words in the code sample at the bottom to make changes. Quick Video Tour of the Ease Visualizer Take your animations to the next level with CustomEase CustomEase frees you from the limitations of canned easing options; create literally any easing curve imaginable by simply drawing it in the Ease Visualizer or by copying/pasting an SVG path. Zero limitations. Use as many control points as you want. CustomEase is NOT in the public downloads. To get access, create a FREE GreenSock account. Once you're logged in, download the zip file from your account dashboard (or anywhere else on the site that has a download button). Club GreenSock members even get access to a private NPM repo to make installation easier in Node environments.