5 ms·

The issue I have with SSR is that it offloads processing power onto the server. That means I have to pay more as the host instead of relying on user's browser t

The issue I have with SSR is that it offloads processing power onto the server. That means I have to pay more as the host instead of relying on user's browser to handle the compute "for free".

trashburger 4y ago
The problem with this idea is that the user's browser's compute is not "free". Offloading the computing means the users have a worse experience, which will affect your userbase and page rankings.
- ArcaneMoose 4y ago
  That sort of depends. If the compute needs to happen regardless and now you add a layer of shipping data to and from the server, that could add even more latency and make for a worse experience.
- jasonlotito 4y ago
  The argument against this is the cost of a user's bandwidth. If I have all the computation done on the server side, then I have to wait for the round trip every single time just to download the results. In this case, the browser's compute is more free, as the cost to send a remote request is more than likely higher. Like most things, there is no simple right answer, and it depends on what you are doing. But blindly assuming the experience will be worse using CSR is as silly as assuming SSR will always be worse as well.
  - butlerm 4y ago
    It depends on the style of application. For most line of business applications the data on the client side is potentially out of date as soon as it requested, and as a consequence very little can be done on the client side except arrange or rearrange data for display. All requests that make any substantive changes must be sent to a server somewhere anyway and client side data caching is almost useless.
- Havoc 4y ago
  >Offloading the computing means the users have a worse experience Does it though? Loading a webpage barely registers in cpu usage etc on a reasonably modern device
  - kitsunesoba 4y ago
    Depends on the complexity of the page. A lot of sites with heavier JS and SPAs eat a lot of memory which can cause problems for users of the many laptops out there with 4/8GB of RAM, as well as many smartphone users who have 2GB of RAM or less. In the case of the latter visiting a heavy website can be enough to prompt the OS to kill some other app to make memory available, which means in that situation one's site is in direct competition with other things the user may be needing more than the site.
    - Dalewyn 4y ago
      That's a problem with the dingus that wrote all that JavaShit, not a problem with the end user's computer. We have 20+ core consumer-grade CPUs and double- to triple-digit RAM and the internet at-large (read: Web2.0) still runs like it's the 1970s.
  - butlerm 4y ago
    > Does it though? Loading a webpage barely registers in cpu usage etc on a reasonably modern device. CPU usage is not the problem. In most cases the problem is latency including the network latency to issue and return a substantial number of remote API requests across the Internet to get the data necessary to render the page. In many cases unless you make page specific APIs that aggregate all the necessary data into a composite object on the server side this is the number one thing that slows things down. Network turnarounds are expensive but they are a lot less expensive when made inside of a datacenter than from a thousand or more miles away.
    - zeroonetwothree 4y ago
      Aggregating the data requests is pretty easy if you use something like GraphQL + one of the clients (Apollo or Relay). Probably other frameworks can do it too, I'm too lazy to check.
superkuh 4y ago
I'm probably not in your target demographic but when a website pushes computation to me for simple things like displaying text and images I close the tab.
- ehutch79 4y ago
  And congrats on getting fired for refusing to use the companies internal tools. Not all web sites are brochure-ware. Sometime the target demographic is a limited number of internal employees who open the app once and keep it open. Never mind that i don't know how you would display images server side.Your client needs to decode that image and render it to screen at some point
- forgotpwd16 4y ago
  >when a website pushes computation to me for simple things like displaying text and images I close the tab How will you even know without looking at the source or blocking JS across the web? Like, sure, if they've fancy animations across all elements from the moment you open the page should be obvious. But what about something like https://rhodey.org/ https://rhodey.org/? It opens instantaneously in my ancient laptop connected to a terrible internet line. Check source. Only a single empty div in body. Everything is rendered with JS.
  - superkuh 4y ago
    I block JS across the web by default. For some sites I'll learn the miminum set of domains to allow for temporary whitelisting. But most aren't worth the effort.
    - rwalle 4y ago
      Sure, great for you, but most websites and most developers don't care about use cases like this and always use JS to "enhance" the UI and UX, however you interpret it. They (supposedly) need to achieve basic accessibility but then do whatever they can in the UI. I don't think anyone would care about users who "disabling JS by default", at least now.
- 4y ago
wizofaus 4y ago
Surely most of the compute cycles for turning a web page into pixels happen on the client anyway? I'm not convinced the server necessarily has to do massively more work to return HTML over JSON (though it would obviously depend on how the HTML-generation was coded. If you're trying to use the client-style page rendering techniques on the server, issuing API calls over the network and interpreting Javascript code, then you have a point). Edit: my "most" claim is probably too strong on reflection: while there's still a lot of work to do to convert an in-memory DOM into pixels, it's likely to be highly optimized code (some of it handled at the GPU level) that uses minimal compute cycles. And while the V8 engine may be similarly optimised, it still has to interpret and execute arbitrary JS code supplied to it, plus handle all the necessary sandboxing. It'd be interesting to get a breakdown of what compute cycles are used converting a typical SPA into pixels, and of course a comparison with how much time is spend waiting for data to come across the network.
dbbk 4y ago
So just cache it and then have it be processed once every minute or whatever.
mmcnl 4y ago
It's not an issue, it's a trade-off. Do you want your users to experience faster initial page loads? If yes, then the cost might be worthwhile. If not, then not. Especially in ecommerce it's well worth the cost.

