madleo

No worries ~ and appreciate the input. If this was purely for learning, I'd agree with you on the approach. The decision to pick up one of these webGL tools is based on a strict timeframe for a project, and so I have to be a bit more cautious. If it wasn't for the performance issues, I would definitely lean towards sticking with pure css, js, and gsap. From what little I've researched however, ThreeJS + react three fiber doesn't seem too bad given the available resources -- it's more of the issue of volume. That aside, the point about Pixi being more general purpose is something I haven't considered...and quite frankly, 2d animations should most likely suffice. I'm going to try and recreate the shared animations with canvas first as you suggested, then perhaps progress into webgl land.

Ah, haha gotcha. Thanks for clarifying. And of course! Much more credit is due, and it's great to see the product evolving. On a side note, I'd really appreciate your opinion with the following... I have a project that I hope to make live in about 2-3 months time. The most I can devote towards learning something like threejs + react-three-fiber is about 5 hours a day for 2 months, equating to a conservative 200-300 hrs. I have zero background in graphics, but decent in JS land. I need to be proficient enough to build backgrounds that you see in the various sections in http://vaalentin.github.io/2015/. (minus the scroll animations). It's difficult to say how easy/difficult this would be. Lastly, if you were me, what would your learning path look like? And apologies in advance for the horrendously bloated question!

Jack -- really appreciate the insightful answer! Hmm..I do need a scalable solution; and by that I mean, the ability to create more robust/heavy UIs and animations. I was hoping that for now I could push out some basic animations with CSS and/or JS, but as you said, it comes quite costly. I never considered the PNG idea, although to achieve the certain fade out/ fade in effect, I can't imagine trying to swap out pngs at 60fps. I am trying to achieve an affect akin to the levitating particle effect as shown in one of the codepens. Currently what I'm working with is box-shadow + pseudo elements, but see that it's expensive to work with. Hmm. Welp, nevertheless, thanks again -- I sincerely appreciate the help. Oh and GSAP is definitely my favorite animation tool thus far -- even though all my work is done within the context of React Frameworks. Congrats with all the progress, and oh and also, I feel that I should note that the two codepens i shared are not mine. heh.

Hi Team, From experimentation, I'm assuming that there is no way to create an infinite loop animation with let's say 100 elements that won't air fry the fan/CPU. Whether this be in CSS or JS. Tried the will-change, and he translateZ(0)s with marginal benefit. I think I have a base understanding as to why this cannot be achieved with CSS or JS alone. I've added a simple codepen URL that demonstrates an example of what I'm referring to. This 'performance' issue is quite critical to the implementation of an important feature. With this in mind, should I want to achieve this effect, the only workarounds I can think of are: - PIXI, ThreeJS, Canvas, and the like - Create a video. After effects / Lottie files? - pseudo elements (are pseudo elements less expensive to animate? I'm sort of kidding with the latter. But should the first option be viable, as in the CPU/performance will fair much better, then there is 1 more requirement, which is: These animating elements needs to sit in front of an image. An image that can be dynamically changed by the user. So, something like https://codepen.io/hf666/pen/WVrpWe Given that the particles are just elements, it's simply a matter of using basic css. But will this work with something like PIXI/Three? Needless to say, I've never used something like PIXI/Three before. Although I will say that I will most likely move forward with ThreeJS given react-three-fiber. Thanks a lot in advance. Should time allow, I'd also really appreciate some insight as to how PIXI/Three works on a more fundamental and practical level when compared with pure css/js implementations. As well as how long it would take for an intermediate JS dev (advanced react...not that this means much) to pick up these tools to confidently implement the above. Thanks again!

Many many thanks for investing time into this, truly grateful and always great to see your examples. I'll be sure to try and learn as much as i can from this. Thanks Blake!

