3 ms·

Hm, just a few notes: Progressive Web Apps are a Chrome-only thing by now, since Firefox has practically stripped support. (This was a somewhat experimental th

Hm, just a few notes: Progressive Web Apps are a Chrome-only thing by now, since Firefox has practically stripped support. (This was a somewhat experimental thing, anyways, and there are strong arguments, why users should be able to discern installed programs from external websites. You may argue that this makes much sense for Google, but isn't that desirable from an OS point of view.) WebRTC: While it's true that Safari was lagging significantly regarding WebRTC Data, a basic implementation (for media) isn't exactly new. Then, there is actually some leeway in the definition of some standards (e.g., storage) and it's not automatically clear that the way, Chrome does it, is the right one. (By the same argument, you may propose that typed arrays must be slower than normal ones, since this is how it had been in Chrome for several years.) What's rather annoying for developers, on the other hand, is that Safari is following some common trends as propagated by Chrome. E.g., Safari has stripped its comprehensive list view of loaded sources, which had been quite a selling point. Finally, yes, Safari has a much slower release cycle. However, if you care for compatibility and do not assume that everyone is driving the latest release of an evergreen browser, this shouldn't be much of an issue.

no_way 5y ago
Safari regularly breaks features that were stable for years: localstorage and indexedDB the most recent ones. So I am not sure how you can talk about "compatibility".
- masswerk 5y ago
  Hm, Safari has done it its own way right from the beginning. (Meaning, Chrome and Safari had never the same implementation.) Edit: As I recall it, Safari was an early adapter of the standard (even before its release), which comes with its own caveats. And it's actually because of not breaking things that there are these Safari idiosyncrasies. (The alternative would have been some kind of rolling prerelease standard, as it had been with Web Sockets. Which means, the API remains somewhat obscure and fragile, even, when it is eventually frozen, and developers have become accustomed to using some wrapper, anyways.) And it isn't so that Chrome wouldn't do it, as well. E.g., a few years ago, Chrome had a major rewrite of the Web Audio framework. With this, any newly created source node would point to a null buffer and any calls to the `play()` method were triggered immediately, referring to this null buffer (instead of automatically pointing to the processed buffer source, as soon as this becomes available, and postponing the call in the meantime). This meant in effect that you could practically play a sound from its decoding callback only (which is somewhat optional and only seldom used). At this point, the Web Audio API had been around for several years and this was breaking about every use of the Web Audio API, there was (including Chrome's previous implementation). Turned out, the standard wasn't exact on this – and it took Chrome several revisions to fix this issue (in the meantime, you could work around this issue by user-agent sniffing only). The standard was eventually updated to define the specific behavior. (This is probably also why most developers ignore the Web Audio API for the most and use some wrapper instead. Which is much like using jquery to work around IE idiosyncrasies.) Also, what would it have cost Chrome to implement KeyboardEvent.keyIdentifier to provide a somewhat compatible API?
  - jahewson 5y ago
    As a user of Web Audio I can tell you that it’s broken in the latest Safari. As in, we cannot play a simple sound. Our users are not happy about it.
    - masswerk 5y ago
      It requires a user initiated event to unmute the AudioContext first. (This is a fallout of the constant struggle between advertising and browsers, compare the restrictions for auto-play videos. Regarding the latter, if you're not white-listed by Google, you're out of luck on Chrome and your entire site is broken. Safari's restrictions on audible sound are actually transparent in comparison.)
    - mikestew 5y ago
      It's not broken. Maybe your code is broken, I dunno, as I don't have it in front of me. But Web Audio most certainly works "in the latest Safari".
    - marcellus23 5y ago
      I'm running latest Safari and I can definitely play sounds on websites. Is Safari broken, or just your code?
masswerk 5y ago
P.S., my own critique on Safari: the tight tie-in into the OS. Nowadays, as computers are often longer in use as they are in the support/update cycle, it would be really nice to be able to update Safari beyond the OS level. I get it that Safari is basically running the OS web-view framework and that there are serious issues with this (edit: meaning, updating a single framework out of sync with the rest of the OS), but you should be able to update Safari as a stand-alone application, even, if this means that it's practically running in virtualization using it's own framework overlays.
- unilynx 5y ago
  They seem to be working on that. We got Safari 14 some time before the Big Sur release, and I think Safari 13 was faster than the accompanying OS update too ?
  - nvrspyx 5y ago
    I think they're referring to Safari on iOS, not macOS
  - masswerk 5y ago
    This would be great news. As it is, Safari is a great browser, when you get your new Mac, probably the fastest browser, there is (and economical on resources, as well). So there's reason to adopt it as the default browser, but then it eventually falls behind to the point of becoming incompatible with newer sites and users have to shop for a new standard browser. Which isn't the best user experience imaginable.

no_way 5y ago

Safari regularly breaks features that were stable for years: localstorage and indexedDB the most recent ones. So I am not sure how you can talk about "compatibility".

masswerk 5y ago
Hm, Safari has done it its own way right from the beginning. (Meaning, Chrome and Safari had never the same implementation.) Edit: As I recall it, Safari was an early adapter of the standard (even before its release), which comes with its own caveats. And it's actually because of not breaking things that there are these Safari idiosyncrasies. (The alternative would have been some kind of rolling prerelease standard, as it had been with Web Sockets. Which means, the API remains somewhat obscure and fragile, even, when it is eventually frozen, and developers have become accustomed to using some wrapper, anyways.) And it isn't so that Chrome wouldn't do it, as well. E.g., a few years ago, Chrome had a major rewrite of the Web Audio framework. With this, any newly created source node would point to a null buffer and any calls to the `play()` method were triggered immediately, referring to this null buffer (instead of automatically pointing to the processed buffer source, as soon as this becomes available, and postponing the call in the meantime). This meant in effect that you could practically play a sound from its decoding callback only (which is somewhat optional and only seldom used). At this point, the Web Audio API had been around for several years and this was breaking about every use of the Web Audio API, there was (including Chrome's previous implementation). Turned out, the standard wasn't exact on this – and it took Chrome several revisions to fix this issue (in the meantime, you could work around this issue by user-agent sniffing only). The standard was eventually updated to define the specific behavior. (This is probably also why most developers ignore the Web Audio API for the most and use some wrapper instead. Which is much like using jquery to work around IE idiosyncrasies.) Also, what would it have cost Chrome to implement KeyboardEvent.keyIdentifier to provide a somewhat compatible API?
- jahewson 5y ago
  As a user of Web Audio I can tell you that it’s broken in the latest Safari. As in, we cannot play a simple sound. Our users are not happy about it.
  - masswerk 5y ago
    It requires a user initiated event to unmute the AudioContext first. (This is a fallout of the constant struggle between advertising and browsers, compare the restrictions for auto-play videos. Regarding the latter, if you're not white-listed by Google, you're out of luck on Chrome and your entire site is broken. Safari's restrictions on audible sound are actually transparent in comparison.)
  - mikestew 5y ago
    It's not broken. Maybe your code is broken, I dunno, as I don't have it in front of me. But Web Audio most certainly works "in the latest Safari".
  - marcellus23 5y ago
    I'm running latest Safari and I can definitely play sounds on websites. Is Safari broken, or just your code?

masswerk 5y ago

P.S., my own critique on Safari: the tight tie-in into the OS. Nowadays, as computers are often longer in use as they are in the support/update cycle, it would be really nice to be able to update Safari beyond the OS level. I get it that Safari is basically running the OS web-view framework and that there are serious issues with this (edit: meaning, updating a single framework out of sync with the rest of the OS), but you should be able to update Safari as a stand-alone application, even, if this means that it's practically running in virtualization using it's own framework overlays.

unilynx 5y ago
They seem to be working on that. We got Safari 14 some time before the Big Sur release, and I think Safari 13 was faster than the accompanying OS update too ?
- nvrspyx 5y ago
  I think they're referring to Safari on iOS, not macOS
- masswerk 5y ago
  This would be great news. As it is, Safari is a great browser, when you get your new Mac, probably the fastest browser, there is (and economical on resources, as well). So there's reason to adopt it as the default browser, but then it eventually falls behind to the point of becoming incompatible with newer sites and users have to shop for a new standard browser. Which isn't the best user experience imaginable.