I am simultaneously very excited and very nervous about the View Transitions API.
You may know it by its former name—Shared Element Transitions. The name change is very recent.
I’ve been saying for years that some kind of API like this would be brilliant:
I honestly think if browsers implemented this, 80% of client-rendered Single Page Apps could be done as regular good ol’-fashioned websites.
Miriam Suzanne describes the theory of View Transitions succinctly:
Shared-element transitions are designed to work with standard web navigation across multiple page loads, as well as page transitions in ‘single-page’ apps (often called SPAs).
This all sounds brilliant. But the devil is in the implementation details. Right now, the API only works for single page apps. This is totally understandable. For purely pragmatic reasons, single page apps are a simple use case to solve for. It’s going to take a lot more work to get this API to work for multi-page apps (or as we used to call them, websites).
But if the API only ever works for single page apps (which is the current situation), then it will act as an incentive to make any kind of website into a single page app, regardless of whether it’s actually the appropriate architecture.
That prospect has me very worried indeed.
I’m making my feelings on this known just in case any of the implementators out there are thinking, “Hey, maybe it’s fine that this API only works for single page apps—I’m sure most people would be happy with that.”
If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.
If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.
Update: Jake says:
We’re currently landing code in Chrome for the MPA version.
Very happy to hear that! It’s already in the spec, but it’s good to hear that the implementation isn’t going to lag too much.
Also, read this follow-up.