I don't think that's true at all. We get only a handful new CSS features every year, and features introduced today are much more carefully defined than the ad-hoc features of yesteryear. Implementing them is pretty straightforward. Certainly not more difficult than any of the million other things you have to do when building an OS from scratch.
The difficulty of building a state-of-the-art browser is almost entirely about performance. Everything else is straightforward by comparison.
> features introduced today are much more carefully defined than the ad-hoc features of yesteryear.
Many of them are just as ad-hoc, even if they are better defined, and meant to cover some holes in previous ad-hoc specifications. For example, the entire `subgrid` spec is patching one specific hole which actually has a proper general definition: "These <children> however are independent of the parent and of each other, meaning that they do not take their track sizing from the parent. " [1]
So instead of solving that general problem, we have a hyper-specific patch for a single feature. Which will definitely clash with something else in the future.
I mean, the entire web components saga is browser developers patching one hole after another that exist only because the original implementation was just so appalling.
> The difficulty of building a state-of-the-art browser is almost entirely about performance.
But that performance is directly affected by the numbe rof specs and features.
What is harder, starting with nothing and building the equivalent of 2020 Chromium from scratch, or taking Chromium from 2020 and extending it with the new features to get it up to date with today's Chromium?
The former is 100x harder than the latter, and the prior statement that new CSS/JS features are a burden to keep up with is patently absurd. Because it's a tiny amount of work relative to the total work required to make a browser. (But still hard in the absolute sense, because browser engines are among the most complicated software projects.)
Posing the problem as making just one change hides the problem. The problem is long term. A constant deluge of externally driven changes inevitably creates a quagmire of technical debt since you have no choice but to implement them regardless whether your chosen architecture is suitable for the change.
> the prior statement that new CSS/JS features are a burden to keep up with is patently absurd.
Chrome ships up to 400 new APIs a year (that is JS, CSS etc.)
Safari and Firefox ship 150 to 200 new APIs a year. [1]
Even Microsoft gave up on trying to keep up with browser development and switched to Chromium.
> Because it's a tiny amount of work relative to the total work required to make a browser.
That is, like, the primary work required. And many of those things often don't even have a solution until someone finally figures them out in a performant manner (like CSS's :has)
The difficulty of building a state-of-the-art browser is almost entirely about performance. Everything else is straightforward by comparison.