[winrid]

Hmm. But if you can impersonate users and see what they see, doesn't that let you see the problem?

Also you're describing database queries and architecture as being a potential issue. Won't APIs be just as slow for the same reasons?

[_heimdall]

Impersonating users only gives you their data, with client rendering you may need their device and network conditions to reproduce a bug.

If the bug is in an API you're really just tracking down an issue in your server rendering. When an issue is in client rendering it's after the API response. It could be anything from a network delay that times out some client logic to a corner case that causes a re-render loop or a specific JS performance difference on a specific device with a specific browser version.

My point is just that you don't own the actual hardware or network when rendering UI on the client. That's not to say you should never use client rendering, it is a good fit for some use cases, but I've always found debugging rendering or performance bugs a huge pain compared to server rendering.

[winrid]

I don't use React - I like just using the DOM - so personally I rarely have client side performance issues (unless I do something really dumb).

[wordofx]

No because you’re not using their computer to reproduce the issue.

[winrid]

I found keeping an old machine or two around is enough. Old laptops are pretty much free.

Generally frontend performance problems are easy to diagnose, easy enough that that's not a consideration when architecting an app in most cases. If your React UI is taking 30% of your dev PC CPU then that's pretty obvious that it's gonna be slow on an average laptop from Walmart with a 5k passmark score.