Your frustration is understandable, but so too is why they never were -- HTML was never intended to be a programming language or component-based.
HTML was originally meant to be page-based. And pretty much everything added to it (CSS, JavaScript) is scoped to the page. (Some data storage like cookies is scoped to the domain.)
So shoehorning a "component" model to what is fundamentally page-based is essentially an impossible task to do elegantly. Either you wall components off in sandboxes and break the entire premise of the page having control ("why can't I modify the style of my component anymore with the page's CSS?!"), or your components are extremely leaky and accidentally stop working because of page-level CSS and JavaScript interfering.
So we have a ton of different component models that use different tradeoffs.
Obviously if HTML/CSS/JavaScript were being built from scratch today as a platform for apps, it would probably be designed extremely differently, very much around contained components. But that's not what it grew out of historically.
The sad thing about HTML is that its original markup was designed for academic texts (h1,h2, p), but now it is unused because every publisher uses PDF for that end
But now? Publishers, even independent self publishers, have overwhelmingly never left PDF as output of choice, as it is superior in terms of typography, consistency and layout. Take any (non-Print Replica; i.e., reflowable) Kindle book that has just a few logical symbols, and you’ll see they soon become sufficiently ugly to be distracting, and in some cases just unclear due to poor typography. I celebrate projects such as MathJax, but what is sad is that 30 years on MathJax should be necessary at all, and here the typography is better but still doesn’t feel completely natural as in PDF documents.
And from a practical, layman’s standpoint, now that we’re all becoming “mobile first”, while it’s natural to complain when a web link points to a PDF file, the resulting app makes the experience more immersive and self-contained, enabling any average user to save that document. Just saving an HTML document with all its linked material using your phone requieres a l337 browser, Evernote, Notion, or wget from a terminal emulator with the right flags... undoubtedly it’s a chore. I agree this is all sad, but by now I don’t see this changing anytime soon.
HTML was originally meant to be page-based. And pretty much everything added to it (CSS, JavaScript) is scoped to the page. (Some data storage like cookies is scoped to the domain.)
So shoehorning a "component" model to what is fundamentally page-based is essentially an impossible task to do elegantly. Either you wall components off in sandboxes and break the entire premise of the page having control ("why can't I modify the style of my component anymore with the page's CSS?!"), or your components are extremely leaky and accidentally stop working because of page-level CSS and JavaScript interfering.
So we have a ton of different component models that use different tradeoffs.
Obviously if HTML/CSS/JavaScript were being built from scratch today as a platform for apps, it would probably be designed extremely differently, very much around contained components. But that's not what it grew out of historically.