[mattgperry]

This is a home-grown solution but the version in Framer is extensively tested (though still not perfect ofc).

The version in Framer has stuff like infinitely deep scale correction and shared element transitions so because of the filesize overhead (~10kb) I would only use this for complex stuff that is otherwise prohibitively tough (shared element transitions, layout etc).

However I do want to make the point that this approach should be more robust and simpler to maintain for even simple examples.

If you imagine an iOS-style pill toggle. The "simplest" way to animate this would be to have `translateX(0)` when off and something like `translateX(100px)` when on.

However, if there were no animations, this isn't how you'd write it. You'd probably do something like switch `flex-start` to `flex-end` on the parent.

This is easier to change the design and also maintain between breakpoints. But it can't be animated. Except with these technique, where you'd simply write

<motion.div layout />

And it would be. Much more maintainable.

[som]

Hey thanks for the detailed response. I'm actually all for progressive enhancement, and appreciate the philosophy you're getting at here. I still think, generally speaking, you're either designing for animation or not. With CSS, if something works with a transition it also works without. Once you start meddling with animation states in JS you've taken point on all that otherwise abstracted away state-based logic. What happens when an animation get interrupted, memory use, timing functions, etc. Sure, if you weren't animating a pill-box you might use flex. But if a transform works, why not use that for both animated and inanimate versions? It's certainly not any less correct or legible.