As someone who has had to build stateful (usually scroll-based) animations, it's really easy to get burned by doing all the work on the main thread and dropping a frame. This new API lowers the...
As someone who has had to build stateful (usually scroll-based) animations, it's really easy to get burned by doing all the work on the main thread and dropping a frame. This new API lowers the barrier to how one would think about building these.
For example, many engineers will bind to the scroll handler for navbar based transitions/animations. That's well and good when it works on your machine, but the scroll event fires A LOT. This can cause too much animation work to get done in the space of the frame resulting in lost frames. Lost frames means a janky animation at best and a tied up main thread at worst (meaning loss of interaction).
I'm going to wait for it to get further in the standards process, before I start using it but I'm excited!
As someone who has had to build stateful (usually scroll-based) animations, it's really easy to get burned by doing all the work on the main thread and dropping a frame. This new API lowers the barrier to how one would think about building these.
For example, many engineers will bind to the scroll handler for navbar based transitions/animations. That's well and good when it works on your machine, but the scroll event fires A LOT. This can cause too much animation work to get done in the space of the frame resulting in lost frames. Lost frames means a janky animation at best and a tied up main thread at worst (meaning loss of interaction).
I'm going to wait for it to get further in the standards process, before I start using it but I'm excited!
Also TIL
document.timeline