CSS3 Transitions vs GSAP: Cage Match



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 transitions 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 transitions 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.

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.

Impossible with CSS3 transitions. Easy with GSAP.


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 = supported   unsupported = 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;
    -ms-animation-fill-mode: both;
    -o-animation-fill-mode: both;
    animation-fill-mode: both;
    -webkit-animation-duration: 1s;
    -moz-animation-duration: 1s;
    -ms-animation-duration: 1s;
    -o-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); 
    }
}
@-o-keyframes introAnimation {
    0% {
        -o-transform: scale(0) rotate(-180deg);         
        opacity: 0;            
    }
    
    50% {
        -o-transform: scale(1) rotate(0deg);                    
        opacity: 1;
    }

    70%{
         -o-transform: scale(1) rotate(0deg);
    }

    100% {
        -o-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;
    -o-backface-visibility: visible !important;
    -o-animation-name: introAnimation;
    backface-visibility: visible !important;
    animation-name: introAnimation;
}

.two {
    -webkit-animation-delay: 0.3s;
       -moz-animation-delay: 0.3s;
        -ms-animation-delay: 0.3s;
         -o-animation-delay: 0.3s;
            animation-delay: 0.3s;
}

.three {
    -webkit-animation-delay: 0.6s;
       -moz-animation-delay: 0.6s;
        -ms-animation-delay: 0.6s;
         -o-animation-delay: 0.6s;
            animation-delay: 0.6s;
}

.four {
    -webkit-animation-delay: 0.9s;
       -moz-animation-delay: 0.9s;
        -ms-animation-delay: 0.9s;
         -o-animation-delay: 0.9s;
            animation-delay: 0.9s;
}

.five {
    -webkit-animation-delay: 1.2s;
       -moz-animation-delay: 1.2s;
        -ms-animation-delay: 1.2s;
         -o-animation-delay: 1.2s;
            animation-delay: 1.2s;
}

.six {
    -webkit-animation-delay: 1.5s;
       -moz-animation-delay: 1.5s;
        -ms-animation-delay: 1.5s;
         -o-animation-delay: 1.5s;
            animation-delay: 1.5s;
}

.seven {
    -webkit-animation-delay: 1.8s;
       -moz-animation-delay: 1.8s;
        -ms-animation-delay: 1.8s;
         -o-animation-delay: 1.8s;
            animation-delay: 1.8s;
}

.eight {
    -webkit-animation-delay: 2.1s;
       -moz-animation-delay: 2.1s;
        -ms-animation-delay: 2.1s;
         -o-animation-delay: 2.1s;
            animation-delay: 2.1s;
}

.nine {
    -webkit-animation-delay: 2.4s;
       -moz-animation-delay: 2.4s;
        -ms-animation-delay: 2.4s;
         -o-animation-delay: 2.4s;
            animation-delay: 2.4s;
}

As you can see, the CSS3 code is literally 50 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

GAME OVER

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:

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.

  • Twitter
  • Facebook
  • Digg
  • StumbleUpon
  • del.icio.us
  • Yahoo! Buzz
  • Google Bookmarks
  • RSS
  • LinkedIn
  • Reddit

Comments (34) RSS

Posted by Isaac Chargoy on December 27, 2012

I totally agree!
That’s all…

Posted by Todd on December 27, 2012

How about performance on mobile devices? That’s usually where the CSS3 hardware acceleration is really able to outshine JS-based animations. I agree that the differences are negligible in desktop browsers. How does GSAP compare to CSS3 perf on devices like the iPhone 4/4s/5?

Posted by Jack on December 27, 2012

Todd, according to my tests GSAP did very well on mobile devices including my iPhone 4s and iPad 3, even slightly better than Zepto which uses CSS3 transitions. I’d encourage you to do your own comparisons as well. Here’s one test: http://www.greensock.com/js/speed.html.

Posted by Alec on December 27, 2012

Great article. Would it be feasible to use CSS3 transitions as an “engine” behind GSAP? So when you define a tween with Tweenlite, instead of GSAP calculating and setting css properties every frame, it sets css transition properties on the element at the start. You would lose the ability to track progress of a tween, but it would be a good way to get the best of both worlds.

Posted by Robert on December 27, 2012

I don’t agree. The main excitement about CSS3 animations is hardware acceleration. The future is mobile and javascript is miserable at animation on mobile. Javascript should be used for logic indeed, but animation shouldn’t be part of that logic.

Posted by Jack on December 27, 2012

Alec, it isn’t very feasible to use CSS3 transitions under the hood of GSAP because they have some significant limitations:

  • They can’t accommodate on-the-fly changes to timeScale. We’d have to constantly monitor the parent timeline’s timeScale and if it isn’t 1, we’d have to stop the transition and do things manually thereafter. Messy.
  • They only recognize a subset of the easing options (no Elastic, Bounce, SlowMo, SteppedEase, etc.)
  • They can’t do advanced things like Bezier tweens or kinetic-based animation (ThrowPropsPlugin), physics, motionPaths, etc.
  • They can’t reverse() smoothly with easing intact (easing flip-flops)
  • They don’t work around some browser bugs like Safari’s 3D transformOrigin bug
  • I don’t think it would be possible to ensure that everything remains perfectly synchronized, like if we had to employ a bunch of conditional logic to check if a tween doesn’t use a special ease, isn’t a Bezier/Kinetic/Physics one, is supposed to run at a timeScale of 1, is running in a browser that supports transitions, etc. (qualifies as “legal” for a CSS3 transition) – even if that’s all true, what if that’s running along side a different tween that didn’t qualify – they could get out of sync inside their parent TimelineLite/TimelineMax.
  • Some browsers (like Safari) don’t accurately trigger requestAnimationFrame events with each render, so it would be virtually impossible to accurately fire onUpdate callbacks.

If CSS3 transitions delivered incredible speed boosts over JS-based animation, it might be worth all the extra conditional logic, kb, etc. to implement them under the hood when possible. We’d still need to unhook them when their limitations would otherwise break things. However, it just doesn’t seem like the trade off is worthwhile at this point. I’m seeing GSAP run very fast overall even on mobile devices, often faster than CSS3 transitions! We’ll keep our eyes open for opportunities to leverage any tools the browsers give us to optimize performance, that’s for sure. But we’ve got to ensure that workflow isn’t impaired and that we don’t take a step back in terms of functionality or speed.

Posted by Jack on December 27, 2012

Robert, have you compared GSAP with CSS3 transitions on mobile devices? I’d totally agree with you if you’re comparing jQuery.animate() to CSS3 transitions, but keep in mind that GSAP is significantly faster than jQuery. One of our primary concerns is performance, without a doubt. I think you might be surprised by how well things perform in mobile browsers. I’m hoping that the browser vendors give us a way to tap into hardware acceleration via JS too instead of forcing developers to use CSS rules.

Posted by Robert on December 27, 2012

Jack, I’m with you on the whole GSAP vs everybody else. I was just talking about pure js vs css animations, touching on your argument about keeping logic outside of css. That’s all fine by me as long as I can deliver smooth animations on my client’s smartphone. We’ll see what the future holds and how we might tap into HA with pure js.

Posted by Robert on December 27, 2012

And btw, you all know Ceaser Easing for CSS, right? http://matthewlein.com/ceaser/
There’re lots of eases in there and you could build a custom one like bouce or elastic.

Posted by Matthew Lein on December 27, 2012

I think the overall point here is that CSS3 is only great for simple animations. And most “websites” can take easily advantage of simple animations with transitions to do boring things like fade a tooltip or animate a menu dropdown or accordion. That is the extent of what the vast majority of “websites” do, and CSS3 is perfect for that (and I even like having that logic in CSS). However when a site becomes more of an experience, with interactivity and life, CSS is pushed way past its limit. I think people get caught up in imagining using GSAP for regular ol’ websitey stuff, and I don’t think that’s its goal. Just because something is animated, doesn’t mean its animation.

I have just recently used GSAP in my first project after finding that transitions could not easily do what I wanted in that case. I used about 5% of GSAPs features and it was so perfect for me.

I hate to say the same thing that I’ve read a thousand times, but let the project drive the technology.

Posted by Jack on December 27, 2012

Robert, Matthew Lein (author of Ceaser) is actually a great guy who I’ve met in person. In fact, he was kind enough to just chime in here a few minutes ago. Anyway, I’m pretty sure you can’t get an Elastic or Bounce or SteppedEase or SlowMo ease using the custom Bezier easing option that CSS3 transitions/animations offer (which is what Ceaser trades on) because they only understand 2 control points. If I’m wrong, I’d love to be corrected and shown a way to accomplish it. The only way I’ve seen people simulate it is to literally create a ton of keyframes for a CSS animation which gets incredibly verbose and clunky.

Thanks again for weighing in and offering your thoughts. I’m anxious to see what the browser vendors offer someday in the way of hardware accelerated JS too.

Posted by Jack on December 27, 2012

Matthew, excellent points as usual. Especially pertinent coming from such a well-respected css guy. Thanks for sharing about your experience with GSAP too.

Posted by Robert on December 28, 2012

Thank you Matthew, and Jack, you guys both have great points. GSAP is the best at full rich experiences and css is perfect for small slides and fades (and flips) especially on mobiles. If and when JS could do HA, we’d all be very happy indeed.

Posted by felix on December 28, 2012

Re performance on mobile devices, it’s interesting that the speed test linked above runs better with GSAP (13fps) over Zepto (6 fps) on my iPad 1 in both Chrome and Safari.

Posted by Christian Varga on December 29, 2012

This seems promising and I’m keen to give it a try. Back in the day I used jQuery for every animation: hovers, fades etc. CSS animations are great for simple effects like this. But then I tried to use CSS animations for everything, which I constantly struggle with. Even simple things like fade out to display none are excessively hard with pure css. And dont mention callbacks. I think there’s a line between where CSS animations and javascript ones should be used, yet no one knows where it really is. But after wrestling with CSS animations for so long, I really don’t think they’re the future for complex animations.

Posted by Markus on January 17, 2013

I would very much agree with the project drives the technology, but still there are some ground rules that I’d violate only with very good reasons, and the separation of content, design and functionality is one of them. There are grey areas concerning animations, but if we talk serious animation I’d clearly opt for the third area.

One more thing @Robert: I’ve been around for nearly 20 Years int the business of creating and (re)inventing the web and I’m tired of people saying XXX is the future. Even if the future is mobile, the statement ‘javascript is miserable at animation on mobile’ is one that might hold some truth now, but most likely not in the future. In the here and now the percentage of browsers (even mobile ones) that do not (fully) support CSS-Animation is a far bigger problem.

I’ve used the greensock platform for years now (great work!!!!!!) to solve real world challenges and am quite happy to let the ‘cool kids’ do cool latest-tech projects for show.. ;-)