The issue I have with SSR is that it offloads processing power onto the server. That means I have to pay more as the host instead of relying on user's browser to handle the compute "for free".

trashburger 4y ago

The problem with this idea is that the user's browser's compute is not "free". Offloading the computing means the users have a worse experience, which will affect your userbase and page rankings.

ArcaneMoose 4y ago
That sort of depends. If the compute needs to happen regardless and now you add a layer of shipping data to and from the server, that could add even more latency and make for a worse experience.
jasonlotito 4y ago
The argument against this is the cost of a user's bandwidth. If I have all the computation done on the server side, then I have to wait for the round trip every single time just to download the results. In this case, the browser's compute is more free, as the cost to send a remote request is more than likely higher. Like most things, there is no simple right answer, and it depends on what you are doing. But blindly assuming the experience will be worse using CSR is as silly as assuming SSR will always be worse as well.
- butlerm 4y ago
  It depends on the style of application. For most line of business applications the data on the client side is potentially out of date as soon as it requested, and as a consequence very little can be done on the client side except arrange or rearrange data for display. All requests that make any substantive changes must be sent to a server somewhere anyway and client side data caching is almost useless.
Havoc 4y ago
>Offloading the computing means the users have a worse experience Does it though? Loading a webpage barely registers in cpu usage etc on a reasonably modern device
- kitsunesoba 4y ago
  Depends on the complexity of the page. A lot of sites with heavier JS and SPAs eat a lot of memory which can cause problems for users of the many laptops out there with 4/8GB of RAM, as well as many smartphone users who have 2GB of RAM or less. In the case of the latter visiting a heavy website can be enough to prompt the OS to kill some other app to make memory available, which means in that situation one's site is in direct competition with other things the user may be needing more than the site.
  - Dalewyn 4y ago
    That's a problem with the dingus that wrote all that JavaShit, not a problem with the end user's computer. We have 20+ core consumer-grade CPUs and double- to triple-digit RAM and the internet at-large (read: Web2.0) still runs like it's the 1970s.
- butlerm 4y ago
  > Does it though? Loading a webpage barely registers in cpu usage etc on a reasonably modern device. CPU usage is not the problem. In most cases the problem is latency including the network latency to issue and return a substantial number of remote API requests across the Internet to get the data necessary to render the page. In many cases unless you make page specific APIs that aggregate all the necessary data into a composite object on the server side this is the number one thing that slows things down. Network turnarounds are expensive but they are a lot less expensive when made inside of a datacenter than from a thousand or more miles away.
  - zeroonetwothree 4y ago
    Aggregating the data requests is pretty easy if you use something like GraphQL + one of the clients (Apollo or Relay). Probably other frameworks can do it too, I'm too lazy to check.

superkuh 4y ago

I'm probably not in your target demographic but when a website pushes computation to me for simple things like displaying text and images I close the tab.

ehutch79 4y ago
And congrats on getting fired for refusing to use the companies internal tools. Not all web sites are brochure-ware. Sometime the target demographic is a limited number of internal employees who open the app once and keep it open. Never mind that i don't know how you would display images server side.Your client needs to decode that image and render it to screen at some point
forgotpwd16 4y ago
>when a website pushes computation to me for simple things like displaying text and images I close the tab How will you even know without looking at the source or blocking JS across the web? Like, sure, if they've fancy animations across all elements from the moment you open the page should be obvious. But what about something like https://rhodey.org/ https://rhodey.org/? It opens instantaneously in my ancient laptop connected to a terrible internet line. Check source. Only a single empty div in body. Everything is rendered with JS.
- superkuh 4y ago
  I block JS across the web by default. For some sites I'll learn the miminum set of domains to allow for temporary whitelisting. But most aren't worth the effort.
  - rwalle 4y ago
    Sure, great for you, but most websites and most developers don't care about use cases like this and always use JS to "enhance" the UI and UX, however you interpret it. They (supposedly) need to achieve basic accessibility but then do whatever they can in the UI. I don't think anyone would care about users who "disabling JS by default", at least now.
4y ago

wizofaus 4y ago

Surely most of the compute cycles for turning a web page into pixels happen on the client anyway? I'm not convinced the server necessarily has to do massively more work to return HTML over JSON (though it would obviously depend on how the HTML-generation was coded. If you're trying to use the client-style page rendering techniques on the server, issuing API calls over the network and interpreting Javascript code, then you have a point). Edit: my "most" claim is probably too strong on reflection: while there's still a lot of work to do to convert an in-memory DOM into pixels, it's likely to be highly optimized code (some of it handled at the GPU level) that uses minimal compute cycles. And while the V8 engine may be similarly optimised, it still has to interpret and execute arbitrary JS code supplied to it, plus handle all the necessary sandboxing. It'd be interesting to get a breakdown of what compute cycles are used converting a typical SPA into pixels, and of course a comparison with how much time is spend waiting for data to come across the network.

dbbk 4y ago

So just cache it and then have it be processed once every minute or whatever.

mmcnl 4y ago

It's not an issue, it's a trade-off. Do you want your users to experience faster initial page loads? If yes, then the cost might be worthwhile. If not, then not. Especially in ecommerce it's well worth the cost.