7 ms·

I see a big difference between Hadoop and React though: React pushes the costs on the client. This is something that's not often mentionned, but with a traditio

by Zababa 5y ago

I see a big difference between Hadoop and React though: React pushes the costs on the client. This is something that's not often mentionned, but with a traditional SPA, a good part of your code runs on the client, which is server costs you don't have to pay. I don't know if it's something that people do consciously to reduce costs and just never talk about, or if it's an unintended consequence, but it's here. If your React app is too slow/unoptimized, the client will pay the cost, not you. If your Hadoop cluster is too big/not efficient enough/not useful, you're directly paying for it.

zozbot234 5y ago
The "server cost" of traditional SSR is heavily overrated. It can be made small enough to be basically a rounding error compared to everything else your backend is doing. Even more so since retrofitting SSR onto a JS single-page application is quite inefficient, so you end up paying for that load many times over.
- scrollaway 5y ago
  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.
nexuist 5y ago
I think this is a good assumption, but it breaks down when you look at bandwidth costs. A large reason why these apps take so long to load is because of the kb of dependencies and bundles they have to download. That adds up quickly with many visitors, and there's practically no way you would be accruing the same amount of bandwidth costs with a bland PHP or direct HTML response.
- Zababa 5y ago
  You're absolutely right. You can put the files on a CDN at least but I'm not sure if it's enough.
- 8n4vidtmkvmk 5y ago
  You think heavy HTML responses are cheaper than one extra-heavy initial JS request? I'd like to see some analysis on that. I'm assuming if you're building an SPA or any kind of app, many of your visitors and clicks are repeat visitors and won't have to download that bundle... probably once a day, M-Th assuming daily release schedule w/ lets-not-break-it-before-the-weekend policy. I think all that client-side caching would outweigh the cost of the initial bloated bundle.
  - nexuist 5y ago
    > many of your visitors and clicks are repeat visitors I think this isn't a guarantee and depends on what kind of application you're trying to build. A DMV website is (hopefully?) not going to have many users returning every day or even every week or month. If it's not social media or gaming, it's probably not going to have any sort of consistent userbase, so most visitors are not going to benefit from client side caching. > You think heavy HTML responses are cheaper than one extra-heavy initial JS request? If we assume "cheap" means cost-wise here, almost certainly. Consider a search engine like Google. If you are generating HTML server side (ex. PHP), the row count is limited by whatever you assume the user's screen resolution will be. That means a few hundred results returned at most, since no user is going to scroll through thousands of results on the same screen. So you perform a DB query and generate the HTML for a hundred rows or so and return it, job done. Now consider the JS equivalent: the user downloads up to a megabyte of bundled JS. Then, the JS has to perform a fetch call to some API which probably returns the rows in JSON. At last, the client side JS iterates over the JSON and generates some new DOM elements for each row. Job done. In the JS example, the user's browser had to download the bundle and the API response in order to render the rows, while the PHP example only queried the DB in order to render them. You might think, well the PHP way still uses up bandwidth to get results from the database right? Which is technically true, but pricing wise your database is most likely in the same data center as your web server so you're not paying anything for that bandwidth (since it's going over a physical direct connection cable instead of the Internet proper). Whereas the user is 100% not going to be in the same data center as your API server, so you're going to get whacked with bandwidth charges wherever your API is hosted on top of serving the JS bundle. Of course, for the majority of people we're talking about pennies here. It really doesn't matter until you start getting more than 1 request per second, at which point every hour of every day of every month of every year is going to compound your bandwidth pricing problem until you figure out a way to slim down your payloads. Or, just do what most news sites do and keep adding third party advertiser JS until your ad profits outweigh your bandwidth expenses. Lots of options in this brave new frontier! See 1MB club: https://1mb.club/ https://1mb.club/
