4 ms·

> correctness of the features they do decide to implement, performance, If this was the case, I would hate Safari significantly less. If the only issue with Sa

by doix 4y ago

> correctness of the features they do decide to implement, performance, If this was the case, I would hate Safari significantly less. If the only issue with Safari was that they didn't implement certain features, that would be fine. I could check the compatibility matrices and just avoid features that aren't implemented. The problem is that every now and then they support something, and it _appears_ to work, but then there's some weird interaction that breaks some interaction and it takes forever to debug. Sometimes it's reproducible in Epiphany(webkit issue), but other times it isn't. Safari updates their webkit version pretty infrequently so bugs that are fixed in webkit are not fixed in Safari. So the only way to know if it works in Safari is to test in Safari, which requires OSX. Safari is the new IE. IE had better client-side resource use for a long time compared to firefox/netscape. IE didn't implement new features and they had IE only features just like Safari (you can select text in images in Safari). IE only worked on windows and made linux/osx developers suffer just like Safari makes linux/windows developers suffer today.

nwienert 4y ago
When you develop in Chrome of course you’ll feel like bugs only exist in other engines. Developing on Safari it feels like the opposite. A few years ago I’d have agreed somewhat, but Safari has accelerated considerably and improved wrt standards. In fact better than Chrome as of late, if you follow the Interop project, and it feels as much.
- doix 4y ago
  I primarily use Firefox, but I usually have 3 browsers open: Chrome/Firefox/Epiphany to try and make sure stuff works correctly across all 3 major engines. Unfortunately stuff still slips through into Safari land. I am not a language specification lawyer. If I hit a difference in behavior, I don't open up the spec to try and figure out who is right and wrong. It's entirely possible that Safari is in the right. But when Chrome/Firefox/Latest webkit agree, and Safari doesn't, I'm fairly confident it's Safari's fault at that point. But even if it was Safari's fault and I could test that on Linux/Android, that would be fine. The biggest annoyance is that you can't possibly know if what you're doing would work without buying Apple hardware.
  - Jcowell 4y ago
    > I am not a language specification lawyer. If I hit a difference in behavior, I don't open up the spec to try and figure out who is right and wrong. It's entirely possible that Safari is in the right. But when Chrome/Firefox/Latest webkit agree, and Safari doesn't, I'm fairly confident it's Safari's fault at that point. This is weird to me. Say if I’m working with Swift, JavaScript, and Java. And only Swift built-in mergesort is the right implementation (say it’s the common case where it correctly implements the mid logic not shown in textbooks). That’s not Swift’s fault, that’s Javascript & Java’s fault for implementing a bad Mergesort.
depressedpanda 4y ago
> IE only worked on windows and made linux/osx developers suffer just like Safari makes linux/windows developers suffer today. Safari is worse than IE. With IE, Microsoft at least provided a VM I could test with. With Safari, Apple expects me to buy their hardware. And both a phone and laptop, since iOS/Safari supports even less stuff than desktop Safari. No thanks.
- sokoloff 4y ago
  Hackintosh VMs are readily available (admittedly not provided by Apple, but that’s hardly a significant hurdle).
  - yakak 4y ago
    I'm going to commit crimes to make sure Apple customers get the best experience?
  - sofixa 4y ago
    Isn't that breaking Apple's ToS, so basically a non-starter for work?
  - watermelon0 4y ago
    License prohibits running macOS on non-Apple hardware. I'm not sure if EULA is legally binding in EU (and if it can prevent you from using a product), but I think companies would rather avoid this if possible.
- password4321 4y ago
  Windows builds of WebKit exist, though "better than nothing" would be very generous. https://build.webkit.org/#/builders/67 https://build.webkit.org/#/builders/67 (give it a sec) They require "Apple Application Support", which is installed with iTunes; you can crack open the installer and only install the support library.

by doix 4y ago

nwienert 4y ago

When you develop in Chrome of course you’ll feel like bugs only exist in other engines. Developing on Safari it feels like the opposite. A few years ago I’d have agreed somewhat, but Safari has accelerated considerably and improved wrt standards. In fact better than Chrome as of late, if you follow the Interop project, and it feels as much.

doix 4y ago
I primarily use Firefox, but I usually have 3 browsers open: Chrome/Firefox/Epiphany to try and make sure stuff works correctly across all 3 major engines. Unfortunately stuff still slips through into Safari land. I am not a language specification lawyer. If I hit a difference in behavior, I don't open up the spec to try and figure out who is right and wrong. It's entirely possible that Safari is in the right. But when Chrome/Firefox/Latest webkit agree, and Safari doesn't, I'm fairly confident it's Safari's fault at that point. But even if it was Safari's fault and I could test that on Linux/Android, that would be fine. The biggest annoyance is that you can't possibly know if what you're doing would work without buying Apple hardware.
- Jcowell 4y ago
  > I am not a language specification lawyer. If I hit a difference in behavior, I don't open up the spec to try and figure out who is right and wrong. It's entirely possible that Safari is in the right. But when Chrome/Firefox/Latest webkit agree, and Safari doesn't, I'm fairly confident it's Safari's fault at that point. This is weird to me. Say if I’m working with Swift, JavaScript, and Java. And only Swift built-in mergesort is the right implementation (say it’s the common case where it correctly implements the mid logic not shown in textbooks). That’s not Swift’s fault, that’s Javascript & Java’s fault for implementing a bad Mergesort.

depressedpanda 4y ago

> IE only worked on windows and made linux/osx developers suffer just like Safari makes linux/windows developers suffer today. Safari is worse than IE. With IE, Microsoft at least provided a VM I could test with. With Safari, Apple expects me to buy their hardware. And both a phone and laptop, since iOS/Safari supports even less stuff than desktop Safari. No thanks.

sokoloff 4y ago
Hackintosh VMs are readily available (admittedly not provided by Apple, but that’s hardly a significant hurdle).
- yakak 4y ago
  I'm going to commit crimes to make sure Apple customers get the best experience?
- sofixa 4y ago
  Isn't that breaking Apple's ToS, so basically a non-starter for work?
- watermelon0 4y ago
  License prohibits running macOS on non-Apple hardware. I'm not sure if EULA is legally binding in EU (and if it can prevent you from using a product), but I think companies would rather avoid this if possible.
password4321 4y ago
Windows builds of WebKit exist, though "better than nothing" would be very generous. https://build.webkit.org/#/builders/67 https://build.webkit.org/#/builders/67 (give it a sec) They require "Apple Application Support", which is installed with iTunes; you can crack open the installer and only install the support library.