fwiw, your comment would almost certainly have positive karma if you had left off the final paragraph. Asking for sources is popular here. Grousing about how you're oppressed by the dumb voters on the site is not.
Native date pickers can’t handle range. So then you need two date pickers with validation logic.
That’s just one example of the native implementation lacking common utility. That’s one thing they could mean when they say the native solution is lacking.
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.
fwiw, your comment would almost certainly have positive karma if you had left off the final paragraph. Asking for sources is popular here. Grousing about how you're oppressed by the dumb voters on the site is not.
[flagged]
I saw the final paragraph when your comment was minutes old and wasn’t downvoted. I downvoted it for the final paragraph.
3 replies →
Native date pickers can’t handle range. So then you need two date pickers with validation logic.
That’s just one example of the native implementation lacking common utility. That’s one thing they could mean when they say the native solution is lacking.
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.
1 reply →
You can see how other people’s comments are voted? I can only see my own.
2 replies →
What would you expect a designer to measure when making an aesthetic judgement?
[dead]