I know that they’ve optimised this as much as they can, but it still seems to catch pretty much everybody by surprise that every single instance of a web component with a shadow DOM needs the site’s CSS reset added to it individually (or just skip it and keep forgetting that things like box-sizing will be inconsistent with your non-shadow-DOM styles). There’s no way to say “here’s my default styles” that will work consistently across the whole page once you start using web components. And then you have the !important fights between the web component and its contents as well.
Even though it’s been standard practice amongst web developers for 15+ years, the people working on the web platform seem to mostly act like CSS resets aren’t a thing.
And don't call me Shirley
See eg the (now removed) HTML imports standard.
Please familiarise yourself with the guidelines for participating here:
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.
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.
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.
Thankfully, this opinion is measurably false just by reviewing source code of any website. What you're referring to, primarily, are categories of elements like form elements like <datalist> and that's fair.
This is why the web community is asked to support improving the platform through submissions to Interop, such as this one for <datalist>