Re:JavaScript hydration is a workaround, not a solution
by boredtofears on Thursday September 01, 2022 @12:53PM
(#32679263)
What is SSR exactly in the context that you're describing?
I thought if you're using server side rendering you'd be serving HTML directly from your application.
Re:JavaScript hydration is a workaround, not a solution
by diceduckmonk on Thursday September 01, 2022 @01:02PM
(#32679459)
The difference is more heuristical than technical.
Render the entire page in one go, rather than have the server render small chunks at a time and have the client patch the DOM. I.e. not having to think about below the fold, adding event handlers to pre-empt and preload. In practice, you’ll need to sprinkle in JavaScript interactivity, but the point is keep this to a bare minimum. See Craigslist or HackerNews.
Re:JavaScript hydration is a workaround, not a solution
by strongpigeon on Thursday September 01, 2022 @01:08PM
(#32679549)
> Having worked on one of the most bloated SPAs at Google [...]
Let me guess. Google Ads?
Having worked on one of the most bloated SPAs at Google and doing an SRE rotation to optimize exactly these metrics, I couldn’t agree more on the hypothesis that this is where complexity, jank and fragility arises.
This is why our startup set out to build the best-in-class frontend for cloud computing and making a bet on SSR. I’m from a JavaScript background and personally think hate for the language is undue. V8 is also a marvel of engineering. We elected Go for our application language. It’s faster for our purposes but with SSR the domain language isn’t as important. We could use Haskell if it was fit for the problem domain. We empathize with how ideas such as “user-perceived latency” came about but SSR is a much simpler model and our philosophy is that “simpler is faster is faster”.