FWIW, I don't think CSS/JS have been much of a problem in terms of breaking. Before Said Achmiz got involved, while gwern.net was still a fairly simple static website, there were pretty much no serious instances of browsers breaking the CSS/JS. Everything ran fine. (Browsers are good at backwards compatibility, as long as you aren't pushing features too hard, as my site was not.)
The big problem was changing expectations and demands. 2010-era Gwern.net would continue to look fine and render fine in a 2025 web browser... as long as you were on a desktop/laptop. If you were laying in bed at night on a smartphone or a tablet, it would be both blinding and unreadable. This wasn't a problem in 2010, when <5% of my traffic was 'mobile' and mobile was very hard to design for even if you wanted to bother, but it is a problem in 2025, when >50% of my traffic is mobile. You can't write off >50% of your traffic.
People now assume that a website will render reasonably on a smartphone, and they increasingly assume there will be a dark-mode. But, even if you aren't using a legacy website based on Flash or tables, and are creating a clean greenfield HTML5 website, these are actually quite complex, demanding features!
You can get 80% of the way with some relatively simple tweaks, but then the rest can be almost arbitrarily difficult. Note that aspects of dark-mode can be subtle - while most websites have settled on the body class approach which avoids the 'blinding flash of white' problem, they continue to screw up dark-mode by treating it as a binary toggle between light vs dark, instead of a three-way toggle between auto vs light vs dark, and most dark-modes settle for fading out images instead of inverting vs fading them with a heuristic like https://invertornot.com/ . (We're still iterating on both features. Most recently, in November 2024: moving the scrollspy header to the bottom of mobile screens instead of top, and taking another dive into color theory in order to have colored link-icons which look good on mobile dark-mode.)
Compared to the burden of features like a mobile mode which is actually good, the regular level of web browser JS/CSS breakage is scarcely noticeable. (It tends to look something like, 'oh no, now in Chrome 123, there's a 1px gap in the dropcaps and the spacing constants have to be adjusted, THANKS GOOGLE'. Annoying, but hardly a major burden.)
Of course, you can quickly strangle yourself with your dependency stack, particularly if you get involved in NPM or you listen to the wrong web gurus, and your website will break overnight, and JS is definitely very fragile and rapidly bitrotting if you define 'JS' as node et al. But if you are being sensible about it and using plain JS (as we do) or well-chosen stable frameworks, of web dev's woes, 'web browsers keep breaking old working CSS/JS' is thankfully far down the list.
The big problems are self-inflicted ecosystem problems like bitrot/bitcreep (https://gwern.net/holy-war#bitrot), and the ever greater complexity expected of websites compared to the old 'preview in the only web browser anyone uses (ie. IE6), make sure it looks fine in the standard monitor dimension 800x600, export from MS Frontpage, ftp up to your shell account, done' days.