Hi @mskelton , I understand your concern here. Unfortunately, it's really hard to create an example that could demonstrate visually what usually happens in complicated apps with multiple developers working on them, without actually implementing those apps fully. And also to make the examples as close to the "real" code as possible, without introducing artificially slowed down components. And at the same time making the article educational and easy to understand.
Imagine, for example, that instead of this Countries list, it's a Jira's issues board component, where usually a lot is happening, and you have no idea whether they create components in render or not. And you're a developer tasked with introducing "theming" to it. Usually you wouldn't have neither time, nor resources or knowledge to investigate and fix the underlying problems of the board itself. But at least you can make sure that your code doesn't slow it down.
While I understand you are trying to demonstrate poor performance with a simple app rather than making a giant full blown application, I disagree with how you did it given that three of your main points don't really impact the outcome and it is the last point that truly is the problem. For those who have more complex apps, a more complex solution may be required, but that should include performance tracing and timing to create baselines that can be used to ensure the changes are making a positive impact.
My concern is that devs are going to look at this post and start adding unnecessary memoization everywhere they can in their app when most of the time that isn't needed.
Hi @mskelton , I understand your concern here. Unfortunately, it's really hard to create an example that could demonstrate visually what usually happens in complicated apps with multiple developers working on them, without actually implementing those apps fully. And also to make the examples as close to the "real" code as possible, without introducing artificially slowed down components. And at the same time making the article educational and easy to understand.
Imagine, for example, that instead of this Countries list, it's a Jira's issues board component, where usually a lot is happening, and you have no idea whether they create components in render or not. And you're a developer tasked with introducing "theming" to it. Usually you wouldn't have neither time, nor resources or knowledge to investigate and fix the underlying problems of the board itself. But at least you can make sure that your code doesn't slow it down.
While I understand you are trying to demonstrate poor performance with a simple app rather than making a giant full blown application, I disagree with how you did it given that three of your main points don't really impact the outcome and it is the last point that truly is the problem. For those who have more complex apps, a more complex solution may be required, but that should include performance tracing and timing to create baselines that can be used to ensure the changes are making a positive impact.
My concern is that devs are going to look at this post and start adding unnecessary memoization everywhere they can in their app when most of the time that isn't needed.
I'd give developers more credit than that 🙂