I think this is completely wrong. The reason why nkt a lot of people use the built in elements is because sooner or later you will hit a limitation that you cannot fix.
If it is a javascript element you can do whatever you want if it doesn'fit.
Take dialog as an example. If you have a server side rendered app and you want to show an open dialog without js. You are out of luck, you can't just render it as open because that opens a dialog that does not correctly work.
Or take a multiselect input. Just unusable as a normal browser element.
Also most elements miss something essential like no search function in an input. So also unusable for big lists.
I could make a list of 100 things that are wrong with native browser elements.
It is just easier to use a js framework/library and have a clean view and state.
> It is just easier to use a js framework/library and have a clean view and state.
To note, it's "easier" if you don't really care outside of your specific and limited case.
Multi select is a perfect example: if you only ever need that component to work in your language on your specific list for the browser you personally use for the screen sizes you care about, it will be pretty easy.
Hell starts when you try to think beyond that: how does the JS component work in responsive for super small screens and super big screens ? do you handle touch and mouse and stuff in-between ? what about CJK ? Right to Left ? do you care if there is any very long entries in the list ? How do you handle previous selections ?
The more you start to care about the details or expand the range of what you're doing, the more you'll be pulling hairs if you try to handle them.
The native components won't be perfect either. Native devs will also be dwelling in that same hell as you, whether or not the native state is better will depend on how much they cared on their side.
sebastiangrill · · focus · HN ↗
Take dialog as an example. If you have a server side rendered app and you want to show an open dialog without js. You are out of luck, you can't just render it as open because that opens a dialog that does not correctly work. Or take a multiselect input. Just unusable as a normal browser element. Also most elements miss something essential like no search function in an input. So also unusable for big lists. I could make a list of 100 things that are wrong with native browser elements. It is just easier to use a js framework/library and have a clean view and state.
makeitdouble · · focus · HN ↗
To note, it's "easier" if you don't really care outside of your specific and limited case.
Multi select is a perfect example: if you only ever need that component to work in your language on your specific list for the browser you personally use for the screen sizes you care about, it will be pretty easy.
Hell starts when you try to think beyond that: how does the JS component work in responsive for super small screens and super big screens ? do you handle touch and mouse and stuff in-between ? what about CJK ? Right to Left ? do you care if there is any very long entries in the list ? How do you handle previous selections ?
The more you start to care about the details or expand the range of what you're doing, the more you'll be pulling hairs if you try to handle them.
The native components won't be perfect either. Native devs will also be dwelling in that same hell as you, whether or not the native state is better will depend on how much they cared on their side.