4 ms·

This is only sometimes true. Other times, cutting the server rendering makes things a million times easier because maybe you're not contacting your database, or

This is only sometimes true. Other times, cutting the server rendering makes things a million times easier because maybe you're not contacting your database, or you're offloading large per-user objects to the client instead of keeping them in ram for thousands of uniques per minute, or, or ... Some calculations are less heavy on the client side. It's not building the html itself once you know what you need that is heavy, it's that awful dropdown menu with dozens of nested filters that rely on user-input data which is awful to build serverside, but incredibly easy to build client side.

h0l0cube 5y ago
> because maybe you're not contacting your database Except you will anyway, to do all those API queries you need to fill the page. That involves multiple handshakes back the server, and yet more server-side resources tied up. > or you're offloading large per-user objects to the client This access happens either way, and will be discarded in short order by any cache, even using the most naive LRU policy.
- scrollaway 5y ago
  A lot of assumptions you're making about a hypothetical there.
  - h0l0cube 5y ago
    Not really. If you have to make database queries in order to display the page, there's no way of getting around it. Even if your webserver isn't in a cluster with your API and database, while you might be sharing the load between your servers, it's still server load that needs to be accounted for. And if it is in the same cluster, probably cheaper to make those fetches from your webserver than to have multiple connections, in addition to those database queries you're going to do anyway.
    - h0l0cube 5y ago
      Whoever downvoted me want to clarify where I'm wrong on this?
    - scrollaway 5y ago
      You're still making assumptions. Some stuff is harder to calculate server-side, period. For a very simple example, I'm currently replacing a SSR feature that takes a list of items and renders a "screenshot" of them. The screenshot has to go through PDF rendering, conversion to JPG, it's insanely expensive. I'm replacing it with a client-side generation of an SVG, and in-browser conversion to PNG. It's very clean, very fast, simple to do, cheap for the client, takes less time than it would to even download the original. (Keyword: Currently. This isn't a hypothetical scenario, this is a real-world instance of replacing SSR with CSR)
      - h0l0cube 5y ago
        Firstly, thanks for providing an explicit criticism to the argument. It's more helpful than a dismissal (or an inexplicable downvote), and it's appreciated. As I see it, the subject of the OP, and this broadly this thread, is about the downsides of using SPAs (e.g., React) vs SSR for applications that require server-side persistence. Of course, pre-processing (or display post-processing) client-side makes a lot of sense. Such client-side offloading doesn't require an SPA, and also it can be part of an SSR driven application (as you are doing) using vanilla JS. So the distinction here between SPA and SSR is moot. The cycle of data retrieval -> user transformation -> data persistence to server, is where SPAs vs SSR have actual tradeoffs. And this, I believe, is what zozbot234 was alluding to. As for Hadoop, I don't personally know how that fits into modern web apps.
- habibur 5y ago
  Basically it boils down to storing state per client. Would you rest the bulk part of it on the server, or on the client? In the initial days of the web, it was stored on server. But before that, in desktop application era it was stored on client.
  - h0l0cube 5y ago
    If the state is coming from the server-side database, and has to be persisted there, you'll still need to fetch it, and save it. If there's some transient state that belongs to the web page, vanilla JS is just as capable as a SPA at managing that - and it's just as prone to losing unsaved changes.

h0l0cube 5y ago

> because maybe you're not contacting your database Except you will anyway, to do all those API queries you need to fill the page. That involves multiple handshakes back the server, and yet more server-side resources tied up. > or you're offloading large per-user objects to the client This access happens either way, and will be discarded in short order by any cache, even using the most naive LRU policy.

scrollaway 5y ago
A lot of assumptions you're making about a hypothetical there.
- h0l0cube 5y ago
  Not really. If you have to make database queries in order to display the page, there's no way of getting around it. Even if your webserver isn't in a cluster with your API and database, while you might be sharing the load between your servers, it's still server load that needs to be accounted for. And if it is in the same cluster, probably cheaper to make those fetches from your webserver than to have multiple connections, in addition to those database queries you're going to do anyway.
  - h0l0cube 5y ago
    Whoever downvoted me want to clarify where I'm wrong on this?
  - scrollaway 5y ago
    You're still making assumptions. Some stuff is harder to calculate server-side, period. For a very simple example, I'm currently replacing a SSR feature that takes a list of items and renders a "screenshot" of them. The screenshot has to go through PDF rendering, conversion to JPG, it's insanely expensive. I'm replacing it with a client-side generation of an SVG, and in-browser conversion to PNG. It's very clean, very fast, simple to do, cheap for the client, takes less time than it would to even download the original. (Keyword: Currently. This isn't a hypothetical scenario, this is a real-world instance of replacing SSR with CSR)
    - h0l0cube 5y ago
      Firstly, thanks for providing an explicit criticism to the argument. It's more helpful than a dismissal (or an inexplicable downvote), and it's appreciated. As I see it, the subject of the OP, and this broadly this thread, is about the downsides of using SPAs (e.g., React) vs SSR for applications that require server-side persistence. Of course, pre-processing (or display post-processing) client-side makes a lot of sense. Such client-side offloading doesn't require an SPA, and also it can be part of an SSR driven application (as you are doing) using vanilla JS. So the distinction here between SPA and SSR is moot. The cycle of data retrieval -> user transformation -> data persistence to server, is where SPAs vs SSR have actual tradeoffs. And this, I believe, is what zozbot234 was alluding to. As for Hadoop, I don't personally know how that fits into modern web apps.
habibur 5y ago
Basically it boils down to storing state per client. Would you rest the bulk part of it on the server, or on the client? In the initial days of the web, it was stored on server. But before that, in desktop application era it was stored on client.
- h0l0cube 5y ago
  If the state is coming from the server-side database, and has to be persisted there, you'll still need to fetch it, and save it. If there's some transient state that belongs to the web page, vanilla JS is just as capable as a SPA at managing that - and it's just as prone to losing unsaved changes.