4 ms·
> React’s performance relative to the field is pretty well-documented, so I don’t feel we need to go into it here. But suffice to say: if your goal is to build
by bastawhiz 4y ago
> React’s performance relative to the field is pretty well-documented, so I don’t feel we need to go into it here. But suffice to say: if your goal is to build the most performant thing you can, React isn’t what you’re considering.
React is amazing in that you can build nearly anything in a mediocre way and it'll probably be fast enough. And when there are performance issues, there's a ton of resources and tools to figure out why and how to make it better.
That's not to say React has great performance. Everything in our field has performance tradeoffs. But on the whole, I think it's really disingenuous to say React's performance is bad. Python is orders of magnitude slower than Rust but for any use case where performance is that critical, you weren't fretting about language choice in the first place. If you actually had a use case where you're rendering a massive spreadsheet or lists with tens of thousands of nodes or some other wildly complicated UI, React can do the job if you really wanted it to, but why are you even fighting that battle in the first place?
Most UIs are boring. Dialog boxes. Forms. Tooltips. If your CTO is trying to optimize one of these UIs for sixty frames per second instead of thirty, they're an absolute fool and shouldn't be evaluating front end frameworks.
- neon_electro 4y agoCan you elaborate on the final sentence of your post?
- deleted 4y ago[deleted]
- bastawhiz 4y agoA CTO should be worried about the big picture and product quality. Not an imperceptible performance difference. CTOs should be detached from the implementation details of the code except where it poses long term risk to the business. A text box rendering in 0.2ms versus 0.6ms is a useless distinction for a person in leadership to waste their time on.
- anonymoushn 4y agoHow did we get to a place where it's unreasonable to expect to change some text boxes within 50 million cycles?
- jfengel 4y agoWhen computers started doing a billion cycles per second, you can shift your whole mental organization to prioritize other things. You can waste a ton of the computer's time rather than waste your own debugging something the user won't even notice.
- anonymoushn 4y agowe can waste the users' time you mean?
- jfengel 4y agoMilliseconds at a time, sure.
- ZephyrBlu 4y agoThe real question is, for your application does it matter if some text boxes are rendered in less than 50M cycles or not?
- anonymoushn 4y agoYes, for every application.
- ZephyrBlu 4y agoThat is provably false.
- anonymoushn 4y agoDo you mean "people still use VSCode even though many interactions have unnecessarily high latency" or "people's experience using VSCode would not be improved by the elimination of these latencies?" Can you post the proof you are referring to? Here's some article about this topic: https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-...
- typingcyclist 4y agoGood point. Also probably the performance problem will come from some slow query on the server side rather than some React code on the UI side.