6 ms·

This statement here should be seen as a crimson flashing red flag waving as madly as a person can wave. "Want global web compatibility? Fuck you buy a Mac" -A

This statement here should be seen as a crimson flashing red flag waving as madly as a person can wave. "Want global web compatibility? Fuck you buy a Mac" -Apple

jojobas 4y ago
Well who wouldn't want to be in position to dictate that your bugs have to be other peoples' specs?
illiarian 4y ago
> "Want global web compatibility? Fuck you buy a Mac" Still better than "whatever we throw over the wall is now a standard" that Chrome has, and you can see people clamouring for those on HN.
- bioemerl 4y ago
  Not really in my experience as a primary Firefox dev. It's easy enough to not use stuff like web USB, and in my experience chrome and firefox "get along" while a page (doing more advanced things) not built for safari simply will not work in safari. The problem with safari is that Apple makes it so you have to use it if you want your site to work on it. Chrome, I can safely ignore. I also literally can't use safari if I don't have a Mac.
  - whywhywhywhy 4y ago
    > It's easy enough to not use stuff like web USB Unless you have the option to use it for your product then the decision is ship a product using just your web developers and have it not work on Safari/iPads or hire iOS developers and build and maintain a completely separate app. So it's a 6-7 figure cost to your business that could be saved if they supported that.
  - illiarian 4y ago
    > while a page (doing more advanced things) not built for safari simply will not work in safari. I've yet to see such a page [1]. And I've been using Safari since 2007 [1] Unless it's built with Chrome's non-standards of course. Edit: of course there will be pages broken in Safari (or FF) for no reason other than the sheer incompetence of people building them. E.g. we have an internal dashboard page that is literally nothing more than tables and charts. Ooops, "only works in Chrome". There's also the minor case of nominally open audio and video codecs that Google pushes to device manufacturers on pain of removing access to its services, but even that hasn't affected me, or most people really, that much.
    - bioemerl 4y ago
      > I've yet to see such a page Developers are eating the problems for you because safari support is almost always a requirement. This is a developer side problem, not a user side one. > for no reason other than the sheer incompetence of people building them Safari never breaks, but when it does it's because the developers are incompetent? The fact it takes a bunch of extra work to support safari (in more advanced cases like graphs and dashboards) is the whole problem. I have every intent to kick safari out of any home game stuff I do.
      - illiarian 4y ago
        > Developers are eating the problems for you because safari support is almost always a requirement. The problems "developers are eating" are hugely overblown > Safari never breaks, but when it does it's because the developers are incompetent? In 99% of the times? Yes. > The fact it takes a bunch of extra work to support safari No, it doesn't. Source: web developer myself. Of course, if you rely on Chrome-only non-standards, that's a different issue. > in more advanced cases like graphs and dashboards Graphs and Dashboards are advanced use cases now. Gotcha.
        bioemerl 4y ago
        You should reconsider your position when your only response is dismissal and insult.
        illiarian 4y ago
        > You should reconsider your position when your only response is dismissal and insult. I've been in these threads many times, and it's the same thing again and again: - Safari is holding back the web! It doesn't. Well, if you think that Chrome is web, then you're entitled to your opinion - Safari is new IE! It's not. That it doesn't implement the 400 or so APIs a year that Chrome implements is a feature, not a bug. If your site ends up with a "only works in Chrome" badge, that is your new IE - Chrome split from WebKit three years after WebKit appeared. And the only reason for the split? Well, to do the same thing you accuse Apple and MS of doing: control. And look how well it worked for them. Everything they do is now considered standard and gospel by the gullible masses of web devs. And so on. The irony is that it's Chrome that breaks the web often, and badly, but they get a pass because it's Chrome! They have the new shiny APIs!
  - the_other 4y ago
    > I also literally can't use safari if I don't have a Mac. You should embrace this; this is how the web should be. I don't mean you need to buy a Mac. Instead, I mean that the web standards effort originally came up out of supporting diversity. There was a wider range of possible clients, on a wider range of "popular" platforms. As developers we had to cater to support diverging capabilities. Progress on API development was slower, but it was more evenly spread out. Today, Chrome lurches ahead of everyone else in terms of API feature count, mostly supporting Google's business aims, and many vocal developers seem to think they should only support one set of capabilities. The slower, broader, way was better, in my opinion.
    - kitsunesoba 4y ago
      Yes, exactly. Use APIs that are broadly supported and somewhat settled and agreed upon. There is seldom an actual need to use whatever new thing that just became supported or is only implemented by Chrome… 95%+ of sites and web apps are doing the same old CRUD things that sites and web apps have been doing for decades and work fine with "boring" APIs.
