Search the Community

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

Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements including a much smaller file size! Please see the GSAP 3 release notes for details. In recent months, the whirlwind shift to HTML5 in the banner ad industry has prompted a slew of policy changes. Publishers and networks are scrambling to answer questions from designers who want to build things "properly" (a term whose meaning can vary wildly these days). Growing pains abound. Shortly after we published an article describing the state of affairs and offering recommendations for a path forward, the IAB released a draft of their new HTML5 ad specs which echoed many of those recommendations. For example, the file size limit for standard ads was raised to 200kb. This was cause for much celebration across the industry. But we're not out of the woods yet. There is still a persistent mindset about how we look at kilobytes that's crippling the web. This article aims to challenge the old paradigm and explain why it's so important to re-assess kilobyte costs. Why limit kilobytes? Conventional wisdom says that kilobytes have a direct impact on load times and consequently user experience. File size limits exist to promote better performance. Period. Does conventional wisdom apply the same way in the HTML5 era? As we modernize our kilobyte-count policies, let's remember what the goal is: performance...or more accurately, better user experience. Not all kilobytes are created equal HTML5 has unique strengths that challenge us to move beyond the simplistic "aggregate total file size" mentality of yesteryear. We need to look at kilobyte cost in a new, more nuanced way. There are four primary factors: Cache status When is 35kb not really 35kb? When it's cached. A cached file has absolutely zero bandwidth cost regardless of its size. It loads immediately. This is particularly relevant in banner ads because there are certain chores common to almost every ad (like animation management tasks) that can be encapsulated and shared among many, many banners. The end user only loads that shared resource once and then it's cached and completely "free" thereafter...for all ads pointing at that file...on all sites. Does it really make sense to penalize ads for using those ubiquitous shared resources even though they're so pervasively cached that they don't typically affect load performance? In the modern world, file size limits should apply to the banner-specific assets that have a direct impact on loading times, not standardized shared resources. Location Kilobytes loaded from a CDN (Content Delivery Network) are typically "faster" because they're geographically dispersed and automatically loaded from the closest server. Plus CDNs have inherent redundancies leading to better reliability. Spread 200kb spread across 24 files will take longer to download than 200kb spread across only 4 files. This isn't particularly relevant in the discussion about shared resources (which should be cached very quickly), but is an argument in favor of loading TweenMax rather than the combination of TweenLite, CSSPlugin, EasePack, and TimelineLite even though they collectively use fewer kilobytes. If the industry remains focused solely on aggregate total file size, it pushes designers/developers toward less capable solutions that use fewer kilobytes even though they don't necessarily affect load times and could be replaced by more robust options that allow more creative expression. Performance yield Some kilobytes are cheap in terms of the initial load but expensive for runtime execution. If our goal is better user experience, this factor should weigh heavily into the overall kilobyte cost equation. Would you rather have a banner that loads 200ms faster with janky animation or one that's super-smooth at runtime but takes a fraction of a second longer to load? Are publishers primarily concerned with displaying ads faster initially or ensuring that their site runs smoothly once loaded? Of course there are reasonable limits either way (waiting an extra 30 seconds for a huge file to load would be intolerable even if it made things run buttery smooth), but in most cases we're only talking about fractions of a second difference. For example, GSAP contains "extra" code that automatically GPU-accelerates transforms, applies lag smoothing, leverages 3D transform matrices, avoids layout thrashing, organizes things internally to make auto overwriting super fast, etc. - would removing those features for the sake of milliseconds on initial load (and zero savings once it's cached) be a step forward or backward? Incentivizing the wrong things If the IAB and publishers don't embrace a common set of shared resources that get excluded from file size calculations... It creates inefficiencies and redundancies - thousands of ads may each contain their own [duplicate] copy of a library like TweenMax, squandering valuable bandwidth. It penalizes the use of robust, industry-standard libraries in favor of custom JS and micro-libraries that probably aren't nearly as capable, well-tested, cached, compatible, or performant. When something breaks, it will be more difficult for the various ad networks and publishers to troubleshoot and support custom JS and diverse micro-libraries. Lots of APIs to learn (or in the case of custom JS, more advanced expertise would be required). GreenSock would likely need to create a minimalistic version of TweenMax that has a tiny subset of the features. We feel strongly that this is a step backward and explain why here. So ultimately, an "all-inclusive" file size policy could actually hurt load times as well as runtime performance. Yet the primary goal of file size limits is to protect performance. Hm. If the industry rallies behind a few popular, well-maintained and performant libraries, exempting them from file size calculations because of their ubiquity, it would not only deliver a better overall user experience, but also make it easier to create high quality banners. There would be fewer headaches for networks and publishers too. TweenMax (GSAP's largest file) technically weighs around 34kb but those kilobytes are the remarkably inexpensive kind. TweenMax is widely cached, it's on multiple CDNs, it packs various tools into a single file (zero "spread"), and it has an extremely high performance yield because of its many runtime performance optimizations. There are so many ads using it already that it has little or no effect on load times. Should it really cost banner ad designers/developers 34kb against their file size budgets? Is it wise to incentivize cooking up their own custom code for handling animation tasks instead? The good news Every major ad network we’ve contacted understands the value of shared resources and is very GSAP-friendly. In fact, virtually all of them have GSAP on their own CDNs and don't count its file size against ads unless the publisher insists otherwise (which is rare). One notable exception is Adwords, but we have been told they're working on a solution. Allows GSAP Excludes GSAP from file size calculation* Hosts GSAP on CDN Advertising.com/AOL YES YES YES Google DoubleClick YES YES YES Flashtalking YES YES YES Sizmek YES YES YES Flite YES YES YES Cofactor YES YES YES Adwords YES YES YES *Unless publisher objects which is uncommon Google DoubleClick is even pioneering a process that will automatically detect when GSAP is used in an ad and swap in its own CDN link to maximize caching benefits. Pretty cool stuff. Conclusion Let's embrace the unique strengths of HTML5 and modernize the way we count kilobyte costs. Let's support policies that incentivize better performance and user experience rather than a race to the smallest total file size for each individual ad. Caching, CDNs, kilobyte spread, and performance yield should all factor into the way we view kilobytes the HTML5 era. FAQ Isn't it unfair if the IAB only recommends a few popular libraries? What about newer or lesser-known libraries? This is an entirely valid concern. The list should be reviewed regularly and the IAB can assess each library's industry support, performance profile, compatibility, and track record for ongoing updates and bug fixes. New contenders could be submitted for consideration anytime. But remember that the key to realizing the performance benefits is keeping the list short so that caching is focused and pervasive. If there are too many "standardized" libraries, it dilutes caching and defeats the purpose. There's no way that everyone will agree on which libraries should be on the list but if we get hung up on not offending anyone or being afraid to appear biased, we'll miss the opportunity to move the industry forward. The list won't be perfect, but not having a list at all is much worse. What happens when a library gets updated? Wouldn't it need to be re-cached? Yes. And trust me - we want libraries to be updated somewhat regularly to work around new browser inconsistencies, patch library bugs, and implement new features that drive things forward. But these updates wouldn't need to interfere with existing or legacy ads - when a library is updated, a new CDN URL would be generated and new ads could optionally point to that version. Those ads would indeed trigger browsers to cache that new version but this should happen very quickly. Most likely within a matter of days the new version would be pervasively cached across the web. Yes, each end user would pay that kilobyte tax once on the first load and then it would be "free" thereafter. Would GreenSock still recommend this policy if GSAP wasn't included in the short list of exempt libraries? Absolutely. This isn't just about getting GSAP an exemption - this is what we believe is best for the industry overall even if GSAP isn't on the list.

Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements. While it is backward compatible with most GSAP 2 features, some parts may need to be updated to work properly. Please see the GSAP 3 release notes for details. The following is a guest post by Chris Gannon. Chris is the leading authority on using GSAP with Edge Animate. A veteran of the Flash world, Chris has been applying his animation and design skills to many cutting-edge HTML5 projects. We asked Chris to explain to our audience some of the techniques that he uses in his client work and top-selling components on CodeCanyon.net. The concepts he describes have many practical applications and can serve to radically transform how you approach complex projects. Be sure to explore the demos and study the source code. This is not intended to be a step-by-step tutorial. .wide .content p { font-size:20px; } I love 3D stuff and I'm always trying out interesting ways to add depth to my projects. In this article I'll talk about how the CubeDial below was made, the concepts surrounding its underlying mechanism and how some of the solutions I employ overcome some common issues. Ok, so let's get going. Explore the CubeDial demo In the demo below, spin the dial. Notice that spinning the dial spins the cube. You can also swipe the cube and the dial will spin. Both the cube and the dial spin using momentum-based physics. If you are really clever, you may notice that the cube isn't really a cube, as it has 6 front-facing sides. See the Pen Gannon - Cube / Dial by GreenSock (@GreenSock) on CodePen. What's it using under the hood? The core functionality is handled by the GreenSock Animation Platform (GSAP). I always load TweenMax because it includes all the things I need in one script load: TweenLite, CSSPlugin, EasePack, timeline sequencing tools, etc. I use TweenMax all over the place not only to immediately set CSS properties (using TweenMax.set() but also to delay the setting of them, to tween them, and to trigger events not only when they start or stop but crucially whilst they're animating too. Next up is Draggable - a very useful and flexible utility that I use in practically all of my projects now as most UIs need something dragged or moved. Finally we add in ThrowPropsPlugin (and couple it up to Draggable) for that flick/throw/physics/inertia that we have all become so used to on our mobile devices. So the three main GreenSock tools I will be using are: Draggable, TweenMax and ThrowPropsPlugin. The Cube's Structure A lot of you reading this will be visually led developers so below is a diagram of what's going on with the cube (ok it's a hexahedron I think as it has 6 sides). Each face of the 3D object is a <div> with a background image. Each <div> has its Z transformOrigin point set a fair bit away from the actual face (behind it) so that when its rotationY is animated it pivots left to right in perspective. This diagram illustrates the 6 faces - their transformOrigin X and Y are simply set to the middle of the faces (50% 50%) but the crucial part is the transformOrigin Z position which is -200px. In the actual code I dynamically work out what that distance should be based on the number of faces but to keep the diagram simple, I use -200px. The dotted center is that value (-200px) and once that's set each face will appear to swing around a point 200px behind itself when you tween its rotationY. By spinning each face around the same point, we achieve the illusion of the entire cube spinning around its center. To programmatically figure out the rotational offset of each face I use this equation: rotationY: (360/numFaces) * i; What wizardry is used to make a 6-sided object look like a cube? There's a simple answer to this and to demonstrate what's going on I have coded it so that all the faces become slightly transparent when you drag the cube. Try dragging and then holding it halfway through a drag - you'll see the other faces are distorted behind (see sceenshot on left). That's because the transformPerspective on each face is set fairly low (meaning exaggerated) in order to 'bend' the other faces behind. I've also added a slider to help illustrate this in the demo at the top of the page. As you drag the slider, the faces' transformPerspective is set higher and higher to the point where if the slider is fully to the right the perspective is so flat that the cube looks more like an infinite slide show. Try dragging it halfway then spinning the dial or the cube. Creating the dial In simple terms, the dial is just a png with some divs with some numbers in them. I do a little loop based on the number of sides in the cube to generate those divs and position them over the dial image. To make the dial "spin-able" literally takes one line of code using GSAP's Draggable. myDialDraggable = Draggable.create(dial, { type:'rotation', throwProps:true // for momentum-based animation }) That's really all you need to spin something. Amazing. However, the dial I use for this project is a little more advanced. I've isolated some of the dial's code in the demo below. Take note of how the numbers stay vertically oriented as the dial spins. Spin the dial See the Pen Gannon - Dial Only by GreenSock (@GreenSock) on CodePen. Using this method keeps everything in sync and it allows for multiple UI inputs - the null object is always controlled by user interaction and its X position is used to determine the rotation value of the dial (if the cube is dragged) and rotationY value(s) of the faces (if the dial is dragged). You can also use it to work out which face is at the front and because Draggable has the brilliant snap function you can ensure that when you release your drag/throw on either the 3D element or the dial it will always animate the null (and consequently all dependent objects) to a position where a face is flat on. Once it's come to rest you can also fire an onComplete event and have something happen - you might want the active/front face to load an iframe or animate its content. Or maybe you'd like a sound to play or you might want to perform a calculation based on the X position of null. Examples of using onComplete to trigger an animation when the spin is complete can be seen in demos for EdgeRotater and EdgeDial. Interacting with the 3D cube Unlike the simplified 2D demo above, grabbing and throwing the cube is a little more involved. The secret here is that you aren't directly touching the cube at all. In fact it would be literally impossible to effectively drag the cube by a face as the face would eventually disappear in to the distance of 3D space and overlap with other faces. It would be extremely difficult to assess which face receives the touch / mouse input for dragging. To solve this issue a Draggable instance is created that has the null object as its target and uses the <div> that contains the faces of the cube as its trigger. In simple terms this means that any time you click and drag on the div containing the cube it controls the x position of the null object, which in turn sets the rotation of each face of the cube and the rotation of the dial. Its sort of like interacting with a touch screen. There is a piece of glass between you and the UI elements you tap. Where you tap on the screen dictates which UI elements respond to your input. In the CubeDial, the div that contains the cube is like the glass screen of your phone. As you move your finger over the container, the app tracks your motion and applies the new values to the null object. Wrap up Ok that's enough of the complexities - it's hopefully not that complicated when you play around with it and adjust some values and see how things react. And if you're not already familiar with this kind of mechanism, once you've got your head around it you'll probably find you use it everywhere as it can be applied in pretty much all of your interactive projects. So that's all for now - I hope you found some (if not all) of this article interesting and/or informative. Admittedly it introduces the concept of null objects using a fairly complex example but it really doesn't have to be complex (or 3D). The 2D null object demo above might be a great place to start if all of this is pretty new to you as it uses a null object at its most basic level. Dive into the entire source code of the CubeDial Demo. My first draft of this article was peppered with gushing compliments regarding GSAP and I was told to tone it down a bit and maybe leave them until the end. So here it is (it's toned down a bit because I'm quite an excitable person!). GSAP rocks my world and the world of all my clients. If you aren't using it yet you are potentially missing out on one of the best (if not the best) animation platforms for JavaScript/CSS3. Its flexibility, ease of use and performance is light years ahead of anything else and if you're not using it and are curious then I heartily recommend you dive in and see for yourself. Jack has created amazing tools for designers and developers like us and Carl does an extraordinary job of explaining how they work in a simple, relevant and, most importantly, usable way. Happy tweening!