Safari is the new IE | Hacker News Reader

Safari is the new IE

fabiofranchino.com

79 pointsabusedmedia80 comments

Safari is not as bad as IE was compared to other browsers. However, calling it the 'new IE' is accurate if the definition is 'the browser with the worst support of new features and most bugs'. Here is a comparison http://html5test.com/compare/browser/safari-10.2/ios-10.3/ed...

What is especially frustrating for web devs is that all browsers on iOS are Safari underneath. We have to deal with those weird bugs and missing features the same painful way we dealt with IE, hence the title of the article. Saying that it's not as bad is not the point, IE 11 was also not as bad as IE6, we still had to deal with its quirks.

I don't know if the feature support chart paints the full picture. I think web developer's problem with Safari is more nuanced. It's not so much about whether a feature is implemented or not, as is about 'how' it's implemented.

As someone who did extensive browser dev from 2001 onward, that's exactly how it was with IE as well.

Safari doesn't compare with how IE was in its heydays.

In IE times, it was the majority browser and web shops were complaining that they were developing on less popular platforms (typically Firefox, and Netscape before it) and then ranting about how IE did things differently. Had they developed for IE all along with an aim for compatibility with FF, they'd have done things differently and, in many cases, compatibility wasn't that hard if you targeted lower common denominator - that is, a few earlier versions of each browser.

Sure, you'd miss out on the latest browser features, but that's not what web dev was about then. Rather, it was - depending on the shop - about making a site work on all platforms, or about making it work on IE and to hell with other platforms - with great despise from the rest of the community.

For some reason, things changed in recent years. Chrome is now dominant, and for whatever reason developing against its latest version has become the new normal, with web shops complaining that other browsers aren't keeping up fast enough, and no echo chamber to counter that discourse by pointing out that "hey, why aren't you targeting older browsers to begin with?" In case it needs reminding, iOS 7 is from 2013 and iOS 5 is still running on 2010 devices. That's only a few years ago. For comparison, we coped with IE6 for well over a decade, and XP (from 2001) only recently got deprecated.

True.

But in some ways current situation with Safari is worse. With IE you could at least say "download a proper browser if you want proper experience" (if you had the luxury of not being in servitude to your visitors). With Safari it's more like "get a proper phone", which is far from costless.

On the bright side, Apple is also hurting themselves with this approach. Missing a good browser will only speed up the decline of iOS.

Drastic title for an incredibly weak article that barely even bothers to make a case. So Safari has a bug. Why does that warrant immediately labelling it abandonware?

"Safari is the new IE" has been a complaint for many years. The author is providing supporting evidence.

Here is an article from 2015 http://www.businessinsider.com/apple-safari-web-browser-is-b...

As web developer I back this. I didn't hear it before but say that in the office because is the browser that often has weird css bugs. But to be fair Edge also requires some dedication and their update deployment is a nightmare. Their latest stable release was on April but because Windows rolling update strategy some users might be using a 2 year old Edge that doesn't support css variables.

As a HN reader i'm shocked by the number of downvotes my post recieved. Articles with the title Safari is the New IE routinely recieve dozens of upvotes.

Maybe some Apple devs downvoted my post :-)

If anything, these journalist are incredibly misinformed and shallowly invested in the issue (they do love clicks though). There's not a sentence about the power usage of browsers, performance on mobile browsers, the mass amount of APIs that have been added over the past few years, the evolution of JavaScript that is happening in tandem with new features that are being released, not even a sentence about how these APIs are extremely immature and still a WIP; all things that if taken in perspective will highlight the nuances of Safari's strategy of slow adoption.

Apple could make a browser that has all these features (where APIs are slow to being adopted on sites that users most use, low impact) or they could keep investing in iOS (where APIs are mass adopted from day one on apps used by hundreds of millions, high impact).

Why is it an either/or? They are the largest company by market cap in the world with more than $8B in profit last quarter. They should be able to handle both.

