Grow your CSS skills. Land your dream job.

Myth Busting: CSS Animations vs. JavaScript

Published by Guest Author

The following is a guest post by Jack Doyle, author of the GreenSock Animation Platform (GSAP). Jack does a lot of work with animations in the browser and has discovered that the generic opinion that "CSS is faster" just isn't true. It's more than that, as well. I'll let him explain.

Once upon a time, most developers used jQuery to animate things in the browser. Fade this, expand that; simple stuff. As interactive projects got more aggressive and mobile devices burst onto the scene, performance became increasingly important. Flash faded away and talented animators pressed HTML5 to do things it had never done before. They needed better tools for complex sequencing and top-notch performance. jQuery simply wasn't designed for that. Browsers matured and started offering solutions.

The most widely-acclaimed solution was CSS Animations (and Transitions). The darling of the industry for years now, CSS Animations have been talked about endlessly at conferences where phrases like "hardware accelerated" and "mobile-friendly" tickle the ears of the audience. JavaScript-based animation was treated as if it was antiquated and "dirty". But is it?

As someone who's fascinated (bordering on obsessed, actually) with animation and performance, I eagerly jumped on the CSS bandwagon. I didn't get far, though, before I started uncovering a bunch of major problems that nobody was talking about. I was shocked.

This article is meant to raise awareness about some of the more significant shortcomings of CSS-based animation so that you can avoid the headaches I encountered, and make a more informed decision about when to use JS and when to use CSS for animation.

Lack of independent scale/rotation/position control

Animating the scale, rotation, and position of an element is incredibly common. In CSS, they're all crammed into one "transform" property, making them impossible to animate in a truly distinct way on a single element. For example, what if you want to animate "rotation" and "scale" independently, with different timings and eases? Maybe an element is continuously pulsing (oscillating scale) and you'd like to rotate it on rollover. That's only possible with JavaScript.

See the Pen Independent Transforms by GreenSock (@GreenSock) on CodePen

In my opinion, this is a glaring weakness in CSS but if you only do simpler animations that animate the entire transform state at any given time, this won't be an issue for you.

Performance

Most comparisons on the web pit CSS animations against jQuery since it is so pervasive (as if "JavaScript" and "jQuery" were synonymous) but jQuery is widely known to be quite slow in terms of animation performance. The newer GSAP is also JavaScript-based but it's literally up to 20x faster than jQuery. So part of the reason JavaScript animation got a bad reputation is what I call the "jQuery factor".

The most frequently cited reason for using CSS for animation is "hardware acceleration". Sounds yummy, right? Let's break it down into two parts:

GPU involvement

The GPU is highly optimized for tasks like moving pixels around and applying transform matrices and opacity, so modern browsers try to offload those tasks from the CPU to the GPU. The secret is to isolate the animated elements onto their own GPU layers because once a layer is created (as long as its native pixels don't change), it's trivial for the GPU to move those pixels around and composite them together. Instead of calculating every single pixel 60 times per second, it can save chunks of pixels (as layers) and just say "move that chunk 10 pixels over and 5 pixels down" (or whatever).

Side note: It's not wise to give every element its own layer because GPUs have limited video memory. If you run out, things will drastically slow down.

Declaring your animations in CSS allows the browser to determine which elements should get GPU layers, and divvy them up accordingly. Super.

But did you know you can do that with JavaScript too? Setting a transform with a 3D characteristic (like translate3d() or matrix3d()) triggers the browser to create a GPU layer for that element. So the GPU speed boost is not just for CSS animations - JavaScript animation can benefit too!

Also note that not all CSS properties get the GPU boost in CSS animations. In fact, most don't. Transforms (scale, rotation, translation, and skew) and opacity are the primary beneficiaries. So don't just assume that if you animate with CSS, everything magically gets GPU-juiced. That simply isn't true.

Offloading calculations to a different thread

The other part of "hardware acceleration" has to do with being able to use a different CPU thread for animation-related calculations. Again, this sounds great in theory but it doesn't come without costs, and developers often overestimate the benefits.

First of all, only properties that don't affect document flow can truly be relegated to a different thread. So again, transforms and opacity are the primary beneficiaries. When you spin off other threads there's overhead involved with managing that process. Since graphics rendering and document layout eat up the most processing resources (by FAR) in most animations (not calculating the intermediate values of property tweens), the benefit of using a separate thread for interpolation is minimal. For example, if 98% of the work during a particular animation is graphics rendering and document layout, and 2% is figuring out the new position/rotation/opacity/whatever values, even if you calculated them 10 times faster, you'd only see about a 1% speed boost overall.

Performance comparison

The stress test below creates a certain number of image elements (dots) and animates them from the center to random positions around the edges using random delays, creating a starfield effect. Crank up the number of dots and see how jQuery, GSAP, and Zepto compare. Since Zepto uses CSS transitions for all of its animations, it should perform best, right?

See the Pen Speed Test: GSAP vs Zepto (CSS Transitions) vs jQuery by GreenSock (@GreenSock) on CodePen

The results confirm what is widely reported on the web - CSS animations are significantly faster than jQuery. However, on most devices and browsers I tested, the JavaScript-based GSAP performed even better than CSS animations (by a wide margin in some cases, like on the Microsoft Surface RT GSAP was probably at least 5 times faster than the CSS transitions created by Zepto, and on the iPad 3 iOS7 transforms were significantly faster when animated with GSAP instead of CSS transitions):

Animated properties Better w/JavaScript Better w/CSS
top, left, width, height Windows Surface RT, iPhone 5s (iOS7), iPad 3 (iOS 6), iPad 3 (iOS7), Samsung Galaxy Tab 2, Chrome, Firefox, Safari, Opera, Kindle Fire HD, IE11 (none)
transforms (translate/scale) Windows Surface RT, iPhone 5s (iOS7), iPad 3 (iOS7), Samsung Galaxy Tab 2, Firefox, Opera, IE11 iPad 3 (iOS6), Safari, Chrome
Exactly how much "better"? The original version of the test had a frames-per-second counter for quantifiable results, but it quickly became apparent that there's no truly accurate way to measure FPS across browsers especially with CSS animations, and certain browsers were reporting misleading numbers, so I removed it. You can easily gauge relative performance, though, by cranking up the number of dots, switching among engines, and watching how things perform (smooth movement, steady timing and dot dispersion, etc.). After all, the goal is to have animations look good.

Interesting things to note:

  • When animating top/left/width/height (properties that affect document flow), JavaScript was faster across the board (GSAP, not jQuery).
  • A few devices seemed highly optimized for transforms whereas others handled top/left/width/height animations better. Most notably, the older iOS6 was much better with CSS-animated transforms, but the newer iOS7 flip-flopped and now they are significantly slower (I blogged about it here).
  • There's a substantial lag in the initial animation startup with CSS animations as the browser calculates layers and uploads the data to the GPU. This also applies to JavaScript-based 3D transforms, so "GPU acceleration" doesn't come without its own costs.
  • Under heavy pressure, CSS transitions were more likely to spray out in bands/rings (this appears to be a synchronization/scheduling issue, possibly due to them being managed in a different thread).
  • In some browsers (like Chrome), when there were a very high number of dots animating, it completely killed the opacity fade of the text, but only when using CSS animations!

Although well-optimized JavaScript is often just as fast if not faster than CSS animations, 3D transforms do tend to be faster when animated with CSS, but that has a lot to do with the way browsers handle 16-element matrices today (forcing conversion from numbers to a concatenated string and back to numbers). Hopefully that'll change, though. In most real-world projects, you'd never notice the performance difference anyway.

I'd encourage you to do your own testing to see which technology delivers the smoothest animation in your particular project(s). Don't buy the myth that CSS animations are always faster, and also don't assume that the speed test above reflects what you'd see in your apps. Test, test, test.

Runtime controls and events

Some browsers allow you to pause/resume a CSS keyframes animation, but that's about it. You cannot seek to a particular spot in the animation, nor can you smoothly reverse part-way through or alter the time scale or add callbacks at certain spots or bind them to a rich set of playback events. JavaScript provides great control, as seen in the demo below.

See the Pen Impossible with CSS: controls by GreenSock (@GreenSock) on CodePen

Modern animation is very much tied to interactivity, so it's incredibly useful to be able to animate from variable starting values to variable ending ones (maybe based on where the user clicks, for example), or change things on-the-fly but declarative CSS-based animation can't do that.

Workflow

For simple transitions between two states (i.e. rollovers or expanding menus, etc.), CSS Transitions are great. For sequencing things, however, you generally need to use CSS keyframe animations which force you to define things in percentages, like:

@keyframes myAnimation {
  0% {
    opacity: 0;
    transform: translate(0, 0);
  }
  30% {
    opacity: 1;
    transform: translate(0, 0);
  }
  60% {
    transform: translate(100px, 0);
  }
  100% {
    transform: translate(100px, 100px);
  }
}
#box {
   animation: myAnimation 2.75s;
}

