4 ms·
Because for anything beyond basic website Safari is a buggy mess, and requires a Mac and maybe had less good dev tooling.
by dathinab 5y ago
Because for anything beyond basic website Safari is a buggy mess, and requires a Mac and maybe had less good dev tooling.
- acdha 5y agoThis is hyperbole: if you are developing against web standards, most things work compatibly in all browsers now. In my experience, it's a bit more likely that you'll find a problem with Safari than Chrome or Firefox but not enormously so; the worst I've found are typically cases where someone only developed in Chrome and ended up relying on the non-standard API they started with rather than the final standard version.
- wildrhythms 5y agoiOS Safari (for iPhone) still does not support the Fullscreen API. Works fine on iPad, but not iPhone. Why? https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API#document.fullscreenelement https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_... And some weird CSS behavior that only exists in Safari right now: like :first-child selectors, limited flex-basis values, the gap property not working in a multi-column layout... It's mysterious discrepancies like this that drive me insane doing frontend for iOS. Apple can't spend a crumb of it's $2T+ getting their browser and dev tools up to par with even Firefox? Please
- smoldesu 5y ago> Apple can't spend a crumb of it's $2T+ getting their browser and dev tools up to par with even Firefox? Ugh, please. They've only got a mere 200 billion in liquid cash.
- acdha 5y agoTwo things: that's not “a buggy mess” unless you think Firefox/Chrome magically turn into one if you use one of the APIs which Safari supports which they don't or have bugs with. Again, remember that I wasn't saying that there are no problems, only that they were exaggerating the magnitude and degree to which it's specific to Safari. Second, this is not only not “a buggy mess” but a conscious design decision and one which I generally agree with. Safari supports full-screen video, which is the primary reason why I want this, and the full-screen API is a notorious security risk on touchscreen devices even more than traditional computers because you don't have the equivalent of the escape key or the operating system UI giving you a way to tell that the “Please enter your password” dialog which just popped up was generated by the web page and not your OS. On iOS, Safari is already close to full screen anyway so the extra few pixels is less than what you'd need to account for in different screen heights between devices anyway.
- dathinab 5y agoCrashing not just the tab but freezing the whole browse and desktop UI on a non malicious well formed standard compatible pice of wasm... That (freezing the whole desktop) shouldn't even be possible even if safari has some bug. also no usable crash report or anything, no way to debug it etc. Sure that's just one maybe especially unlucky example. And my comment comes from a "additional cost safari imposes compared to e.g Firefox" point of view. So I'm counting long outstanding missing features as bug (except if missing for reasonable privacy concerns). Anyway as far as I can tell it's not as bad as IE in it's later days, but not that much better (wrt. cost it forces onto you).
- acdha 5y agoThat sounds like you may have an issue with the total amount of RAM used until it eventually failed but that's an edge case, not “a buggy mess”, and it's not like neither Chrome nor Firefox never crash. It's been at least half a decade since one of them has been notably more or less reliable than the others in my experience. Regarding crash logs, Safari uses the same system crash reporter as everything else. If you want to see those, look in the Console app or use “defaults write com.apple.CrashReporter DialogType prompt” or the Crash Reporter Prefs tool from the Additional Tools for Xcode package to make crashes trigger a prompt. > And my comment comes from a "additional cost safari imposes compared to e.g Firefox" point of view. Welcome to web development? Preferring one browser always means that you perceive other browsers as a cost because inevitably you will run into a bug or compatibility issue in the one(s) you test less frequently with. It's less common in all browsers these days but it's still pretty much a given that I'll find something unexpected in one of the 3 browsers I end up supporting.
- dmitriid 5y ago> Because for anything beyond basic website Safari is a buggy mess As a person who uses Safari as the main browser, I call bullshit.
- dathinab 5y agoYou use it sure, but du you know how much additional money was sirens just to work around problems with safari so that you don't notice a difference? How many web apps where cancelled or has to be fundamentally changed because safari? As a user you tend to not see it as safari is a high profile target and as such devs tend to make sure it works for it.
- PeterWhittaker 5y agoAs a dev who works on a Mac with Safari, I say none: my co’s app, which is quite complex, “just works” on Safari (what I use), Chrome (what the rest of the team uses), and Edge (what our bigger customers use). Is this because of React? Babel? Webpack? Maybe. All I know is that we happily code away on this complex beast, and everything. Just. Works. Everywhere.
- dmitriid 5y agoThe original statement was "anything beyond basic website Safari is a buggy mess", not "You use it sure, but du you know how much additional money was sirens just to work around problems". So. As a person who uses Safari as a primary browser, I call bullshit on the first statement. Additionally, as a person who does frontend for a living (21 years and counting, sometimes just frontend, sometimes fullstack), I call bullshit on the second statement.