In Defense of Going Slow

I remember the browser wars.

Incompatible, poorly designed APIs fragmenting the web. These APIs are still present in browsers because we believe in "don't break the web" and there might still be websites that use attachEvent(), document.all, and innerText.

If one goal of the web is consistency between all browser engines, then Interop is a much better way to do that. Yes, it's slower, but it's also intentional.

Why did it take so long to come up with the command API as a solution? Because it's a hard problem, with lots of requirements (works with no/minimal JavaScript, doesn't bloat the API surface area) and constraints (works across all browsers, is performant). And it required some dependencies before it made sense to implement, like a declarative element.

Same with CSS nesting, or — good heavens — container queries and the ⁨:has()⁩ selector. Devs were asking for these kinds of APIs for years and we only just now got them. But best of all, we got them in every browser.

The command API is so good in part because it went through a slow, meticulous, intentional design process instead of being slap-dash added as ammunition in the browser wars that only one browser can take advantage of until the other browser begrudgingly adopts a quickly designed API.

Same goes for the popover API. And CSS anchor positioning. And the upcoming CSS grid lanes. All designed meticulously in ways that are extensible while not breaking existing APIs or websites.

I much prefer this reality that we're in.