rip kabosu (2005-2024)

Dan Abramov's "React for Two Computers" was a seminal talk. It makes the case for the inevitability of the Server and Client component paradigm. Every time you visit a page, you're witnessing computation distributed over time and space. When a page gets server-rendered, Computer 1️⃣ did some work, sends it to you, the client, and then Computer 2️⃣ can pick up from where 1️⃣ left off and do more work. This is the 'fundamental physics' of rendering. Even if you claim "well, I only have a client-rendered app, your server components make no sense…" Imagine I turned off SSR for the @vercel dashboard. Visitor gets linked to the Usage page and gets this: That 'static shell' of the page would have been built in a 'distant time and space', namely build time and in a server environment (the CI computer). The only distinction is that a static page is Computer 1️⃣ being in 'memoization mode'. For each input, there's a constant and equal output. Whether Computer 1️⃣ gets activated 'on-demand' (SSR upon request), or at 'build time' (static exports or partial pre-rendering), is irrelevant here. The fact is that React has evolved to be able to model this handoff. It's indeed possible you refuse to leverage the power of 1️⃣ altogether, which you're free to ship: a completely blank page that starts up a bunch of `<script>` bundles on 2️⃣. That case, however, is somewhat exotic these days. If a CDN served your page, you'd be going out of your way to not give your customer a fast FCP (first contentful paint)… And you'll really want to ensure that Computer 2️⃣ has data locality, otherwise after the script load it'll have to go back and forth to some other computer over the internet to `fetch` some data, wasting time. I believe this paradigm is so fundamental that it'll outlive React. If tomorrow we switched to Rust SSR + a wasm client runtime for interactivity, you'd want to account for the handoff and distance between the computers involved in the client-server exchange. If React didn't exist, it'd be re-discovered. I really enjoyed this talk and I'll likely watch it again. It's that good, check it out: youtube.com/live/T8TZQ6k4SLE…

Nothing beats linking people to your working code