Hacker News Reader

Comment by jagged-chisel | Hacker News Reader

"Safari team" doesn't necessarily have the same motivations as "App Store review team." Apple, as a company, needs to play nice with the web.

View on HN

lol. There's a reason Safari is called the new IE. So many features missing or buggy, not following standards.

Actually, most developers with an opinion on "new IE" says that Google Chrome is the new IE. There are cases of Firefox and Safari implementing features and Chrome-specific behavior that they won't endorse but are used by webistes (notably, unsurprisingly, Google's sites) [1, 2, 3]. Additionally, there are features that most have requested but are effectively being blocked by Google [3].

1: https://hacks.mozilla.org/2020/04/twitter-direct-message-cac...

2: If you have Firefox, browse about:compat to see Firefox's workarounds to websites which relies on Chrome-specific behavior.

3: Firefox implementing a wholesale change that maps "-webkit"-prefixed CSS properties (usually implemented by Chrome even, so Google should used "-blink" (the name of their HTML/CSS engine) since "-webkit" is for Safari's changes) to the standard and/or "-moz" equivalents for websites who are using it.

4: https://news.ycombinator.com/item?id=24959588

I think you’re really cherry picking here. Most developers that frequent “caniuse” most likely encounter lack if safari support above every other browser. Also have you seen webgl 2? What a joke from the webkit team. Yes webgpu is on the way but it’s been like a decade now.

I'm arguing on to the "Safari is the new IE" here (unless you're being pedantic on this and say Safari is Mac IE's replacement in 2003), not on what Safari actually lacks (which is many and it also bugs me to no end). There are more features that are actually being essentially "vetoed" by the Chrome team not implementing than by Safari's implementation being delayed (which is somehow around 5 years late).

Memory is hazy, but from what I've read most people that call Chrome the new IE is because it likes to incorporate non-standard aspects that other browsers don't (because they're not standard) which causes apps to lose functionality (or outright break) outside of Chrome.

I can kind of see it both ways. I appreciate that Chromium browsers may have little extras you can tap into as it'll make for neat features (Project Stream and I imagine later Stadia is because of that sort of thing), but it does break browser compatibility so it runs the risk of replicating that "works in IE" experience from way back when.

The IE I don't specifically miss though was needing to support older releases of it at work, personally. But I could see disliking the "what do you mean it doesn't work in Safari/Firefox/etc.?" discussions that may happen.

I do also appreciate the so-called experiments by the Chrome team, but my gripe is that they are implemented directly instead of hiding it in flags. Other people do want to comment on the specific implementation and probably change the API so that for example it is less destructive when there are new subfeatures in the specification. I personally hate how they handled the Polymer specification: thry are still using their draft instead of the standardized version in YouTube for example.

> I do also appreciate the so-called experiments by the Chrome team, but my gripe is that they are implemented directly instead of hiding it in flags

IIRC all of them start as flags, and there are tons of them available, most disabled by default. Most move up to stable and enabled by default after some time and testing and feedback though.

My experience with pretty complicated web development (interactive graphical tools built in webgl, synchronous behavior across hundreds of active clients) was that Safari was responsible for massively more bugs than any other browser we dealt with. IE11, Edge, Chrome, Firefox, Chromium, across OSs from a decade back through modern ones - all of those permutations combined.

Most commonly we'd see just weird things. Every other browser could handle "render this circle lightly colored, put some text inside it." But random versions of Safari would draw "solid black circle" with illegible text. Update the OS (the only way to update Safari) and the bug goes away. So we wrote work around after work around to make the same code that ran everywhere else run on Safari. And before you ask, all of our devs were on macs, but they weren't running random versions of the os where the bug was present. Or worse, the simulator in xcode wouldn't show the error but it would on a device. At one point over 90% of browser-specific bugs (and almost all customer-reported ones) were due to Safari or Safari mobile, despite making up less than 20% of our traffic.

Plus Apple keeps trying to stop people from running test infrastructure of every permutation of os and hardware. It's a nightmare and we just eventually put up a "safari may not work" warning on all our help docs.

For our team Safari was worse than ie6, because at least there everyone shared workarounds and knew how to handle the MS foolishness.

Okay, I forgot that side of IE to be honest, and we have encountered some weird bugs (real bugs, Safari was out-of-spec). It just didn't dawn on me that maybe what they meant on Safari is the new IE in terms of the workarounds (which were harder because there is no conditional comments unlike in IE). I have said that Chrome is the new IE because not of the bugs but more of the very Microsoft way of apparent EEE (but otherwise they tend to try to implement specs in a more tested way).

I should have worded it in a better way, and when someone said "X is the new IE" I should view the context of it. "Chrome is the new IE" is a very valid opinion, but not in all contexts, and so is "Safari is the new IE".

Reply on news.ycombinator.com