I don’t entirely agree with the original comment too but hydration has always been an issue when TTI is discussed.

Aside from the inefficient rendering of SSR due to data aggregating data, another inefficiency here is the need to re-render them again client side all that same JavaScript and json server side.

React tries to solve this issue with its concurrent mode, and streaming ssr, and server components.

I argue hydration is near to the core problem that many of today’s popular tools like graphql relay and react’s concurrent mode are trying to solve. Or Remix, Marko, Nextjs’s layout RFC. Each tool solves the problem slightly differently. Some try to make sure all data are loaded in parallel as much as possible so that hydration doesn’t cause a waterfall of requests. Others lazy load islands of JavaScript.