I recognise that this is a controversial take, but in my opinion what Google is doing is a variant of “embrace and extend”. Traditionally, this meant proprietary extensions (e.g. VBScript) but I think this a subtle variant with similar consequences.
I recognise that this is a controversial take, but in my opinion what Google is doing is a variant of “embrace and extend”. Traditionally, this meant proprietary extensions (e.g. VBScript) but I think this a subtle variant with similar consequences.
The web platform doesn't need to move so fast.
The ever current adage of distortion field applies here.
Just like Safari not having webgpu was touted as a feature and now that it has support, webgpu suddenly turned into a feature. Apple can do no wrong to some. Whatever they do is a feature. And if they don't do, it's a feature too.
Implying otherwise is itself a bad argument.
It is true that Safari sometimes lagged in ways that are legitimately open to criticism. There are instances where Safari had incomplete or broken feature implementations. But many claims of “broken sites” are really just evidence of lazy developers failing to test beyond Chrome or to implement graceful fallback. Relying on bleeding-edge Chromium features before they've been broadly adopted by browsers is, IMHO, a infatuation with novelty over durability. It's also, IMHO, a callous disregard for the open web platform in favour of The Chrome Platform. Web developers are free to do whatever they like, but it's misleading to blame browsers for the bad choices and/or laziness of some web developers.
As a web developer myself, I appreciate the frustration with Safari's flexbox bugs of a decade ago and viewport bugs more recently. I also remember being endlessly frustrated by Chrome bugs too, like maddening scroll anchoring behaviours, subpixel rounding inconsistencies, and position:fixed bugs which were broken for so long than the bugs became the de-facto standard which other browsers had to implement. All browsers have bugs. To suggest that Safari was uniquely bad is to view history with Chrome-tinted glasses.
Correct. People test Chrome first and often only. That'll never change because people are lazy and you have a humongously long tail of websites with varying levels of giving a shit and no central authority that can enforce any standards. Even if another browser takes other, they'll only test that one.
The solution is formal tests and the wpt.fyi project. It gives a path to perfectly compatible implementations of agreed-upon standards, and a future where *the only* differences between browsers will be deliberate (e.g. WebMIDI). Brilliant.
That's why I wish the gap between Safari TP's wpt.fyi score and Safari stable's score was shorter. Simple!
That hasn't been true for a few years now.
Even now, when a site breaks in Safari, more often than not, it's because that particular site is using a Chrome-only feature that hasn't shipped in Safari or Firefox yet. These developers need to be reminded that progressive enhancement is a thing.
There are web developers who only test their sites on Chrome, which makes no sense, given mobile Safari has around 50% marketshare in the US [1] and about 21% globally [2].
> Just like Safari not having webgpu was touted as a feature and now that it has support, webgpu suddenly turned into a feature.
I must have missed this one, but anyone paying attention would have noticed WebGPU had been available in Safari (behind a flag) long before it became official; it was always on track to becoming a real feature.
[1]: https://gs.statcounter.com/browser-market-share/mobile/unite...
[2]: https://gs.statcounter.com/browser-market-share/mobile/world...
You shouldn't be allowed to use an old device with an updated browser, especially not a browser from a 3rd party, because that doesn't help Apple sell more iPads.