Everything they said! Rendering is shockingly bad at times. Try running some transforms on SVG with CSS or WAAPI and it’s laughably bad. The dev tools are all but useless. Just simple things like adding a new prop/value to a selector declaration is horrid and often inadvertently removed a different declaration. The JS perf is great but the debugging stepper is virtually opaque with buttons with no labels and the like. Let’s not even get started on the raft of web platform features it either doesn’t have yet or has no intention of adding.

I too would like to use Safari but it’s so far behind evergreen browsers like FF and Chrome I just can’t rely on it.

Seconding all of this.

I still regularly use it because of battery life/power (Firefox seems determined to turn my laptop into a space heater) and that has its merits but it's objectively bad in a number of other ways.

(Oh, and I'm still thinking about the MBP 16" release a year ago -- Apple had a fancy web page for it with certain actions that triggered on scroll. That page crashed every time I tried to read it in Safari; I literally had to use another browser besides Apple's in order to take in an Apple product page. And I reported to Apple, they had mildly helpful front line support suggestions for troubleshooting... as if it was my problem, not theirs.)

I'll second the text selection (on Catalina, but the new safari). Not sure how they messed up so badly on that.

Also, safari on my iPad sucks as well, but got better with the 14.2 update.

EDIT: Screenshot here of Apple's Big Sur page NOT rendering! https://imgur.com/a/tF4TDPH

Screenshot of the sidebar of GitHub rendering only partially: https://i.imgur.com/Fa370r2.png (I hid the center feed myself, but the left sidebar is blank)

The only time I've seen rendering issues with Safari was on early versions of Catalina but that was true of a lot of apps back then. I blame how sucky Catalina was for the first few releases.

In the latest versions of Catalina and on Big Sur, Safari has been rock solid; none of these issues.

Again, no issues with CSS Grid either.

Igalia (https://www.igalia.com) implemented CSS Grid for both Webkit and Blink; they had more commits to Webkit and Blink than anyone else except Apple and Google.

It's not clear why there would be major differences between the two…

Devtools on Safari have been a joke for 5 years now. Ever since they split from Chrome and went down the Xcode "fancy" route, I have not been able to accomplish anything debugging in that browser.

They never split from Chrome. Chrome forked WebKit into Blink because Apple's wasn't merging Google's patches

There were many reasons for the split, but as far as I know this was not one of them. There was no patch backlog, and there were many reviewers on the Chrome team. I think it was a combo of desire for control and debates over various architectural approaches.

Not sure why you're getting downvoted but this is correct. KHTML -> WebKit -> Blink.

And now we only can only hope for the next iteration to take over: KHTML → WebKit → Blink → Edge

Unlikely, given how Edge just migrated to Blink itself.

I think the point your parent comment is making is that Microsoft may break away from Blink just like Google broke away from Webkit.

He's getting downvoted because people misunderstand what he means. Real debugging requires the xcode tools , not the built in 'web developer' garbage.

> Ever since they split from Chrome

WOW, talk about revisionism! Chrome/Chromium was based on WebKit!

Unless you mean something else?

Yeah, the devtools have come a long way but there's still some friction there. At this point it might just be because I'm used to Chrome's and I just need a little exercise in mental plasticity. However, eventually I'd like to take a look at porting Vue devtools to Safari, if only for iOS.

Maybe I'm just old enough to remember the bad old days, but browser bugs seem very few and far between. One I've found is Chrome's implementation of backdrop-filter is extremely buggy, while Safari works 100% of the time. Specifically it seems that two sibling elements cannot both specify a backdrop-filter in Chrome. I work on a rather large SPA and it has only one browser hack: a dummy div that works around Chrome (and thus Edge's) implementation.

The browser bugs/differences I run into these days aren’t surprising; they live at the edges with features that aren’t 100% complete usually, and I know that going in. Long gone are the days of surprising cross browser bugs, I’ve found

The network tools drive me insane. It's a major part of why I can't use the dev tools routinely.

> consistent rendering issues

This is because lazy/incompetent web developers make their sites in Chrome and don’t bother testing other browsers.

You could have said the same about any browser that wasn’t IE a decade ago.

> This is because lazy/incompetent web developers make their sites in Chrome and don’t bother testing other browsers.

This has not been my experience at all.. I use Firefox on a day to day basis and generally build applications which work in Chrome and Firefox. They used to work well with EdgeHTML too.

I've run into cases in the past where basic SVG rendering with an feColorMatrix filter doesn't work properly in Safari and looks like garbage .. but works fine in Firefox and Chrome. I've run into lack of support for HTML elements that every other modern browser vendor supports. I still can't believe there's no proper input[type=date] support on desktop.

