News for hackers. Stuff that matters.

A comment on Single Page Applications using Rust. Parent comment

Re:Single Page Applications using Rust by ng12 on Thursday August 13, 2020 @02:53PM (#24146862)
It's not that I have a problem with the idea, it's that I've spent most of the last decade building data visualization apps on the web and have never truly hit a wall with respect to JavaScript's performance characteristics. I think of it like this: no user is visually processing data faster than React can render it. If you render 300 elements and then want to render more updates before those first 300 had finished, did you need to render those first 300 at all? A human can't visually process hundreds of elements that quickly. The problem is that you're attempting to render a bunch of data that's not actually what your user is trying to see, not that React can't render it fast enough.

Most "performance" problems on the web are solved by simple techniques like virtualization, pagination, pushing expensive calculations to the server, avoiding round-trip requests, or basic UI/UX improvements. The only time I would care about JavaScript's actual runtime performance if I were doing something crazy like 3d rendering in the browser and that's a completely different set of problems than React or Yew are set up to handle.

[ Parent | on HN ]
Re:Single Page Applications using Rust by brundolf on Thursday August 13, 2020 @03:35PM (#24147466)
The constraints on data visualization are not the same as the constraints on an IDE, which is closer to what we were building. Also, our users could definitely "process" the data faster than it could be rendered, because what they were doing most of the time was skimming through it for points of interest. They were not sitting and deeply considering each data point one at a time; they could glance at a page and know in a moment whether what they were looking for was there, or whether they needed to scroll further, or whether they needed to tweak the query and re-run it or click a link to a different screen. It was muscle-memory for them, and the tiniest hitch was frustrating to the user experience.
[ Parent | on HN ]