danehansen

im having a hard time figuring out what is going on when calling gsap.getProperty() by looking at the source code, but i assumed that under the hood that it would be calling element.getBoundingClientRect(), which in theory shouldn't be necessary if there is someplace else to get the value without calculating it off a dom element. am i correct or wrong?

in a scenario where i want to tween a dom element's position, but i would like to also make some caclulations on that current position onUpdate, is there a way that i read that dom element's current position without having to get it off the styles of the element or any of its getters?

just found something that applies to this topic that i thought i would share here. it appears that when tweening a parent element's css variable to tween multiple children, it causes repaints on each child. where doing the same tween on the children themselves can cause no repaints. check out the following jsfiddle example with your dev tool's paint flashing turned on and see the difference between the two: https://jsfiddle.net/k95c51yy/3/ kind of a bummer but oh well.

i think the performance concerns are probably related to the babel side of things? those are definitely to be considered. babel does not always convert stuff into vanilla js in the most efficient manner. but utilizing webpack does not mean having to use babel. you can still write vanilla js that wont be touched. in this case webpack would only be adding a very thin wrapper to handle the imports/exports. also as far as moving to new build systems (browserify to webpack etc...) if you had jumped on browserify, you wouldn't need to rewrite any code, with the possible exceptions of the import/export statements. if/when webpack goes anywhere, it will be because something else solves that problem better and you will still be able to leave almost all code untouched. the rewriting would just be in config files for the build process.

i suppose i will jump back in here too. i wanted to include some other reasons to move to a traditional build system (doesn't HAVE to be webpack, but might as well be webpack) 1. collaboration/forking - i know you guys dont accept PRs because you maintain the code yourself, but having a more traditional build can allow people to help try stuff out, which you could in turn decide whether or not you want to incorporate. also could allow users/businesses to fork the repo and use their own flavor. currently the git repo and what is installed from npm appear to be unrelated so it is quite difficult to be able to alter the gsap code and have it installed via npm. 2. ability to more easily get away from the global scope. its unavoidable for users installing via script tags, but for those using npm, it is sometimes quite important to keep the global scope clean. it can become a security issue. the duality of globals for script tag importers and privates for npm users can be solved with UMD, built into webpack. 3. your source code will be simplified and easier to understand if you let webpack handle the dependencies rather than various other hacks. 4. the longer these difficulties exist, the more open to the danger of a major tech company (google, facebook, etc...) putting an entire team of engineers on the task of creating an open source/free animation library that would almost certainly be immediately adopted throughout the tech community, and in turn be adopted by casual users. if your library is easy for everyone to implement and doesn't make anyone have to compromise, no one will want to re-solve the problem. 5. javascript changes so fast, and its always good to keep up with latest common practices for your own knowledge/experience.

yes, this does this trick! but when implementing i noticed that on a .fromTo tween that i need the modifier on both objects passed in. is that expected? and if so, why?

49, not 59. at my job we ship our product in chromium v49, and yes, applied multiple times like you said at first. the reason for not applying the tweened css variable at the root is that i want it scoped to each element. as far as the performance/timing issues, its more difficult to see in my jsfiddle, but i was able to see some lagging when clicking around a bunch. in implementation on the project it was much more obvious because of the weight of the application. i wouldn't suggest always calling `removeProperty`, but on the first css variable tween it could probably be determined if it were necessary and then called or not called from then on.

i attempted to upgrade gsap version at work and implement a tween of some css variables and immediately found an problem in chrome version 49 which i have personally already bumped into, and not sure what other browsers this could also branch to. to be clear, this is a problem in chrome, but the workaround is easy enough you might want to incorporate it into gsap. in chrome 49 when calling `setProperty` on a css variable that is already declared, rather than replacing the old value, it is added to the element. so throughout the course of a tween, a css variable is then defined on an element many times, which the latest one is always the overriding winner, but there seems to be some performance hits associated with this as well as timing effected. teh known workaround is to call `removeProperty` before calling `setProperty` again. go ahead and try out the jsfiddle in chrome 49 and watch the inspected markup as you click around.

ah back to the ol' alias trick again =(

this would work fine locally but in a large team, not so much. i would still want to install the `gsap` npm package and then probably included the bonus files with the project's source.

having trouble with CustomEase in webpack as well. if i'm installing gsap through npm, then i need to have the special plugins in the projects own source, and in the case with CustomEase its throwing an error that CustomEase cannot resolve module TweenLite. if someone has a license to use the special case gsap plugins, they're still gonna want to install the majority of gsap through npm.

this is great, i was just gonna post on here asking about css variable support. any word yet if it hinders performance? on one hand, we can tween the properties of many items by changing one variable, but on the other hand it utilizes window.getComputedStyle and style.setProperty, which might offset any savings.

this is great. i remember reading about this technique back in the day but totally forgot about it. thanks.

when using `BezierPlugin` to tween something along a bezier curve, you are able to add a `type` of values `thru`, `soft`, `quadratic`, or `cubic`. is there a way to get a curve of similar results when getting bezier objects from `BezierPlugin.bezierThrough`? i understand that there is the `curviness` argument, but i would really like to apply `soft` to my data i am getting back. thanks.

there appears to be an issue with the ordering of gsap related imports in webpack. i had seen and mentioned this in one of our earlier threads, but was finally able to narrow down when it happens. i'm working on something where i'm trying to utilize several classes from the gsap library, and noticed when attempting to introduce TweenMax that it logs out as an empty object, and therefore i am not able to utilize it. TweenLite is also in the project, as well as BezierPlugin. the problem appears to be resolved if TweenMax gets imported before BezierPlugin, but hopefully this could be rectified as it is confusing to users, and in large organizations some codebases are subjust to strict linting rules that would prevent the reordering of imports. including zip file of simplified project with comments. Archive.zip