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.
This issue remains true even with the JS "wrapper" elements.
The number of times I have senen frontend people pull in some frontend component from a library (say, for fancy select widgets) and then have to spend a bunch of time trying to fight the existing bugs in that... and then struggle to swap it out later on for another library with a distinct set of bugs...
UI is hard, so it's hard to have a general thing fit _your_ specific purposes nicely. This is why I think it's super valuable to wrap things you can't control easily. That way you both document what you _do_ use, can fix issues at a bit of a higher level, and can swap out the internals way more easily.
People fight back on me on this on so many projects (the most recent thing: "the LLM won't know about our special UI component" IT WILL! IT CAN READ THE CODE!), but then hit those moments of regrets and end up wrapping stuff anyways.
Especially annoying coming from people who talk about design systems. A base vocabulary is a real good way of enforcing a design system!
I mean this relatively lightly, I understand the qualms at a high level, and coming up with the right abstraction is a skill. I've just felt the burn too many times and have very little issue coming up with very limited abstractractions and relying on tech debt to get my wrapper components out into the world.
I agree. Still better than the native elements.
The biggest downside is 100kb js elements because they try to handle everything.
I used basecoat and that worked ok, even if some essentials are missing.
Currently I am using my own webcomponents created with rocket (from datastar)
I disagree it’s better than the native elements. At least the native elements work reliably rather than just on whatever version of chrome the custom one happened to be tested on
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.
rtpg · · focus · HN ↗
The number of times I have senen frontend people pull in some frontend component from a library (say, for fancy select widgets) and then have to spend a bunch of time trying to fight the existing bugs in that... and then struggle to swap it out later on for another library with a distinct set of bugs...
UI is hard, so it's hard to have a general thing fit _your_ specific purposes nicely. This is why I think it's super valuable to wrap things you can't control easily. That way you both document what you _do_ use, can fix issues at a bit of a higher level, and can swap out the internals way more easily.
People fight back on me on this on so many projects (the most recent thing: "the LLM won't know about our special UI component" IT WILL! IT CAN READ THE CODE!), but then hit those moments of regrets and end up wrapping stuff anyways.
Especially annoying coming from people who talk about design systems. A base vocabulary is a real good way of enforcing a design system!
I mean this relatively lightly, I understand the qualms at a high level, and coming up with the right abstraction is a skill. I've just felt the burn too many times and have very little issue coming up with very limited abstractractions and relying on tech debt to get my wrapper components out into the world.
sebastiangrill · · focus · HN ↗
maccard · · focus · HN ↗