Comment by ikurei

> Networks are fast.

Well, it depends on what you mean by “fast”: bandwidth or latency? While the bandwidth has improved enormously over the years, latency… not so much. And it never will due to the simple fact that the speed of light is limited.

Most of the slowness seems to come about by treating latency as something that doesn’t matter (because the testing is done on a local, low-latency network) or will improve radically over time because bandwidth did (which it will not).

Unfortunately, React wants to be both a rendering library and also manage state by tying it to the component lifetime, which encourages cascaded fetching - exactly the kind of workload that is sensitive to latency.

> Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.

Isn't the runtime state optimization the only responsibility of React. It's a library. The rest goes for Vite, Deno et al.

Low powered android devices are a thing. Networks outside of Metro US, EU, and parts of Asia, are also a thing.

Check out google maps there’s more to the world than your open office.

It's both. The majority of web developers today suck, plain and simple. They thought they could make a lot of money doing web dev and don't approach engineering as an art form or a science. They just scrape by and do not level up on their own outside of or during work.

I've had to come in and rewrite apps before where the developers had full leeway and still produced an unmaintainable behemoth of third-party components loosely taped together.

Also, React is a nightmare. An absolute minefield with zero cohesive vision, with an ever-changing API and a culture of shaming developers who haven't switched to the new React paradigm-of-the-year. For a framework meant for serious adults, I'd check out mithril. It's small, API-stable and intuitive, and gets right out of your way.

I've seen this happen many times:

Dev: Hey, I added that screen you asked for- take a look and tell me what you think- any layout changes, wording, etc.

PM: Looks great! Okay, the next thing is...

Dev: Hold on! I need to go back and clean up some of the code I put in there to test a few ideas, and there's a loop in there that has some side effects if some if the timing is off.

PM: This looks fine. Let's move on to the next thing..

How can you close the ticket without "taking any time to optimize, lazy load, cache, minimize dependencies..." if that is in the AC/DoD?

Why don't those developers that care put important things the AC/DoD?

That's a good point. I didn't mean to demean React developers: I've been one for years and I can't say I optimized everything I could've.

The blame for not caring enough about performance and UX is on the whole industry. That does include developers, but not just them.

I’ve worked with plenty of developers who will argue that it’s fine on their development environment and their machine on the same network with test data and that it must be $OTHER_TEAM who is causing it. Arguably more of them than ones who really care. The problem is it only takes 2-3 of those people to bring the whole thing crashing down.

Exactly. If it's a common enough occurrence that most React SPA's are slow and bloated, it may not be the framework's fault, but if changing to a simpler framework makes it better, then it's just a semantic argument

We built a document management system as React SPA which is very performant.

Key: when user clicks on something, this causes 0 to 1 HTTP requests.

We didn’t do lazy loading or caching either.

EU has laws that give back control to users.

But for this to be effective, the browser should be cooperating and working on the user’s behalf to limit tracking. (You know, the whole reason why WWW calls it “user agent” — it should be on the user’s side.)

Unfortunately >90% of browsers use an engine made by the greatest beneficiary of user tracking. Hundreds of billions in future profits might be endangered by giving users actual control. The proverbial fox guarding the hen house.

Where do these 1600 trackers even come from? Does every text writer add their own in the CMS? Is it not managed centrally? Or does every web component load their own flavour?

I didn’t even know there were 1600 different distinct trackers around.

The reason we still have 300 scripts is that ad-tech companies want direct control over their tracking rather than relying on an intermediary.

So they make it harder or more limited to integrate with tools like Segment.

> why cant we have ONE scripts to rule them all

Because those tracking scripts are provided by competing advertising platforms and they want to own the data.

Why would React be bigger and slower than it needs to be? It's a very mature project with a professional development team behind it, I'm sure we can trust them to tackle whatever unnecessary bloat they may have. I think we should be able to trust that anything that is in there serves a purpose, and that it serves hundreds of niche edge-cases that someone will eventually run into but are non-obvious until it's widely used.

These kinds of statements are only true if you're willing to sacrifice in other areas such as maintainability, security, stability, compatibility, accessibility, extensibility or something similar.