Comment by dghlsakjg
9 hours ago
You’re concentrating on quantitative “better” with performance.
Qualitative “better” is frequently what design and front end people are concerned with.
If the solution to date range pickers is two individual pickers tied together with validation logic, most people will call that qualitatively worse from a ux perspective and probably code wise too. If I have to run a bunch of code to get the native element to do standard things, then why not just use a better propietary thing anyway. A date picker taking an extra 1.3ms to render on click is fine if it gets me a bunch of functionality that is not possible with the native version.
In other words, you seem to be defining “better” way too narrowly. Raw performance is one metric amongst many.
I try to avoid words like better, because they don't have an agreed upon definition. The most important thing about performance is the second order effects. For example the fastest test automation can only be as fast as the application it tests.
Another important quality about performance engineering is that it exposes, from deeper investigations, other unrelated technical problems that were otherwise not evident.
Perhaps the most important benefit of performance engineering is that faster software is capable of supporting features and experiments that slower software cannot.
So, its not that performance analysis is necessarily better than something else. Its important for its own sake to improve software quality generally. Of course, the very first step in any of this is measuring things with numbers and comparing those numbers. It is astonishing how many people in software cannot do this and become hostile to defend themselves against it.