It is precisely an either/or because it has made $8B in profit last quarter. Apple as a massive company must make thousands, hundreds of thousands of tiny decisions to make it's business more profitable.

Investing in iOS attracts more customers and buy in to its products and services. Investing in Safari is not a key differentiator for their business and rivals will be able to easily implement the same features. Apple is smart not to play Google's game.

If Apple were to engage in this, the browser now becomes a selling point of the phone. Apple goes from iOS/iPhone company to Safari company. They give away their offering/unique selling point that no other company has, along with their massive advantages as a market leader.

Because their tech and business strategy is more developed in this space (browsers), Google can start acquiring customers at a lower cost than Apple without having to differentiate its core product more than the fact that it has more APIs/features. We see Google already does this to a degree, they market their products more on the feature set rather than the mission and brand.

Web technologies also inherently support Google's business strategy, the more APIs in the browser, the more data Google can collect on Apple's users, the more advanced targeting they can do to swipe away Apple's customers and collect intelligence on what Apple is up to. Do not be fooled, every time there is an API added to the browser, there are teams of people at Google ready to capitalize on it to help drive profits.

It would be a bad, bad bet for Apple to start all of sudden focusing its energies on Safari. As a SWE, it is completely understandable why Apple gives Safari little love, I'm okay with it.

IE was a totally different situation. With IE you started with no forward motion plus a flawed product with lots of deficiencies, and then evolved to a product with no coherent direction (i.e. IE 7-10).

Apple is very consistent with their products: upgrade or else. The only exception really is iTunes, and that's only because not supporting older versions would lead them afoul of merchantability laws for devices.

The Apple approach is not great, but at least it's comprehensible. Try certifying any product or configuration with Microsoft -- you have a minimum of 6 versions of Windows 10 alone, not to mention the various Windows 7, 8, 8.1 and Windows server browsers.

Safari is full of bugs and incompatibilities. Every time I develop something for the web it's always "works on Firefox, works on Chrome, works on IE/Edge and works on... Nope! Something broke on safari again."

And the thing that bugs me the most about it is that it's tied to the iOS version you have on mobile. Eventually you're prevented from upgrading it because your device doesn't support the new iOS version.