Posted by Earl on January 20, 2013

The line for when I should use CSS3 animations for me is for hover effects only. I use CSS3 for any hover effects that are designed to show that the element is interactive (clickable, draggable, etc…). In the past I have used them for 3D transitions but GSAP can handle that for me now.

I use JS for everything else. I want complete control and that’s what GSAP offers me.

Posted by Earl on January 21, 2013

I rely heavily on progressive enhancement for degrading to browsers without CSS3 animations, which is why I anything that is task oriented I use GSAP for.

Posted by kuhinje on January 23, 2013

Finaly IE can do all that neat stuff, gj!

Posted by Stefan on March 26, 2013

Very impressed by the library but unfortunately it doesn’t perform well on iPad.
I’ve tested on iPad 3/iOS 6 (really bad combination) and iPad 2/iOS 5.1, and Zepto (translate/scale) easily outperform all other options.

CSS transitions/animations seem to be the best option for performance on iOS.

Posted by Jack on March 26, 2013

Thanks, Stefan. Yeah, Zepto uses CSS3 transitions which don’t work at all in IE before version 10, and they have a bunch of really nasty limitations which make them ill-suited for a professional-grade animation system (too many to list here, but I touched on them above). iOS Safari has some nice optimizations under the hood for transform transitions (x/y/scale/rotation), so that is one area where there’s an advantage for sure. But if you try doing anything except very simple transitions, you’ll quickly see how Zepto (or any transitions-driven solution) breaks down. Try animating “top” and then halfway through that animation, try starting another one for the “left” property. Oops – it breaks the “top” transition and makes it skip to the end (the same problem affects all properties, not just top/left). Try doing advanced eases or animating along a Bezier or seeking/reversing/pausing/resuming or altering the timeScale or independently controlling transform properties or animating non-css properties of generic objects.

