Showing posts for Browser
-
Dia browser
The Browser Company of New York is back at it. Here is a link to a post titled "Letter to Arc members 2025" with an update on the abandoned Arc browser and and update on the work they've been doing on the new "Dia browser", which just appears to be Chrome but where you’ve set your homepage to chatgpt.com.
(What the hell is an “Arc member” by the way? It’s a browser.)
And here is a link to the Dia browser website, with a (very masturbatory) intro video which makes it seem like it’s just Apple Intelligence, except for instead of the interface being Siri, the interface is the browser search bar.
The video has lots of shots like this where the guy says things like "you can literally dream about some wild new interface for AI and the web" with the focus fading in and out in a totally insufferable way I cannot understate how little faith I have in this project.
Further reading: Here is a link to Tom MacWright with the exact same take, and here is a link to my previous opinions about Arc & why I didn't use it back then, which maybe means that I'm just a Hater.
-
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?
-
Arc browser vs. Safari
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.
No chrome, no tabs, no omnibox—just a keyboard-friendly, power user's browser. 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.
-
View transitions with video
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.
Just look at that! Look at it! 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.)
-
Server-sent events
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-Typeheaders. 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.