Away from desktop, I've also run into Mobile Safari failing to properly calculate the height of <iframe> elements, not supporting background-attachment: fixed and localStorage failing unintuitively in incognito mode.

Safari is absolutely the browser that gives me the most issues; I'd call it the new IE.

Or they just don't own a Mac and have mixed results with virtualization. Maybe instead of blaming them recognize that Safari is extremely inaccessible software for most people

That is so obvious! But For those of us who has a Mac we dont think about these issues as we can test Chrome and Firefox.

How are Windows Dev suppose to test with Safari when they dont have access to it?

Generally by running selenium tests with BrowserStack or SauceLabs, but that's not cheap.

That is awful! Thank You I think Apple needs to do something about this.

There's the Epiphany web browser which is based on WebKit and will get you a similar experience to Safari - https://webkit.org/downloads/

> Safari is extremely inaccessible software for most people

How the hell is it "extremely inaccessible" for "most" people?

It's Chrome that has an weirdass non-standard UI (the practice of showing app preferences/dialogs in a webpage needs to burn in the flames of Hades) and other niggles, not to mention being a privacy black hole.

If they weren't told to use Chrome (i.e. Google didn't nag people to use Chrome when they're trying to use Search etc.) "most" Mac users wouldn't give a fuck about Chrome.

> How the hell is it "extremely inaccessible" for "most" people?

Because most people don't own Macs. The last Windows compatible version of Safari was back in 2012 or so, and as far as I know, it was never available on Linux.

