Components: remove Framer Motion

DaniGuardiola commented 1 week ago

This is a tracking issue. There has been some discussion of removing Framer Motion (the use of motion especially), citing a few arguments:

It's chunky: just the motion component is 40.2kb or about x13 production reacts (all gzipped and minified!).
Pure CSS animations are more performant.
CSS is advanced enough to make most animation use-cases simple enough to implement and maintain.
Often, it costs more effort than just implementing the vanilla CSS alternative.

Current situation

Framer Motion is wrapped in the components package (packages/components/src/animation/index.tsx). A few utilities are re-exported from it, including the motion component.

Those wrappers are then used both internally and externally in a few places. This issue tracks those instances as we transition out of them.

Strategy

A good start would be removing all instance of internal usage within the components package.

In a second stage, external uses within Gutenberg could be removed as well.

Then, we should set the component as deprecated and nudge potential consumers (if any) towards either using CSS directly (preferred), using a lightweight alternative like motion.dev, or at least using framer-motion directly, as we don't want to officially support it anymore from the components package.

Finally, the re-exports should be deleted, or if we feel like an intermediate phase is useful, replaced by mock functions that throw errors asking users to migrate before completely deleting a few versions after.

Internal instances

External instances

youknowriad commented 1 week ago

If we are able to achieve the same results, I think that's fine but I think we should probably leave the deprecation as the last step after removing all usage in Gutenberg. We don't want core's codebase to trigger deprecation messages.

DaniGuardiola commented 1 week ago

@youknowriad agreed, updated the strategy in the issue description.

WordPress / gutenberg