Your premise that the browser implementation is faster and better is rarely true. And when it is true, it's only true in a very narrow lane.
Take for instance something like suggestions on form fields: you start typing something and it presents some options from a hardcoded list that matches the prefix. This is natively achieved through the HTML element <datalist>. However, <datalist> implementations on most browsers suck to the point of being unusable.
The drive to roll your own is not so much that "it would be fun to learn this" as much as it's "rolling my own would let me express my vision exactly". What draws a lot of people to software engineering is that it lets you make anything you imagine. This is also what makes a lot of devs turn their nose at no-code and vibe-coding.
If you can't build things exactly how you want them to be, then it's hard/impossible to build something that's truly genius.
> Your premise that the browser implementation is faster and better is rarely true.
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.
I find that developers add a CSS reset without thinking about it as if there is always a need. We never used resets. There was never a need. Typically we would set something according to the design anyway and starting with a reset was like slamming something against one wall only to throw it back to a different wall later.
They were a lot more necessary when each browser threw in fairly random sets of default styling. These days they've converged heavily on the same defaults.
roncesvalles · · focus · HN ↗
Take for instance something like suggestions on form fields: you start typing something and it presents some options from a hardcoded list that matches the prefix. This is natively achieved through the HTML element <datalist>. However, <datalist> implementations on most browsers suck to the point of being unusable.
The drive to roll your own is not so much that "it would be fun to learn this" as much as it's "rolling my own would let me express my vision exactly". What draws a lot of people to software engineering is that it lets you make anything you imagine. This is also what makes a lot of devs turn their nose at no-code and vibe-coding.
If you can't build things exactly how you want them to be, then it's hard/impossible to build something that's truly genius.
JimDabell · · focus · HN ↗
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.
assimpleaspossi · · focus · HN ↗
ceejayoz · · focus · HN ↗