Jump to content


Tween Nano

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

are you planing on a nano version for javascript?

Link to comment
Share on other sites

I'm on the fence about that one because it'd need to be a hybrid of TweenNano and CSSPlugin since so many people would want to do CSS stuff and TweenNano doesn't support plugins. It's tough to strike the PERFECT balance of features, performance, and file size. Actually, it's impossible to please everyone in those regards because we all have different preferred ratios.


Plus, these days file size doesn't seem to be nearly as much of a concern as it was years back which is why I'm not sure there's a huge need for TweenNano vs. TweenLite.


Shall I consider this your vote for TweenNano being included in JS? :)

Link to comment
Share on other sites

I have wondered about this too, because there is a trend now with rich media ad units, that are non-Flash banners and only HTML/JavaScript, that restrict the included JavaScript code size to less than 35k or even smaller.


Granted, 30k-35k of minified JavaScript is quite a lot of code, but I wonder if there's a hybrid approach where perhaps a hybrid minified JavaScript include file could have a couple of ease types, the basic stock CSS tweenable props and of course the core nano tween engine?


Currently, file size is sitting at:

  • ~3.9k for EasePack.min.js
  • ~20.0k for TweenLite.min.js
  • ~12.8k for CSSPlugin.min.js
  • Total ~36.8k +/-

Unless the nano version can be crunched down to 20k or less and still perform up to the par standard, it's probably not a worthwhile conversion/endeavor. I'm happy just knowing that for less than ~40k, the base minified animation platform as it stands now is super swanky and solid.

Link to comment
Share on other sites

Fair points. I very well may do something like that. Rip out the code in CSSPlugin that makes transforms work in old versions of IE, only the Power eases, and basic functionality of TweenLite. I'll chew on that idea. There are some higher priority things right now like some of the plugins (bezier, throwProps, etc.)


and by the way, those sizes that you mentioned are the pre-gzip sizes. It's actually much smaller once you gzip stuff via the server.

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...

I think the solution is to make a adhoc system like ender.js or incorporate it into that. The main reason your system was so popular for flash is its ability to be small and functional or bigger and fully functional mainly working with rich media. I kind of disagree with the file size thing tho mainly because sites are moving to responsive to support mobile sites. Websites have to scale now to any device from iphone to ipad to desktop all on the same site "separate mobile sites are dead now", I think file size is more important than ever. The reason people are moving away from jquery to ender is because its ability to do the same thing with the adhoc approach minus the npm integration reasons. You need some sort of package manager to add and remove packages and resolve dependencies. Yes you have my vote for tween nano, along with your motion blur plugin, loader and transform around center/point. Also for your css plugin you should make it use a dynamic loader with a feature detection poly-fill. The only drawback is that extra http request but it will be universally faster.

Link to comment
Share on other sites

I could create a TweenNano class that would strip out some of TweenLite’s functionality and pack in some of the essentials of CSSPlugin and I’d guess that it’d end up weighing 50-75% of what TweenLite + CSSPlugin does. That’s the good news. But here are the challenges I see...

  1. Which features do I remove? I have already gone through this pruning process for the AS3/AS2 versions so I’m relatively comfortable making that call, but CSSPlugin is more difficult. The biggest kb drain by far relates to the transforms (rotation, scale, skew, etc.) but aren’t those things that a lot of banner makers would want? Do I remove the ability to tween colors? I certainly wouldn’t want to. Do I remove the ability for it to automatically tween between various units like % to px and em? This gets pretty uncomfortable and I can see people who have used TweenLite jumping to TweenNano and getting frustrated. “TweenNano is broken” or “WHAT? I can’t tween rotation? This is crap!”
  2. I don’t want to create a plugin system for TweenNano because it could get very convoluted and confusing to have TweenLite plugins and TweenNano plugins that are distinct. People would likely confuse them. And making one set of plugins that works in both poses some unique challenges, particularly kb-wise but even if I overcame that barrier, I’d worry that people would quickly start wondering why they’d ever use one or the other (TweenLite or TweenNano). Currently, TweenLite and TweenMax have a particular relationship where TweenMax is a beefed-up TweenLite but TweenNano can’t relate in the same way because it isn’t built on the same set of classes. It would have to be completely distinct and separate from the rest of the platform but shared plugins blur that line. And TweenNano instances couldn’t be inserted into TimelineLite/Max instances, etc. It just isn’t possible if the primary goal is shaving kb off of TweenLite which is already remarkably lightweight considering its functionality.
  3. I wonder how much TweenNano would realistically help because of CDNs and caching. Let’s say TweenNano shaves 12k off of TweenLite/CSSPlugin (4k gzipped) (totally guessing), how much does that really help when you factor in caching? Ideally, sites (particularly banner ad networks) will standardize on a set of animation classes (hopefully TweenLite). They’d include it on their network and once a browser hits one ad, it’d get that file and all the ads thereafter would get free access to TweenLite, zero extra loading time. So if we’re going that route does that initial 12k (or 4k gzipped) savings make a big enough difference to make up for all the functionality developers LOSE by going from TweenLite to TweenNano? Wouldn’t it be better to put the much more robust TweenLite at their disposal? Heck, that might actually reduce kb overall when you factor in all the extra code they’d have to write to get rotations, scaling, blah, blah apart from what’s normally standard in TweenLite/CSSPlugin.