Also, keep in mind that the performance advantage in iOS is specific to transforms, NOT all properties. Try the speed test with top/left instead of transforms and you’ll see that (at least on my iPad and iPhone) GSAP is much faster. So, yes, Zepto seems faster on iOS for transforms but it’s slower almost everywhere else with other properties and it doesn’t work at all in IE9 and earlier. Plus there are all the other limitations inherent in CSS3 transitions.

In real-world projects, I think you’ll see that GSAP performs amazingly well on mobile devices. But yes, if you’re only looking at doing simple x/y/scale/rotation on iOS, Zepto (or any CSS3 transitions option) is a great choice. At least that’s the case as of today with iOS, but Apple may very well add some juice to their JS engine in iOS soon like Chrome has done on the desktop. JS has come a LONG way and I suspect it’s going to get even better.

Posted by Tim Itano on April 15, 2013

Awesome. Can you add a share button for Linkedin? I am definitely going to post this to my colleagues.

Posted by Jack on April 15, 2013

Absolutely, Tim. Good idea. Done.

[...] JQuery .animate() and CSS3 transitions and animations; cf. the Jquery-Death-Match and CSS3-Death-Match [...]

Posted by GSAP – Javascript Animation | on July 17, 2013

[...] a look at these very relevant performance comparisons, whereby GSAP is pitted against JQuery and CSS3. Also, have a glance here for a more traditional speed test against other plugins such as Moo [...]

