Leaderboard

If you see the same code a few times, there's almost always a way to turn it into a function or loop. I'd agree with Jack in that this may be a bit over-engineered and I wonder if this thread may help. It's not exactly the same as your project, but you want the active animation to reverse before the new one plays and that's similar to what's happening in that thread. @Carl has a really nice simplified example of code and @Sahil followed up with some nice additions to the project. I think studying those examples could help. Happy tweening.

Would you mind stating your question more succinctly? The demo has 120+ lines of code and I don't quite understand what you were hoping we'd help you with exactly. A quick glance at the code does seem like it's over-engineered maybe. There's probably a much easier way to do what you're attempting, but I'm not entirely clear on what your goal is. Do you have a GSAP-specific question we can help you with?

The perceived lag is coming from the timeline duration increasing each time your slideAnimate() function fires. Check out this fork of you pen. Keep scrolling your mousewheel over it. See how the duration keeps increasing? There is no lag or delay. You're just making the timeline longer. I think your best bet here is to create a timeline for each slide and assign the active one to a variable much like @Carl's demo here: You can assign the active slide to that variable, reverse it on a mouse wheel event and then assign the new timeline as current and play() it when the reverse is complete. You also have a problem with interrupting the current animation. I know Blake asked you about this in one of your other threads. Can the user interrupt it? If not, you need to prevent that with the isActive() or isTweening() methods. https://greensock.com/docs/TweenMax/isActive() https://greensock.com/docs/TweenMax/static.isTweening() Happy tweening PS It's not necessary to quote an entire answer in your replies. It makes the thread harder to follow. You can quote an answer and then edit that quote to only the relevant parts. Thanks.

Yeah this was one thing I thought modifiers might be good for back when it was first proposed I just never got round to testing it out till now. I think it's a pretty good option for this kind of thing as long as you don't push it to the point where the added load from using the modifiers degrades the animation performance. I also really like the option from @OSUblake's post referenced at the beginning of this thread that records the animation progress then rebuilds it.

Regarding the if statements: if all the animations they are executing are the same then you should be able to replace the ifs with just a single selector for the active slide shown at the bottom. That's kind of the point of adding a class like active so it's selectable. tl.set($currentSlide,{autoAlpha: 0,className:'-=active'}) tl.set($nextSlide,{autoAlpha: 1,className:'+=active'}); tl.play(); if($nextSlide.index()==0&&$nextSlide.hasClass('about')){ var aboutH1 = $('.about h1'); slideAnim.to(aboutH1,0.5,{x:300},'-=0.5'); slideAnim.play(); }else if($nextSlide.index()==1&&$nextSlide.hasClass('team')){ var teamH1 = $('.team h1'); slideAnim.to(teamH1,0.5,{x:300},'-=0.5'); slideAnim.play(); }else if($nextSlide.index()==2&&$nextSlide.hasClass('case')){ var caseH1 = $('.case h1'); slideAnim.to(caseH1,0.5,{x:300},'-=0.5'); slideAnim.play(); } // if all the above animations are the same then you should be able to replace the ifs with just a single selector for the active slide slideAnim.to(".active h1",0.5,{x:300},'-=0.5'); slideAnim.play();

Really interesting that modifiers is another way to avoid "caching" values!

One more pen for the concept. I animated the size of the parent container so you can see how it works responsively without having to resize the window.

Here is how you can animate element as you change it's parent. You can do that by recording element's old and new position using getBoundingClientRect and then animate the difference using from tween.

I've read a lot of articles on why ES6 classes are bad, and I can summarize every single one of them. Classes are bad, classical inheritance is bad, functional programming is good. It's all opinions. I'm not saying there's no merit to their claims, but there are no technical reasons for why classes are bad. But here's the thing about classes, what they do isn't new. It's mostly just syntactic sugar for constructor functions. https://hacks.mozilla.org/2015/07/es6-in-depth-classes/ I personally use classes all the time. The biggest argument against using classes is one of the reasons why I like using them, classical inheritance, creating a class from another class. The people that wrote those articles would consider my CustomSprite class bad, but they would be OK with my CustomElement class. They're essentially doing the same thing. See how to create a custom element. You need to use a class. https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements // Inherits from PIXI.Sprite class CustomSprite extends PIXI.Sprite { constructor() { super(); } customMethod() { } } // Inherits from HTMLElement class CustomElement extends HTMLElement { constructor() { super(); } customMethod() { } }