Back when I created TweenNano for AS3/AS2, I purposely made a design decision that sacrificed some capabilities because I thought that overall it would benefit users by decreasing confusion and nudging them towards the far more capable TweenLite which would save them frustration in the end. I positioned it as the crippled option that should only be used if you can’t possibly afford the extra 4kb that TweenLite cost.


After having this discussion with a good friend of mine (who can chime in here if they want to reveal their identity), he made an excellent point: "After knowing the true strengths of TimelineLite/Max it would simply be torture for me to stack a dozen Tween Nanos together and manually increment the delays to build a decent sequence. I feel strongly that the modern-day animator should be able to take advantage of the robust tools they have at their disposal. We should be pushing the limits and not accepting the restrictions of a dead age."


As for your suggestion for a "package manager", I wasn't quite sure what you meant - something like RequireJS? I purposely avoided building the platform with autoloading of interdependencies because:

  1. It would lead to a lot more http requests (poorer performance)
  2. It would bloat the file sizes (to add the code for auto loading)
  3. It would impose a certain structure on the file directories (not the end of the world, but I think some people really like to have flexibility to put files wherever they want)
  4. It would force people to code in a very different manner, defining dependencies up-front. For example, if they use CSSPlugin somewhere in their code they'd have to specifically request that file somehow or define the dependency whereas in AS3/2, the compiler does all that automatically for us. Frankly I think it's easier and more intuitive to just have the person load whichever .js files they need (like typing import statements in Flash) rather than making them use a proprietary com.greensock.import(...) type statement or define(...)

Oh, and transformAroundPoint functionality is pretty much the same as the built-in transformOrigin feature of CSSPlugin. Have you seen that yet?

  • Like 3
Link to comment
Share on other sites

After chewing on this discussion for a while, I've moved towards the idea of simply having the flexibility to include any additional specific plugins beyond the base GSAP, which effectively gives us 'nano-like' control of total file sizes by virtue of what we choose to include or not.


In that respect, the main issue would likely be any code that potentially references missing plugins and how the GSAP will respond. And that code we write could/should check for the existence of any missing plugin dependencies before any animations are started.


Example of a dependency where TweenLite and TimelineLite (with CSSPlugin) would be required for a particular GSAP animation routine.