reaperducer 5y ago
I don't know if it's something that people do consciously to reduce costs and just never talk about, or if it's an unintended consequence, but it's here. It's very deliberate. It's even what is taught in colleges. I've had debates with recent graduates who believe the proper way to build anything from a web site to an app is to offload as much of it as possible on the client. If the client doesn't have the latest gear? Too bad. They're an "edge case" and shouldn't be allowed to be on the internet. Go curl up in a corner and die, you old and poor people. The tech world would be an entirely different world if ethics were part of the required curriculum.
- dntrkv 5y ago
  Nobody teaches that. You don't offload things to the client in order to save money. You offload things when it will improve performance. Most of the processing power and bandwidth will still be incurred by the server, just at a different time in the lifecycle of the app.
  - webmaven 5y ago
    Well... improving performance because otherwise your server is being slowed down by the load from SSR? That's still saving money in disguise.
    - dntrkv 5y ago
      No. That's not it at all. If your page takes 3 seconds to show anything at all, your bounce rate will be stupid high. If your page loads nearly instantaneously with placeholders, and then the content loads in over the span of 4 seconds. Your bounce rate will be significantly better. Even though your page loads slower, it will be perceived as faster resulting in less users navigating away before your page starts rendering. Perceived performance is only one factor but there are many other reasons why you offload things to the client.
      - timw4mail 5y ago
        I've never had the second scenario feel faster.
edoceo 5y ago
How much is that render cost? Would love to see the trade-off comparison. Does it really save any money?
edgyquant 5y ago
In my experience it is definitely talked about. Most clients are pretty powerful these days so if you can save backend compute power by e.g. returning a redis cached table and then sorting the rows on the front end without bogging it down there isn’t a good reason not to.
datagram 5y ago
I think it's mostly a tradeoff for having a more developer-friendly abstraction. If React only offloaded computation and didn't make complex UIs simpler to write, it wouldn't be anywhere near as popular.
cosmotic 5y ago
React optimization problems are more than just CPU; React encourages lots of little requests in such a way that no amount of computing power can tackle. Coupled with other flawed but popular design antipatterns like skeleton screens, performances is abysmal. Not just long page loading times but browser and machine freezing slowdowns. BitBucket and Jira have gotten so much worse since they moved to React. With all my computers resources at its disposal, it takes longer now to load a single jira ticket than it did when it was all handled server side 10 years ago. If you look at the chrome debugger, its no wonder why. React fans can stand back, cross their arms, and explain about how atlassian must be doing it the wrong way, but it seems pretty consistent behavior across many react apps.
- midrus 5y ago
  Proof of this: https://old.reddit.com/ https://old.reddit.com/ vs https://reddit.com/ https://reddit.com/
  - asddubs 5y ago
    also the slow buggy monstrosity that is the new SPA-ified paypal
rakoo 5y ago
> If your React app is too slow/unoptimized, the client will pay the cost, not you For the client the experience is worse and the cost is higher, so it's definitely a worse solution. SPAs really only make sense when you have a mostly offline application, which is just a very tiny bit of websites out there.

by Zababa 5y ago

zozbot234 5y ago

The "server cost" of traditional SSR is heavily overrated. It can be made small enough to be basically a rounding error compared to everything else your backend is doing. Even more so since retrofitting SSR onto a JS single-page application is quite inefficient, so you end up paying for that load many times over.

scrollaway 5y ago
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.

nexuist 5y ago

I think this is a good assumption, but it breaks down when you look at bandwidth costs. A large reason why these apps take so long to load is because of the kb of dependencies and bundles they have to download. That adds up quickly with many visitors, and there's practically no way you would be accruing the same amount of bandwidth costs with a bland PHP or direct HTML response.