meh, desktop Safari is actually a very good browser. It is the fastest of all browsers in macos for a bunch of operations and their support for ES6 features beats all the other browsers (99% in https://kangax.github.io/compat-table/es6/ ).

Also one could argue that if Apple did not invest so much in WebKit then chrome would have had a harder time achieving its current usage and would probably be a very different browser than what it is today.

My 2cents

> their support for ES6 features beats all the other browsers

This is deceptive. They purposefully do not support critical features that other browsers do support. As a developer, if there's one browser that consistently gives me headaches, it is Safari.

https://developer.mozilla.org/en-US/docs/Web/API/FormData/ge...

As a user, I hate having to open Chrome[1] because of some "critical feature". Honestly, I sometimes wish you "developers" would find some other way to implement your application.

[1]: http://i.imgur.com/NcPu5IU.png

Honestly, there are so many libraries out there that abstract away issues like this. By building an app from scratch, custom rolling logic, you automatically opt-out of the good tools that negate all of the tiny differences in browsers. I've had my share of Safari issues, but over time, the amount of libraries I've co-opted into my dev strategy has helped me bypass the majority of browser issues.

I do not know enough about Safari to agree or disagree with your general point, but I find this part to be really irrelevant:

> Also one could argue that if Apple did not invest so much in WebKit then chrome would have had a harder time achieving its current usage and would probably be a very different browser than what it is today.

The same can be said on an even larger scale about microsoft and IE 5 and 6; that doesn't mean in anyway that years later they were not a pain stopping the web from going forward. In other word, I don't see how that has any impact on the conversation at end (neither for or against the point made).

EDIT: Not sure why the downvotes.

Apple invested a lot into Safari (and thus webkit which lead to chrome). Doesn't change in any way if Safari is or isn't holding the web back currently, which is why I say it's irrelevant to paren't countering argument.

And in fact, we have a previous examples since we lived the same scenario with Microsoft who invested a lot into IE 5/6 (and leading into DHTML, XMLHttpRequest, ...), which then definitely hold the web back.

This is, literally, the same argument. I don't see how I can be downvoted for stating that obvious fact unless you think that IE 6 didn't hold the web back after a while.

Chrome's renderer started as a fork of WebKit. Last time I checked nobody was able to fork any version of IE.

That's not my point.

Thread says "Safari is holding the web back". Parents answers "Safari created the tools that lead to big parts of the modern web".

My answer is: so did IE 5/6. That doesn't mean after a while and for a long time they weren't holding the web back, it's a side fact that has no relevance.

> their support for ES6 features beats all the other browsers

That's really grasping for straws. All modern browsers almost fully support ES6 features. Tail optimization are more controversial because they can actually lead to a performance decrease in some cases.

Far more important are things like custom elements and service workers on which Safari is lagging behind.

> Tail optimization are more controversial because they can actually lead to a performance decrease in some cases.

How exactly can the tail-call elimination optimization decrease performance?

Sounds more like an implementation problem.

Both TCO and PTC can decrease performance easily for a bunch of reasons. TC39 addressed this[0] when considering explicit tail call sites. Reasons vary from Windows ABI (Chakra) to something as simple as "now I have to figure out if this is really a PTC" -- and if your function has a PTC but that only gets invoked once, it's not hard to see how the extra analysis pressure doesn't weigh up to the elided stack frame. JS engines were already extremely optimized, it's not like you're taking a CS student's first lisp interpreter and adding TCO. (Fortunately, some of the litmus tests for whether you can apply PTC are encapsulated within strict mode, and the compiler stages definitely know that for free already.)

[0]: https://github.com/tc39/proposal-ptc-syntax#performance

I remain unconvinced that just because it's difficult for a couple of JavaScript implementations, that we're still not talking about an implementation problem.

How exactly does anyone think that v8 doing something badly, is proof that something cannot be done well?

I don't know which "anyone" you're referring to, but the argument I made about analysis pressure isn't implementation-specific, and neither are the concrete issues raised in both the TC39 notes I linked and elsewhere (they affect Chakra primarily, and *Monkey/V8 secondarily). The parts of a JS implementation (or really, any JIT) that decides to inline portions of code, attempt to detect loops and unroll them,... are already central to those implementations. I hope it's not difficult to see why a change that directly impacts that might have negative consequences elsewhere. Indeed, _because_ this is implicit and part of the spec, implementations can't take the simple multi-staged path they did before: they _have to_ do the PTC dance. I've heard no argument why the PTC mode should be intrinsically faster than the non-PTC mode (yes; you elide a stack frame at the cost of a whole-function analysis pass -- heuristically, "stack frame" isn't the expensive one of the two). This is why STC was proposed: it allows an impl to decide at _one_ location how to handle a function, in an obvious-to-the-parser way. No other code paths are affected. To contrast with PTC: even a compiler that knows with epistemological certainty that a particular call will happen only once or even never, _still has to do the PTC dance_.

However, you're asking me to prove a negative. I've given arguments, which apparently you find unconvincing. The people you are disagreeing with (not I) are responsible about 85% of the JavaScript engines on the Internet, an incredibly competitive space with billions in funding. I submit that they are probably neither incompetent nor lazy. (Evidence for "not lazy": the V8 team implemented it and turned it off.) If you are convinced that it's a (presumably fixable) implementation problem, I'm sure they'd love a patch or at least something more actionable than your insistence that they're doing it wrong.

> I hope it's not difficult to see why a change that directly impacts that might have negative consequences elsewhere.

Sure, but at the risk of repeating myself: That sounds like an implementation problem.

> I've heard no argument why the PTC mode should be intrinsically faster than the non-PTC mode

There's a simple one: Hitting the stack less means you hit less memory.

> The people you are disagreeing with (not I) are responsible about 85% of the JavaScript engines on the Internet, an incredibly competitive space with billions in funding. ... I'm sure they'd love a patch

Happy to oblige. I'll implement TCO on V8 for a billion dollars in a way that beats these benchmarks.

> However, you're asking me to prove a negative.

And you're making straw men instead: At the beginning of your response, it's not even clear you read my complaint, but at the end, it's quite clear.

The simple answer would probably have been "yes, it's about an implementation, but it remains unknown where else we can go", but instead you doubled down...

I'll repeat myself: it is not an implementation problem that a compliant implementation needs to do necessarily more work. You say:

> there's a simple one: Hitting the stack less means you hit less memory.

But I explicitly acknowledge this in my comment:

> (yes; you elide a stack frame at the cost of a whole-function analysis pass -- heuristically, "stack frame" isn't the expensive one of the two)

(Completely ignoring that there are already plenty of optimizations where a compliant interpreter may avoid the stack frame already anyway, so it's not even true that PTC must be faster for that reason.)

You keep picking on V8, but remember that there is so far only 1 major JS implementation that managed to do this without impact. It would seem that it's more probable that it's the other way around: it's an implementation detail that JSC had it easy.

> And you're making straw men instead: At the beginning of your response, it's not even clear you read my complaint, but at the end, it's quite clear.

I'd be happy to address this point, but I genuinely don't know which straw man I've supposedly built.

> > > I've heard no argument why the PTC mode should be intrinsically faster than the non-PTC mode

> > there's a simple one: Hitting the stack less means you hit less memory.

> But I explicitly acknowledge this in my comment!

Not really sure what your point is. If you agree that's an argument as to why tail-call elimination should be intrinsically faster, I'm not sure why you'd say it isn't.

I can't shake this feeling you think you're having a very different argument than I am.

> remember that there is so far only 1 major JS implementation that managed to do this without impact.

Which for some reason you think means this isn't an implementation issue.

> But I explicitly acknowledge this in my comment!

I did not put an exclamation mark there, but a colon, pointing out the specific reason why PTC can end up slower.

It's not really important if the community is ambivalent on using it. Who here opts for using custom elements (and the extra work) over a library like Vue, React or Angular?

Is there even a consideration on how these new features become just another tool to spy on people?

To me it is far more important that Apple take its time letting these APIs mature and being reviewed for security and performance than blindly implementing anything that Google demands.

I agree. Not only is it the fastest, it's also the most reliable. I have Firefox thrashing about more often than not, and I refuse to use Chrome or its google infected variants.

Brave seems promising but doesn't yet have extensions.

Anecdotal, but this doesn't match my own experience. When developing for the web I usually develop on Safari. More specifically for a first-gen iPad running Safari Mobile. And then, for whatever reasons, it almost always works on other browsers pretty much as is - the main exceptions being very old devices running ancient versions of IE.

(Admittedly I aim to make sites that degrade well and work without JS, so that might be an important caveat in an age of Angular and what have you. Perhaps I'm stuck in y2k and still think a site should render in 0.2s on all but 10+ year old browsers. [Shrugs])

That is because Safari's feature support is the lowest common denominator of the other browsers. By developing on it you are ensuring you don't use features every other browser but Safari supports.

Unless of course you're referring to ES6 support, in which case it has the best support.

You're probably right, I only have to deal with CSS inconsistencies since JS tooling largely solves that problem for me these days. Unfortunately tools like CSS prefixer can't solve for everything.

Totally.

Anecdotally, though, a) firefox diverges further from chrome than safari does and b) the types of CSS flaws don't wven approach the black magic of designing for IE6.

> By developing on it you are ensuring you don't use features every other browser but

Sure. But isn't developing against the least common denominator precisely what web development has been all about in the past 20 years or so?

Edit: Just to expand on that...

Then, there was a laundry list of web shops that were targeting IE first because "more advanced" and complaining about other browsers because they "suck". And it looked wrong to just about everyone else who targeted other browsers because Microsoft.

Now, we've a laundry list of web shops that are targeting Chrome first because "more advanced" and complaining about other browsers because they "suck". And for some reason those browsers should all catch-up and fast because Google?

amen

If Safari would run on Windows and Linux maybe everybody would develop with it and take advantage of this least common denominator thing (but still wish it would get on par with the other browsers.) Unfortunately it is not.

This app store first / web second policy served well Apple bottom line. Too bad web developers are paying for it with extra work and this is the point of the post.

A few bugs don't really make Safari the new IE. There will always be bugs and differences with rendering engines, that is the price of competition. However IE was a completely different class of shit sandwich that inflicted horror onto all devs who had to work with it.

Agreed.

Saying Safari is the new IE is like saying Trump is the new Hitler.

Not even close.

Just no.

I suspect all the people disagreeing with this either

A) Are not web developers

B) Use macs as their primary development platform

C) Have never had a user using iOS 7 complain that your website is entirely broken and not be able to replicate or debug it because every mac in your office is using OSX 10.10 and Apple have jigged it so you can't run an emulator for iOS <9 and everything on the computer (Except iTunes) refuses to believe the iOS 7 device exists when you finally persuade the customer to bring it in to you.

