Comment by WuxiFingerHold | Hacker News Reader

Comment by WuxiFingerHold | Hacker News Reader

There are only few use cases, where the new kind of SSR (with hydration) is worth it. An example are e-commerce sites where you want the customer to see all your great products as soon as possible and then some seconds later to be able to interact with your side fluently to buy something. These kind of scenarios paired with low end devices are the only proper use case. And I say consciously "only proper" because SSR comes with downsides as well:

- SSR is always slower than static sites

- SSR is often slower than CSR - especially when using a small and fast framework like Solid, Svelte or Vue3

- When rendering on the edge and using a central API (e.g. for the DB) SSR is always slower when interacting with the site than CSR because of the extra hop from your central API to the edge to the browser instead of from the central API directly to the browser

- SSR is always more complex and therefore more fragile, however this complexity is handled by the frameworks and the cloud providers

- SSR is always more expensive - especially at scale.

- Traditional SSR with html templates will scale your site much better, simply because traditional languages like Go or Java or C# are scaling much better than NodeJS rendering the site via JS

We owe the technology of the "new" SSR and genius stuff like islands many very smart and passionate people.

Overall, this article not balanced at all. It is pointing out only some potential benefits. It simply is a marketing post for their product.

> SSR is always slower than static sites

I don't think this is _always_ true. With SSR you only render the HTML server-side on the first page load. Any interaction after that is just the JSON payload being retrieved and rendered by a JS framework, which is faster than a complete rerender.

Your comparison is valid for first page loads. But usually people visit multiple pages on a website. And then SSR usually wins, though I agree the added complexity is usually not worth it for 100% static websites.

Usually people visit multiple pages? I think this is a 90-10 situation. 90% of the sites I visit, I reach a web page through another website, either a aggregator or a search engine, and I almost never navigate that website. Those could be purely static for all I care.

The remaining 10%, where I stay 90% of the time, could benefit from a mostly static interface with a tiny amount of server-side rendering.

Have a look at Qwik, it’s a new framework from the author of Angular. It does SSR without the need for client-side hydration. It’s fast and immediately interactive.

I’m really hoping it gains some momentum because I’d love to use it in some client projects.

Looks like a shiny new thing syndrome to me tongue-in-cheek ;)

It's claimed to be fast for "initial page load".

Remains to be seen if that's worth it for everything and if it remains as fast on subsequent navigations.

If third party scripts are the bottleneck, that probably has a marginal effect at best.

Partytown looks much more interesting to me.

Author of angular is a real red flag after that whole angularJS -> angular 2.0 "transition". Worked at a company that spent a bunch of money on contractors trying to get a big angularJS app ported, they never fully completed it, and at the point I left it still had both versions running in the same app. What a nightmare.

> It simply is a marketing post for their product.

For something that could be a single point of failure, like Cloudflare workers was according to this post:

https://news.ycombinator.com/item?id=34639212

Edge workers are cool and all but if you don't need them, why add them as an intermediary / source of lock-in?

Thanks, exactly what I was going to say. This article seriously lacks context. Not many websites will benefit from going SSR.

Reply on news.ycombinator.com