Posted by Ram on August 27, 2013

This is just awesome. Excellent stuff !!!

Though, please note that in Chrome 29 (latest version ) when I played around with the controls sample in this post it caused the browser to crash… I just dragged the scrubber back and forth for sometime and later when I tried to click the buttons it crashed the window.
This did not happen in Firefox.

Posted by Jack on August 27, 2013

Sorry to hear about the trouble, Ram. I just checked in Chrome 29 and it worked flawlessly. No crash at all in Windows or Mac. Nobody else has reported issues like that either. I wonder if it’s an issue specific to your system, unrelated to GSAP. Perhaps it’s a video card driver issue? The good news is that GSAP appears to work great in Chrome 29 (at least from what I can tell).

Posted by Ram on August 27, 2013

Jack, you are almost right about the video card problem, because in the past, I tried to view some demo samples of Babylon.js in Chrome browser ( they worked great ), but they did not work at all in Firefox ( since FF had only partial support for WebGL – http://caniuse.com/#search=webgl )

Now in GSAP’s case it’s seems to be the other way around… ( partially supported in Chrome while works flawlessly in FF ) though I am not sure of the specifics of the reason behind …

I use Win XP SP3.

Posted by fatal on September 18, 2013

Of course GSAP will win all battles on this site..

I’m wondering however why animations in GSAP are so much faster then jQuery, or any other js library.

I mean, there is an interval, a style property and a short formula to update the current frame value of the property.
My first thought is: which part can be optimized.
But I’ll look into it :-)

Posted by jeffreytgilbert on September 19, 2013

Just to be fair, i think it’s important to note that one of the primary benefits of CSS3s hardware acceleration is the battery savings that come from using it. I’m not sure how this is comparable to the greensock animation library, but the lib itself is very impressive just as it was in flash. :)

Posted by Jack on September 20, 2013

Yes, hardware acceleration and battery savings are definitely key considerations. And I think there’s a misperception out there that CSS transitions/animations deliver hardware acceleration (and battery savings) but JS-based animation doesn’t. In reality, though, there’s all sorts of things that can be done in JS that offload compositing to the GPU and limit animation calculations to only when the screen is refreshing and throttling back significantly when the user switches to another tab, for example (to conserve battery). GSAP already does that. For example, using requestAnimationFrame by default. And there’s a force3D flag you can set to make transforms use the GPU-accelerated flavor.

And have you seen CSS transitions performance in iOS 7? I just posted a side-by-side comparison here: http://www.greensock.com/ios7/. It’s shockingly bad. I was expecting hardware acceleration to get better and better, but no dice in iOS 7. Very strange.

Anyway, thanks for chiming in and bringing up the very valid considerations folks should keep in mind.

Posted by Jack on September 20, 2013

You’re absolutely right that ultimately things boil down to running code at an interval that updates style properties. The key, however, is doing that as efficiently as possible within an architecture that delivers a lot of flexibility (sequencing, altering timeScale, reversing on-the-fly, accommodating many different easing effects, plugins, etc.) As far as how GSAP is able to be so fast, there’s no simple answer because it’s a combination of a BUNCH of techniques. From using linked lists to inlining logic to using bitwise operators to baking in most of the common easing calculations in the main rendering loop to minimizing the calling of functions and structuring things to make it easier for modern JITs to discern data types and optimize compilation as well as creating a super-fast algorithm for finding conflicting tweens and releasing objects for garbage collection, etc. It’s definitely not a simplistic thing :)

I think jQuery just wasn’t built with highly optimized animation in mind, that’s all. I can’t fault the authors – they’ve done an amazing job at what jQuery was supposed to be. GSAP, however, is built specifically for high-performance, professional-grade animation. There are a lot of architectural decisions made accordingly.

