You're not being conspiratorial at all. At some point in the last decade the Chrome organization decided that they would pull their own version of classic IE where between WebExtensions/Chrome Apps (their own conveniently proprietary "web" standards... at least they killed chrome apps) and massive piles of half-assed bespoke APIs that no competitor can afford to implement, they would ensure that Blink was the only "web" capable of running lots of new software.
While it wasn't the first example of this, I think Web Audio set the standard for this pattern - individual Chrome contributors making their best effort to design and implement a cool API, but then the org's scheduling and priorities result in it shipping before it's remotely ready and before other browser vendors have meaningfully contributed to the process. This early ship date combined with Google's market power results in applications building on top of these immature APIs, which means that other vendors have no choice but to implement and ship absolute garbage.
Web Audio is a great example because they kicked that steaming pile out the door in order to enable (Chrome-only, naturally) web ports of things like Angry Birds, even though in practice that API was barely usable for anything and had all sorts of undesirable characteristics that still aren't completely fixed nearly a decade later. At the time Mozilla was working on a design and implementation for an API that was actually good, but Google's unilateral move killed any chance of a good solution being shipped by multiple vendors.
Other Chrome-only APIs have been similar stories, though at least Native Client/Pepper - probably the worst example - failed because the doomed design and implementation made it impossible for it to even hit their own production targets and drove app developers (like Unity) away.
In some cases you can meaningfully argue that other vendors are just dragging their feet - Safari being the main example, where they simply have been years late to ship useful things that both FF and Chrome had - but in practice nobody else has the massive development resources Google has to waste on dead-end trash APIs and nobody wants to pay the cost of implementing something they'll have to throw out a year later with the knowledge that websites won't support their browser anyway.
The meaningful security/privacy concerns Apple and Mozilla use to reject new Google APIs are also a good example, because Google has the resources to just address these security issues via brute force. They can unilaterally deprecate an existing API and break tons of websites (Web Audio, video, etc) or just ship something busted and rapidly rework it to try and paper over the consequences (WebMidi etc being used for fingerprinting...)
In my time working on the nacl (then WebAssembly) team it became clear to me that most of the devs there weren't acting on malicious motives, the overall structure and priorities of Google as a whole just produced bad outcomes. Sadly with their de-facto monopoly there's no pressures to fix that.
I think you’re discounting that everything Chrome does these days is designed to become a web standard, unlike IE which was trying to have browser-only features for lock-in.
Chrome does seem to be somewhat hasty, which can have a similar effect in practice. But it might seem different if you actually want a feature and don’t want to wait years for it?
I don’t think Web Audio is as bad as you say. There is the ScriptProcessorNode which is getting deprecated in favor of audio worklets because having JavaScript processing audio on the foreground thread is a bad idea. But other than that, it seems nice for making simple audio processing graphs, and the infrastructure for putting JavaScript in the background took a while to work out.
Just look at how many revisions the W3 spec has had. It had even more churn that wasn't visible there... IIRC it originally shipped with synchronous audio decoding on the main thread for some reason. Chrome has also shipped multiple p0/p1 level bugs in Web Audio that users had to wait weeks or months for fixes to, like a while back when they introduced a priority inversion while rewriting their whole mixer so audio was just completely broken for a double-digit % of their userbase.
They also treated basic use cases like 'pause a piece of playing audio' as out of scope, which is simply bizarre.
Every web app or port I've ever touched had issues caused by the poor design and quality of the API.
> I think you’re discounting that everything Chrome does these days is designed to become a web standard
Indeed. It's rarely designed to be a web standard. However, Chrome rams that through standards body, calls that a standard and enables it by default in Chrome.
Just look at WebHID. Firefox devs couldn't even understand the spec [1], it was so Chrome-specific. Guess what, it's enabled by default in Chrome [2] and Chrome says that it's a standard now [3]. Most of those non-standards are not even out of the "draft" stage of the standards process, with both Safari and Firefox objecting to many, many, many things in the specs.
The comment in [1] is from January and the spec is dated March, so perhaps they saw an early draft? I only took a quick glance, but it seems fairly readable now. It would be nice to be able to connect game controllers to web pages.
The fact that they tried and failed (if they did fail; maybe they will succeed eventually?) shows that they cared at least a little about standardization, even if it was somewhat half-hearted.
When negotiations fail, it's not a given that one side is entirely at fault.
> The comment in [1] is from January and the spec is dated March, so perhaps they saw an early draft?
The "request for Mozilla's position" was on December 1, 2020.
Chrome enabled it by default in Chrome 89 that was released only 4 months later, on March 3, 2021.
So they "requested Mozilla's position" and still went ahead, implemented it and enabled it by default. But so nice of them to update the spec two weeks after they released it.
> The fact that they tried and failed (if they did fail; maybe they will succeed eventually?) shows that they cared at least a little about standardization
As reality and facts show, they couldn't care less about standardization.
> When negotiations fail, it's not a given that one side is entirely at fault.
Please show me at which point this was a negotiation.
While it wasn't the first example of this, I think Web Audio set the standard for this pattern - individual Chrome contributors making their best effort to design and implement a cool API, but then the org's scheduling and priorities result in it shipping before it's remotely ready and before other browser vendors have meaningfully contributed to the process. This early ship date combined with Google's market power results in applications building on top of these immature APIs, which means that other vendors have no choice but to implement and ship absolute garbage.
Web Audio is a great example because they kicked that steaming pile out the door in order to enable (Chrome-only, naturally) web ports of things like Angry Birds, even though in practice that API was barely usable for anything and had all sorts of undesirable characteristics that still aren't completely fixed nearly a decade later. At the time Mozilla was working on a design and implementation for an API that was actually good, but Google's unilateral move killed any chance of a good solution being shipped by multiple vendors.
Other Chrome-only APIs have been similar stories, though at least Native Client/Pepper - probably the worst example - failed because the doomed design and implementation made it impossible for it to even hit their own production targets and drove app developers (like Unity) away.
In some cases you can meaningfully argue that other vendors are just dragging their feet - Safari being the main example, where they simply have been years late to ship useful things that both FF and Chrome had - but in practice nobody else has the massive development resources Google has to waste on dead-end trash APIs and nobody wants to pay the cost of implementing something they'll have to throw out a year later with the knowledge that websites won't support their browser anyway.
The meaningful security/privacy concerns Apple and Mozilla use to reject new Google APIs are also a good example, because Google has the resources to just address these security issues via brute force. They can unilaterally deprecate an existing API and break tons of websites (Web Audio, video, etc) or just ship something busted and rapidly rework it to try and paper over the consequences (WebMidi etc being used for fingerprinting...)
In my time working on the nacl (then WebAssembly) team it became clear to me that most of the devs there weren't acting on malicious motives, the overall structure and priorities of Google as a whole just produced bad outcomes. Sadly with their de-facto monopoly there's no pressures to fix that.