5 ms·

Why would react fail for higher traffic pages? If it's a traditional React SPA, you can use a versioned bundle with immutable caching and each user only has to

Why would react fail for higher traffic pages? If it's a traditional React SPA, you can use a versioned bundle with immutable caching and each user only has to download your bundle when you release an update or they use a new browser. You will need to think about how you handle spikes in traffic when you do a release, but even then users won't all load your page immediately after you bump the version. Most of the time (existing user using the same browser, no update) there will be precisely zero traffic to your servers to load the React app except for the initial HTML skeleton. For an app using SSR it's more complicated and I'll admit I don't know how that works at very high load

xutopia 3mo ago
I had landing pages using React on a 1.6M/m budget. The loading times on cell phones in mainland USA meant we had people cancelling the loading of pages. When we converted to straight up cached HTML we saw a huge increase in full page loads. People weren't cancelling the page load and surfing back anymore. You cannot argue that React is extremely heavy and also adds a lot of time between first render. Test a normal HTMX page in Lighthouse and then convert it to React and you'll see how drastic things are. People use React today out of habit rather than because it's the best tool for the job.
- asdfsa32 3mo ago
  This just shows that despite the 1.6M/m budget, you did not have people who could do react correctly. React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015. But while first render is of course important, now everything else is more expensive with htmx because you have to generate HTML on the server, on top of your usual fetch pipeline. Yes, for small traffic it makes little difference, but once you have >10k/s requests, things start to cost.
  - xutopia 3mo ago
    Yes but why bother with React, Hydrating pages at all if you can do something simpler? What advantages does React provide here? HTMX tools are simpler while providing straightforward thinking around html fragment caching, whole page caching. React just gives a runaround way of doing everything. I'll remind you React was built so that people could continue watching a streamed video while they navigated on a page. Most pages aren't streaming anything.
    - asdfsa32 3mo ago
      Because "simple" is transient at best and a lie at worst. But for more details, see the sibling comment: https://news.ycombinator.com/item?id=49069477 https://news.ycombinator.com/item?id=49069477
      - yawaramin 3mo ago
        Most webapps out there will never need the level of complexity of SPA frameworks. They will work completely fine for the foreseeable future with something like htmx. The GitHub notifications update bug is more of an eventual consistency issue than a ‘forgetting to update the UI’ issue.
        asdfsa32 3mo ago
        Do you like programming in Blub? Because you're telling me that Static Pages are not good enough but React is too much, only Blub is the one true ideal.
        yawaramin 3mo ago
        One man’s React is another man’s Blub.
        asdfsa32 2mo ago
        Obviously you missed the entire point of the conversation if you think it is "React good". It is about a paradigm, one that is grounded in mathematical soundness, of course, that doesn't mean the implementations out there are perfect and flawless, but that is not the point.
- shooly 3mo ago
  > loading times What does React have to do with loading times of a page? React does not contribute to that at all other than having to download the JS runtime, which with Preact is 3KB. > You cannot argue that React is extremely heavy and also adds a lot of time between first render Yes you can! In no world would React itself add enough render time to make people navigate back, even if running on a computer from the 90s!
  - Skinney 3mo ago
    React itself, or Preact for that matter, is just the baseline. You still need the application itself, which in every application I’ve worked on is quite a bit bigger than the framework itself. So you need to download the app, maybe have that app perform some fetch requests, then have the app generate html to show to the user. This is going to be slower than just retriving the resulting html directly. If you’re in a place with unreliable or plain out bad signal, the difference will be quite noticeable.
    - shooly 3mo ago
      > every application I’ve worked on is quite a bit bigger than the framework itself That's why most client-side routing libraries support lazy loading. You don't have to load the entire application at once, only the parts you need. > So you need to download the app, maybe have that app perform some fetch requests That's... completely unrelated to React, though? Parent comment claimed that React is slow and HTMX fast - does HTMX make fetches magically faster or what?
      - Skinney 2mo ago
        > That's why most client-side routing libraries support lazy loading. Trading off total size with more network requests. > does HTMX make fetches magically faster or what? With backend rendering (htmx) you'd do all of that on the initial render, which would be faster than first fetching the app, then fetching the data, as you'd typically do in a single page app.
