I noticed your comment was down voted quite a bit, so I up voted it. It is not really performance related, but it does make an excellent technical point.
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.
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.