People joke about Safari being the new IE6 a lot, but I've never seen as succinct and well-reasoned a take on just how true this is becoming than what Tim has written. Their argument breaks down into multiple sections, but clearly demonstrates that Safari (and the WebKit team) are fundamentally failing the web, through a combination of (what appears to be) stubbornness, protecting existing business interests, and poor development practices (to be clear, Tim only mentions number three on that list, but the others seem fairly likely).

For example, I knew (and have personally been frustrated by) the fact that Safari seems to always be the last to ship new web features, but seeing a full list of fairly basic functionality that is still missing was still informative (especially with some of it having shipped a decade ago in Chromium or Firefox). Ditto seeing a detailed list of web APIs and elements that have shipped in WebKit, but did so years after widespread adoption elsewhere.

One aspect of Tim's article I found interesting was how WebKit's monopoly on iOS was framed as a good thing, effectively forcing devs to actually care about the browser engine. I'm all for diversity in browsers (and browser engines), but I think this is a stretch: Apple are just abusing their competitive edge here and I thoroughly hope that the EU (and many other courts) slap them firmly back into place soon. Still, they have a point that when this does happen, WebKit's own behaviour may end up being its downfall:

There is no point in winning on principles if there are no users left.

On why Safari should be leading innovation, not playing catch up (and how their ridiculous release cycle is hurting their competitiveness):

A far better way to improve APIs would be to ship such features early in Safari, behind flags & origin trials, and gather feedback from as wide an audience of developers and browser implementors as possible before they become stable, so that feedback can help every browser include better APIs.

On why a 6 month minimum release cycle hurts the web and forces people off Safari:

This makes the whole problem so much worse, because even if bugs were quickly recognized and fixed, they're going to be around for at least 6 months, and likely well beyond too

On the localStorage bug that I hadn't realised was still an issue 🤦‍♂️:

As an example: the localStorage bug above seriously breaks a core web API, and was very quickly fixed (within 24 hours! Superb) but today nearly 3 months later that working fix still hasn't been released to users

On why taking a hardline stance against the new web APIs that Chrome is shipping will ultimately leave Safari (and Firefox, they're just as at fault here) in the dust:

That's not to say that every website will use these shiny new APIs - they're mostly isolated to web application use cases. In some ways that's worse though: your average user isn't going to install a new browser to read a news article, but they might if it offers them reliable notifications from their chat app (background push), makes it easier to work with a webapp they use at work every day (native filesystem), or if it's required to set up a new bluetooth gadget (web bluetooth). Once they switch for one thing, it significantly increases the change they switch for everything.

The percentage of users who'll never use Chrome out of principle is vanishingly small compared to the group of users who will switch to the best tool for the job.

On why WebKit, Mozilla, and others should be actively working with the Chromium team to ensure these new Web APIs aren't just what Google wants, but will actually consider aspects like privacy and mobile performance, instead of just refusing to join the discussion (and thereby letting Google win):

Safari and others can't simply ignore serious proposals for popular features that Chrome wants to implement. They need to engage and offer alternatives, or the problem will only get worse.