Hacker News Reader

Comment by ifwinterco | Hacker News Reader

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

View on HN

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.

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.

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.

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

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.

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.

One man’s React is another man’s Blub.

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.

What advantages does HTMX have? You end up with splintered spaghetti code, multiple languages/idioms, and unpredictable state.

* 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.

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.

> 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!

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.

> 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?

> 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.

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

Reply on news.ycombinator.com