Zababa 5y ago
You're absolutely right. You can put the files on a CDN at least but I'm not sure if it's enough.
8n4vidtmkvmk 5y ago
You think heavy HTML responses are cheaper than one extra-heavy initial JS request? I'd like to see some analysis on that. I'm assuming if you're building an SPA or any kind of app, many of your visitors and clicks are repeat visitors and won't have to download that bundle... probably once a day, M-Th assuming daily release schedule w/ lets-not-break-it-before-the-weekend policy. I think all that client-side caching would outweigh the cost of the initial bloated bundle.
- nexuist 5y ago
  > many of your visitors and clicks are repeat visitors I think this isn't a guarantee and depends on what kind of application you're trying to build. A DMV website is (hopefully?) not going to have many users returning every day or even every week or month. If it's not social media or gaming, it's probably not going to have any sort of consistent userbase, so most visitors are not going to benefit from client side caching. > You think heavy HTML responses are cheaper than one extra-heavy initial JS request? If we assume "cheap" means cost-wise here, almost certainly. Consider a search engine like Google. If you are generating HTML server side (ex. PHP), the row count is limited by whatever you assume the user's screen resolution will be. That means a few hundred results returned at most, since no user is going to scroll through thousands of results on the same screen. So you perform a DB query and generate the HTML for a hundred rows or so and return it, job done. Now consider the JS equivalent: the user downloads up to a megabyte of bundled JS. Then, the JS has to perform a fetch call to some API which probably returns the rows in JSON. At last, the client side JS iterates over the JSON and generates some new DOM elements for each row. Job done. In the JS example, the user's browser had to download the bundle and the API response in order to render the rows, while the PHP example only queried the DB in order to render them. You might think, well the PHP way still uses up bandwidth to get results from the database right? Which is technically true, but pricing wise your database is most likely in the same data center as your web server so you're not paying anything for that bandwidth (since it's going over a physical direct connection cable instead of the Internet proper). Whereas the user is 100% not going to be in the same data center as your API server, so you're going to get whacked with bandwidth charges wherever your API is hosted on top of serving the JS bundle. Of course, for the majority of people we're talking about pennies here. It really doesn't matter until you start getting more than 1 request per second, at which point every hour of every day of every month of every year is going to compound your bandwidth pricing problem until you figure out a way to slim down your payloads. Or, just do what most news sites do and keep adding third party advertiser JS until your ad profits outweigh your bandwidth expenses. Lots of options in this brave new frontier! See 1MB club: https://1mb.club/ https://1mb.club/

reaperducer 5y ago

I don't know if it's something that people do consciously to reduce costs and just never talk about, or if it's an unintended consequence, but it's here. It's very deliberate. It's even what is taught in colleges. I've had debates with recent graduates who believe the proper way to build anything from a web site to an app is to offload as much of it as possible on the client. If the client doesn't have the latest gear? Too bad. They're an "edge case" and shouldn't be allowed to be on the internet. Go curl up in a corner and die, you old and poor people. The tech world would be an entirely different world if ethics were part of the required curriculum.

dntrkv 5y ago
Nobody teaches that. You don't offload things to the client in order to save money. You offload things when it will improve performance. Most of the processing power and bandwidth will still be incurred by the server, just at a different time in the lifecycle of the app.
- webmaven 5y ago
  Well... improving performance because otherwise your server is being slowed down by the load from SSR? That's still saving money in disguise.
  - dntrkv 5y ago
    No. That's not it at all. If your page takes 3 seconds to show anything at all, your bounce rate will be stupid high. If your page loads nearly instantaneously with placeholders, and then the content loads in over the span of 4 seconds. Your bounce rate will be significantly better. Even though your page loads slower, it will be perceived as faster resulting in less users navigating away before your page starts rendering. Perceived performance is only one factor but there are many other reasons why you offload things to the client.
    - timw4mail 5y ago
      I've never had the second scenario feel faster.

edoceo 5y ago

How much is that render cost? Would love to see the trade-off comparison. Does it really save any money?

edgyquant 5y ago

In my experience it is definitely talked about. Most clients are pretty powerful these days so if you can save backend compute power by e.g. returning a redis cached table and then sorting the rows on the front end without bogging it down there isn’t a good reason not to.

datagram 5y ago

I think it's mostly a tradeoff for having a more developer-friendly abstraction. If React only offloaded computation and didn't make complex UIs simpler to write, it wouldn't be anywhere near as popular.

cosmotic 5y ago

React optimization problems are more than just CPU; React encourages lots of little requests in such a way that no amount of computing power can tackle. Coupled with other flawed but popular design antipatterns like skeleton screens, performances is abysmal. Not just long page loading times but browser and machine freezing slowdowns. BitBucket and Jira have gotten so much worse since they moved to React. With all my computers resources at its disposal, it takes longer now to load a single jira ticket than it did when it was all handled server side 10 years ago. If you look at the chrome debugger, its no wonder why. React fans can stand back, cross their arms, and explain about how atlassian must be doing it the wrong way, but it seems pretty consistent behavior across many react apps.

midrus 5y ago
Proof of this: https://old.reddit.com/ https://old.reddit.com/ vs https://reddit.com/ https://reddit.com/
- asddubs 5y ago
  also the slow buggy monstrosity that is the new SPA-ified paypal

rakoo 5y ago

> If your React app is too slow/unoptimized, the client will pay the cost, not you For the client the experience is worse and the cost is higher, so it's definitely a worse solution. SPAs really only make sense when you have a mostly offline application, which is just a very tiny bit of websites out there.