6 ms·

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

by xutopia 2mo 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 2mo 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 2mo 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 2mo 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 2mo 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 2mo 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 2mo ago
        One man’s React is another man’s Blub.
        asdfsa32 1mo 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.
  - robertoandred 2mo ago
    What advantages does HTMX have? You end up with splintered spaghetti code, multiple languages/idioms, and unpredictable state.
    - Skinney 2mo ago
      * spaghetti or not depends on how you structure things, not on the framework/library used. * HTMX doesn’t introduce a new language. It extends HTML with props, which is less than what React is doing. * unpredictable state? You rely on the browser and (partial) page-refreshes.
      - asdfsa32 2mo ago
        HTMX does introduce a new language, in fact it introduces 2 different ones, one is an extension of HTML and second is for the codelets it uses inside the array of attributes it uses as a pragma.
shooly 2mo 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 2mo 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 2mo 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 1mo 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 2mo 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

by xutopia 2mo ago

asdfsa32 2mo 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 2mo 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 2mo 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 2mo 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 2mo 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 2mo ago
        One man’s React is another man’s Blub.
        asdfsa32 1mo 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.
- robertoandred 2mo ago
  What advantages does HTMX have? You end up with splintered spaghetti code, multiple languages/idioms, and unpredictable state.
  - Skinney 2mo ago
    * spaghetti or not depends on how you structure things, not on the framework/library used. * HTMX doesn’t introduce a new language. It extends HTML with props, which is less than what React is doing. * unpredictable state? You rely on the browser and (partial) page-refreshes.
    - asdfsa32 2mo ago
      HTMX does introduce a new language, in fact it introduces 2 different ones, one is an extension of HTML and second is for the codelets it uses inside the array of attributes it uses as a pragma.

shooly 2mo 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 2mo 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 2mo 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 1mo 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 2mo 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