(OTOH at least it has a vague attempt at developer tools - with Samsung Internet you're on your own matey)

Here’s an irritating bug that popped on Safari 10.1 (iOS 10.3) that strains the use of CSS variables: You can’t just use a variable to declare a box-shadow’s color opacity, you need an intermediate variable.

Demo: https://codepen.io/anon/pen/YxmQdj

Apple versus Google keeping devices up-to-date is a reversed problem on the web: iOS’s web browser updates only with new OS releases, and they don’t come to all devices. iPhones 5 (and iPads 4) will be stuck with that bug forever. On Android you can use Chrome’s latest version if you’re on ≥ 4.1 and Firefox’s if you’re on 4.0. 99% of Android users are.

Even if you’re very aggressive on focusing only on recent browsers for your website, you need to handle Safari bugs for years.

Safari is far from being as bad as IE ≤ 8, but it sure is the most annoying browser when you’re targeting only recent ones.

I am as weary with Chrome, but for a different reason.

While Safari lags, Chrome seems to introduce more and more Chrome-isms onto the web.

Web fragmentation, unfortunately is built in to our community, but my hope is that we won't ever see an era of fragmentation like the HTML5 era. I'm okay with Chrome-isms, as long as they're not too radical.

I think both you and me would agree that Google aims to make them radical.

Just today I changed my Chrome's search engine to DuckDuckGo. Of course, I get periodically politely asked if I am sure that this is my correct search engine setting. <facepalms> As an Eastern European, I'd shut them down the same instant on this basis alone, no questions asked. Shame that we don't run the world. :D

An off-topic for sure but the gist is: Google wants to entangle you in their web. They are just much more subtle compared to Microsoft and thus almost nobody notices. So, less Chrome-isms, please.

This is only going to get worse as newer iOS versions drop support for older hardware, especially iPads. It is doubly concerning since Apple bans browsers from the app store unless they just use the iOS-provided webkit engine for, so these devices are stuck with legacy Mobile Safari versions for the end of time.

As more and more modern iDevices become legacy while still being perhaps "powerful enough", I think we will start to see a persistent population of web users similar to the clan of IE6 users that took forever to shake off.

Oh right, of course few years old android phones can still be updated officially (-> by the average user, too), being way better this way.

> This is only going to get worse as newer iOS versions drop support for older hardware, especially iPads.

I don't think that it's fair to say it's going to get worse, in the sense that it's as bad as it's going to get right now.

And it's not too bad right now.

Apple is quite good about support for older devices. For example, iOS 11 supports 4-year-old devices, and that's even somewhat of a special case since it's dropping 32-bit support.

People use iOS devices older than 4 years old, but it's not a huge burden to keep a handful iOS 10 and iOS 9 devices around for development and testing. Certainly, it's a wonderland compared to testing on Android.

The first example seems to work fine in iOS 11, but congrats on the clickbait title.

Ditto - the bug appears to have been fixed in Safari 11.

To be fair, iOS 11 is only a couple of weeks from being adopted from hundreds millions of people. Our community isn't as proactive in testing against unreleased software as the native iOS community. :disappointed_face:

Why not simply just div { height: 100vh } though? No overflow rules on the body needed

Luckily, it doesn't have near the numbers IE 6 ever had and it's not something a company would require their employees to use for work applications long after EOL, that was the real pain of IE.

It works the other way arround too. 2 years ago part of a site in production stoped working just because how chrome loaded some js libs at loading time. Ff,safary heck even ie worked ok but chrome.

I fixed his bug by changing the height on panel from 100% to 100vh. No need for extra markup like his fix plus as someone else mention iOS 11 doesn't have this problem and that most likely means the next desktop version will that fix also.

This is not a fix, on mobile 100vh and 100% are different due to the auto-hiding address bar.

IE still holds the crown here. Lots of "enterprise" still use IE (not Edge), and IE have not got that much updates lately. That said I've had more issues with Safari then IE.

This article barely makes a point for itself. Why is this on HN?

Wasn't this "bug" originally meant to reproduce IE behavior for compatibility purposes with IE?

Safari won't be the new IE until it has an IT department enforceable compatibility mode which breaks everything forever.

I don't know about the challenges for a web dev. But as a MacOS user I love Safari. It is very fast, it does not drain my battery and it gives me an increadibly streamlimed experience (bookmarks sync across all my Apple devices, I can continue a session that I started on my iOS device on my Mac).

Chrome kills my battery. Firefox is way to slow (startup time).

Durn whippersnappers, when I started developing for the web Apple didn't even have a web browser. Personally, I dev on a Mac and use and test with Safari, Firefox, and Chrome and to be fair they're all great.

I can deal with little CSS issues but what Safari really needs is Service Worker support.

The great things about CSS is that there are many ways to achieve the same result.

You just found one incompatible way of doing it.

Safari may be broken but it's not as broken as ie6 was back in the day.

Safari isn't the new IE for one big reason: it's the only rendering engine on iOS, which means if you want to support mobile web, you have to support it, and that won't change anytime soon.

It sounds like it is the new IE, except you can't even install another browser.

Wasn't this exactly one of the items Microsoft got in trouble for with the European antitrust authorities?

iOS doesn't have anywhere near the market share that Microsoft had/has on the desktop

Not just the EU regulators.

The US antitrust lawsuit was also about using their desktop OS marketshare, and the bundling of IE with said OS, to drive companies towards using IIS at the server end.

Damn it, Microsoft basically coined the expression "Embrace, Extended, Extinguish". Meaning that they embrace some standard, then extend it with MS specific behavior, then extinguish the original standard via creeping incompatibilities.

Doing something like that is illegal if you have a monopoly. Apple doesn't (or even majority market share).

Can't you download other browsers in iOS? In any event, it may not be relevant if most iOS users don't bother.

Don't they have to use the iOS rendering engine?

Yes.

They're all Safari underneath.

Thanks for replying! (I don't own an iOS device, so please bear this in mind before further dowloading, dear fellow HNers.) If all browsers render the same way, what is the point of downloading Chrome or Firefox, just syncing? Thanks again.

Pretty much. Different UI and features but all the same rendering engine.

I know "all the money is on iOS" is verifiable for apps as a counter to Android's far greater market share, but is that true for the web? iOS might just be a little blip in both usage and money on the web.

Reply on news.ycombinator.com