Therefore, for me to test on Safari, I either have to spend thousands to buy a laptop, or pay out of my pocket for some sort of cross-browser testing tool (even if it's free, I am spending extra time) while Chrome/Firefox are used by most of the world and ensuring that I deal with Safari's idiosyncrasies does nothing much for me.

> It's Chrome that has an weirdass non-standard UI (the practice of showing app preferences/dialogs in a webpage needs to burn in the flames of Hades) and other niggles, not to mention being a privacy black hole.

I would argue its more standard since it is the same UI in every OS I wanted to use. I honestly don't think people are that angry about preferences as a webpage.

In terms of privacy, Firefox kicks Safari out of the water, and in terms of performance, it is faster, and actually renders everything (something Safari fails way too often at).

> "most" Mac users wouldn't give a fuck about Chrome.

Eh. Safari not rendering elements of the page, constantly crashing, and other myriad of issues do well enough to push people to Chrome/Firefox. Also, most people quickly start using Firefox when they realize that UBlock Origin doesn't work on Safari and is easily better than anything that comes on Safari.

Honestly, for me as developer, Safari is the new IE6, except possibly worse because bugs for IE6 are very well-documented with good workarounds.

"Therefore, for me to test on Safari, I either have to... pay out of my pocket for some sort of cross-browser testing tool (even if it's free, I am spending extra time)"

That's precisely the 'lazy web developer' that they're talking about. Oh god no, you have to test on a browser you don't use.

Sure Chrome is dominant, but Safari has about 15% of the market so by taking the stance you do, you're dismissing 1 of 6 people. Because you're lazy.

That 15% of the market is only relevant for companies targeting first world countries with people having wages to buy Apple stuff.

The large majority of the companies across the globe have already enough to do with their local markets with zero (0%) presence of Apple devices.

If Apple wants them to care about Safari, they can easily make Safari available in other platforms, has they have done when they were struggling for survival.

Supporting 85% of the market is basically free - because you already have a PC, and all browsers can be installed on that, except for Safari. But supporting the remaining 15% requires paying several hundred dollars for hardware that you don't really need for any other purpose. I don't think that refusing to do the latter is a case of "lazy".

We have very different opinions on how bad IE6 really was if you think Safari is comparable at all.

I wouldn't go so far as to say Safari is the new IE 6, but I do feel that calling it the new IE 11 is very accurate across multiple dimensions.

I don’t remember good workarounds. IE6 fixes often required entire libraries. Websites ballooned in size due to needing constant shims, normalization, and polyfills. For a long while it wasn’t uncommon to send out a separate stylesheet for ie6 to fix whatever would break using the regular styles. I can’t think of anything Safari does that’s that bad.

How does Firefox win in privacy? Maybe through certain extensions but Safari has the edge in things like private mode tabs not sharing cookies etc. between each other.

It sure doesn’t feel faster.

As for Chrome I read this just now:

https://www.zdnet.com/article/google-patches-two-more-chrome...

Privacy/no-cookie sharing: Container Tabs + Multi Account Containers in Firefox is incredible. Yes, I realize those are extensions - but that kind of control or extensibility isn't even possible in Safari.

Which is actually the biggest reason I don't use Safari, it has no support for profiles or user-chosen cookie separation (multiple different accounts for GSuite, etc).

As for Chrome just getting patched with zero-days - fine, but remember that Safari doesn't have the concept or ability to do Site Isolation the way Chrome or FF do, Chrome uses the macOS sandbox the same way Safari does, and there have been plenty of Safari CVEs as well. Chrome is usually the last to fall at Pwn2Own; pointing out "oh they just patched a zero-day CVE" doesn't mean much, especially since Apple pushes Safari updates far less often than Chrome does, and will often leave desktop Safari unpatched for weeks after iOS has been fixed.

It’s inaccessible in the sense that most devs don’t have Macs

If you're a professional and don't test Safari, you're not being professional. Don't have a Mac? Use https://www.browserstack.com or similar. Don't want to bother? Then, yeah, you're lazy.

I don't have a Windows machine. I still test against Edge. No Android phone. Still test against a range of them. How? See above.

Not so much in macos but in ios safari is our constant pain. Most bugs we get are in ios and most of the times are because of bugs in safari engine and are unfixable.

I think you're probably right, but if the site doesn't work in Safari that's a problem for Safari users regardless of whose fault it is.

As a daily user of the safari devtools, I have to disagree

I don‘t have much need for the Network tab, so maybe that’s why. They handle the basics very well for me, with a much better interface (IMHO) than chrome tools.

I really wish they didn‘t skip the devtools part of WebExtensions so we could get the tools for React/Vue/Redux et al.

Genuinely curious: what are you developing that you don’t ever need the network tab?

I don‘t know, like, average SPA stuff, a lot of React.

I just considered what the network tab actually is and I have of course used it before, to work on the loading speed of sites, but haven‘t done that for a while. The only performance work I‘ve done recently is with react profiler.

I have never used it to inspect API requests, which I assume it can do? I‘m comfortable with Charles proxy, which is likely overkill.

My usage is maybe 45% elements, 45% console, 5 % source/debugger, 3% storage, 2% network. Somehow I dislike elements UI in chrome.

Now I‘m thinking that I may be missing out and should look at what it does and what chrome could give me.

Edit: after playing around with it for a few minutes: I have in fact been missing out and using Charles and Paw way too much when I could have done it way quicker in the browser. I hope I don't have to switch to chrome now.

I was going to tease you but you've realized the error of your ways. Unless you don't value your time, by all means, continue to use Charles and Paw. Network tab is great.

I've been using Safari as my browsing browser and Chrome as my development browser for years. Chrome's network tab is way better than Safari and their profiling tools are also very useful.

In old safari, try setting 'max-content' to to any div 'width' attribute and it'll crash. This has been a persistent since many years and yet not fixed.

Still no webm support on mobile is awful :(

That’s why I keep Firefox around as well. Surf in Safari and work in Firefox or Chrome.

yep, Safari is absolutely unusable for development. Opening DevTools from an iOS open tab crashes instantly for me and it's impossible to use. It's the biggest pile of and I hope one day that Apple just discontinue it cause they obviously aren't putting any effort into it.

If you use Safari I hate you

And why are you using Safari daily?

I only use it to open non work related sites to split distractions because I agree it's not the best browser.

• Because Safari takes up much fewer CPU and RAM and feels much snappier in general compared to Chrome and Firefox.

• The UI is 100% Mac'cy and doesn't try to be different in retarded ways. Fuck preferences-as-a-webpage.

• The automatic syncing between my iPhone, iPad and Mac is also amazingly convenient. I can Handoff this page over to my phone and it will retain the comment I am currently typing! Can't beat that shit.

• I don't do webdev so I don't care about the in-browser devtools, but they suffice for me when I dabble in it.

• I want to limit what Google sees about me to as little as possible.

It's not perfect but it's pretty darn close. Using the dev tools in Safari daily and it works like a charm.

You’re so right. It used to be great, the nightly WebKit build still uses the old one, I think.

But I now use Safari for browsing and Chrome for developing, ever since they destroyed it.

> The network tools suck (why is it so hard to find the request payload??)

Speaking as a non-web-dev who looks at web inspector once in a blue moon, this took me about 5 seconds. I looked at the Network tab, selected a resource, noticed the information in the detail pane had headers but not payload, and then right-clicked the resource and selected "Reveal in Sources Tab" which revealed the payload there.

If I followed your instructions correctly, that's the response payload not the request.

Exactly :) the request payload is hidden at the bottom of the Headers tab (yep...), you need to uncollapse it. I always forget where it is and confuse it with the response payload, which is really confusing when trying to debug what you send to a REST endpoint

Yes, which I think helps prove the parent's point!

Isn't that the response payload and not the request payload?

Personally I'm usually looking through a bunch of responses trying to find the one I'm interested in, and that workflow sounds pretty awful.