布里吉斯
GSAP 宣布所有插件都可 100% 免费使用
简单提一下我对 GSAP 和 Framer Motion 的看法吧
两个框架我都有在使用，之前我更倾向于使用 GSAP，后来因为工作上的一些需求也接触了一下 Framer Motion。两个都是很好的前端动画框架，但我觉得两者目前暂时还不能一个替代另一个。
首先说 GSAP。GSAP 是一个相当老牌的动画框架，我使用它最大的理由就是它提供一个和传统 Flash 和视频剪辑等场景下十分类似，且直觉上十分容易理解的 API，即基于时间轴的动画 API。通过 GSAP 的时间轴接口，我可以很容易地复合多种复杂动画的时序和场景。我觉得如果是传统动画师转码上手 k 动画的话也会更喜欢使用 GSAP。
另一个是 Framer Motion，它的最大优势在于体积小，非常小，好像只有几十 kb 的体积。它使用的 API 也是比较新的 Web Animation API，性能（据说）要比 GSAP 使用的纯 CSS 要好上不少。同时，它提供的 API 也是状态式的，即开发者只需要确定组件会处于什么状态、在这些状态下是什么样式，再设定一些渐变需求等等，然后根据需要转换状态就可以完成十分流畅的动画绘制了。
我曾经尝试过「强行」使用 Framer Motion 制作一个滚动条触发的动画，不是说不可以，但有个很严重的问题是，基于状态的 API 让我很难调和拥有一大堆动画元素的炫酷交互网页。具体来说，我需要精确地按百分比为每个组件绑定滚动位置触发；一旦我需要在这中间调整一个值，我有可能需要同时调整其他十万个组件的值。如果你使用的是 GSAP，那么通过时间轴 API 就可以轻松修改其中一个元素的值，GSAP 会自动对 context 进行调整。
额外暴论一句，被人吐槽过很多次的 useGSAP 这个东西，我觉得这玩意纯就是 React 的锅——React 的副作用系统是一个十分垃圾的设计，实际上很多程序 bugs 都是因为没有妥善处理副作用造成的——而这些 bugs 很多本来可以通过传统的生命周期函数和监听函数就能解决。
两个框架我都有在使用，之前我更倾向于使用 GSAP，后来因为工作上的一些需求也接触了一下 Framer Motion。两个都是很好的前端动画框架，但我觉得两者目前暂时还不能一个替代另一个。
首先说 GSAP。GSAP 是一个相当老牌的动画框架，我使用它最大的理由就是它提供一个和传统 Flash 和视频剪辑等场景下十分类似，且直觉上十分容易理解的 API，即基于时间轴的动画 API。通过 GSAP 的时间轴接口，我可以很容易地复合多种复杂动画的时序和场景。我觉得如果是传统动画师转码上手 k 动画的话也会更喜欢使用 GSAP。
另一个是 Framer Motion，它的最大优势在于体积小，非常小，好像只有几十 kb 的体积。它使用的 API 也是比较新的 Web Animation API，性能（据说）要比 GSAP 使用的纯 CSS 要好上不少。同时，它提供的 API 也是状态式的，即开发者只需要确定组件会处于什么状态、在这些状态下是什么样式，再设定一些渐变需求等等，然后根据需要转换状态就可以完成十分流畅的动画绘制了。
我曾经尝试过「强行」使用 Framer Motion 制作一个滚动条触发的动画，不是说不可以，但有个很严重的问题是，基于状态的 API 让我很难调和拥有一大堆动画元素的炫酷交互网页。具体来说，我需要精确地按百分比为每个组件绑定滚动位置触发；一旦我需要在这中间调整一个值，我有可能需要同时调整其他十万个组件的值。如果你使用的是 GSAP，那么通过时间轴 API 就可以轻松修改其中一个元素的值，GSAP 会自动对 context 进行调整。
额外暴论一句，被人吐槽过很多次的 useGSAP 这个东西，我觉得这玩意纯就是 React 的锅——React 的副作用系统是一个十分垃圾的设计，实际上很多程序 bugs 都是因为没有妥善处理副作用造成的——而这些 bugs 很多本来可以通过传统的生命周期函数和监听函数就能解决。
布里吉斯
https://fabulous.systems/posts/2025/05/anubis-saved-our-websites-from-a-ddos-attack/
理论上我是不是可以在 Telegram Watchdog 上使用同样的逻辑