You’re also right about the fact that this site would naturally feature battles where GSAP does well, but we’ve tried very hard to be fair and very honest. You’re welcome to run your own tests and if they contradict our results, we’ll surely *not* post them ;)

Posted by Daniel Grant on February 8, 2014

The important thing is to have clear separation of concerns and keep the animation logic separate from the state logic. The application layer should not need to know if a page is sliding left or rotating counter clockwise, it just needs to know which one is active.

For animations that are controlled by CSS properties it makes complete sense for animation logic to be defined in CSS.

It’s also a lot more lean.

For example, say you want to transition between 2 pages, you can apply .is-active to the one that is being animated in and .was-active to the one that’s getting animated out and let CSS handle the rest. The great thing about doing this is, first of all, it requires fewer lines of code, secondly, it has a lot of semantic meaning and, thirdly, you can easily swap out the animation.

For greensock (which is completely new to me and something I’m looking forward to trying out) it makes sense that the animation logic would be defined in JS as it’s controlled by JS.

Posted by Jack on February 8, 2014

Daniel, I think you’re right about simple transitions of states – those are quite simple to do directly in CSS (as long as you don’t require compatibility with IE9 or earlier). However, if you’re doing anything more advanced, I’d argue that CSS is not at all “more lean” and in fact it becomes quite cumbersome. See the article and videos Carl did here: http://www.greensock.com/css-workflow/. Also read about many of the limitations of CSS animation and some myths that a lot of people believe at http://css-tricks.com/myth-busting-css-animations-vs-javascript/

Thanks for chiming in!

To download the code, you must agree to the following license:

"NO CHARGE" NON-EXCLUSIVE SOFTWARE LICENSE AGREEMENT
-----------------------------------------------------------------------------
PLAIN ENGLISH SUMMARY:

  1. You may use the code at no charge in commercial or non-commercial apps, web sites, games, components, and other software as long as end users are not charged a fee of any kind to use your product or gain access to any part of it. If your client pays you a one-time fee to create the site/product, that's perfectly fine and qualifies under the "no charge" license. If end users are charged a usage/access/license fee, please sign up for a "Business Green" Club GreenSock membership which comes with a comprehensive commercial license. See http://www.greensock.com/club/ for details.
  2. Use at your own risk. No warranties are offered.
  3. Please respect the copyright.

-----------------------------------------------------------------------------

LEGALESE:

This is a legal agreement between you (either an individual or a single entity) and GreenSock, Inc. ("GREENSOCK") for the proprietary GreenSock code known as TweenLite, TweenMax, TweenNano, TimelineLite, TimelineMax, and other copyrighted code that is available for download at http://www.greensock.com (this code and documentation, as well as any updates which may at GREENSOCK's sole discretion be provided to you from time to time, are referred to in this Agreement as "PROGRAM"). By downloading, copying, or otherwise using the PROGRAM, you agree to the terms and conditions of this Agreement. If you do not agree to the terms and conditions of this Agreement, please do not download or use the PROGRAM.

I. LICENSE
A. Subject to the terms and conditions of this Agreement, GREENSOCK hereby grants you a non-exclusive, worldwide, non-transferable right to use the PROGRAM in apps, web sites, games, components and other software applications ("Developed Works") for which the end user is NOT charged any fees. If you would like to use the code in a commercially licensed Developed Work for which end users are charged a fee (either for usage or access), simply sign up for the appropriate "Business Green" Club GreenSock membership at http://www.greensock.com/club/.

II. LIMITATION OF LICENSE AND RESTRICTIONS
A. You agree that you will not sell, rent, or license the PROGRAM's source code or any derivative works thereof to any third party without the prior written consent of GREENSOCK. Distribution of the PROGRAM as part of your Developed Work is acceptable so long as it is used exclusively as a part of your Developed Work. You agree not to modify or delete GREENSOCK'S existing copyright notices located in the source code.

B. You may use, duplicate, and distribute the compiled object code as embedded in Developed Works created by you, either for your own use or for distribution to a third party so long as end users of the Developed Work are not charged a fee for usage of or access to any portion of the Developed Work. Please see http://www.greensock.com/licensing/ for descriptions of Developed Works that qualify for the "No Charge" license.

C. You may make modifications to the source code exclusively for your own use in order to perform bug fixes or other minor edits required to operate the PROGRAM as originally intended.

