Jump to content
Search Community

Web Animations API and GSAP

GreenSock test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

I saw this tweet today: https://twitter.com/MiguelCamba/status/560806390210363393asking about whether the Web Animations API will ultimately make GSAP obsolete, so I figured I'd offer a few quick thoughts here and invite others to chime in if they'd like. 

 

For those who don't know, the "Web Animations" spec I'm talking about is described here: http://www.w3.org/TR/web-animations/

 

I think it's a great initiative by some browsers to address quite a few major deficiencies in the current crop of animation technologies that exist inside the browser. For example, if the spec is adopted, you'd be able to create tweens and timelines that have a lot of the controls that GSAP users have enjoyed for years (play(), pause(), resume(), reverse(), etc.). Awesome. Big step forward for the native browser. 

 

Web Animations also aims to unify some pieces of SVG animation capabilities and CSS animation capabilities. Again, bravo. 

 

I have spoken to some of the editors of the spec (super smart, and super nice guys) who have consistently maintained that they don't see Web Animations as competing with tools like GSAP. Instead, they're intended to be complimentary. They recognize that tools like GSAP offer a lot of sugar on top that makes things far more practical for real-world animators. So if Web Animations get adopted by all the major browsers (and that's not guaranteed - only Firefox, Chrome and Opera have said they'll adopt them last time I heard), tools like GSAP could leverage them under the hood where appropriate to potentially get a speed boost or additional capabilities. Excellent. 

 

Why not just use Web Animations instead of GSAP? 

I don't mean this to sound critical of Web Animations, but since we're being asked to explain why/where GSAP fits in, allow me to point out a few important factors to keep in mind:

  1. Animate scale, rotation, skew, and position independently - this is a BIG deal for real-world animators, and since the Web Animations spec is built on top of the CSS spec which shoves them all into a single "transform" property, it's impossible to manage them in a truly independent fashion. GSAP, on the other hand, makes it easy. I had a long talk with the editors about this a while back, and although they really wanted to find a solution, none of us were able to find one because of the need to maintain backward-compatibility with the CSS spec. So a tool like GSAP is necessary to get robust independent control. Transforms are definitely the future of animation because they can be GPU-accelerated and don't affect document flow (better than "top" and "left").
  2. Compatibility - GSAP works back to IE6. Web Animations aren't fully implemented in any browser today, but are partially implemented in Chrome and Opera. Microsoft may never implement them. Not sure about Apple either. There is a polyfill that's considered "beta", but when I tested it there were huge performance problems and garbage collection bugs that crashed the browser in my tests. It didn't seem ready for production use. Keep in mind that the spec itself is in flux, so you may write code today that'd break when the spec gets finalized.
  3. Works beyond the DOM - GSAP can be used to animate pretty much anything JavaScript can touch including canvas library objects, generic objects, or whatever. The Web Animations spec is for DOM elements.
  4. Solve SVG (and other browser) bugs and inconsistencies - GSAP solves problems with things like transform-origin behavior and harmonizes it across browsers. See http://css-tricks.com/svg-animation-on-css-transforms/Web Animations don't solve problems like that. GSAP "just works" where standards fail.
  5. Plugins and conveniences for real-world problems - there are all sorts of problems that animators face and GSAP solves. The spec won't do that. For example, overwrite management, physics, scrolling, relative values, directionalRotation (clockwise, counter-clockwise or shortest), rounding, labels, etc.
  6. More easing options - GSAP offers RoughEase, SlowMo, and more. See http://greensock.com/ease-visualizer/

One of the biggest promises of Web Animations is that it'll tap into the browser's native power to make things perform better, like layerizing things and shoving them to the GPU efficiently. I sure hope that happens and that it translates into real-world gains. GSAP already does some of that by leveraging 3D matrices during tweens, although I'd bet it could be faster if it was done directly by the browser. The problem is that in tests I've done with CSS animations (which use the same engine under the hood), they really weren't much faster in most cases, and JS was often faster. I know, it sounds crazy. JS execution is super fast these days (when written well). But if the browsers do indeed make things faster with Web Animations, that'd be amazing and GSAP can just tap into that under the hood.

 

Again, I don't mean to criticize the Web Animations spec at all - I think it's a cool initiative and I hope the browsers get better and better an animation. The more tools they give us, the more GreenSock will leverage them and create even more refined tools for that special breed of top-notch animator out there who needs to solve real-world problems. GSAP + Web Animations could be a great combo eventually. And I'm confident that Web Animations won't supplant GSAP.

 

Feel free to correct me about any assertions above. I'm admittedly no expert on the Web Animations spec. 

  • Like 6
Link to comment
Share on other sites

This is great! I've often wondered about your thoughts on Web Animations and how GSAP fits in.

 

I don't see Web Animations making GSAP obsolete. Rather, I see more people being turned onto GSAP for one simple reason, abstraction. The same reason people use jQuery, LoDash, D3, Pixi, and CSS/JS preprocessors.

 

And If GSAP ends up becoming syntactic sugar for Web Animations, I'm sure more people will prefer GSAP's API over the Web Animations API.

// Web Animations
var animation = new Animation(element, {"transform": "translate(100px, 200px)"}, 1500);

// GSAP
var animation = TweenMax(element, 1.5, { x: 100, y: 200 });

The Web Animations API also use arrays of keyframes to group animations together, unlike the nice method chaining that GSAP offers. You check out what some of the syntax looks like here.

https://www.polymer-project.org/platform/web-animations.html

 

And here's some Web Animation demos to check out. You can view the page source to check out the code.

http://web-animations.github.io/web-animations-demos

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...