4 ms·
That's already the case, though. The battery life difference using Safari versus Firefox/Chrome is staggering. Sure, you don't have an option to buy a FF/Chrome
by CamJN 5y ago
That's already the case, though. The battery life difference using Safari versus Firefox/Chrome is staggering. Sure, you don't have an option to buy a FF/Chrome mac atm, but you've definitely bought one where safari is the only decently efficient browser.
- vel0city 5y agoIs that really due to the hardware or because of the overall behavior of the two browsers? Isn't Safari better battery-wise than Chrome even on Intel Macs? IIRC Edge has better efficiency in Windows than Chrome, so its not surprising me Chrome is less efficient. Its a bloated shadow of its original self.
- FireBeyond 5y agomacOS has a bunch of energy management and performance-related "private" APIs and libraries that Safari is allowed to call, but Chrome is not.
- JohnBooty 5y agoCan you point me to information about this? The Google results are a bit polluted with (hilariously enough) articles about Google's recent restriction of Chrome's private APIs. I've been having trouble figuring out exactly which private bits and bobs Webkit might be taking advantage of on MacOS.
- dev_tty01 5y agoThat's the second time you have made that assertion in this discussion. Can you be more specific please? I have not seen any evidence of that, but I am very interested.
- edgyquant 5y agoI would also like to see some documentation on these private apis. Sounds fascinating I wonder what they’re doing differently? Are they exposing the same kind of abstractions but the public api is purposely slower? Why would they not want all apps to use less battery life?
- JohnBooty 5y agoYeah, that's my question. Other commenters are suggesting that Apple's intent is to keep Chrome and other third-party apps from matching Safari's energy efficiency. But as you say, I'm not sure that makes strategic sense. If that is true, Apple is essentially crippling most Mac use cases just to benefit Safari. That really would not seem to be in Apple's best interests. I am a developer, but not a iOS/MacOS developer. So I have followed this sort of thing only very loosely over the years. But whenever I have heard about grumblings about private Apple-only APIs being used by blessed first-party Apple apps on iOS, it seems to me that the explanation was always that the private APIs either: 1. posed some sort of security issue 2. were simply not yet stable enough to expose to third-party apps As every developer knows, publicly exposing any API represents a maintenance burden: you're committing to support that API and keep it stable for X number of years. In general you see this kind of pattern a lot: a platform developer dogfoods APIs internally for some period of time before they're stable enough to expose publicly.