But when you're animating, don't you think in terms of time rather than percentages? Like "fade up the opacity for 1 second, then slide to the right for 0.75 seconds, and bounce down to a rest 1 second later". What happens if you spend hours crafting a complicated sequence in percentages, and then the client says "make that part in the middle 3 seconds longer"? Ouch. You'd need to recalculate ALL of the percentages!

Usually building animations involves a lot of experimentation, especially with timing and eases. This is actually where a seek() method would be quite useful. Imagine building out a 60-second animation piece-by-piece and then finessing the final 5 seconds; you would need to sit through the first 55 seconds every time you want to see the results of your edits to the last parts. Yuck. With a seek() method, you could just drop that into place during production to skip to the part you're working on, and then remove it when you're done. Big time-saver.

It is becoming increasingly common to animate canvas-based objects and other 3rd-party library objects but unfortunately CSS animations can only target DOM elements. That means that if you invest a lot of time and energy in CSS animations, it won't translate to those other types of projects. You'll have to switch animation tool sets.

There are a few more workflow-related conveniences that are missing in CSS Animations:

  • Relative values. Like "animate the rotation 30 degrees more" or "move the element down 100px from where it is when the animation starts".
  • Nesting. Imagine being able to create animations that can get nested into another animation which itself can be nested, etc. Imagine controlling that master animation while everything remains perfectly synchronized. This structure would promote modularized code that is much easier to produce and maintain.
  • Progress reporting. Is a particular animation finished? If not, exactly where is it at in terms of its progress?
  • Targeted kills. Sometimes it's incredibly useful to kill all animations that are affecting the "scale" of an element (or whatever properties you want), while allowing the rest to continue.
  • Concise code. CSS keyframe animations are verbose even if you don't factor in all the redundant vendor-prefixed versions necessary. Anyone who has tried building something even moderately complex will attest to the fact that CSS animations quickly get cumbersome and unwieldy. In fact, the sheer volume of CSS necessary to accomplish animation tasks can exceed the weight of a JavaScript library (which is easier to cache and reuse across many animations).

Limited effects

You can't really do any of the following with CSS animations:

  • Animate along a curve (like a Bezier path).
  • Use interesting eases like elastic or bounce or a rough ease. There's a cubic-bezier() option, but it only allows 2 control points, so it's pretty limited.
  • Use different eases for different properties in a CSS keyframe animation; eases apply to the whole keyframe.
  • Physics-based motion. For example, the smooth momentum-based flicking and snap-back implemented in this Draggable demo.
  • Animate the scroll position
  • Directional rotation (like "animate to exactly 270 degrees in the shortest direction, clockwise or counter-clockwise").
  • Animate attributes.

Compatibility

CSS-based animation doesn't work in IE9 and earlier. Most of us hate supporting older browsers (especially IE), but the reality is that some of us have clients who require that support.

Browser prefixes are necessary for many browsers, but you can leverage preprocessing tools to avoid having to manually write them out.

Conclusion

Are CSS animations "bad"? Certainly not. In fact, they're great for simple transitions between states (like rollovers) when compatibility with older browsers isn't required. 3D transforms usually perform very well (iOS7 being a notable exception), and CSS animations can be very attractive for developers who prefer putting all of their animation and presentation logic in the CSS layer. However, JavaScript-based animation delivers far more flexibility, better workflow for complex animations and rich interactivity, and it often performs just as fast (or even faster) than CSS-based animation despite what you may have heard.

When compared to jQuery.animate(), I can understand why CSS Animations were so appealing. Who in their right mind wouldn't jump at the chance to get a 10-fold performance boost? But it's no longer a choice between jQuery and CSS Animations; JavaScript-based tools like GSAP open up entirely new possibilities and wipe out the performance gap.

This article isn't about GSAP or any particular library; the point is that JavaScript-based animation doesn't deserve a bad reputation. In fact, JavaScript is the only choice for a truly robust, flexible animation system. Plus, I wanted to shed some light on the frustrating parts of CSS animations (which nobody seems to talk about) so that you can ultimately make a more informed decision about how you animate in the browser.

Will the Web Animations spec solve things?

The W3C is working on a new spec called Web Animations that aims to solve a lot of the deficiencies in CSS Animations and CSS Transitions, providing better runtime controls and extra features. It certainly seems like a step forward in many ways, but it still has shortcomings (some of which are probably impossible to overcome due to the need for legacy support of existing CSS specifications, so for example, independent transform component control is unlikely). That's a whole different article, though. We'll have to wait and see how things come together. There are definitely some smart guys working on the spec.

