Hacker News Reader

Comment by davely | Hacker News Reader

Every single React app has to ability to be nice and performant.

The issue (and this isn’t React’s fault) is that every single web app is so obsessed with measuring analytics and engagement metrics and loading multiple ad containers and and and…

Whether Vite, or Svelte, or Vanilla JS, when you start stuffing a site with all these tracking pixels and other junk, they are all horrible.

There is likely a bit of observer bias going on with your comment, as many popular sites these days run React and they happen to run like crap due to the reasons I listed above.

View on HN

Whether Vite, or Svelte, or Vanilla JS, when you start stuffing a site with all these tracking pixels and other junk, they are all horrible.

They're definitely horrible from a moral standpoint, but if you look at the flamechart of JS activity in your browser you can easily see that they sit idle 99% of the time and only send events to an API as low priority background work when the browser does things. They aren't what makes websites slow.

You don’t think Amazon is tracking tons? And their site blows Walmart, target etc out of the water. Google?

https://infrequently.org/#e-commerce

I’m not sure how that refutes my point. Of course they are.

That probably explains why the Amazon website just took 5 seconds to load on my phone while on a gigabit connection at home.

The point is clear. Amazon is far more performant and does tracking so that’s not to blame.

I don’t know how accurate this is. I just loaded up Walmart and Targets sites and they load very quickly and navigating between pages is snappy as well. What’s your metric for performance?

Are you in a fast and wired connection? The link I posted above has data:

https://infrequently.org/#e-commerce

React is also incredibly behind the rest of the industry in terms of performance and has been for a long time. What you’re saying isn’t wrong but it’s a different problem on top of React.

Yes but in 6 months react will release a compiler to catch it up by a lot. Performance has diminishing returns and at some point, things just need to be fast enough (see vscode) and the industry will continue on as the switching cost is way too high.

True. But if the sites performed well (big if) and feel responsive, look nice, don’t break middle click and other browser functions - well I don’t see the problem, then. I don’t think the “hate” is irrational.

Which is why I think react (and other SPA frameworks) are now pointing beginners to full stack frameworks like nextjs, remix etc where those best practices are baked in. It took the JS frameworks a bit to find their path there but I think they are there now.

What are your thoughts on things like HTMX though, which with a small payload allow lots of SPA-like features and part of the content language itself. The other hatred I have is the need for all of this crap on top of a crappy language.

HTMX has a ceiling on how interactive/complex you can make your site [1]. If you know you will never need to exceed those sure. However I like to use nextjs as it gives me the peace of mind I will always be able to pivot or implement whatever the customer wants.

[1] https://htmx.org/essays/why-gumroad-didnt-choose-htmx/

that's true[1] but there is also the programmer dictum "You Aren't Gonna Need It" (YAGNI)[2]

it very much depends on the type of app you are building, but I think many web applications could at least start with htmx and then, when more complex user interactions present themselves, use an island of interactivity approach that localizes the complexity.

this keeps overall system complexity as low as possible for as long as possible, and you may never need to go beyond htmx, which can lead to a much less complicated codebase [3]

[1] - https://htmx.org/essays/when-to-use-hypermedia/

[2] - https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

[3] - https://htmx.org/essays/a-real-world-react-to-htmx-port/

I think nextjs does lead to a very simple codebase at every step of the interactivity gradient. You can have pure server side rendered HTML all the way up to full blown SPA and everything inbetween with just one tool rather than having...

1. HTMX itself

2. Your backend language Go/Java/whatever

3. Whatever JS framework for your interactivity islands

But yes we are all on the same team here of reducing complexity in the codebase and if HTMX works for you go for it.

It's a big step back

Reply on news.ycombinator.com