3 ms·

No one needs SSRs. - The SEO argument is long dead. - Client devices are sufficiently performant for anything you throw at it. Yes, even the $100 Chinese Andr

No one needs SSRs. - The SEO argument is long dead. - Client devices are sufficiently performant for anything you throw at it. Yes, even the $100 Chinese Android smartphones that taxi drivers in India use. - The last argument I've heard is "I don't want to expose a JSON API to the world", but that's false security because scraping a web page is not difficult.

ec109685 4y ago
It’s slow. Why make a user make multiple round trips to fetch the page’s data versus serving it online? Spinners stink.
- cyral 4y ago
  Any decent SPA is serving the content in the initial request and not showing a spinner after it downloads the JS
- roncesvalles 4y ago
  That's just because the REST API that serves the requests was poorly implemented. Most SPAs on the web don't even bother including spinners.
ovao 4y ago
> Client devices are sufficiently performant for anything you throw at it Possibly true of the devices themselves (although dubious generally), but definitely not true of wireless networks. If you can deliver a rendered page in 10 KB versus a 1 KB doc and 120 KB of framework to render that same page, you win. That’s true regardless of whether it’s a 3G connection or 5G. SPAs can hold a small advantage in the aggregate, so if you expect your users to be bouncing around routes quite often within a session, you might amortize the cost of the view framework and bundles, but that’s probably not the typical case on mobile, particularly in developing regions.
- roncesvalles 4y ago
  120 KB is largely overblown. Especially with gzip, it reduces even further. There aren't many countries left where the time to load 1 KB vs 120 KB on mobile or broadband Internet would be noticeable.
acdha 4y ago
This is engineering, not religion, so an absolute assertion is unlikely to be true. The whole point of SPAs is to run code on the client instead of servers. That tells us that the load time will favor SSR for any site where the code and/or supporting data is much larger than the displayed result. This means that the question of what’s better depends on how much data you’re talking about and whether you do enough dynamic behavior to make up for the unavoidably slower initial load time, and weather doing that dynsmic work locally is a net win relative to doing fewer requests over a higher latency / lower bandwidth network. This is different for every application so there isn’t a global optimum. Hybrid approaches (progressive enhancement, hydration) are also popular for blending the two, as are approaches like CDN edge execution, which again suggests different sweet spots for different types of applications. The correct answer is to measure and adjust. I have seen exactly zero SPAs which delivered the authors’ original expectations for performance so I’d always rely on data. This can also be repeated for reliability: SPAs can be great for reducing server load if you can run a lot of work on the client, but that comes at the cost of giving up control of more of the runtime environment and complicating monitoring and support. The right balance is going to depend on what you’re doing, who your users are, and where you’re running servers. The other big factor to consider is development time. Writing an SPA requires shipping a lot more code to the client and taking on more responsibility to duplicate what browsers have built-in - for example, they usually have significant accessibility challenges which are easy to miss until late in the cycle. That extra code necessitates more work on things like packaging and since you’re running it on other people’s computers deployment is more complicated. Again, different teams will have different sweet spots based on their staffing, needs, and chosen tools.
- rektide 4y ago
  > That tells us that the load time will favor SSR But the runtime behavior will near-certainly far-prefer a thicker client model, where more is retained & locally available. This was obvious & clear in the aughts, as web-apps emerged from purely server-side systems. Having a client that could re-render based on dynamic data was vastly better than trying to find portals of HTML to re-render & send. It seems still likely & obviously true now. But folks sure AF love load time metrics!

ec109685 4y ago

It’s slow. Why make a user make multiple round trips to fetch the page’s data versus serving it online? Spinners stink.

cyral 4y ago
Any decent SPA is serving the content in the initial request and not showing a spinner after it downloads the JS
roncesvalles 4y ago
That's just because the REST API that serves the requests was poorly implemented. Most SPAs on the web don't even bother including spinners.

ovao 4y ago

> Client devices are sufficiently performant for anything you throw at it Possibly true of the devices themselves (although dubious generally), but definitely not true of wireless networks. If you can deliver a rendered page in 10 KB versus a 1 KB doc and 120 KB of framework to render that same page, you win. That’s true regardless of whether it’s a 3G connection or 5G. SPAs can hold a small advantage in the aggregate, so if you expect your users to be bouncing around routes quite often within a session, you might amortize the cost of the view framework and bundles, but that’s probably not the typical case on mobile, particularly in developing regions.

roncesvalles 4y ago
120 KB is largely overblown. Especially with gzip, it reduces even further. There aren't many countries left where the time to load 1 KB vs 120 KB on mobile or broadband Internet would be noticeable.

acdha 4y ago

This is engineering, not religion, so an absolute assertion is unlikely to be true. The whole point of SPAs is to run code on the client instead of servers. That tells us that the load time will favor SSR for any site where the code and/or supporting data is much larger than the displayed result. This means that the question of what’s better depends on how much data you’re talking about and whether you do enough dynamic behavior to make up for the unavoidably slower initial load time, and weather doing that dynsmic work locally is a net win relative to doing fewer requests over a higher latency / lower bandwidth network. This is different for every application so there isn’t a global optimum. Hybrid approaches (progressive enhancement, hydration) are also popular for blending the two, as are approaches like CDN edge execution, which again suggests different sweet spots for different types of applications. The correct answer is to measure and adjust. I have seen exactly zero SPAs which delivered the authors’ original expectations for performance so I’d always rely on data. This can also be repeated for reliability: SPAs can be great for reducing server load if you can run a lot of work on the client, but that comes at the cost of giving up control of more of the runtime environment and complicating monitoring and support. The right balance is going to depend on what you’re doing, who your users are, and where you’re running servers. The other big factor to consider is development time. Writing an SPA requires shipping a lot more code to the client and taking on more responsibility to duplicate what browsers have built-in - for example, they usually have significant accessibility challenges which are easy to miss until late in the cycle. That extra code necessitates more work on things like packaging and since you’re running it on other people’s computers deployment is more complicated. Again, different teams will have different sweet spots based on their staffing, needs, and chosen tools.

rektide 4y ago
> That tells us that the load time will favor SSR But the runtime behavior will near-certainly far-prefer a thicker client model, where more is retained & locally available. This was obvious & clear in the aughts, as web-apps emerged from purely server-side systems. Having a client that could re-render based on dynamic data was vastly better than trying to find portals of HTML to re-render & send. It seems still likely & obviously true now. But folks sure AF love load time metrics!