Interestingly, keeping your original implementation and simply adjusting the scroll speed seemed to have done the trick. At least in Chrome / Android. The resize event is still firing but given the new range of values maybe the jump is too small to notice. let scroller; if (window.innerWidth <= 800 && window.innerHeight <= 730) { scroller = { target: document.querySelector("#playground-subcontainer"), ease: .5, // <-- scroll speed on mobile endY: 0, y: 0, resizeRequest: 1, scrollRequest: 0, }; } else { scroller = { target: document.querySelector("#playground-subcontainer"), ease: .05, // <--scroll speed on !mobile endY: 0, y: 0, resizeRequest: 1, scrollRequest: 0, }; }

Hey Blake, Great to hear from you! Could you elaborate using your smooth scroll implementation? Or if you could elaborate a little more on the fixed body size approach.. I just tried the following.. body { // BEFORE // overflow-x: hidden !important; // overflow-y: scroll !important; background: #148991; height: 310rem !important; } a { cursor: pointer; text-decoration: none !important; } #main { // AFTER overflow-x: hidden !important; overflow-y: scroll !important; background: linear-gradient(to right top, #148991, #011219, #022531, #074757) !important; overflow: hidden !important; position: fixed; width: 100vw; display: -ms-flexbox; display: -webkit-flex; display: flex; justify-content: center; top: 0; left: 0; right: 0; bottom: 0; } Am I going in the right direction here? At this point the address bar still causes teh issue

Nice man, site looks impressive! My site just requires two things -- smooth scroll + fading elements on scroll. For this I'm using Blake's implementation + Intersection Observer API. What I really like about Blake's implementation is it's purely JS, and JS that I can see/tinker with easily. I haven't tested my app on iOS but see this on chrome + android. To visually see what's happening, Found this video on a thread btw. The only workaround (if you can call it that) I can think of to address all devices, is to remove the smooth scroll functionality for mobile. Having trouble with this too. Tried going the JS + GSAP way, if (window.innerWidth <= 800 && window.innerHeight <= 730) { // remove and update classes TweenMax.set(this.el, { className: -=main}); TweenMax.set(this.el, { className: +=main-mobile}); }; Tried swapping css files dependent on viewport but having issues in a SSR Next.js environment. But still no luck. Seems like ViewportUnitBuggyFill is meant for legacy browsers on android where vh,vw units are not recognized. This is a concern too, but not quite there yet. I'm still working on getting this to work on modern browsers lol. As you can see, right now I'm leaning heavily on this forum lol.

Hello Everyone, I've implemented Blake's smooth scrolling solution and am in love with it. With that in mind, I'm bashing my head the past 24 hrs on trying to get this to work in mobile. Blake's already addressed what the issue is, Has anyone found a workaround or even better, come up with a working solution for mobile? Any suggestions, direction, help on any level would be greatly appreciated.

Ah, ok i see what you're saying -- thanks a lot for clarifying!

That sounds right -- React takes a snapshot of the virtual DOM, compares with proposed updated DOM, then syncs/updates objects to the real DOM. At the end of the day we're targeting the real DOM. Could you elaborate a little more regarding the problems that refs would resolve? Specifically the one's you're alluding to: I think it might just be the way its phrased. Thanks in advance!

Awesome. Really appreciate the level of insight. If I’m understanding this correctly (and allow me to summarize here) — The surest way to get GSAP and React working together is to leverage lifecycle hooks, in that you’re able to control the creation/start of animations only after the DOM has rendered or completed an update to the DOM. With that in mind, we mainly use componentDidMount and componentDidUpdate respectively. The most obvious reason for wanting to leverage lifecycle hooks is to prevent the situation where a tween target gets removed during an animation due to an update to the DOM. Although the approach of selecting elements through css selectors ‘works’ given that I’m placing the animation logic in componentDidMount/useEffect, it is not best practice, less safe, and thus prone to unexpected/unwanted behavior. Regarding React hooks — I completely agree, and understand that I’ve taken a risk in investing time into React hooks. I just couldn’t help myself. XP. Lastly, I would certainly love to see your implementation with React hooks (React in general), but if you have to go out of your way for this, no worries -- if anything I can try to whip up something myself and you can have fun demolishing it. I'll have a little bit of time tonight, and more so over the weekend. But when I do come up with something I’ll be sure to PM you. Thanks again!! @GreenSock @Rodrigo

I think that qualifies as a "real" answer, haha. Definitely helps. In case @Rodrigo or another React vet has a chance to assist, allow me to briefly set some small context here. In a nutshell, I'm trying to find the most efficient way of utilizing gsap within React 16.7 -- more specifically, using gsap with the newly introduced hooks such as (useEffect hook), and without the use of classes. In the mean time, when i get a chance this evening I will continue tinkering and try to incorporate refs to ensure the best chance of expected behavior.

Hi Team, Within the virtual DOM environment (Vue, React, etc), what's the difference between targeting/tweening an element using a ref vs selecting via css selector string (performance, known quirks/bugs)? I've been targeting/animating virtual DOM elements using css selectors, but just came across the "Getting Started: React and GSAP Animations" and see that using refs is advised. Perhaps I'm veering too far away from a GSAP specific question at this point, and if that's the case, understanding the difference between targeting with css selectors vs targeting the node/element directly would be certainly helpful. Thanks in advance!

Sorry about the limited info, I've got it to work though thanks to you guys! In my case, it was Nuxt (SSR) related. if(process.browser) { CSSRulePlugin = require("gsap/CSSRulePlugin") } Thanks again!!