Many native web browser capabilities exist because adventurous developers came up with the patterns themselves. There is no way we’d have CSS scroll-driven animations available to us if front end developers hadn’t already established the requirement and pattern. Browser standards, CSS specs etc follow what _we_ hack together and make ubiquitous (sort of like desire paths), not the other way around. That is why we shouldn’t blindly “use the platform”; vendors should adjust to our demands, not the other way around. Of course, if a native element or capability matches exactly your requirements in some scenario, using it would be sensible.
I always try to make HTML and CSS do the main work, while using HTML semantically. JS sprinkled on top where HTML/CSS won't perform the desired function (has gotten less over the years). And obviously server-side code where such a thing is needed.
But if I can get away with a static website that uses just HTML and CSS that is the baseline. And it has served me very well and produced very low (=zero) maintenance results.
wuhhh · · focus · HN ↗
atoav · · focus · HN ↗
But if I can get away with a static website that uses just HTML and CSS that is the baseline. And it has served me very well and produced very low (=zero) maintenance results.