- zdragnar 4y ago
  That's part of the ECMA standards process, and part of some others; progressing from a certain stage requires a minimum of two major implementations. The chrome team happens to sit on the leading edge of that process, being more willing to experiment. Safari sits on the other end, for better or worse depending on the feature.
  - illiarian 4y ago
    > progressing from a certain stage requires a minimum of two major implementations. The chrome team happens to sit The Chrome team happens to throw something over the wall and ship it to production with no oversight. And sometimes complain that that they cannot hide it behind a flag because people are already using it. There's no end of people right here on HN who scream bloody murder when Safari (and Firefox) refuse to implement some new Chrome-only API.
    - jefftk 4y ago
      > sometimes complain that that they cannot hide it behind a flag because people are already using it The way this is supposed to work is an origin trial: you ship something behind a flag, and then allow sites to flip the flag for testing and experimentation. But it's well documented that this is a temporary process, some Chrome visitors you get won't be eligible for trials, and it's not guaranteed that features in origin trials will ship. What are you thinking of where they just shipped something, without an OT?
      - illiarian 4y ago
        > The way this is supposed to work is an origin trial: you ship something behind a flag, and then allow sites to flip the flag for testing and experimentation. For something to become a standard they way it's actually supposed to work is for browsers to come up with two independent implementations. And yet, Chrome frequently ships APIs it calls standard with just Chrome as the sole implementor.
        jefftk 4y ago
- frozenlettuce 4y ago
  At least Chrome does not have a price tag - In my country a MacBook equals 22 months of work on minimum wage
- andybak 4y ago
  How is it better?
coldtea 4y ago
Better than the alternative: leave it to Google to dictate whatever they like as a standard and ship it.
- bioemerl 4y ago
  I would happily rather that neither of these happen. For safari not to be a buggy mess/work without extra development efforts and for chrome to have real competition enough to prevent them setting a standard. I will however, take chrome and user choice every single day over Safari's monopolistic crap. The mere fact it's largely successful by it's nature of being bundled should scream to you how bad it really is.
  - kitsunesoba 4y ago
    > I will however, take chrome and user choice every single day over Safari's monopolistic crap. That's the problem, though: more and more as time goes on, Chrome isn't user choice. Sites that only work with or only perform as expected under Chrome are becoming more and more common. It's becoming a monopoly too, but enforced by developers rather than a platform owner (though this is muddy with how Google gives Chrome performance advantages in Youtube, Docs, etc), and I'm not sure it's really any better.
    - illiarian 4y ago
      > though this is muddy with how Google gives Chrome performance advantages in Youtube, Docs, etc When (mostly) Chrome came up with Web Components, they immedieately re-wrote Youtibe with Web Components v0 (now deprecated). The polyfill for them was infamously slow on Firefox. Just another ooops in a long line of oopses: https://twitter.com/johnath/status/1116871237240852480 https://twitter.com/johnath/status/1116871237240852480
- nobleach 4y ago
  I don't have such a problem with browser makers putting their own ideas into their software. If Google wants to put a Flutter runtime into Chrome, great, go ahead. Where things fall apart is when they prioritize these projects ahead of supporting standards upon which they agreed. Microsoft was free to build and support VML back in IE days. The issue I had was that they refused to support SVG which WAS A ratified standard. So Google creating experiments is just that. They're free to build these, evangelize them and bring these to WHATWG, CSSWG or TC39, or whatever other governing body they'd like. They aren't "creating standards" if these governing bodies do not adopt their experiments.
flatiron 4y ago
https://github.com/kholia/OSX-KVM https://github.com/kholia/OSX-KVM also works (also not very legal)
- notpushkin 4y ago
  I don't think you really need a Mac – any browser running on WebKit should get you 95% there. GNOME Web on Linux, for example.
  - flatiron 4y ago
    In a professional environment you will need to test on safari proper.
    - notpushkin 4y ago
      I think this greatly depends on your definition of a “professional environment”. Also, using non-Safari WebKit for everyday testing (will my newest commit break it? should I fix something before I send the PR?) but using the proper Safari for more thorough testing (e. g. before public releases, or when a bugreport can't be reproduced otherwise) is an option too.
kevincox 4y ago
To me this is the biggest difference between Safari and IE/Edge. Microsoft provided free VMs that you could download with all supported versions of IE and Edge. So you could test sites and investigate bug reports. With Safari you can't debug an issue without expensive Apple hardware. I was happy to keep my sites compatible with IE and Edge (maybe not constant testing but some manual testing after big changes). However no way I was going to do that work for Apple when they didn't help out at all. (The Edge VMs don't appear available anymore but since Edge is cross-platform and free it should be easy enough to install it in your own VM or on your workstation.)

This statement here should be seen as a crimson flashing red flag waving as madly as a person can wave. "Want global web compatibility? Fuck you buy a Mac" -Apple

jojobas 4y ago

Well who wouldn't want to be in position to dictate that your bugs have to be other peoples' specs?

illiarian 4y ago

> "Want global web compatibility? Fuck you buy a Mac" Still better than "whatever we throw over the wall is now a standard" that Chrome has, and you can see people clamouring for those on HN.

bioemerl 4y ago
Not really in my experience as a primary Firefox dev. It's easy enough to not use stuff like web USB, and in my experience chrome and firefox "get along" while a page (doing more advanced things) not built for safari simply will not work in safari. The problem with safari is that Apple makes it so you have to use it if you want your site to work on it. Chrome, I can safely ignore. I also literally can't use safari if I don't have a Mac.
- whywhywhywhy 4y ago
  > It's easy enough to not use stuff like web USB Unless you have the option to use it for your product then the decision is ship a product using just your web developers and have it not work on Safari/iPads or hire iOS developers and build and maintain a completely separate app. So it's a 6-7 figure cost to your business that could be saved if they supported that.
- illiarian 4y ago
  > while a page (doing more advanced things) not built for safari simply will not work in safari. I've yet to see such a page [1]. And I've been using Safari since 2007 [1] Unless it's built with Chrome's non-standards of course. Edit: of course there will be pages broken in Safari (or FF) for no reason other than the sheer incompetence of people building them. E.g. we have an internal dashboard page that is literally nothing more than tables and charts. Ooops, "only works in Chrome". There's also the minor case of nominally open audio and video codecs that Google pushes to device manufacturers on pain of removing access to its services, but even that hasn't affected me, or most people really, that much.
  - bioemerl 4y ago
    > I've yet to see such a page Developers are eating the problems for you because safari support is almost always a requirement. This is a developer side problem, not a user side one. > for no reason other than the sheer incompetence of people building them Safari never breaks, but when it does it's because the developers are incompetent? The fact it takes a bunch of extra work to support safari (in more advanced cases like graphs and dashboards) is the whole problem. I have every intent to kick safari out of any home game stuff I do.
    - illiarian 4y ago
      > Developers are eating the problems for you because safari support is almost always a requirement. The problems "developers are eating" are hugely overblown > Safari never breaks, but when it does it's because the developers are incompetent? In 99% of the times? Yes. > The fact it takes a bunch of extra work to support safari No, it doesn't. Source: web developer myself. Of course, if you rely on Chrome-only non-standards, that's a different issue. > in more advanced cases like graphs and dashboards Graphs and Dashboards are advanced use cases now. Gotcha.
      - bioemerl 4y ago
        You should reconsider your position when your only response is dismissal and insult.
        illiarian 4y ago
        > You should reconsider your position when your only response is dismissal and insult. I've been in these threads many times, and it's the same thing again and again: - Safari is holding back the web! It doesn't. Well, if you think that Chrome is web, then you're entitled to your opinion - Safari is new IE! It's not. That it doesn't implement the 400 or so APIs a year that Chrome implements is a feature, not a bug. If your site ends up with a "only works in Chrome" badge, that is your new IE - Chrome split from WebKit three years after WebKit appeared. And the only reason for the split? Well, to do the same thing you accuse Apple and MS of doing: control. And look how well it worked for them. Everything they do is now considered standard and gospel by the gullible masses of web devs. And so on. The irony is that it's Chrome that breaks the web often, and badly, but they get a pass because it's Chrome! They have the new shiny APIs!
- the_other 4y ago
  > I also literally can't use safari if I don't have a Mac. You should embrace this; this is how the web should be. I don't mean you need to buy a Mac. Instead, I mean that the web standards effort originally came up out of supporting diversity. There was a wider range of possible clients, on a wider range of "popular" platforms. As developers we had to cater to support diverging capabilities. Progress on API development was slower, but it was more evenly spread out. Today, Chrome lurches ahead of everyone else in terms of API feature count, mostly supporting Google's business aims, and many vocal developers seem to think they should only support one set of capabilities. The slower, broader, way was better, in my opinion.
  - kitsunesoba 4y ago
    Yes, exactly. Use APIs that are broadly supported and somewhat settled and agreed upon. There is seldom an actual need to use whatever new thing that just became supported or is only implemented by Chrome… 95%+ of sites and web apps are doing the same old CRUD things that sites and web apps have been doing for decades and work fine with "boring" APIs.
zdragnar 4y ago
That's part of the ECMA standards process, and part of some others; progressing from a certain stage requires a minimum of two major implementations. The chrome team happens to sit on the leading edge of that process, being more willing to experiment. Safari sits on the other end, for better or worse depending on the feature.
- illiarian 4y ago
  > progressing from a certain stage requires a minimum of two major implementations. The chrome team happens to sit The Chrome team happens to throw something over the wall and ship it to production with no oversight. And sometimes complain that that they cannot hide it behind a flag because people are already using it. There's no end of people right here on HN who scream bloody murder when Safari (and Firefox) refuse to implement some new Chrome-only API.
  - jefftk 4y ago
    > sometimes complain that that they cannot hide it behind a flag because people are already using it The way this is supposed to work is an origin trial: you ship something behind a flag, and then allow sites to flip the flag for testing and experimentation. But it's well documented that this is a temporary process, some Chrome visitors you get won't be eligible for trials, and it's not guaranteed that features in origin trials will ship. What are you thinking of where they just shipped something, without an OT?
    - illiarian 4y ago
      > The way this is supposed to work is an origin trial: you ship something behind a flag, and then allow sites to flip the flag for testing and experimentation. For something to become a standard they way it's actually supposed to work is for browsers to come up with two independent implementations. And yet, Chrome frequently ships APIs it calls standard with just Chrome as the sole implementor.
      - jefftk 4y ago
frozenlettuce 4y ago
At least Chrome does not have a price tag - In my country a MacBook equals 22 months of work on minimum wage
andybak 4y ago
How is it better?

coldtea 4y ago

Better than the alternative: leave it to Google to dictate whatever they like as a standard and ship it.

bioemerl 4y ago
I would happily rather that neither of these happen. For safari not to be a buggy mess/work without extra development efforts and for chrome to have real competition enough to prevent them setting a standard. I will however, take chrome and user choice every single day over Safari's monopolistic crap. The mere fact it's largely successful by it's nature of being bundled should scream to you how bad it really is.
- kitsunesoba 4y ago
  > I will however, take chrome and user choice every single day over Safari's monopolistic crap. That's the problem, though: more and more as time goes on, Chrome isn't user choice. Sites that only work with or only perform as expected under Chrome are becoming more and more common. It's becoming a monopoly too, but enforced by developers rather than a platform owner (though this is muddy with how Google gives Chrome performance advantages in Youtube, Docs, etc), and I'm not sure it's really any better.
  - illiarian 4y ago
    > though this is muddy with how Google gives Chrome performance advantages in Youtube, Docs, etc When (mostly) Chrome came up with Web Components, they immedieately re-wrote Youtibe with Web Components v0 (now deprecated). The polyfill for them was infamously slow on Firefox. Just another ooops in a long line of oopses: https://twitter.com/johnath/status/1116871237240852480 https://twitter.com/johnath/status/1116871237240852480
nobleach 4y ago
I don't have such a problem with browser makers putting their own ideas into their software. If Google wants to put a Flutter runtime into Chrome, great, go ahead. Where things fall apart is when they prioritize these projects ahead of supporting standards upon which they agreed. Microsoft was free to build and support VML back in IE days. The issue I had was that they refused to support SVG which WAS A ratified standard. So Google creating experiments is just that. They're free to build these, evangelize them and bring these to WHATWG, CSSWG or TC39, or whatever other governing body they'd like. They aren't "creating standards" if these governing bodies do not adopt their experiments.

flatiron 4y ago

https://github.com/kholia/OSX-KVM https://github.com/kholia/OSX-KVM also works (also not very legal)

notpushkin 4y ago
I don't think you really need a Mac – any browser running on WebKit should get you 95% there. GNOME Web on Linux, for example.
- flatiron 4y ago
  In a professional environment you will need to test on safari proper.
  - notpushkin 4y ago
    I think this greatly depends on your definition of a “professional environment”. Also, using non-Safari WebKit for everyday testing (will my newest commit break it? should I fix something before I send the PR?) but using the proper Safari for more thorough testing (e. g. before public releases, or when a bugreport can't be reproduced otherwise) is an option too.

kevincox 4y ago

To me this is the biggest difference between Safari and IE/Edge. Microsoft provided free VMs that you could download with all supported versions of IE and Edge. So you could test sites and investigate bug reports. With Safari you can't debug an issue without expensive Apple hardware. I was happy to keep my sites compatible with IE and Edge (maybe not constant testing but some manual testing after big changes). However no way I was going to do that work for Apple when they didn't help out at all. (The Edge VMs don't appear available anymore but since Edge is cross-platform and free it should be easy enough to install it in your own VM or on your workstation.)