- ifwinterco 3mo ago
  Yes it’s true that for a landing page (relatively simple site, most users are unique) React is not the natural choice. It can probably be made to work well if written by people who know what they’re doing using SSR, but it’s not what React was originally designed for

xutopia 3mo ago

I had landing pages using React on a 1.6M/m budget. The loading times on cell phones in mainland USA meant we had people cancelling the loading of pages. When we converted to straight up cached HTML we saw a huge increase in full page loads. People weren't cancelling the page load and surfing back anymore. You cannot argue that React is extremely heavy and also adds a lot of time between first render. Test a normal HTMX page in Lighthouse and then convert it to React and you'll see how drastic things are. People use React today out of habit rather than because it's the best tool for the job.

asdfsa32 3mo ago
This just shows that despite the 1.6M/m budget, you did not have people who could do react correctly. React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015. But while first render is of course important, now everything else is more expensive with htmx because you have to generate HTML on the server, on top of your usual fetch pipeline. Yes, for small traffic it makes little difference, but once you have >10k/s requests, things start to cost.
- xutopia 3mo ago
  Yes but why bother with React, Hydrating pages at all if you can do something simpler? What advantages does React provide here? HTMX tools are simpler while providing straightforward thinking around html fragment caching, whole page caching. React just gives a runaround way of doing everything. I'll remind you React was built so that people could continue watching a streamed video while they navigated on a page. Most pages aren't streaming anything.
  - asdfsa32 3mo ago
    Because "simple" is transient at best and a lie at worst. But for more details, see the sibling comment: https://news.ycombinator.com/item?id=49069477 https://news.ycombinator.com/item?id=49069477
    - yawaramin 3mo ago
      Most webapps out there will never need the level of complexity of SPA frameworks. They will work completely fine for the foreseeable future with something like htmx. The GitHub notifications update bug is more of an eventual consistency issue than a ‘forgetting to update the UI’ issue.
      - asdfsa32 3mo ago
        Do you like programming in Blub? Because you're telling me that Static Pages are not good enough but React is too much, only Blub is the one true ideal.
        yawaramin 3mo ago
        One man’s React is another man’s Blub.
        asdfsa32 2mo ago
        Obviously you missed the entire point of the conversation if you think it is "React good". It is about a paradigm, one that is grounded in mathematical soundness, of course, that doesn't mean the implementations out there are perfect and flawless, but that is not the point.
shooly 3mo ago
> loading times What does React have to do with loading times of a page? React does not contribute to that at all other than having to download the JS runtime, which with Preact is 3KB. > You cannot argue that React is extremely heavy and also adds a lot of time between first render Yes you can! In no world would React itself add enough render time to make people navigate back, even if running on a computer from the 90s!
- Skinney 3mo ago
  React itself, or Preact for that matter, is just the baseline. You still need the application itself, which in every application I’ve worked on is quite a bit bigger than the framework itself. So you need to download the app, maybe have that app perform some fetch requests, then have the app generate html to show to the user. This is going to be slower than just retriving the resulting html directly. If you’re in a place with unreliable or plain out bad signal, the difference will be quite noticeable.
  - shooly 3mo ago
    > every application I’ve worked on is quite a bit bigger than the framework itself That's why most client-side routing libraries support lazy loading. You don't have to load the entire application at once, only the parts you need. > So you need to download the app, maybe have that app perform some fetch requests That's... completely unrelated to React, though? Parent comment claimed that React is slow and HTMX fast - does HTMX make fetches magically faster or what?
    - Skinney 2mo ago
      > That's why most client-side routing libraries support lazy loading. Trading off total size with more network requests. > does HTMX make fetches magically faster or what? With backend rendering (htmx) you'd do all of that on the initial render, which would be faster than first fetching the app, then fetching the data, as you'd typically do in a single page app.
ifwinterco 3mo ago
Yes it’s true that for a landing page (relatively simple site, most users are unique) React is not the natural choice. It can probably be made to work well if written by people who know what they’re doing using SSR, but it’s not what React was originally designed for