Even Lighter - Custom cssPlugin, easing

[Dennis]

I would like to see an example of how to create my own css plugin, so that I can create a css plugin that only cares about, for instance, "left". (Top of my list)

 

Similarly, I would like to see an example of how to create my own easing plugin, so that I can create an easing plugin that only contains the type(s) of easing that I plan to use.  (Nice to have)

 

It would also be neat if there was an even lighter, barebones version of TweenLite. (Nice to have, but I recognize this might be the biggest ask with the least justification.)

[Carl]

Hi and welcome to the GreenSock forums.

 

Thanks for your questions.

 

I would like to see an example of how to create my own css plugin, so that I can create a css plugin that only cares about, for instance, "left". (Top of my list)

 

 

Unfortunately that is a non-trivial task. CSSPlugin has over 2000 lines of code. It's built to be extremely flexible and handle an unlimited number of CSS properties. There isn't any code specific to properties like left, top, margin-top, border-color, border-color-top, padding-left etc that can just be pruned.

 

Perhaps someday we can make it so that a version of CSSPlugin can be generated that omits support for 2D transforms, 3D transforms and some other types of properties. But right now even that would be a bit of work and not something we can easily explain.

 

Similarly, I would like to see an example of how to create my own easing plugin, so that I can create an easing plugin that only contains the type(s) of easing that I plan to use.  (Nice to have)

 

 

There is no better source for sample eases than EasePack.js (easing/EasePack.js)

The code for every ease is in there and lightly commented. Should be fairly easy to remove eases you don't need. With so many eases in there you should be able to get a good idea of how eases are built. 

 

FWIW we have plans for a custom-ease tool to make ease building easier, but we don't have a firm launch date as of yet.

 

It would also be neat if there was an even lighter, barebones version of TweenLite. (Nice to have, but I recognize this might be the biggest ask with the least justification.)

 

Yup, we hear this every now and then. Very hard to keep everyone happy as everyone has different ideas of what is necessary for their needs. I'm not sure what type of file-size gains you are looking for. We take optimization and performance very seriously and for only 7Kb TweenLite does a tremendous amount of work. 

 

We're always looking for more ways though to optimize and give our users the control over what they need to load. We'll definitely keep your concerns in mind. Its likely that someday we could have a custom build tool in place that offers even more flexibility. Right now there are just a number of new tools and features that have priority.

[GreenSock]

I'd echo all of Carl's sentiments and I'd also encourage you to consider (as we have) the tradeoffs of chopping down the file size (by dumping features) and whether or not it's truly worthwhile for your particular application. Sometimes it surprises me how much people focus on file size in light of the relative impact on their users' overall experience. For example:

1. The average web page is well over 1MB today. The current version of TweenLite and CSSPlugin combined represent less than 1.5% of that. Let's say we could magically make them both 80% smaller instantly (WOW!) - that would only make your page load roughly 1% faster. In terms of time, on the vast majority of connections, that represents perhaps a few hundred milliseconds. Is going through all that effort to rewrite TweenLite/CSSPlugin and drop a bunch of features worth that? Will anyone even notice?
2. If you (or we) created that customized "uber-lean" flavor that only handles a few properties (like "left"), you couldn't benefit from leveraging the CDN files or browser caching from when the user visited another site that uses GSAP (the "standard" files). From a performance standpoint, leveraging the CDN and/or browser cache will likely deliver even better performance than using a custom "uber-lean" flavor of the files.
3. Internet connections (and processor speeds) are getting faster and faster all the time, so the payoffs diminish over time for these kinds of kb-cutting. I'm generally more in favor of leaving a richer feature set in place unless it's really heavy.
4. Imagine the potential hassles you may encounter if you craft a custom flavor of TweenLite/CSSPlugin that only has the features you need for your particular project today, and then next month the client requests something that requires a feature that you chopped out? Maybe you don't remember exactly which things work and which don't - it could get cumbersome over time to maintain/update. Not a deal-breaker; just annoying. 

Check out this article that covers some of the same points regarding jQuery: http://flippinawesome.org/2014/03/10/is-jquery-too-big-for-mobile/

 

If you'd like our help in creating a custom flavor (I realize there may be some use cases where it truly is better to do that), we do offer consulting services for a fee. You can PM or email me about that.