Hacker News Reader

Comment by irrational | Hacker News Reader

Um, no. Just look at sites like caniuse.com and see how much farther ahead Chrome and Firefox are than Safari iOS. Safari iOS has become this generations IE 6. It is seriously holding back the web. And worst of all it really only gets one update a year!

View on HN

And Chrome is reportedly more of a battery hog on macOS[1][2] and Windows[3]. So there you go: different priorities.

[1] http://www.techrepublic.com/article/browser-wars-is-chrome-o...

[2] http://www.theverge.com/2015/4/10/8381447/chrome-macbook-bat...

[3] https://www.extremetech.com/computing/230583-microsoft-claim...

[1] is not good article, no test, no numbers. [2] neither is this. no info about the test other than the results. just knowing that chrome rendered flash by default at the time of this article, i know its irrelevant. [3] claims 70%...

False. From [2]: "The native Safari made the new Retina machine look good: 13 hours and 18 minutes. Google’s Chrome, on the other hand, forced the laptop to tap out at 9 hours and 45 minutes."

Anecdotally, Chrome uses dramatically more memory and CPU than Safari for me (note: I typically have 100+ tabs open at once), and gives me somewhere between half and two thirds the battery life, for the same type of use. I have flash turned off for both and most ads blocked via /etc/hosts, so there shouldn’t be anything especially unfair in the results.

Google web apps (gmail, google maps, etc.) seem to be a particular offender.

It's not holding back the web, settle down! It can still render websites perfectly fine and will continue to do so.

Seriously, what horse are you backing where iOS Safari is compared to IE6?!? What oh-so important feature you simply must-have, that would even begin to signify that iOS Safari is "holding back the web"?

The web dev world is absolutely mental at the moment...

There are a lot of quirks with Safari that are similar to the way IE6 eventually stopped following standards.

That fact that localstorage doesnt work in private mode is 1 example.

Where is the W3C standard for private browsing mode?

There isn't one, that's why it should behave like a normal browser (from the web dev perspective) even while in private mode.

That doesn't follow. If it literally behaved like a normal browser that would break the privacy guarantee of private mode. In fact you could argue that browsers that implement localStorage in private mode are the ones who are not standards compliant.

From the Web Storage spec: "[localStorage] is designed for storage that spans multiple windows, and lasts beyond the current session."[1] Thus if a browser is discarding localStorage prior to the end of the current session, it's explicitly against the spec.

This is more than academic. If apps aren't written to explicitly use ephemeral storage then they may not function as expected in private mode, like, say, unexpectedly causing data loss.

[1] https://www.w3.org/TR/webstorage/

I can see why that'd make someone cross, but it seems in line with how localstorage works + how browsers define their "private browsing" features. On Chrome, for example, when in Incognito mode, you can't undo-close-tab a tab after closing it. Effectively, every tab you open in these "private browsing" modes will sooner-or-later "self-destruct", including all its cookies, localstorage, etc. (iOS?) Safari just chooses "sooner" rather than "later."

If your site relies on using localstorage during the lifecycle of an individual page, you can always replace it with an in-memory mock polyfill if you notice it's missing. There's probably an NPM package for that.

The point of standards for browsers is that you shouldn't need a polyfill just to support a feature (localStorage) in one browser. Ideally, it would just destroy its contents after your private browsing session is done, just like the way (I believe) all browsers treat cookies in private browsing mode.

Sure, what I'm saying is more that localStorage doesn't have the standards equivalent of an SLA guaranteeing it'll work for the "within the lifecycle of one page" use-case. Apple, I think, are just being opinionated (and pushy) here: they think the right way to tell a web-app "your localStorage won't save" is to undefine the API, making trying to write to or read from localStorage raise an exception, so that your app is then forced to decide whether it can go on without localStorage (by handling the exception, or by using a polyfill which does the same) or that it can't (by just telling the user "don't use this page in Private Browsing mode, doofus!" and stalling out.)

It's certainly not the approach everyone would be happy with, but it allows developers much more flexibility than the contrary case, where private browsing is a silent effect that might make apps do very stupid things (like, say, downloading the same huge asset bundle into localStorage over and over.)

> downloading the same huge asset bundle into localStorage

This would happen anyway no matter what storage or cache is used since all data is cleared after private browsing session is over.

Breaking localstorage (with an over-quota error) is not the way to deal with this. Polyfills are just more crap in complexity and downloaded bytes to compensate for a browser's issues.

