View Transitions & frameworks

I'm as stoked as the next developer-whose-job-is-only-tangentially-frontend-related about the new View Transitions API, but does it feel like the major response is relief that this is the feature that will obviate the use of JavaScript-heavy frontend frameworks?

The excitement for a web that feels like a native application is well-placed, but surely page transition animations aren't the only reason we're loading dumptrucks of JavaScript on dev blogs across the webosphere?

I like Arc browser: I like the way it works. I like that they've taken tabs away from us: tabs have sort of become a browsing todo list and were probably a mistake to begin with. I like that Arc has a command palette. Who'd have thought all those years ago that Sublime Text had it right all along? I like that Chris Coyier likes it; I like that Robin Rendle likes it. They're both clever, tasteful, discerning people.

But I don't use Arc, though, despite really wanting to make it my main browser, because it's weirdly resource-hungry. I don't get it. It's just Chromium with a command palette. But a single tab playing a YouTube video runs the CPU on my 2015 MacBook Pro at like ~12-15% continually; compare Safari at ~5%. What is Arc doing that's three times more resource-intensive than Safari? I get the sense that no one at ThE bRoWsEr CoMpAnY oF nEw YoRk is even in the same building as an Intel-based Macintosh, let alone a machine from the previous decade. Somehow I don't think that Chris or Robin is either. The gap between the developers of the world and the rest of us broadens.

Safari gets a bad rap in tech circles: it's hamstrung by a weird release cycle tied to macOS, and the monopoly it has on iOS is dragging its name through the mud. But the WebKit team have done a great job at bringing it up to date with web standards over the past couple years, and Jen Simmons in particular is a fantastic advocate, if a bit spicy on Twitter. And especially on slightly older machines like mine, it sips battery and delivers on performance. The Devtools leave a bit to be desired, but for general-purpose browsing, Safari in 2022 is just great.

Few web APIs continue to inspire and amaze me like the nascent View Transitions API. You might have heard it called Shared Element Transitions—it's undergone a bit of a rebrand. I wrote about it a little bit back in May, but it's come a long way since then.

Specifically, it feels like the messaging around View Transitions is pivoting a bit from "animate page transitions" to "animate any transitions". No demo has illustrated this quite as well as Jake Archibald's recent picture-in-picture demo.

In it, a video playing at full-width is transitioned to a picture-in-picture frame in the bottom right-hand corner—but it continues to play throughout the transition! The current API just takes a screenshot and then crossfades to the transitioned element, but this one doesn't.

Transitioning an element that is itself moving feels like a solution to the three-body problem or something. Just fantastic.

(Note you'll need to have the View Transitions flag enabled in chrome://flags for the demo to work.)

View Transitions video demo, Jake Archibald

Ryan Florence posted this tweet the other day, showing real-time updates in Remix, and I thought at first that he'd built some slick websockets stuff into Remix. Alright, that's pretty cool. But it's not websockets.

It's server-sent events.

Websockets are terrific for opening and persisting a connection with a server that you're going to regularly communicate with. You send data up the line, and data comes back down the line to you. It's two-way.

Server-sent events, on the other hand, only send data down to the client (the browser). As the name implies, the server can't receive events—only send them, over an open HTTP connection. But for 80% of use cases, that's fine^[1].

The benefit of this is that you don't have to spool up a whole nother server just to handle the websocket connections. It's all just HTTP, using some clever Content-Type headers. This makes client-side interactivity based on server-side events trivial to implement—another way that traditional "multipage" applications are closing the gap to single-page applications.

Server-sent events, MDN