Comments

  1. Is the GSAP test in the speed comparison not working for anybody else? All I see is one dot and no animation. Latest Safari on Mavericks.

    • Permalink to comment#

      Sorry, JP – that was just an issue with the codepen embed setting that automatically halts execution. It should be fixed now.

  2. Permalink to comment#

    This article is biased and tests are selective.

  3. name
    Permalink to comment#

    this article is basically a free advert for GSAP.

  4. Nope.

    • Nope what?

    • Timothy
      Permalink to comment#

      I think this is what he means by nope: Myth Busting Mythbusted

    • What
      Permalink to comment#

      Is this an argument not to argue? What a weird post.

    • The problem with Chris’s argument is that this article is based on facts and experiments (however selective) but his blog post is based on his idealism and his view of how the web development world should work.

      Chris is basically saying “Yeah, these libraries probably work well, but if there’s a problem with the web platform we should try to fix the web platform rather than relying on libraries”.

      I don’t disagree, in principle, but the thing is that some of us live in the real world and need to get stuff done before 2016. The author covers the fact that there are new web animation specs in the pipleline, but it’ll be years before they’re available to use in all browsers (I.E cough) and they seem to be out-dated before they’re even implemented.

      Also, CSS-tricks has a comments section, which allows Chris to write totally unconstructive posts like “nope”, and yet his own site has no commenting system so doesn’t allow others to criticize anything he says. Massive fail.

  5. I’m really surprised by the haters, I thought the article was well researched and thorough. Personally, I have found JavaScript to be necessary (or certainly easiest by far) anytime you go beyond a simple animation. The massive ‘transform’ property is the worst to work with.

    I’m not super pumped to add more JS libraries to a page, but I don’t see another option for complex animation right now.

    One caveat to JS animation, I believe, is battery use. My gut says all those JS calculations use a lot of juice, but I don’t have the tests to prove it.

    • I’m also interested in knowing the differences in power consumption between the different animation techniques. While in many cases, I can imagine the difference being negligible, I could see things like infinite loops being worth optimizing.

      And to Jack: Great article. It speaks very well of GSAP that you guys do this kind of fundamental research.

    • iDad
      Permalink to comment#

      I do not have conclusive Test at hand for that issue, but I remember that when his Steveness complained about Flash sucking device batteries empty someone tested an android device with similar animations in Flash and in HTML5/CSS/JS and the later needed a lot more juice. We could reproduce that with our own test.

      I do not se a real reason why there should be a significant difference in battery-drain. In the end the Hardware will have to perform similar tasks anyhow, and as the article states it is the actual rendering that needs the most performance (=energy) the way you achieve it doesn’t matter as much.

      But even if, aside from browser-games that one can/will play for longer times, that will need a lot of complex scripting anyhow, visiting and using a website usually ties some minutes at most. Calculating with a battery-cycle of alt least 24h for your device, even if those minutes will use 50% or 100% of more power than the alternative, it will hardly be relevant, and not every device will act the same.

      So: don’t worry. If if it were true which i sincerely doubt, it would hardly matter and should only motivate vendors to get the much needed javascript performance (and energy consumption) in order.

    • Camaron
      Permalink to comment#

      I agree Matthew, this was well researched and Im really dissapointed in the communities response to a very practical based Article, its not like rules or restrictions were placed its mearly giving perspective to those who have debated the use of CSS animation over javascript/jquery animation.

    • @iDad it probably has a lot to do with the way browsers optimize for animation. JS has certainly gotten a lot faster since then, so its juice sucking may have changed for the better or worse. Maybe GPU offloading levels the playing field.

      My thought was based on an animation that I made that was using transitions, where I got about 50% through what I wanted and it was nice and smooth, the browser wasn’t struggling. I hit a dev wall, and redid it with JS and found the browser spinning CPU up and chugging pretty hard. Still smooth and great, but seemed to be working harder.

      That said, battery use is an avenue that is fairly ignored in many discussions. Maybe for a good reason, its probably not a dealbreaker if you’re only using a site for a little while.

  6. Nazar
    Permalink to comment#

    Regarding CSS animation, what about executing “onComplete” function?

  7. I have done animation many different ways in my career. Testing and trying out a number of different methods and libraries.

    I think CSS animation and Javascript animation both have their place ( as mentioned in this article ). I do agree that GSAP is top tier in the Javascript performance and ease of workflow. It shows that javascript can be used efficiently to achieve some really amazing stuff that CSS just can’t do.

    I personally found this article very true and interesting.

    For anyone who thinks the article is just a plug for GSAP, I think they missed the point of the article entirely.

  8. In full disclaimer, I am a friend of Jack’s (because I’ve used his tooling since the AS3 days) so take my comments with whatever bias you may imagine. That being said, I have used GSAP for a few years now and I use it in JS now exclusively. I’m a firm believer that CSS is for presentation logic and not animation, and thats one of my main reasons for not using CSS animation. The biggest reason, however, is the fact that CSS animations simply can’t do all the things that JS can. I don’t know how many of you are in the same boat as I am but most of my work is for relatively corporate clients where backwards compatibility is a must. I can’t imagine trying to code some of the things I do in CSS alone (or they simply wouldn’t be possible).

    I know you may say “its expected that older browsers get a different experience” but it doesn’t necessarily have to be that way. And to those that say “the tests are biased” or “this is an advert for GSAP”, go check it out for yourself and do your own tests and draw your own conclusions. I think you’ll be pleasantly surprised at what is offered to you. And the fact that its posted here as an “advert” makes you mad? It’s trying to broaden the horizons of people who may not know about it, how is that a bad thing? If all you got out of this post is that it’s an advert then you’re obviously missing the point.

    • David Aimi
      Permalink to comment#

      Matt – you state that CSS is for presentation logic and not animation. The fact is correct that CSS animations simply can’t do all the things that JS can. But to invalidate your statement, JavaScript itself was never meant to be a creative or animation language. Therefore, I would argue neither JavaScript nor CSS handle animation well per say.

      I don’t think people are arguing whether or not GSAP offers value to a developer. They are arguing that the article is biased in saying (CSS vs JavaScript) vs GSAP. That is what makes this article dangerous because all its doing is promoting a framework. Also, this article does very little to compare traditional JavaScript with CSS3 natively. Instead, it compares GSAP to jQuery. If it were a free library I think people would care less about the promotion.

      I don’t think people are missing the point. I think they are confused because the author did not do a great job of really explaining WHAT GSAP is doing differently and why its more performant than just using jQuery vs JavaScript vs CSS combinations. Instead this article came off more self-promoted.

    • Permalink to comment#

      Fair point, David – I didn’t cover specifics about how to write faster JavaScript. Frankly, I had a very hard time keeping this article relatively concise as it is (I get really passionate about this stuff and could go on for a LONG time), and if I dove into a bunch of tips and techniques for optimizing JavaScript, it would get too lengthy and lose focus. I think that topic deserves a whole article for itself. In this article, however, I was really trying to stay focused on exposing some of the weaker spots of CSS animations that nobody seems to talk about, and demonstrate that JavaScript animation doesn’t deserve a bad reputation, and show some unique things that are only possible with JavaScript. Notice I also talk about some strengths of CSS.

      I’m sorry if the article came off as self-promotional; I tried to restrain myself from talking about specific features and benefits that are unique to GSAP, and instead keep most of the focus on the more generic topic of CSS animation and JavaScript animation. I guess I didn’t do that well enough. And for the record, GSAP is completely free for the vast majority of use cases, even commercial ones. In fact, I think the license is one of the strengths of the whole package, as it’s more business-friendly in many ways and provides more stability for ongoing innovation and support than other common open source ones. That’s another article unto itself too :)

    • Permalink to comment#

      I totaly agree with David, the article can feel a bit biased. But I can relate on the fact that GSAP is in fact very fast and that it took a great deal of work to achieve. I tried myself to understand better all this animation stuff and I would be very interested by a technical post from Jack explaining what is the black magic in GSAP that makes it so fast. Because in the end, this is “just” Javascript.

    • I’ll echo David’s sentiments. JavaScript animations !== GSAP. I will have to spend a lot of time explaining this to students (which, if I were a less charitable person, I might think was the intention of this post). Also, I think there’re issues with the tone of the author here, which is unfortunate. I have had my own problems with tone, and it can really make or break the public’s reaction to a piece. That said, my inbox is always open for tone-checking a good animations post ;)

      Interesting post and thank you for sharing!

  9. So glad to see GreenSock alive & kicking! I used their tool exclusively in the Flash-heavy days, and they always brought real solid data, comparisons, and examples to the table. I’m glad to see nothing has changed! It’s great seeing myths like “CSS is always bestorz” being busted. Thanks for the article.

    • I appreciate the strong, opinionated stance of this post, backed up with real data and live examples. For complex animation & interactivity, this approach is worth a look.

  10. Garrett
    Permalink to comment#

    I personally don’t use a lot of animations in my day to day work. Most of the animations I use are fading in and fading out sections on a page. Maybe scaling a button or two, nothing this extreme. The only place I can think that such hardcore animations would be used is in game development, and if that’s what you’re doing you shouldn’t be using standard HTML elements to build out your game, canvas is your friend.

    • Permalink to comment#

      I used to think the same – until last week when I started messing around with various animations for a new project. Once you dip your toe into pool of CSS animations & transitions, you’ll see a whole world of nice ways of presentational techniques appear. I whipped up a demo of some ideas (all pure CSS) on ways to improve over just the usual fade in/out.

  11. Luka
    Permalink to comment#

    I wonder if this is just the current state of browsers in term they aren’t so smart yet about css animations.

  12. Tom
    Permalink to comment#

    I think the distinction between ‘animating with JavaScript’ and ‘animating with CSS’ is a bit confused in this article.

    What is more important is reducing the number of reflows and paints, and a lot of that is to do with how well you know the browser rendering process.

    You can do crappy JavaScript animation, and you could do crappy CSS animation. They have different use cases, but to be honest, most of the time it’s not the JavaScript execution that’s the problem – it’s the painting/reflow.

  13. Guilherme de Souza
    Permalink to comment#

    Control css animations by adding and removing classes it’s a dumb choice !

    CSS animation control sucks

    GSAP animation control rocks

  14. Permalink to comment#

    I was using GSAP and javascript animations because I too come from AS3 background and writing javascript code seems for natural for me.

    But one very important aspect I would like to point out is that another top-tier Canvas framework KineticJS changed its animation engine to GSAP because it offered over 16% increase in performance.

    The reason I’m stating this is because with javascript even Canvas animations are possible, which is something that cannot be done with CSS animations.
    Of course CSS animations are the way to go for simple/or complex UI enhancements.

  15. David Clark
    Permalink to comment#

    Great coincidence! I’ve just been looking into GSAP, considering it for a current project, after finding it in the sourcecode of some animation-intensive award-winning sites.

    Looking into it, I’ve been a little baffled by GSAP’s weird web-presence: the library is under active development but the webpage and documentation look quite old; and I have trouble finding adequate conversation about it — I just find either advocacy or silence. I have no problem with the advocacy (it’s how you get others to use and provide feedback for you library, and if you made it you hopefully believe in it) — but why aren’t others weighing in on GSAP? Where are the blog posts and StackOverflow answers that explain the pros and cons of GSAP, that use it to solve problems that jQuery and CSS don’t adequately solve? Why do the current conversations about browser animations seem to ignore this tool? Why do the numerous animation-performance articles on HTML5 Rocks etc. leave it out of the discussion? The frontend evangelists that I (and many others) tend to rely on to introduce me to great stuff seemed to be either a) unaware of its presence or b) maintaining silence for unknown reasons. (I was just today thinking of writing a question to the ShopTalk show to ask if those two had any opinions about GSAP.)

    So: I’m really glad to see Chris post this article (and thanks Jack for writing it), and I hope it leads to GSAP and tools like it being included in the many conversations about animation.

    • JakeZ
      Permalink to comment#

      I’ve been using greensock’s tools for several years now, both Flash and JavaScript, and I can say, that they are well worth the cost. They haven’t changed their site in a while, but the documentation is up to date, and the forums are active, and extremely helpful. Answers from GS are prompt, and very helpful. Rarely will you see a question unanswered, or unresolved. The libraries themselves are extremely easy to use. I haven’t done a lot in the way of JavaScript, but switching over was pretty simple.

    • tomByrer
      Permalink to comment#

      GreenSock comes out with a new article or long news post almost every 6 weeks or more. But I agree, GreenSock’s ‘ecosystem’ is very very small; finding projects/blogs/repos using JS GSAP is very hard compared to jQuery.

    • David Clark
      Permalink to comment#

      I agree that the Greensock site is very helpful, full of demos, documentation, the forum @Patrick Mullady praised, etc. — that there’s no lack of material there to help us master a very useful tool. (I also find the syntax pretty intuitive, now that I’m playing around with it some.) I didn’t mean my words above to sound like a complaint, if they came off that way — just a comment on the curious fact that the channels I usually rely on to expose me to great stuff have so far been silent on GSAP, as far as I know, and I think that’s weird, given that those channels are always talking about optimizing web animation. It’s not a “problem”, because it’s nobody’s fault; it’s just weird and worth a comment.

    • Justin O'Neill
      Permalink to comment#

      I’ve been in the UI/UX world for 10+ years now and I’m just now hearing about GSAP from this article (and a few more on css tricks), and WOW! I’ve been a believer in CSS animations since they’ve came out but when testing on mobile I found that frankly- CSS animations Suck. I’m one of those guys that are trying to push html 5 mobile apps and steer away from the native world. CSS animations give html5 mobile apps a bad name… but GSAP has opened up a doorway for smooth delivery. I’m going to make GSAP my main tool for animation now, though I am curious to see what the Animation API will bring to the table and also the new Polymer from google.

      Thank you GreenSock for being awesome.

  16. Scott
    Permalink to comment#

    Look, I love GSAP, have used it all the way back to AS2/AS3, and really wish I could take advantage of its clearly superior feature set when working with HTML based animation. Unfortunately, even the most basic animations (for example the spinning green button at the top of the article) suffer from a low framerate on an iPad 3 (not the fastest device, but fairly common). Yes, that animation is not possible with CSS3, but it’s also not smooth with GSAP or any other javascript tweening engine.

    Not smooth is the same as not possible as far as I’m concerned. I’d rather simplify the animation, keeping with what CSS3 can currently pull off than have a fancy animation that chugs along on mobile devices.

    CSS3 animations are a pain, they have limited capabilities, and they do have delays, BUT they’re butter smooth on high resolution mobile devices. If you are developing web applications primarily for mobile devices, and performance is everything to you, there is currently no better option.

    • Permalink to comment#

      Scott, I’ve got an iPad 3 too, so I’m very surprised to hear about your experience. I’ve had some complex stuff animating with GSAP and it was buttery-smooth on my iPad. In fact, in several cases it was much smoother than CSS transitions! Maybe there was something else at play in your scenario. In any case, this just hammers home the point that it’s best to test, test, test. Sometimes CSS may very well be faster (as I mention in the article). I’d respectfully challenge the blanket statement, though, that GSAP is always slower on mobile devices like an iPad. Often (at least according to my tests), the opposite was true.

    • Scott
      Permalink to comment#

      Jack, I agree, I should probably do more testing with GSAP to find and understand the cases where it’s performance is as good if not better than CSS3.

      Here’s a video example of what I was talking about regarding the poor performance: https://www.dropbox.com/s/lpfehb4d8waj6sg/IMG_3804.MOV

      Notice the hiccup and skipped frames when I click ‘skip rotationX’ or ‘Spin rotation’. This is such a simple sample that I don’t see why there should be any hiccup.

      From my experience it takes much more to get a CSS3 animation to hiccup on the iPad, and when it does, it happens in a very different way. Instead of skipping frames, as Javascript tweens do, the CSS animation will take an extra moment to start but then play smoothly once it does. This might sound nitpicky, but I find this sort of performance degradation to be more desirable and pleasing to the user.

      Here’s an example of CSS3 performance degradation: https://www.dropbox.com/s/8j6dqht3ugw3h2o/IMG_3809.MOV

      As I hit the top navigation bar buttons, there is a slight delay as the iPad attempts to load that content into memory (all content is local, no network latency). For pages with simple content, the elements load quickly with very little delay. When I click the button at 0:15, you’ll see there is a longer delay as the iPad attempts to load a very large amount of content into memory (around 20+ large images). BUT you see that CSS3 causes the animation to wait until the content is loaded into memory before attempting to animate, and then it animates smoothly. Had I used javascript for that animation, the tween would have attempted to animate while the iPad was still hung up loading content to memory, and by the time the iPad catches up, the animation has already progressed quite a bit, causing a visual hiccup.

      Again, I should take the time to test further, but wanted you to see what I was talking about.

    • Justin O'Neill
      Permalink to comment#

      I have a Samsung Galaxy 3 and when I tested Animate.css VS GSAP

      I made my decision pretty instantly to go with GSAP.

      The animations we’re very jerky with animate.css and clean with gsap.

      As far as other devices, I have not tested…

  17. Patrick Mullady
    Permalink to comment#

    I’ve been using Greensock in Flash for as long as I can remember. I’ve never met met a Flash Dev that didn’t use Greensock.
    Once it was ported to JS I was thrilled. It gave me a point of reference and comfort that allowed me to overcome my fear of JS. It also gave me the confidence to tackle other languages.
    Concerning the StackOverflow comment, I use StackOverflow for lots of code questions. When it comes to Greensock though I always use the Greensock forum. It’s moderated by Jack, Carl and many others that know all the ins and outs of the codebase. Posting Greensock related questions on StackOverflow doesn’t make sense if you’re looking for Greensock help. :)
    It’s silly to think that this article is nothing more than an advert. Although I would happily advertise for Greensock any day of the week. Without the JS port I would’ve had a hell of a time learning JS quickly from scratch to keep my skills relevant. Greensock helped me keep my job at a certain point and I know for a fact it did the same for many others…so…thanks.
    Between the Greensock forum, StackOverflow, HTML5Rocks and CSS Tricks I’ve learned more than I ever could on my own.
    Peace and love

  18. Alex Stanbury
    Permalink to comment#

    Having just finished a very animation and timeline heavy website using GSAP I’m happy to report that I loved using it, This came as no surprise as I happily used TweenLite for years as an Actionscript developer. I dread to think how much harder my career as a developer would have been without the various Greensock plugins.

    It’s really surprising that GSAP is not as widely known in JS circles as TweenLite is in AS circles, hopefully this article will change that and rightly so.

  19. Permalink to comment#

    Before I say anything I’ll state that I’m a Greensock forum moderator, so there might be a chance that my comments are considered biased as well.

    This is about CSS animations and JS animations, the bottom line is that in terms of performance you can hit a brick wall using either one if you’re not careful about your code. The limit of what you can and can’t do IS the browser not the tool. Coders don’t write poor code because of JQuery, they write poor code because they don’t educate themselves about writing good code and the languages best practices. JS animations libraries are tools and tools (like a wrench for example) can be used in good and bad ways, but that’s not the developer’s fault. Also tools are there to simplify how things are done, working with css animations can be quite a chore if you’re up for something more challenging even if you work with a CSS preprocessor or Grunt. Controlling your animation with CSS is out of the question, building not even complex sequences, playback control, event callbacks and some other are possible in JS because the tools run on RAF, which is something people have been writing about for more than two years now when it comes to animate stuff with JS.

    With all that in consideration, the fact that the samples here use GSAP is because you won’t find a better toolset around and this is by far not a self referenced article or a shameless promotion of GSAP. There are quite some things about GSAP that are not mentioned in this article:

    <

    ul>
    Draggable tool that now <a href=http://codepen.io/rhernando/pen/KAFow”>works with transformed objects.
    SplitText tool
    ThrowProps plugin
    ScrollTo plugin

    Also consider take a look in Codepen, specially the Greensock collection and see the amazing things you can do with GSAP and port them to CSS animations, then spread the hate.

    @David Clark, the pros of GSAP are there for everyone to see them, while the cons are the same cons of other animation tools, perhaps the file size, but the two main files for animating DOM elements are 20kb compressed and GZIP, so that’s not going to delay page loading more than a single medium image.

  20. There’s always smart guys worker on specs, including the ones we already have :/

    Here’s to hoping :)

  21. Great article. Web Animations sound like a JavaScript API, which probably wouldn’t be useful to me as I typically keep my presentation code separated into a stylesheet. However, for things that we typically used Flash for, GSAP will suffice. Just need SVG 2.0 to finally catch up with Flash.

    • Permalink to comment#

      Keep in mind that GSAP has a RaphaelJS and a KineticJS plugin, so you can work on Canvas and SVG using GSAP.

      Also some time ago this post regarding three.js came up in the forums, check the JSFiddle link.

      So basically the tech is there, we just need to for the browsers to catch up with it.

  22. scheme
    Permalink to comment#

    The codebase is a bit too large to be certain after a short review, but isn’t every dot/animation created newly when the dot starts at the center? In that case, this test would only prove that GSAP is faster for this specific application which imo misses the point of CSS animations entirely.

  23. djanes376
    Permalink to comment#

    Great article Jack, and I hope it gives your tool more exposure to the JS crowd. I only discovered GSAP in the last year and it has made for some wonderful experiences with animation on the web. I was able to accomplish things that would just not be possible with CSS alone. I would suggest any nay-sayers give it a try, to create some timelines, complex animation sequences and just see how flexible it is and how great they run on many devices. Also amazing how backwards compatible it can be down to even ie7 for many properties.

    Don’t knock it before you try it for yourself. Also, GSAP is free to use in most cases and super affordable in all the others, there’s no excuse to not give it a shot.

  24. Permalink to comment#

    GSAP is a killing library. We can do so much more thing with it !

    Jack Doyle say it very well:
    for simple animation : css
    For more complexe needed : javascript (i recommend GSAP…;) )

  25. Permalink to comment#

    Great article! Very unbiased and reasonable. Anyone who says otherwise either didn’t read the article, has an emotional attachement to CSS animations, is a moron or just a douche.

  26. Permalink to comment#

    I like this article, really helpful

  27. tomByrer
    Permalink to comment#

    JavaScript logic is needed to solve some CSS animation issues:
    http://lea.verou.me/2014/01/smooth-state-animations-with-animation-play-state/

    I am interested in hearing more about JS programming that can do what CSS alone can’t. GSAP is the main lib I’m curious about, but there are more like animo.js

  28. Jack has been a master in terms of animation through code as long as I can remember. I was a huge fan of TweenMax back in the days while doing Flash/ActionScript and it’s nice to see that all the power of that library has been translated to the browser.

  29. I use a lot of animations in my daily workflow, and I use and CSS, and GSAP on regular basis. My thoughts – CSS is very good for simple animations like animating colour and position on rollover, which is great for some small projects, but you just can’t control CSS animation. What I personally love about JS animation is the control – I have from AS3 background, so events on update, end onEnd are crucial to me. Also, it is impossible to create advanced interactive animations with CSS, when properties ( ex. start and end positions ) have to be calculating on the fly. So if you don’t have animations on your website – good, use CSS for rollovers. If you create sophisticated interactive experiences – you just can’t do it without JS ( or flash/silverlight, but they’re out of the game, you know ) and for me – the best tool is GSAP. The best thing about it – it just works, and it works good. On every single browser I’ve tested.

  30. Very Nerdy stuff but I like it. I have used greensock on a very complex project involving animation of svgs and the sort. After searching around the web for alternatives, I found greensock to be the most performant. It used to be the library powering http://johnpolacek.github.io/scrollorama/ scrollorama plugin if I remember correctly. Good Article.

  31. NoLand
    Permalink to comment#

    I’ve been doing (native) JS-animation for a long time and was considering switching some of them to CSS-animations. Evaluations turned up the same results as described in the article. There were virtually no benefits, but some considerable draw backs.
    Moreover, there was no benefit with threading: Hick-ups related to async loads (like social network buttons loading their APIs and data) were just the same, maybe even more severe.
    Facit: CSS animations may be a convenience (for some easy effects to be applied just by editing stylesheets) but do not offer a performance gain with complex animations.

  32. GSAP didn’t power the original Scrollorama because it wasn’t out for JavaScript yet. Once Jack released it, I switched over and released the new and improved SuperScrollorama.

    I’ve long felt like GSAP is the best kept secret in JavaScript. It is an amazing library, but you don’t need to take my word for it. Just go and browse through FWA or Awwwards or {insert cool websites gallery here}, then view source of anything you see that has cool animation and you will be surprised how widely it is used.

    For example, today’s FWA Site of the Day happens to use GSAP.

  33. Ed
    Permalink to comment#

    Good to read that it get’s more publicity.

    For me: simple animation stuff: CSS, and GSAP for the rest. Works just fine (I am using it for some time now, also before with Action script).

    Beside that: the people of Greensock are great, form a great team, very patient and supportive. So I hope that they keep rocking and making/improving “this” stuff, which certainly helps with an this article.

  34. Permalink to comment#

    For those of you who want to use GSAP to build animations, our browser-based animator can be a good starting point to help you create the basic structure. Check it out at http://tweenui.com/animator

  35. Rich
    Permalink to comment#

    Having just read this post and then checking out CodeCanyon I find that a script has just been posted that uses the above http://codecanyon.net/item/cool-text-incredible-animations/6546649 not sure if it’s from the same author of this post?

    • Permalink to comment#

      Hi Rich,

      For what I can see, that app works on top of GSAP (TweenMax), but is a jQuery plugin actually.

      Greensock has it’s own text animation tool, SplitText, you can check it here.

      Rodrigo.

  36. Hey Jack,

    Long time no hear! Your GSAP lib is stunning as usual. Have you ever thought about downloading the source code for say Firefox and writing the code into there?? It would be freekin awesome!

    Hope you had a good New years, best wishes

    Simon

  37. Jack deserves to be respected for his excellent work. Those zealots defending CSS transition have no clue that it has huge limits compared to what you can do with Javascript. Now that I see it performs even better I’m glad I bought the Greensock Licence back in the days.

  38. Coming from a Flash/ActionScript background, I can honestly tell you that life wasn’t easier without all the tools from Jack (www.greensock.com); be it LoaderMax, TweenMax, Draggable, AutoFitArea, LiquidStage, the almighty TransformManager and lots more. And the key in using all those tools was the consistency and similarity they had with each other. Also, performance has been of paramount importance for this guy (as evident here) so in that aspect there was always this peace of mind for us, developers.

    My humble opinion is that the guys who have actually used both these techniques would be in the best position to judge this ever-long debate of ‘CSS Animation vs JavaScript Animation’ but it would still be subject to taste and/or preference. For me, ‘control’ is the key, second best to ‘intuition’. And GSAP provides me with both along-side a whole lot more functionality (every time I look up to do something new using GSAP, I end up finding that it was already in-built and was just a matter of assigning a value to another property). Perhaps, in time, CSS Animations will catch-up but for me, for now, GSAP does it.

    So let’s just stop wasting our time debating and instead focus on building cool stuff.

  39. Dwayne @alwayzambitious
    Permalink to comment#

    This post is not about Jquery its about Javascript which has the same gpu accessing benefits as css, and You can so much more cool and useful things with GSAP that is impossible to do with CSS. Its not even about being biased its just true. Jack and his team really did a sweet job with GSAP.

  40. Permalink to comment#

    Hi,
    when a highly animation based project arrived to me, I started having a look at different resources for building it, as I really felt that with CSS, jQuery or vanilla JS(at least for me) wouldn’t provably enough.

    Then I found GSAP, I’ve never used any Flash related tool before, and I don’t have idea about how it works, so I thought that the barrier for use GSAP was going to be too hard for use it (I had a short period of time for documenting myself in this project).
    But what GSAP offered me was just amazing, it does not even requires a heavy understanding of JS, it gives an outstanding control about timelines, callbacks (), a very wide range of animations, and lots and lots more with a very easy and understandable sintax.

    So, in my experience, for non Timeline related animations (keyframes are not exactly well supported), CSS is good and easy to set, but when it comes in a complex sequences and you got a be precise, I am very very glad about having GSAP available…

    So, good article and great great tool, thanks!

  41. Cp
    Permalink to comment#

    Hows this for an argument: Animations are stupid.

  42. Nicely balanced and well researched article!

    As a long time Flash and JS GSAP user (and sometimes contributor) I’ve always been surprised more people aren’t using it. Aside from Jack’s laser-focused attention to detail, it’s fast, reliable, flexible, exceptional value (read: free in most cases) and, very importantly, supported.

    The fallout from the rather unceremonious forced abdication of Flash left a lot of animators, creative developers and interactive designers looking for alternative ways to achieve results that had only ever been achievable before in Flash.

    Unless you are the type who has no real desire to animate or create dynamic interactivity (which I suspect the first few ‘pure CSS’ commenters are) then you should definitely check out GSAP – I guarantee you won’t look back.

    If you want some GSAP demos, tutorials and code (often integrated with Adobe Edge Animate) please hop over to my blog or my CodeCanyon portfolio

  43. I thought this was a really excellent article and a tip o’ the hat to the author!

    Recently, I’ve been super interested & eager to incorporate animations to my website… I’m currently using Ember to build it so that complicates things slightly. I was having a lot of trouble with Snap.svg and Ember and so I’ve been looking at different CSS and Javascript options available out there…

    Definitely am going to give it a try but am also going to try Your text to link here… or Your text to link here… … I really wish I could get Snap.svg to work in Ember and am going to try again soon but until then maybe these other options will suffice. Thanks again for the very informative article.

  44. Permalink to comment#

    Can someone show a heavy UI animation running on javascript/GSAP, for example a heavy off-canvas menu (that animates entire screen canvas) or a full-screen image 3D animation that works smoothly with GSAP? Especially on mobile devices for example iPad/iPhone? I have experimented with various solutions, and these UI elements are extremely sluggish especially on smaller devices. CSS3 to the rescue, makes these menus work nicely … I have never seen this done properly with any JS solution.

    Sure, GSAP is a smart and fast javascript solution, and if you want more control, or if you want to animate something that is not possible with CSS3, there you go. However, I don’t see why one would consider reverting from CSS3 to JS in the year 2014 for UI elements/transitions, which after all is primarily what most developers are dealing with.

    • John
      Permalink to comment#

      Creating a side by side comparison might be helpful. Create two projects with the exact same elements to get a true representation of performance.

  45. Great article Jack! I have used GSAP on a few projects and can’t imagine to create similar effects with the CSS3 syntax.

    Here are a few examples – Apple Navigation, Apple Mac Navigation, Christmas Party Apology Maker.

    It took me a while to get used to the workflow, but after a few experiments you really realise the true power of Greensock.

    I will definitely use GSAP on another more complex and interactive projects and keep CSS3 for a simple stuff.

  46. Well I guess i’m sticking to javascript animations for now. I was really hoping css was a better solution but the results above speak for itself.

  47. Dear guest author, allthough some of what you are saying here seems correct I do think you should not make some of the comparisons that you are making in this article. It seems you are blaming CSS animations, transforms, and transitions for not being able to do certain things that they were not meant to do in the first place like making elements drag-and/or-droppable, and do complex calculations, or being able to create or alter it’s own installed functionality.
    Apart from that you are making a few statements that seem boldly incorrect to me. For example one of the first things you are stating above is that it is impossible to apply different transforms with different timings for the same element at the same time using css. I have taken the time to find you a good and easy example of how this is in fact very much possible: http://animateyourhtml5.appspot.com/pres/index.html?lang=en#5
    The fact that your first statement in this article seems to be proven not to be true, to me implicates your research has skipped a few steps along the way. Or did I misread your words somehow?
    Nevertheless I very much appreciate the time and effort you took to write this nice and clear article and for now I agree on your conclusion that css is not to be used for all and or too many animations at the same time. Allthough in response to your concerns about the amount of css needed to accomplish more complex animations I would also like to mention that you could of course reduce the amount of css needed largely by only importing the stylesheets needed for the browser and viewport at hand and by for example not declaring the 0% and 100% keyframes if not really nescessary.
    My end conclusion would be that it’s not a great idea to compare animations created with javascript versus the ones created with css, but if you would ultimately want to do so you should try to use all the different possibilities to create the same effect in both languages and than compare all of those. But I’m not volunteering, sorry.
    Best regards,
    David Bartenstein

    • Permalink to comment#

      I think you may be misunderstanding the first point, David. Your example didn’t show independent transforms at all. Notice how all the transforms (scale and rotation in this case) animated at the same time? Try, for example, staggering a scale animation and a rotation animation (scale starts, then later rotation starts, both partially overlapping and each having different end times and different eases) like in the demo I provided. It’s impossible to do on the same element with CSS animations, yet it is a fairly common need for modern animators who do more than simple UI transitions.

      As far as the “draggable” stuff, I didn’t mean to imply that CSS animations should be the technology that drives the actual drag & drop (that’d be weird) – the link to the draggable demo was merely intended to show a type of animated movement that happens after you flick/throw/spin the object which can’t be replicated well with CSS (notice the smooth snap-back, application of boundaries, etc.). The point of the article was to help people see some types of animation that cannot be done well with CSS. I’ve seen some attempts at the smooth snap-back motion in CSS and it didn’t feel natural at all.

      I’m curious why you thought it’s a bad idea to compare CSS-based animation and JS-based animation, given the fact that so many animators must decide between them, and often struggle to wade through the hype, figure out what’s possible (and not), and then build something that actually works and looks good. Maybe we just travel in different circles, but I know of a LOT of people who are confused about this topic and frustrated with CSS animations.

    • Hello Jack,

      I owe you an apology for making false statements myself. After trying out different things with CSS transforms I have to conclude that what you said was true after all.
      It seems I was having false memories about this being possible. I have not been able to create distinct css transforms with individual eases without using a wrapper element. (http://jsfiddle.net/DavidBartenstein/27DPG/37) Allthough, without the personalized eases it is more or less do-able to make the animated transforms act independantly.

      To adress the rest of your response: I misunderstood some of what you were saying when you mentioned the snap back motion.
      And as to wether I think it’s a bad idea to compare css animation with other kinds: After reading and overthinking your arguments I have come to agree with you on that matter as well. I just feel like it’s common knowledge that css should not be used for complex animations and if someone was to compare the two I would of course like to see a full comparison using every method known to mankind :P Since there might be slight differences in performance when using different methods that would interest me.

      However, overall: good job on the article, and thanks for your dignified reply on my hasty conclusions…

      Best regards,

      David

    • Hi Jack, in regards to your statement about scaling an animation and later on overlap with a rotation. I thought that could be easily achieved with CSS?

      In CSS with animation keyframes, can’t we:

      0% transform: scale(0) rotate(0deg)
      40% transform: scale(0.5) rotate(0deg)
      60% transform: scale(1) rotate (60deg)
      100% transform: scale(0) rotate(0deg).

      Wouldn’t that “visually”, start the animation by scaling and then halfway through rotate it?

      By the way, this is a great article.

    • Venn, perhaps with very simple stuff, yes, but:

      Try making the rotation use a different ease than the scale

      Try adding interactivity, like rotate the element constantly but then animate the scale only on rollover/rollout

      Imagine what a nightmare the workflow would be with CSS when the client says “make the scale twice as long (duration) and the rotation should start a half-second earlier”. Gulp. You’d have to do the math and update almost all the percentages across the board (and the durations). Plus you’d have to duplicate a lot of values in the transforms. Animation by its very nature is very experimental, and the CSS workflow isn’t at all conducive to that. See http://www.greensock.com/css-workflow/ for an article specifically covering workflow challenges.

      Try animating in a relative fashion, like onclick, make the rotation animate 5 degrees more than whatever it happens to be at that moment (even if it’s clicked again mid-tween).

      So yes, if you’ve got a simple enough use case, it is possible to make it look like the transform components are animating independently but there are some pretty significant caveats to keep in mind.

    • Yup, totally agree with you.

      To add that to the wound, animating complex animation in CSS can be a nightmare if you are not a pro SASS user. And you have to be really creative in how you use CSS too.

      I created this really complicated CSS experiment purely using SASS + HAML. http://vimeo.com/84713704

      Few major learnings:
      1) Hard to synchronise. Like you say, updating a duration will give you a cascading nightmare.
      2) The way you write your SASS code is almost identical to writing javascript, until a point you will think it is redundant to continue doing this in CSS.
      3) The crazy CSS transform property when working on the 3d polygon. transform: scaleY(..) skewX(..) rotate(..) translateY(..) rotate(..) etc the maths will mindfuck you.
      4) Lastly, the generated CSS, phew. Massive filesize. Could just use a library.

      It has only been my 2nd day with Greensock but it already looked really promising.

  48. Amazing article, definitely worth the read.

    Using CSS animations for things like transitions , hover effects and stuff like that seems to be more intuitive and easier to manage.

    However using CSS for complex animations is a nightmare, I am not even sure how it could realisticaly be applied to the real world. It’s good to know that there is a viable alternative

  49. Richard
    Permalink to comment#

    i think the best point made here is that the CSS vs JS animation debate has for too long been perceived as jQuery animation vs CSS. there’s a lot more too it than that. this article hopefully helps balance things out a bit.

  50. micky2be
    Permalink to comment#

    Nothing stop you to do CSS animation in JavaScript.
    Which will allow you to do everything you feel is missing such as adding 30 degrees to a rotation.

    • Permalink to comment#

      Unfortunately, I’m pretty sure that’s not true – you can’t do “everything” by setting up CSS animations through JavaScript, like independent transforms, physics, scroll position, animate along a bezier, use eases like Elastic and Bounce, seek to any spot or reverse smoothly on-the-fly (runtime controls), and pretty much everything else mentioned in the article. And as far as being able to just “add 30 degrees to rotation” anytime, technically that’s possible with JS+CSS but I’d love to see how you’d personally tackle it in a way that’s robust enough to, for example, in the middle of a rotationX tween that’s in-progress, and while other parts of the transform are animating (scale and translate), just say “add 30 degrees to whatever the current rotationX value happens to be right now”, and bonus points if you can tell it to go to an absolute rotational value in the shortest direction. :) My point is that even if that one thing is technically doable with JS + CSS, it’s quite cumbersome because you’d probably need to parse a 16-element matrix, calculate the rotation along with any other transform-related values and piece them back together into a matrix or list. Most animators would have no idea (or interest) in how to do that, thus it’s not very practical (workflow issue). Animators want to play and experiment freely and the tools need to facilitate that.

  51. I’ve come up with a pretty good solution to the timeline problem with CSS animations. By using JavaScript to trigger and a stepping function you get the best of both worlds. Plus its incredibly easy to work with. Your text to link here…

  52. kubrick
    Permalink to comment#

    I’d just like to say thanks for having made such an amazing toolset. You’ve saved me so much time over the years.

  53. Dave
    Permalink to comment#

    Is this just about animating on Chrome/Webkit? The benchmark doesn’t seem to work well on Firefox and not at all on IE11.

    • Permalink to comment#

      Works great in all major browsers including IE11 for me (just double-checked). I wonder if you’ve got your browser set to emulate a really old version or something? Did you try going to the codepen directly too (perhaps the embed here was faulty)?

      To answer your question, no, this article was not just focused on webkit browsers (I listed a bunch of others in the results table). Thanks for asking for clarification.

  54. Dave
    Permalink to comment#

    I don’t know what the problem is but I ran it directly in Codepen and it worked. Then I ran it embedded and it worked too.

  55. David Aimi
    Permalink to comment#

    Can you explain why GSAP is heavily promoting itself and using test cases like “GSAP versus jQuery” when their library clearly has jQuery littered all over the place?

    • Permalink to comment#

      Again, sorry if the article came across as self-promotional. I tried (and apparently failed) to avoid that.

      To be clear, GSAP doesn’t depend on jQuery at all. It’s not “littered all over the place”, but we do use it as a convenience in the codepen demos for selecting elements and a few other minor conveniences (as is so common these days). It’d be very easy to eliminate that, though. GSAP is dependence-free.

  56. Patrick
    Permalink to comment#

    Firstly, I haven’t heard that GSAP was a widely used library. I do think I will be using it in a few projects. I’m currently working on a website that that the client wants to have a lot of WOW factor and movement, something similar to some DVD title menus.

    Secondly, WOW…. I am absolutely blown away that anyone would take this post as self-promoting. I myself have used jQuery and CSS animations in the past, but only for basic animations. If I were to create a more elaborate or complex animation based project, I can clearly see where (in my case) GSAP would be a better option.

    If you think that this test is biased, I think we would all love to see YOUR test showing how it is. Jack clearly explains that CSS is a clear cut winner for some animations and did a very good job of not being self promoting. If he had used an alias, nobody would have batted an eye-lash (in my opinion). He is providing a very useful tool to our industry, and he catches grief for publishing it on another website? Great job guys…. way to help our industry grow.

    My $.02…. GSAP is an amazing library, and this post shed light on things that I did not know about animation comparisons.

    Thanks,

    Patrick

  57. John
    Permalink to comment#

    Even if GSAP is promoted in this well written article, what is the problem with that? It is a quality tool that is extremely well supported. If we want to advance the internet experience what is wrong with promoting something that has obviously been well thought out and has a dedicated individual supporting it?

    I personally think that anyone who writes an article and spends a great deal of time and effort explaining the pros and cons deserves some degree of benefit. I also think the community needs to be more careful about bashing something that they know very little about, especially if it is someone’s creation. Maybe take some time to play with it and ask questions to the creator and treat them with the respect they deserve for the effort they have put in.

    After some brief review of the GSAP library and the history of Greensock, it is my personal opinion that Jack is the real deal and his input into the community should be well received.

  58. Andrei Oprea
    Permalink to comment#

    Great read.

    A lot of the features missing from CSS are work in progress. Pause seek etc are coming in web animations

  59. GSAP rocks indeed. Ahead this article seems to bust a lot of myths on Jquery/CSS animator. Kudos!

  60. Jonathan Marzullo
    Permalink to comment#

    I think a lot of people that are complaining how they feel this article was an advert, are missing the point of the article. I see it more like making the web community more aware of their options when it comes to web animation.

    Coming from a Computer Animation and Traditional Animation background.. I was very happy with GSAP AS/AS3 for Flash. Im glad that Jack ported GSAP to JS. I find CSS Animations and @keyframes very frustrating and limited. If you need to make a change to your keyframes and timing with even a slight change, your looking at nightmare of re-calculating the timing. Plus having to write the same rules for cross browser. Animation is all about timing.. and CSS Animations are just not there yet when it comes to full control.

    GSAP is the only animation platform that I found to give me full control for serious simple and complex animations with a virtual timeline. If you take the time to do your own tests, you will see for yourself how GSAP helps cut down complex tasks.

    Now of course, there is nothing stopping anyone from using both CSS Animation and JS Animations in their workflow. But if you have to meet deadlines constantly and need exact control of your animation, then I would give GSAP a try, and do your own tests. It saves me so much time, without the hassle of CSS Animations lack of control, and lack of a timeline.

    Just my opinion… Test for yourself :)

  61. Matthieu
    Permalink to comment#

    I’m a plain old web developper who don’t come from AS3.
    When I first heard about GSAP, it was from ex-flash guys who had hard time transitionning to HTML and who used GSAP for very basic stuff.

    Soooo, I thought it was a stupid library, with a sucky syntax, a bad documentation and no following.

    And, a few month ago, I had a Big project with lots of animations. Not basic stuff. Complex animation, 2D and 3D, need for rewind mode, Speed modes, etc.

    I tried GSAP.

    It´s awesome.

    Not the syntax. Not the doc.

    But, Man, functionnalities and performance and bug-freedom… Awesome.

    If you use this for a slider, you’re a lazy moron. But if you have heavy duty animating, it´s a damn lifesaver.

  62. I have always preferred CSS animations over JavaScript, but the more I think about this the more I realise that I was just taking the “easy way out” (at least as far as work was concerned). As has been pointed out in the article, CSS animations aren’t even all that easy to complete and some things are just downright impossible. I think my reluctance to turn to JavaScript was down to clients saying how much they didn’t want it used, although they still wanted this and this to occur. Whilst I have turned to JavaScript when I have had to in the past, I’ll be sure to do it more often from now on.

  63. The comments above are full of arguments for or against JavaScript animations, but lets be practical here for a moment.

    Can you imagine creating something like 24hoursofhappy.com just with CSS animations?

  64. Permalink to comment#

    This post is a total surprise, in a good way, but somehow it resembles to most of the discovery shows where all the facts keep you up, but ends with a big question mark. After all, I’m not sure where should I care for css or javascript more, because I’m still convinced that each one has its own merit.
    I’ve read all the comments for a solution, but everything seems just like in the old days with the apple-windows, flash-javascript, corel-illustrator combats. Nothing creative and I really hate that.
    Going geeky for a moment here. Aquaman vs. Spiderman. Where? In the livingroom or in the bathroom?

    I see sites built around the GSAP script, just to take advantage of almost every effect, when in fact this should be a tool to polish your design. It is so good that it’s dangerous.

  65. As a fan of Greensock from the good ole Flash days I think a lot of people miss the point. From a developer/designer standpoint it makes since to have the GPU render graphics and cache them. On the other hand where Javascript come in is using the CPU for complex calculation combine with GPU, I mean just that alone will boost performance. However each tool has it’s strengths and weaknesses CSS and Javascript. I wouldn’t use Javascript to design (presentation layer) a page, and I certainly wouldn’t use CSS for interaction and complex calculation. One thing that I’m not a fan of is when all types of developers/designers argue on a specific case they have no experience in, or haven’t researched. I think that’s the problem with the entire web community to many opinions and not enough facts which Jack definitely proved his case with tests. JUST HAVE FUN GUYS!!! WOW. By the way Jack I still practice in Flash sometimes Greensock Flash Animation. I love Greensock

  66. Lots of very intelligent people have made comments here … It’s nice to read them and see how fellow developers feel about things … I’m Adobe Certified in Flash and LIKE MOST OF US, have moved on now doing HTML5 UI design etc … I have deep experience with Greensock libraries in Flash and have used the JS versions too … I just want to say to Jack that he is a superior developer and thinker in the realm of animation … Trust what he says … We embraced his tools at Sony Studios, Charles Schwab creative and other places I’ve worked … For me, animation control has no business being placed in CSS code in the first place … Just my opinion … It’s meant for styling … JS is much more appropriate to control animation … I want an API / old school I am … And GSAP rocks the house, no doubt … Jack, you’re an amazing dude … And I did not hear any bias in the article … I heard you as fair and objective … I think most of these readers did too … You da man …

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".