It would be much better to have a navigator.isPrivate flag enabled so apps can check the environment accurately, not guess based on whether certain APIs work or not. It's not about SLAs but supporting standards. Deleting client-side data is all that private browsing needs to do.

That's not sooner vs later. That's breaking functionality.

Private mode means deleting the data, not disabling the functionality. Chrome and the rest handle it correctly.

Web components, Progressive Web Apps, Fetch, etc.

I'd pay top $$$ if someone could show me how to let a mobile Safari user record audio on their microphone and submit it. iOS doesn't permit this in any way, whether it be with getUserMedia or media capture forms. The only way to do audio recording is to build an iOS app just so I can get this one simple feature which is exactly what they want. Repeat this story for a dozen other features as well.

Apple's total opaqueness on what their plans are for the future functionality of their browser certainly doesn't help either.

This is a feature I would really like to have.

I tried to circumvent it a while ago when I was playing with the Web Audio API by allowing an iOS user to "upload" a video, from which I would then extract the audio using decodeAudioData. Unfortunately it returned an error on callback in iOS.

Perhaps it could still work by processing said video on the server and sending back the audio, but keeping everything client-side was my requirement.

Web pages that can access the microphone sounds like an absolutely insane idea to me, but then like I said, web dev is absolutely mental at the moment...

get off my lawn etc.

So Safari doesn't hold the web back like IE6, because the ways it's hold the web back doesn't count because you don't want those features.

Not buying it.

I'm suggesting that the web is fine - its stupid nonsense like javascript access to the microphone that gives the illusion that the web is moving forward, and that some people are freaking out proclaiming the end of days because some ridiculous feature hasn't been implemented.

How is it ridiculous just because it's a feature you don't use?

There are plenty of uses for newer standards, that's why they're created, but it only works if the browsers carry their weight and implement them consistently. Safari doesnt, and is thus holding back the progress, just like IE6+ did.

Web development relies on browsers. There is nothing mental about this.

Service workers are another example of a feature that is missing in Safari. And an important one for offline support.

Yeah, can't wait for web apps to drain my battery when I'm not using them too.

Web should be just HTML/CSS, no JavaScript at all, so no need for service workers.

Service Worker!!!!

Its absence is a crippling limitation.

+1. This is the main problem right now, especially since web workers are a workaround for anything blocking the main thread, like some local storage.

>Safari iOS has become this generations IE 6

Yeah, the kind of "IE6" that beat Chrome and Firefox last year to be the first to fully support ES6 for example.

https://twitter.com/webkit/status/728643624464883712

Check http://caniuse.com/#compare=chrome+59,safari+TP yourself, and you see the differences in scores is mostly because they give 1 point to every API, however non-important it is. Meanwhile, Chrome supports some good ones (File Storage, WebRTC, Pointer Events etc), but Safari supports some good ones that Chrome doesn't too: MathML, HTTP Live Streaming, Video and Audio Tracks, SVG fonts. But Chrome also tries to push various proposals of (mainly) theirs, down everyone's throats.

MathML has been dead for years. HTTP Live Streaming (HLS) is not part of the spec and never will be. What is part of the spec is MPEG-DASH. But, File Storage, WebRTC, and Pointer Events? Those are actually useful for modern web development.

"But Chrome also tries to push various proposals of (mainly) theirs, down everyone's throats."

Never experienced that with chrome, but I developed a kind of hate towards mozilla, for forcing IndexedDB and IndexedDB ONLY and refusing for anything else and therefore killing FileAPI and WebSQL

It is possible for one's utility function on web browsers to weight speed and power consumption more than standards compliance.

WebRTC and many other major features are still missing from Webkit on iOS, whereas in Chrome & Firefox I can have a full WebRTC client on mobile.

That's consistent with the parent comment. They're working on WebRTC.[1] Possibly they're making it power efficient first and then shipping, as opposed to shipping and then making it efficient.

[1] https://webkit.org/status/#specification-webrtc

Not sure if you're serious about 1 update per year...iOS has ~4 major releases per year. (9.0, 9.1, 9.2, 9.3). Safari receives updates in each one. iOS 10.3, which is in beta, comes with tons of Safari changes.

Safari has so much better HLS video streaming support on iOS then chrome. Chrome has caught up a little bit but the documentation still sucks.

Uh, duh? That's because HLS is not a web standard and never will be so nobody else is going to bother building it into their browsers. The standard (ISO/IEC 23009-1:2012) way to do adaptive bitrate streaming is MPEG-DASH.

Microsoft Edge and Chrome on Android both support HTTP Live Streaming.

Reply on news.ycombinator.com