bewegung.

[bəˈveːɡʊŋ - the german word for motion]. This 8KB, 0-dependency library uses the FLIP animation technique, which can smoothly animate layout changes. It makes the browser work less compared to other css and js animation approaches.

Bewegung can even animate currently unanimatable properties like display: none or element addition/removal

github
documentation
caveats

Examples

single

other

Documentation

Installation

install via npm/yarn/pnpm etc

	npm install bewegung

The simple things: play, pause, reverse

	 
import { bewegung } from "bewegung";

const animation = bewegung(yourCustomDomChangeFunction, 400) });

bewegung.play();

bewegung.pause();

bewegung.resume();

bring your own progress: seek

you can precisely controll the animation via seek. This can be use to make the animation based on scroll or a load progress for example.

	 
import { bewegung } from "bewegung";

const animation = bewegung(yourCustomDomChangeFunction, 400) });

yourOnScrollListener((progress)=> {

 if(progress >= 1) animation.seek(progress, true)

animation.seek(progress)

})

there is the option to pass in a second parameter to indicate that the animation is finish and can be clean up

enough of this: cancel, finish

these to behave very similar, both clean up the animation remains. finish will reapply the dom change though

reactivity escape hatch: forceUpdate

Reacting to dom changes is difficult while animating. Most animations dont need this but if your animation is not like other animations, you can create a custom solution for this your self for now.

Caveats

this is not a production ready piece of software and still in early alpha stage. The API might still be subject to change. I am still not sure if this will ever reach anything further because there are currently some bigger issues to tackle (and a myriad of bugs):

counter-scaling:When scaling an element, its children get counter-scaled to look like they remain unchanged. Depending on the scale-amount the size change every frame for the parent and children might not be the same and the animation looks off even if the start and end are correct. Adjusting the childrens easing can fix this, but calculating an inverse easing curve is difficult.
reactivity:We are calculating pixel-perfect start and end points for a given DOM. If there are changes to the DOM, the calculations are wrong again and need to be recalculated. It is hard to detect changes while animating part of it. With the resize- and mutation observer, we can get some of the direct changes but no indirect changes. There is the possibility to use an intersection observer with a precise root margin to see if an element changes position but that can only work if the animations are paused.
Weird browser behaviors:Chromium-based browsers can throw off the calculations in certain situations. If the calculation happen out of the viewport and the animation is happening above it, the calculations are off again. This is likely due to a mechanism to prevent page jumps from lazy loaded elements but hard to predict.