3 ms·

I used to think it was better to have Safari for browser engine diversity. However Apple develop Safari with such appalling negligence that it's changed my mind

I used to think it was better to have Safari for browser engine diversity. However Apple develop Safari with such appalling negligence that it's changed my mind [1]. Having a single browser engine dominate is not a perfect situation and will have downsides. However it is still better than having to put up with Apple's negligence towards Safari. [1] https://www.construct.net/en/blogs/ashleys-blog-2/safari-releases-development-1616 https://www.construct.net/en/blogs/ashleys-blog-2/safari-rel...

mort96 3y ago
I think it depends entirely on what your goals are. If you think diversity is gonna improve the browser engines, then yeah, Apple isn't gonna be much help with that. However, if your goal is to prevent Google from having complete and total unilateral control of the web standards, simply the existence of WebKit as a prominent browser engine is enough. Its quality pretty much doesn't matter in this regard. This is pretty much my perspective.
- factormeta 3y ago
  And what didn't Chrome forked from WebKit at some point with khtml from KDE. So yeah use WebKit more to avoid Chromium monopoly.
liamwire 3y ago
Reading through these complaints, all of them seem to be your fault. It’s akin to the bike fall meme [1]. Firstly, you complain of a third-party dependency being broken in a preview build of Safari, and that you had went on holiday the week the stable version was published, meaning you couldn’t guarantee the problem was fixed in the stable release. Plainly, that’s an organisational problem on your end—the Safari team fixed the problem on their end. I’ll come back to your complaints re. release schedules. Your second complaint is, in your own words, “we accidentally relied on a Chrome bug that meant our Service Worker was broken in Safari 16.4.” You go on to rehash your initial complaint, which is that Apple doesn’t publish a release schedule for Safari. I don’t inherently disagree with this complaint at face value. Finally you move on to your third complaint, but to me it seems like yet another problem on your end. You made the observation that a given feature was supported and made the assumption that it was supported fully, with no other logic in place to test functionality or fallback to another rendering method. By your own admission again: “We detected OffscreenCanvas merely by seeing if it was defined. I never expected a browser to ship it with some contexts but not others - I assumed it would have parity with the standard canvas element.” I can understand the frustration and panic of being caught out here, but the pitfall is in your application logic. Your arguments afterwards with regard to supporting existing content are well said, but don’t generalise in this case. Just because something broke for you doesn’t mean everyone made the same flawed assumptions you did. You then go on to list a random assortment of historic instances of Safari having flaws, as if that isn’t true of all browsers across the board. [1] https://knowyourmeme.com/memes/baton-roue https://knowyourmeme.com/memes/baton-roue
- AshleysBrain 3y ago
  I think you've misunderstood the point of the post. Of course bugs happen and things go wrong, including on our side. What makes it so much worse is Apple's opaqueness: no communication on bugs, no release schedule, no public plans. So we have no idea what will ship or when or whether catastrophic bugs will go to worldwide release or be fixed. For example how am I supposed to avoid booking a holiday when Safari's stable release happens, when the release date is an Apple secret right up until the very moment it begins its worldwide release? You can't blame me for messing up my planning there, because it's simply not possible, and it can result in a great deal of stress for developers like me. All other browsers have enough communication and transparency to avoid this. Towards the end of the blog post I outline what Apple need to do - which all other browser makers already do - to make it at least vaguely tolerable to develop for Safari.

mort96 3y ago

I think it depends entirely on what your goals are. If you think diversity is gonna improve the browser engines, then yeah, Apple isn't gonna be much help with that. However, if your goal is to prevent Google from having complete and total unilateral control of the web standards, simply the existence of WebKit as a prominent browser engine is enough. Its quality pretty much doesn't matter in this regard. This is pretty much my perspective.

factormeta 3y ago
And what didn't Chrome forked from WebKit at some point with khtml from KDE. So yeah use WebKit more to avoid Chromium monopoly.

liamwire 3y ago

Reading through these complaints, all of them seem to be your fault. It’s akin to the bike fall meme [1]. Firstly, you complain of a third-party dependency being broken in a preview build of Safari, and that you had went on holiday the week the stable version was published, meaning you couldn’t guarantee the problem was fixed in the stable release. Plainly, that’s an organisational problem on your end—the Safari team fixed the problem on their end. I’ll come back to your complaints re. release schedules. Your second complaint is, in your own words, “we accidentally relied on a Chrome bug that meant our Service Worker was broken in Safari 16.4.” You go on to rehash your initial complaint, which is that Apple doesn’t publish a release schedule for Safari. I don’t inherently disagree with this complaint at face value. Finally you move on to your third complaint, but to me it seems like yet another problem on your end. You made the observation that a given feature was supported and made the assumption that it was supported fully, with no other logic in place to test functionality or fallback to another rendering method. By your own admission again: “We detected OffscreenCanvas merely by seeing if it was defined. I never expected a browser to ship it with some contexts but not others - I assumed it would have parity with the standard canvas element.” I can understand the frustration and panic of being caught out here, but the pitfall is in your application logic. Your arguments afterwards with regard to supporting existing content are well said, but don’t generalise in this case. Just because something broke for you doesn’t mean everyone made the same flawed assumptions you did. You then go on to list a random assortment of historic instances of Safari having flaws, as if that isn’t true of all browsers across the board. [1] https://knowyourmeme.com/memes/baton-roue https://knowyourmeme.com/memes/baton-roue

AshleysBrain 3y ago
I think you've misunderstood the point of the post. Of course bugs happen and things go wrong, including on our side. What makes it so much worse is Apple's opaqueness: no communication on bugs, no release schedule, no public plans. So we have no idea what will ship or when or whether catastrophic bugs will go to worldwide release or be fixed. For example how am I supposed to avoid booking a holiday when Safari's stable release happens, when the release date is an Apple secret right up until the very moment it begins its worldwide release? You can't blame me for messing up my planning there, because it's simply not possible, and it can result in a great deal of stress for developers like me. All other browsers have enough communication and transparency to avoid this. Towards the end of the blog post I outline what Apple need to do - which all other browser makers already do - to make it at least vaguely tolerable to develop for Safari.