"After doing this for more than 20 years I have asked that question hundreds of times and the answer is almost always about aesthetics, about 95%+."
It may be that a lot of it is aesthetics (though aesthetics also matter to usability) but some of it is richer functionality.
For example, a pattern I've been asked to implement multiple times is a requirement like this:
"We should have a 'Country prefix' input for a telephone number on the form. It should be a list, but allow the user to filter. They should be able to search by code (+44, 0044) or by country name (United Kingdom). We want a little flag beside the input".
Now I _can_ do that myself from browser APIs, e.g. using something like a datalist, using emojis for flags. But then I've to handle stuff like Win/Chrome not even supporting the emoji properly. Chrome will autocomplete based on label or value but FF won't. Even though there's a datalist, I can't constraint the input to _only_ select one of those values, so I need to do additional client-side validation on inputs anyway.
Then if a designer said of an 'contact book' look-up (e.g displaying an profile photo of people instead of a flag) I now have to come up with some other custom field anyway, to support that.
I think the browser level APIs and supported tags have come a long way from where they were, but they're still at the level of primitives. The libraries people are reaching for are one level above that.
But we've well established patterns on the web now that there's no reason we couldn't have richer OOTB browser chrome and remove the need for a lot of this stuff getting reimplemented in libraries all the time.
It may be that a lot of it is aesthetics (though aesthetics also matter to usability) but some of it is richer functionality.
For example, a pattern I've been asked to implement multiple times is a requirement like this:
"We should have a 'Country prefix' input for a telephone number on the form. It should be a list, but allow the user to filter. They should be able to search by code (+44, 0044) or by country name (United Kingdom). We want a little flag beside the input".
Now I _can_ do that myself from browser APIs, e.g. using something like a datalist, using emojis for flags. But then I've to handle stuff like Win/Chrome not even supporting the emoji properly. Chrome will autocomplete based on label or value but FF won't. Even though there's a datalist, I can't constraint the input to _only_ select one of those values, so I need to do additional client-side validation on inputs anyway.
Then if a designer said of an 'contact book' look-up (e.g displaying an profile photo of people instead of a flag) I now have to come up with some other custom field anyway, to support that.
I think the browser level APIs and supported tags have come a long way from where they were, but they're still at the level of primitives. The libraries people are reaching for are one level above that.
But we've well established patterns on the web now that there's no reason we couldn't have richer OOTB browser chrome and remove the need for a lot of this stuff getting reimplemented in libraries all the time.