[ninkendo]

Ah yes, the "Vibration API", I really wish Safari had that. And the Web MIDI API, and Web Bluetooth, Web Serial, etc etc.

The vast majority of these are APIs that I explicitly do not want websites to use. Especially things like "touch events", which would serve to allow websites to implement their own dumbass broken scroll implementations (again, this is very intentionally not supported.) It would seem Apple is very intentional in choosing not to support most of these.

There is only one reason these APIs exist at all, and it is that Google has decided to make their browser into an OS (chromeOS) and so they need to invent a web API for everything a normal OS may need to do, so that "everything is a webapp" can be a sorta half-true thing. They exist because Google crammed them through standards committees that they have essentially a majority vote on.

[tucnak]

I have no interest in developing "native" applications and engaging with the two-party app stores. So yes, I really wish Safari had implemented Push API, so that iOS users are able to use the same capabilities that my other users are already enjoying. However, they have no choice; as Apple disallows any browser engines besides Safari WebView, they're only allowed to have capabilities that Apple deems worth implementing themselves. I'm even more interested in WebUSB so that iOS users could use USB security hardware like my other users can, and the best iOS users can do for the time being is Yubikey, and they cannot even do PGP, or PIV without installing walled software. That said, I'm up for whatever, ANYTHING, as long as I don't have to interact with Google/Apple to deliver my code.

[ninkendo]

I mean, I totally get the benefits of having the web have so many API’s that the browser is basically an entire OS.

But the fact that a browser decides not to be an entire OS just because google’s doing it, I don’t think that means they’re the “new IE”. It means it’s a browser and not an entire operating system, and I’m ok with that.