5 ms·

> My servers should do as little as possible. Why? It’s not like they wear and tear?

_448 4y ago
One advantage of pushing the computing on the user-side is that it reduces the load on the server: less requests, less processing and smaller request sizes. Thus it reduces the bill for the developers/companies :)
- brtkdotse 4y ago
  So by spending thousands of dollars on developer time we can save dozens of dollars on server costs? ;)
  - hutzlibu 4y ago
    It is all a question, of how big you want to scale it.
    - brtkdotse 4y ago
      Stack Overflow runs SSR with a half a dozen servers. How much more scale do you need?
      - hutzlibu 4y ago
        A bit more, if the servers also have to handle media.
  - sodapopcan 4y ago
    Eeeeeeexactly
  - mvolfik 4y ago
    I wouldn't say that it increases developer time. From my (sure, limited) experience of building both with Flask (Django-like, Python BE framework) and Svelte, the difference between developer time is negligable, if not in favor of building on the client - the component frameworks bring much more to the table, like scoped CSS, often better editor support for dynamic values in the HTML templates etc.
  - Xevi 4y ago
    The developer time isn't higher than if it was server side rendered. And for some applications, like the ones I'm building, it would be impossible to do the work on the server.
- GordonS 4y ago
  The server load from a server-side rendered page vs an API call that returns JSON is... very minimal. Unless you're building at great scale, it's such a negligible difference that it really shouldn't be part of your decision making process, IMHO.
  - scrollaway 4y ago
    [Edit: I don't want to get into this argument right now]
    - recursivedoubts 4y ago
      the original web architecture has sophisticated client-side caching built into it, all modern browsers support it: https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching the difference between constructing a string of JSON and a string of HTML is a round off error when compared with network connection costs and data store accesses, etc.
    - GordonS 4y ago
      I'm guessing you haven't measured it, as IME it certainly is true. Try it, you might be surprised. Also, SSR'd pages can be cached too.
  - hutzlibu 4y ago
    "The server load from a server-side rendered page vs an API call that returns JSON is... very minimal." That greatly depends how you designed your architecture and if you have just a simple webpage or a sophisticated webapp displaying data in various ways. My main app is designed to work mainly offline, with bursts of data transfer. All the state is local. Sending html from the server would mean in my case, the server would need to know and keep track of all the user states and data.
- snomad 4y ago
  Since all the clients have to do the work, doesn't that result in a net increase in electricity consumption? Since most electricity comes from fossil fuels doesn't that in net hurt our battle against climate change?
  - hutzlibu 4y ago
    Servers are probably a bit more energy efficient than most consumer devices, but in general it does not matter if you calculate it at A or at B. Somewhere it needs to be processed. You were maybe thinking of processing once and then push it to thousands of clients? Those scenarios exists, but are the exception and not the topic here.
    - account42 4y ago
      > Those scenarios exists, but are the exception More like, they are the rule.
- DeathArrow 4y ago
  >One advantage of pushing the computing on the user-side is that it reduces the load on the server: But we don't need complicated frameworks on the server, keeping track of changes in a shadow DOM and updating the real DOM afterwards. The server will likely just use some html templates in which it will replace some variables with strings and numbers. Easy peasy, both for the server and for the developer.

_448 4y ago

One advantage of pushing the computing on the user-side is that it reduces the load on the server: less requests, less processing and smaller request sizes. Thus it reduces the bill for the developers/companies :)

brtkdotse 4y ago
So by spending thousands of dollars on developer time we can save dozens of dollars on server costs? ;)
- hutzlibu 4y ago
  It is all a question, of how big you want to scale it.
  - brtkdotse 4y ago
    Stack Overflow runs SSR with a half a dozen servers. How much more scale do you need?
    - hutzlibu 4y ago
      A bit more, if the servers also have to handle media.
- sodapopcan 4y ago
  Eeeeeeexactly
- mvolfik 4y ago
  I wouldn't say that it increases developer time. From my (sure, limited) experience of building both with Flask (Django-like, Python BE framework) and Svelte, the difference between developer time is negligable, if not in favor of building on the client - the component frameworks bring much more to the table, like scoped CSS, often better editor support for dynamic values in the HTML templates etc.
- Xevi 4y ago
  The developer time isn't higher than if it was server side rendered. And for some applications, like the ones I'm building, it would be impossible to do the work on the server.
GordonS 4y ago
The server load from a server-side rendered page vs an API call that returns JSON is... very minimal. Unless you're building at great scale, it's such a negligible difference that it really shouldn't be part of your decision making process, IMHO.
- scrollaway 4y ago
  [Edit: I don't want to get into this argument right now]
  - recursivedoubts 4y ago
    the original web architecture has sophisticated client-side caching built into it, all modern browsers support it: https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching the difference between constructing a string of JSON and a string of HTML is a round off error when compared with network connection costs and data store accesses, etc.
  - GordonS 4y ago
    I'm guessing you haven't measured it, as IME it certainly is true. Try it, you might be surprised. Also, SSR'd pages can be cached too.
- hutzlibu 4y ago
  "The server load from a server-side rendered page vs an API call that returns JSON is... very minimal." That greatly depends how you designed your architecture and if you have just a simple webpage or a sophisticated webapp displaying data in various ways. My main app is designed to work mainly offline, with bursts of data transfer. All the state is local. Sending html from the server would mean in my case, the server would need to know and keep track of all the user states and data.
snomad 4y ago
Since all the clients have to do the work, doesn't that result in a net increase in electricity consumption? Since most electricity comes from fossil fuels doesn't that in net hurt our battle against climate change?
- hutzlibu 4y ago
  Servers are probably a bit more energy efficient than most consumer devices, but in general it does not matter if you calculate it at A or at B. Somewhere it needs to be processed. You were maybe thinking of processing once and then push it to thousands of clients? Those scenarios exists, but are the exception and not the topic here.
  - account42 4y ago
    > Those scenarios exists, but are the exception More like, they are the rule.
DeathArrow 4y ago
>One advantage of pushing the computing on the user-side is that it reduces the load on the server: But we don't need complicated frameworks on the server, keeping track of changes in a shadow DOM and updating the real DOM afterwards. The server will likely just use some html templates in which it will replace some variables with strings and numbers. Easy peasy, both for the server and for the developer.