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.
The tension is between two kinds of CSS users. The ones who want cascading style sheets, and the ones who want scoped style sheets. And sometimes even people who think they want scope find out they also want the cascade, and just wanted to scope a bit "at the end" (something the cascade can do anyway)
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.
singpolyma3 · · focus · HN ↗
owebmaster · · focus · HN ↗
hdjrudni · · focus · HN ↗