III. CONSIDERATION
A. The license rights granted to you under this Agreement are at no charge, but only in the following circumstances: If on your own behalf or on behalf of a third party you incorporate the PROGRAM into a web site, app, game, program or any component thereof (collectively, "Developed Work"), which in the case of a web site, must be accessible to internet users without payment of a fee of any kind, and in the case of a software application, game, program or component, neither you nor anyone to whom you distribute the Developed Work charges a user a fee of any kind to use such Developed Work or application, game, program or component into which such Developed Work is embedded. The foregoing shall apply regardless of whether you are paid to create such Developed Work.

B. In the event your intended use of the PROGRAM does not meet the criteria for the "no charge" license rights set forth in the immediately preceding paragraph, then you are not licensed to use the PROGRAM under this Agreement and must license the PROGRAM under GREENSOCK'S separate fee-based Software License Agreement which is granted to "Business Green" Club GreenSock members (see http://www.greensock.com/club/ for details).

C. You may make modifications to the source code exclusively for your own use in order to perform bug fixes or other minor edits required to operate the PROGRAM as originally intended.

IV. TITLE AND OWNERSHIP
A. The PROGRAM is licensed, not sold, and is protected by copyright laws and international treaty provisions. You acknowledge that no title to the intellectual property in the PROGRAM is transferred to you. You further acknowledge that title and full ownership rights to the PROGRAM, including all intellectual property rights therein, will remain the exclusive property of GREENSOCK and you will not acquire any rights to the PROGRAM except as expressly set forth in this Agreement. You agree that any copies of the PROGRAM you make will contain the same proprietary notices which appear on and in the PROGRAM. You agree that GREENSOCK may identify you as a licensee unless you make a written request otherwise. GREENSOCK hereby grants to you the right to disclose that your product, game, software application, component, or other Developed Work makes use of GREENSOCK code (for example, "Powered by TweenLite").

V. DISCLAIMER OF WARRANTY AND LIMITATION OF LIABILITY
A. THE PROGRAM IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. GREENSOCK DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE PROGRAM WILL MEET YOUR REQUIREMENTS OR THAT OPERATION WILL BE UNINTERRUPTED OR ERROR FREE. GREENSOCK shall not be liable for special, indirect, incidental, or consequential damages with respect to any claim on account of or arising from this Agreement or use of the PROGRAM, even if GREENSOCK has been or is hereafter advised of the possibility of such damages. Because some states do not allow certain exclusions or limitations on implied warranties or of liability for consequential or incidental damages, the above exclusions may not apply to you. In no event, however, will GREENSOCK be liable to you, under any theory of recovery, in an amount in excess of $250. Notwithstanding anything else in this agreement, you agree to indemnify GREENSOCK, its assignees, and licensees, and hold each of them harmless from and against any and all claims, losses, damages, and expenses, including legal fees arising out of or resulting from any negligent act or omission by you.

B. GREENSOCK may, at its sole discretion, provide support services related to the PROGRAM, but has no obligation to do so.

VI. TERMINATION
If you at any time fail to abide by the terms of this Agreement, GREENSOCK shall have the right to immediately terminate the license granted herein and pursue any other legal or equitable remedies available.

VII. MISCELLANEOUS
A. This Agreement shall be construed in accordance with the laws of the State of Illinois. In the event of any dispute between you and GREENSOCK with respect to this Agreement, we both agree that if we cannot resolve the dispute in good faith discussion, either of us may submit the dispute for resolution to arbitration with the American Arbitration Association before a single arbitrator using the AAA Rules for Commercial Arbitration. The arbitrator's decision is final and can be enforced in any court with jurisdiction over such matters.

B. This agreement represents the complete and exclusive statement of the agreement between GREENSOCK and you and supersedes all prior agreements, proposals, representations and other communications, verbal or written, between them with respect to use of the program. This agreement may be modified only with the mutual written approval of authorized representatives of the parties.

C. The terms and conditions of this Agreement shall prevail notwithstanding any different, conflicting, or additional terms or conditions which may appear in any purchase order or other document submitted by you. You agree that such additional or inconsistent terms are deemed rejected by GREENSOCK.

D. GREENSOCK and you agree that any xerographically or electronically reproduced copy of this Agreement shall have the same legal force and effect as any copy bearing original signatures of the parties.

Copyright 2006-2013, GreenSock, Inc. Updated 2012-08-28

I'd like to learn how to get bonus plugins, update notifications, SVN access, and more.
To continue, you must agree to the following license: