I've yet to run into a single case of some code running well on Safari but breaking on other major browsers, so by ensuring my code is compatible with Safari, I'm basically guaranteeing full compatibility with everything.
"Want global web compatibility? Fuck you buy a Mac"
-Apple
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.
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.
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.
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.
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.
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!
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.
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.
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.
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?
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.
Literally "Note that .adoptedStyleSheets is used on about ~.8% of page loads in Chrome now. Backwards-incompatible changes are definitely an issue here." https://github.com/WICG/construct-stylesheets/issues/45#issu...
---
WebMIDI allows enumeration of devices without asking the user for permission: https://twitter.com/denschub/status/1582730988118867968 (note this is a part of a whole bunch of hardware APIs that Chrome just shipped, no consensus needed)
Well, what do you know https://groups.google.com/a/chromium.org/g/blink-api-owners-...
"this is a case where we're going from no permission prompt to a permission prompt, I think a PSA and developer communication is a good idea. Other chromium-based browsers may want to know as well, via these channels."
Thankfully, there will be a change. At some point.
===
These are two I know of, that's why I said "sometimes". As Chrome releases 400 new APIs each year, it's impossible to track them all.
* With adoptedStyleSheets they're objecting to making backwards incompatible changes, which is reasonable: everyone hates browsers breaking sites. But there are ways to do this safely, like changing the name of the property (as rniwa suggested https://github.com/WICG/construct-stylesheets/issues/45#issu...) and if that were the only issue I think they'd have done something like that.
* With WebMIDI they're saying they want to do an announcement before making the change. (I do think it's nuts how long they're taking to fix this, and if you look on the blink-api-owners-discuss thread you linked you'll see I've been bugging them about it.)
Which would not be backwards incompatible if they hadn't shipped something that wasn't agreed on in the first place.
Again, slowly: they literally shipped that to production despite loud and explicit objections from both Firefox and Safari. When asked to hide it back behind the flag, "but backwards incompatible change, the framework we're developing is already depending on it"
And since you're quoting rniwa, here's the relevant quote https://github.com/WICG/construct-stylesheets/issues/45#issu...:
--- start quote ---
I feel like I’ve put so much time & energy into making this feature something sane & useful, and all you did was basically to dismiss many of my feedbacks and go with whatever you like and just ship it. And now you’re saying you can’t make changes because you shipped it?
I’m sorry but that’s just not how standards work.
--- end quote ---
> With WebMIDI they're saying they want to do an announcement before making the change.
Indeed. Once again: because they shipped an API that neither Safari nor Mozilla supported. Now that this issue has surfaced (no thanks to Chrome), they can't just roll it back or fix it because people already rely on this behaviour, which they implicitly acknowledge.
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.
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.
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
Then why is HN is screaming bloody murder when other browsers don't implement the plethora of Chrome-only non-standards?
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.
(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 isn't a Chrome vs Safari issue (Safari is better, of course), it's the fact that browser development suffers from Apple's corporate wall of silence. In this case, devs literally suffering.
Ah the sweet nectar of naivety. Godspeed to you.
Can't believe I've been a webdev 15 years. What's old becomes new, except for me that is....
https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
1. IE6, a titanic that that wants to harm the web so they can push their own ecosystem instead.
2. IE11, the incompetent and rarely updated browser that you have to support because a segment of your userbase is stuck with it.
This article tries to argue 1 isn't the case, but I have to disagree. Safari isn't as large as IE6, but it regardless tries to fill the same role. Ensuring apple gets their app store cut.
2 is also the case, but that needs less argument.
What a retcon.
> This article tries to argue 1 isn't the case, but I have to disagree. Safari isn't as large as IE6, but it regardless tries to fill the same role.
Of course it doesn't
> 2 is also the case, but that needs less argument.
It needs as much argument, if not more.
The primary reason for chrome being developed in the first place was to push the web into a place that stuff like Google maps, docs, and so on could exist at all.
> It needs as much argument, if not more.
Read this thread where people talk about their experiences developing for safari. Read any open source web libraries issue list. It will be immidiately apparent that safari is the odd man out who constantly has to be baby sat in order to work properly.
The reason I said it needs less argument is that I assumed it would be immidiately apparent. Most people who do web dev come away with this impression.
Retcon again.
> Read this thread where people talk about their experiences developing for safari. Read any open source web libraries issue list. It will be immidiately apparent that safari is the odd man out who constantly has to be baby sat in order to work properly.
And then when you actually read what people are saying, it turns out they only develop on Chrome, couldn't be arsed to develop for or test on other browsers, and want Chrome-only non-standards delivered yesterday to every browser.
To quote again, "But do you ever see a “Best viewed with Safari” notice? No, you don’t. Another browser takes that special place in web developers’ hearts and minds."
> The reason I said it needs less argument is that I assumed it would be immidiately apparent. Most people who do web dev come away with this impression.
I do web dev, and it is definitely not immediately apparent.
After IE6 achieved it's goal of destroying the competition, Microsoft literally disbanded the development team. Why would they do that for a very successful product? Because the web didn't have potential?
Firefox started innovation back again a bit, but it took chrome and Google's want to applicationize the web to really kick us into gear.
https://www.androidauthority.com/google-chrome-history-10256...
> A few days before Google Chrome launched, Google released a blog post titled “A fresh take on the browser.” The post explained that they were releasing this new browser because they believed they could “add value for users and, at the same time, help drive innovation on the web.”
> Third, Google saw Chrome as more than just a browser by developing it with rich, interactive web applications in mind. Lastly, it offered tab “sandboxing,” which kept the entire browser from crashing when one website crashed.
...
> And then when you actually read what people are saying, it turns out they only develop on Chrome, couldn't be arsed to develop for or test on other browser
I develop for Firefox. Chrome basically always works fine with my pages. Safari chokes on all of them.
And if you want to test Safari? You literally have to buy a dedicated piece of hardware for it. You wonder why it isn't tested?
So here's a browser that fails to just work, even when you primarily use Firefox to build the page.
You have to buy extra hardware to test on it.
And you blame the developer?
What Google says, and what Google does are two very different non-intersecting things.
Edit: Google's maps and docs etc. ran just fine in WebKit. What Google wanted was control. What they did with that control we all know. For example, sabotaged Firefox: https://twitter.com/johnath/status/1116871237240852480
> I develop for Firefox. Chrome basically always works fine with my pages. Safari chokes on all of them.
Doubt.
> So here's a browser that fails to just work, even when you primarily use Firefox to build the page.
Funnily how I've used Safari as my primary browser since 2007, and I've been a web developer for far longer than that... and I haven't run into these issues everyone on HN pretends to have.
> And you blame the developer?
Yes, yes I do. Always. Even in the days of IE6 the problem was always with the developer.
> Doubt.
For what it's worth, my development profile is similar. I would say that Safari works most of the time, but I get browser-specific failures from it at a noticeably higher rate than Chrome-derivatives.
One memorable one, if you're curious, was triggered because of a minification step. Terser[0] has a special argument `--safari10` to emit code that's supported by Safari. I discovered this argument after running into the bug.
So the problem is with the tool, not with the Safari it seems. Without an explanation what "non-standard" is about Safari 10/11 it's on the same level as the rest of hand wringing on HN.
You're making an assumption. I'm not sure where you're getting that. From what I recall, it was common `const` or parameter declarations in nested scopes. Safari was (is?) unambiguously wrong.
Edit: here's the bug: https://bugs.webkit.org/show_bug.cgi?id=171041
The updates came in plugins tied to the Windows platform: ActiveX. Because that strengthened the monopoly, they were pulling the strings and setting the standards, at their own terms. Tie it to operating system versions, tie it to Office, tie it to the next product they want to promote. Whatever they like.
Why invest so hard in capturing the web in the first place, then? Their behavior is consistent with a push to keep people on windows as much as possible.
I mean you know there was a period of time where Safari existed and Chrome didn't.
Let’s just throw in the towel now and rename the web to the Chrome Platform.
Or depending on your tolerance for legal grey areas, you can also download MacOS directly from Apple servers and run it in a virtual machine.
Or if your objection isn’t to paying money but rather paying Apple, you can buy second-hand hardware.
Probably didn't word my answer well: by "Non-browser based bugs" I mean bugs caused by the code of the webpage having logic issues/bugs (as opposed to bugs caused by browser JS issues or CSS/HTML implementation incompatibilities and such). Perhaps "browser-engine-related" would be a better term
So, I read the parent comment as referring to browser-engine-related bugs - things caused by a browser engine behaving differently, not implemented, etc, and not including in his numbers regular webpage bugs due to html/js programmer error.
There's an important and cool concept here about using the weakest link sometimes.
Similar example: as an app developer, I intentionally use a phone several, several generations behind so I can see what the actual response time and general UX feeling is on the devices frankly a lot of users are going to have.
If my app runs well on my iPhone 8, it's obviously going to scream on a 12.
I'm basically guaranteeing full compatibility with everything, because everyone has to comply with IE's behaviour. After all, I put a "Best viewed in Internet Explorer", this way if it fails, people blame their browser and not me.