3 ms·

This feels like a good hook to me. Imagine how many executives and team leaders have heard “hydration” as an excuse for why a particular feature is difficult/la

This feels like a good hook to me. Imagine how many executives and team leaders have heard “hydration” as an excuse for why a particular feature is difficult/late/complicated. Bypass hydration, problems go away. It doesn’t matter what the solution is. Plus, giving the usually-non-techy manager a good buzzword (which, let’s be fair, “resumable” is because it is a real programming term that is not well-defined and could somehow play a role in the design of an alternative to hydration) gives… uh, what was I talking about? Plus, giving the manager a good buzzword that they can drop in meetings and catch the others participants unaware makes them feel powerful, and they will mention Qwik as part of that buzzword-droppage. Good salesmanship in my eyes, even if accidental.

llamaLord 4y ago
Is this a joke? I’m a senior PM at one of the “bigger” modern software companies they everyone loves to hate and I’ve literally never heard anyone talk about issues with “hydration”. I’ve heard plenty about inefficient rendering of SSR react components, but literally never heard anyone say “we have an issue because of hydration speed etc”.
- belmont_sup 4y ago
  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.

llamaLord 4y ago

Is this a joke? I’m a senior PM at one of the “bigger” modern software companies they everyone loves to hate and I’ve literally never heard anyone talk about issues with “hydration”. I’ve heard plenty about inefficient rendering of SSR react components, but literally never heard anyone say “we have an issue because of hydration speed etc”.

belmont_sup 4y ago
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.