Pangram verdict · v3.3
We believe that this text is a mix of AI and human-written content.
AI likelihood · overall
MixedArticle text · 764 words · 3 segments analyzed
September 06 2026, Monday Introduction I have been using a Framework 16 as my daily driver ever since its launch. For a long time, I maintained a fragile truce dual-booting Ubuntu and Windows. But in late 2025, I finally pulled the plug, wiped both, and went all-in on CachyOS. Why I switched is probably worth a dedicated blog post, but the short version: I couldn't be happier. Arch / CachyOS has been an absolute breath of fresh air. At work, my daily driver is an M5 MacBook. Lately, macOS has felt increasingly frustrating to live with. How Apple managed to trade away desktop performance in favor of Liquid Glass eye candy is a compromise I will never quite understand. Moving to Linux full-time was surprisingly painless. Most tools I rely on had native Linux builds, and for the few that didn't, solid alternatives stepped in. But there was one painful sacrifice that gave me pause: Apple Keynote (and, more specifically, Magic Move). As someone who speaks at conferences fairly often, presentation tooling isn't vanity - it's narrative scaffolding. For years, I had the luxury of leaning on Keynote to make complex technical concepts look effortless. Walking away from that workflow stung. Magic Move, and Its Shortcomings Yet for all its brilliance, Magic Move has always had a glaring blind spot: animating code snippets. If you've ever tried to transition between two snippets of code in Keynote, you know the horror. Keynote doesn't understand code; it understands glyphs. Watch in dismay as the val from line 1 flies diagonally across the slide to morph into the al of calculate(), while punctuation scrambles like alphabet soup. To make it look professional, you're forced into brittle, unhinged workarounds: splitting lines into invisible bounding boxes, inserting transparent dummy characters, and pixel-nudging tokens by hand just to show a clean three-line refactor. You can make it look magical, but only through sheer brute force. Still, the payoff was real: after almost every conference talk, people would come up not to ask about the architecture, but to ask: "How on earth did you do those cool animations?" Working on the Jetpack Compose team, a UI toolkit that is now fully multiplatform - this comes up constantly. In fact, it's practically an annual tradition: every Google I/O or major conference season, someone on the team inevitably stares at a mangled transition and declares: "What if we just wrote our entire slide deck in Compose so code animates properly?" A few brave souls have actually done it using Compose's Shared Element transitions. I wasn't quite brave enough to abandon WYSIWYG tooling entirely - Keynote is still unmatched for layout, typography, and the parts of your presentation that are not code (even if Apple is slowly gatekeeping more templates behind a subscription).
The Trigger A couple of weeks ago on HN, there was a project called Bento that really caught my attention. This is a fully local, offline and an extensible presentation toolkit. The project is very slick, and definitely worth paying attention to. Bento supports morph already for shapes and mathematical expressions. You can tween position, colors & even gradients. The only feature missing from my perspective was to be able to support morphing code snippets. Research I decided to roll up my sleeves and see what it would take to build this. The first step in a project like this is to survey the existing literature. It turns out there is plenty, given that diffing content is a well-trodden problem. We do this every day as developers whenever we run git diff, for example. The usual suspects are Myers and Patience diff, both of which compute the shortest edit distance between two sequences. There have also been previous attempts at this problem by members of the Kotlin / Android community (such as Re-creating Magic Move with Compose). Intuition: When Math Makes for Bad Animations Having looked at past attempts, my intuition was that Myers diff was solving the wrong problem for this use case.
Myers diff is mathematically elegant: it finds the shortest sequence of edits to turn String A into String B. But the mathematically optimal diff often makes for a visually jarring animation. If a variable is renamed or moved, Myers might choose to delete three characters here, insert two there, and slice an identifier in half because it saves a single edit step. In an animation, human perception matters far more than minimal edit distance. You don't want minimal operations; you want visual continuity. You want tokens to glide smoothly to their new positions or fade away gracefully.