What's up with those Hydration IDs?

A deep-dive livestream transcript exploring why SolidJS generates hydration IDs (data-hk attributes) in its SSR output, using a real-world SSR benchmark as the jumping-off point. The author walks through the benchmark's history, showing how small implementation differences (spread operators in Svelte, dev mode in React, extra style bindings in Solid, the toFixed() call) dramatically shifted results. The core explanation: because SolidJS uses JSX without a virtual DOM, elements can be created without knowing their parent context, so a counter-based hierarchical ID system is needed to correctly match server-rendered DOM nodes to client-side reactive bindings during hydration. Async components compound this by potentially resolving in different orders on server vs. client, requiring hierarchical IDs rather than simple sequential ones. The author concludes that while these IDs penalize Solid in pure SSR throughput benchmarks, SSR render time is rarely the real bottleneck for end users compared to client-side hydration and data-fetching waterfalls.