// conditionals would ideally be wrapped in
// recursive logic for checks/tests/loading
if( TweenLite == undefined || TimelineLite == undefined ){
// we'd better load the GSAP stuff since
// it's not available on the page at this moment...
// perhaps registering somewhere else that we're loading
// GSAP so other scripts wait for it instead of trying to load it
  if( CSSPlugin == undefined ){
   // logic for missing plugin (either load it or wait until
   // it's loaded if already queued in another loader... or
   // registered it somewhere else as currently being loaded
   // and then wait for it to be available, forcing other scripts
   // on the page to wait as well instead of loading it)
  // if we get this far, then all is well and we
  // can now animate without issues

With the scenario of centrally hosting the GSAP pieces and parts somewhere, if more elements on a given page (think rich media banners) reference GSAP and its various plugins, it would be great to construct our code to check for the existence of any required plugins (missing or already loaded/available) to determine if anything should be loaded prior to animation.


The goal is to prevent near-simultaneous loading of the same plugin per page, if possible, which brings up the idea that I have used where instituting a ‘registration of loading dependency method’ where other scripts can check/test against the base framework if any given plugin is ‘registered’ to be loaded, and if not, ‘register’ that a particular plugin is being loaded so that other scripts merely stand by and wait for it to be available. It's all a bit tricky because if the base framework isn't loaded yet, the scripts somewhere have to load GSAP somehow without loading it more than once and keeping track of all those requests from various entrance points becomes a nightmare when factoring in human error.


Then again, maybe this is all just way too much work and over complicated if we don't really care if multiple requests to load pieces and parts of GSAP are happening all the time without care and without regard.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

All good thoughts, Randall. I personally wouldn't worry too much about writing a bunch of code to avoid multiple requests for common files/plugins because the browser's cache should handle that nicely. In other words, if TweenLite is requested 5 times on a single page, it will really only incur the download penalty once (the first time) and all subsequent requests would be pulled directly from the cache which is nearly instantaneous. Although that's not the case if you're employing a framework that does AMD loading but typically if you're doing that, the system will automatically handle exactly what you're talking about (avoiding duplicates and managing dependencies).

  • Like 1
Link to comment
Share on other sites

If you go the AMD module route which is the way everything is going. I was told bye a worthy developer "but haven't verified it yet" that Require.js has its own build script that looks to see what modules exist and all its dependencies then throws in a concatenated file together. You can maybe just right throw that ant target in a primer script for people to add to there build scripts for further optimization. Either way if you go the AMD module route it will take care of the issue you can do a request or you can concatenate it.

Link to comment
Share on other sites

Interesting, does concatenation affect the caching on any measurable level? I've noticed that according to http://tools.pingdom.com/fpt/ that a score is much lower when loading a lot of files with the same file type like CSS, JS, etc. and it suggest combining them, but with large frameworks, combining all of the JS and CSS is really not ideal at all and quite the hassle if done manually or even macro-manually.

Link to comment
Share on other sites

Yes, scubajosh, my understanding is that it is possible to have RequireJS suck all those dependencies in and create a minified JS file for you, but I wouldn't quite go so far as to say "that's where everything is going". There are definitely benefits to this whole approach, but it isn't a silver bullet and it could actually could be undesirable in certain situations. For example, if you're on a site that uses TweenLite and the page has 4 ads that also use TweenLite and ALL of them have done what you suggested (have RequireJS create a minified version of all the dependencies), that means that the page wouldn't be able to leverage caching for TweenLite and it would load it 5 times (once inside each minified JS file).


Like I said, there are definitely some big benefits to using an AMD system like RequireJS but it's not quite the silver bullet that everyone had hoped for.

Link to comment
Share on other sites

  • 4 months later...

I dont agree with your approach at all I been building some big javascript projects after this discussion and have ran all kinds of bench marks the benefit you get from caching is minimal compared to the benefits you get concatenating. In theory yes cacheing sounds nice, but it actually slows things the best practice would be to minimize requests because of the time it takes to hand shake for each individual file is far greater than the added k-weight of the non cached file. I tried both ways on some very heavy modular javascript pages and the difference is massive 2s for my approach vs 7-30 seconds for your approach average.


The good thing is I been using tweenlite on my projects and they dont need to be in a AMD wrapper to get to work with r.js optimizer to concatenate them together. All you have to do is throw it in your AMD definition. Also I would definitely say AMD is the way everything is going. If you follow everyone at fluent conference this year allot fo the big dogs like Paul Irish or Nicholas Zakas have predicted these trends. I tested out there stuff with projects like backbone boiler plate and have had far greater success then without it. Also jquery supports AMD and since there new update with grunt support you can now split jquery up to make it smaller now.




Maintainable javascript Must see



Application Architecture



High performance javascript


Link to comment
Share on other sites

Thanks for the input! I'm curious about your assertions regarding cached vs concat: were you saying that loading one entire concatenated JS file on each page over the network is much faster than loading several files that are already cached on the hard drive? I'd be curious to see how you tested - do you have a set of files we can peek at?


Obviously one concatenated file would be far better than a bunch of independent ones on a single load, but I'd be very surprised if, for example, a 120k single file would load faster than 20 10k files that are already in the browser's cache (thus no network access is necessary). I'm not arguing against concatenation at all, by the way. Just curious to see when and how it's truly best in real-world situations.


Thanks for the links too!

Link to comment
Share on other sites

  • 5 months later...

Lets just put it this way my last pingdom test with my framework which is a stripped down version of backbone I removed underscore and added in the 11 methods underscore uses. I am using Tweenlite and its my only bloated piece code on it. I made my own version of jquery with qwery, bean, bonzo, tweenlite, "took methods from jeesh" and using reqwest. Everything is AMD, and I am using rjs optimizer and grunt.


My loadtime from pingdom test is 357ms. If I was just using require it would be 5 seconds async. My entire framework is lighter, faster, more powerful than jquery alone. My test page has 5 tabs and about 30 images all in one sprite using glue and a custom tinypng.org service I made 300kb pngs down to 80kb. My sass is converted to css and contatenaded in one file 30kb. My framework and all my modules are about 180kb minimized and compressed. This includes product 360, the heaviest part is videojs, store locator, product reviews module, tool tips, my own custom omniture code that calls omniture.


 I have full MVP with backbone micro I call it, and dotjs, with fully functional dom manipulation, animation, query engine, cross browser events, and ajax.




There is no framework out there that can top my functionailty and performance! Now trust me when I say this ;) make it nano please! I cant show you the code because I work for a big corperation that pays me allot of money to keep it private...






Josh Spivey

Link to comment
Share on other sites

That's really cool to hear about the success you've had improving load times. Congrats. 


Regarding TweenNano, I'd love to hear your response to reply #6 above. Specifically, which features would you drop?


Hopefully you've seen that the code base is very compact for what it does - there's not much waste at all, but one thing that really sets GSAP apart is its flexibility and robust feature set and I'm afraid that'd be sacrificed in TweenNano. There are TONS of JavaScript tweening engines out there, but they only do very basic stuff. It's really not that hard to make a value tween from one number to another over time, but professional animators care about the details and advanced stuff. Try doing complex sequencing with other tweening engines, or animating along a bezier path or reversing or timeScale or managing groups of tweens, etc. Most of that would go out the window in TweenNano too, so it'd be a lot like all the other plain Vanilla engines.


Another conundrum involves CSSPlugin and all the things it does under the hood to make animating DOM elements simple. It works around a bunch of browser bugs automatically so you don't have to worry about them. It handles complex stuff like 3D transforms, boxShadow, multiple textShadows, etc. - should that all be gutted in TweenNano? 


Sure, we could create a very small TweenNano that just does very basic stuff - no plugins, no timelines, no reverse/timeScale/pause/resume, and only basic css properties with simple values (left:"10px" but not backgroundPosition:"bottom right" or boxShadow:"0px 0px 20px red"), no unit conversion ("px" to "%" or "em"), no ability to add your own "tick" event listeners, and no className tweens. But is that a GOOD idea? I struggle with that. If there's enough market demand, we'd definitely consider it. Is this what you're voting for? Something like the other simplistic engines out there, but using the familiar GreenSock syntax? 

Link to comment
Share on other sites

  • 3 weeks later...

I did a grep on about 70 modules. I would say about 90% of my modules use this functionailty below. The rest I rarely use and everything I do has animations.


TweenLite.to($("#buyNowBtn")[0], 0.3, { css: { autoAlpha: 1} });

TweenLite.to($("#slideWrapper")[0], 0.8, { css: { top: this.incrementTop} });

TweenLite.to($("#microWrapper")[0], 0.8, { css: { left: this.xPosition} });


TweenLite.to($("#fullSizeImage")[0], 0.3, { css: { autoAlpha: 0 }, onComplete: function () {




TweenLite.to($("#videoContainer")[0], 0.8, { css: { height: 438 + "px"} });



So animate top, left, height, width using pixles, alpha and a oncomplete callback... Thats all a nano version needs... Anything other than that is bloat!


The main reason I use tweenlite is performance, it isn't because of the syntax I can write a wrapper to make it look like anything infact I tied it in with my notJquery to look like $("#selector").animate(); so jquery plugins will work with very little change, and I can swap out any animation engine I want. Even tho the syntax is similar with what I did in my flash days just about every animation engine has the same/similar syntax...

Link to comment
Share on other sites



It sounds like in your particular scenario, you're not doing very much. Simple top/left/width/height/opacity tweens. That's cool, but I think most people doing animation these days (especially with GSAP) want to do a lot more. At the very least rotation is common, and that requires transforms plus a pretty complex workaround for IE8 and earlier. If we released TweenNano and said "oh, by the way, you can only do top/left/width/height/opacity tweens...nothing else", there would be some very upset customers. "WHAT? I can't even rotate something? Sheesh. What about backgroundColor or backgroundPosition or scale???" And then there would be forums posts like "TweenNano is awesome...but I desperately need to animate rotation - can you just add that one feature?" And the same for backgroundColor, and others. 


If you only want super basic stuff, there are tons of options out there. Our goal with GSAP was to solve a different problem - the market desperately needed (and lacked) a robust solution with a simple syntax and excellent performance.


Like I said, we may eventually offer a customization tool that allows you to select certain features and have it spit out a js file that strips out everything else. That sounds like a pretty good compromise, don't you think? 


We're still considering a TweenNano, though. We appreciate the feedback and suggestions.

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