The two answers

Correspondence has to be decided somewhere. There are two somewheres, and picking one decides almost everything else about what you end up building.

Solve it on the device

Ship a solver. When a morph is requested, take the two shapes, work out the pairing, and animate. Roughly what a good one does:

1. Normalise. Convert every command to a cubic, so the two paths are comparable.
2. Resample. Redistribute points evenly along each subpath so both sides have the same count, typically 64 per stroke. Now the lists are the same length.
3. Match subpaths. Score every possible pairing on things like centroid distance and arc length, then pick the cheapest overall assignment.
4. Align. For each pair, find the rotation, scale and translation that best maps one onto the other. This is a Procrustes fit, and it is what stops a stroke turning inside out.
5. Interpolate and spring. Walk the numbers, drive the whole thing with spring physics.

Five nouns, and none of the work they name is visible in the finished animation. So here it is one step at a time, on the pair this book opened with. Every number below is computed in the demo rather than typed into it.

That is real engineering and it works on anything you hand it. The appeal is obvious: you import a library, you pass it two icons, and it animates. No build step, no configuration, nothing to learn.

Write it down

The other option starts from an observation that sounds too simple to matter.

You already know both icons at build time. They are in your repo. A hamburger is not going to become a different shape between now and when a user clicks it.

So why is a phone recomputing a fixed answer, on every page load, forever?

Write the answer down instead. Give every icon in a set the same fixed number of slots, one <path> per slot, and declare that slot 0 of any icon becomes slot 0 of any other. Correspondence stops being a search and becomes a fact about how the icons are drawn.

menu     slot 0: top bar     slot 1: middle bar   slot 2: bottom bar
cross    slot 0: "\"         slot 1: "/"          slot 2: parked

There is no matching step. There is no cost function. There is nothing to get wrong on someone else's device, because there is nothing left to decide.

What each one buys

Once correspondence is fixed ahead of time, every frame of the animation is knowable ahead of time. Which means it can be computed at build and emitted as CSS keyframes, and a menu-to-cross toggle ships zero bytes of JavaScript.

It also means a wrong pairing is fixable. When a solver picks something you dislike, there is nowhere to put the correction: it will re-derive the same answer on every device forever. When correspondence is data in your repo, you edit it and commit.

And slots have identity, so they can be choreographed individually. The middle bar can leave 60 milliseconds before the outer two rotate. A solver has one similarity per subpath and nothing to address.

What each one costs

The solver wins on effort, decisively. Install, pass two icons, done. It also handles pairs you cannot know in advance, which the other approach cannot do at all, ever.

Writing it down costs a build step. That is not a detail to engineer away, it is the shape of the trade: a build-time answer requires a build.

The honest comparison

That last row is the one people underrate, and it is the subject of Part 8. Roughly 5% of arbitrary icon pairs produce a morph worth shipping. Something has to notice the other 95%, and only one of these two approaches has a moment at which to notice.

Which this book follows

The second one, because it is the less documented of the two and because the consequences are more interesting.

That is a choice, not a verdict. If you need to morph a pair your code will not know until it runs, stop reading and go install a runtime solver. It is the right tool and no amount of build-time cleverness gets you there.

Everything from here is about what becomes possible once correspondence is something you write down. Part 4 is how you write it.