Hacker News Reader

  > in my experience, it's the fastest browser on OS X by a pretty
  > wide margin. Chrome is so bloated and full of garbage at this
  > point that when I have it open, I usually have at least one tab
  > sitting at 100% CPU (and this is with FlashBlock enabled). Safari
  > also manages to feel faster while using significantly less power
  > -- I suspect Apple has done some optimizations through Grand
  > Central on this front.

This. As a developer... I sympathize with people who like developing on the desktop with Chrome and for Chrome, but as a user, I prefer the browser that doesn't spin up the fans on my MacBook Air.

As we adulate Tesla for their accomplishments with battery technology, we often point out that battery life is a software problem, and that it involves a specific set of engineering tradeoffs. Apple is simply making those tradeoffs. And it has to.

Google make a browser that runs on everything. If one platform is slower than another, or has less battery life than another, blame the platform vendor. Google doesn't care. But Apple sells hardware. If a MacBook gets so hot it burns your thighs, they lose sales. If the battery life on an iPad is terrible, they lose sales.

Safari gives their users a legitimate way to enjoy web browsing on a cool-running system with long battery life. That sells.

It also has better performance with retina, scrolling, less jank, and other user-experience/satisfaction related qualities.

It's dev tools aren't adequate for my use, but for being a user of other sites, it has been wholly sufficient.

Apple's improving the dev tools in El Capitan: https://developer.apple.com/videos/wwdc/2015/?id=505

> I sympathize with people who like developing on the desktop with Chrome and for Chrome, but as a user, I prefer the browser that doesn't spin up the fans on my MacBook Air

For me it's just video perf, but the worst part is that it's Google own web services that are spinning up the fans, and their video services work 10x better in Safari!

I have a shiny new 15" Retina MBP, which heats up like a stove if I use Chrome to open a video Hangout or watch YouTube. So for work meetings I've made a habit of having my calendar always open in Safari so when I click the video link, I get the Hangout in Safari as well.

And Safari manages to not set my computer on fire, amazing!

> IE was so bad because Microsoft tried to go off and create its own standards

That's a common misconception, but what actually happened was that MS implemented draft CSS specs which ended up being a bit different from the final standard. At the time they were extremely eager to pack new stuff in IE (including a state-of-the-art XML/XSL processor!), so they rushed in a lot of stuff before other players had agreed how this stuff should really behave.

IE was then basically abandoned. MS just refused to fix their engine to adhere to newer standards. By the time this became to be seen as a problem, Netscape was dead, IE was dominant, and they were busy trying to plug the ActiveX security sieve, rebuilding on .Net and finding an alternative to Flash.

In this sense, Apple have done exactly the same with Safari: they poured resources into it while they were competing on the desktop. Now they only care about iDevices, where they have no competition at the browser level, the priority is battery time, and stability (aka rot) is preferable over innovation. Look at Safari for Windows: they built it only to support iTunes, and basically dropped it when iTunes on Windows became fundamentally unnecessary.

They went ahead when they wanted to be in the game, now they own the game so their incentives are different. Exactly what Microsoft did back in the days.

> Safari on mobile is a bit of a different story; yes it has problems

that's a understatement., working on ios safari has been a travesty: it steals a good 20% of view area and 25% of clickable area, it makes a mess with pages trying to be responsive by misreporting the viewport area, it has loads of bugs with resizing and orientation change events and just dies if one script in any page becomes unresponsive

Right, but the problems Safari has on mobile aren't going to be fixed by implementing IndexedDB; and honestly the WebSQL vs IndexedDB argument is irrelevant to most people: 95% of web developers will just use a framework that abstracts the differences. And I wouldn't claim that mobile Chrome is a whole lot better on this front, even (or especially) on Android. The limitations of mobile CPUs combined with higher user expectations on responsiveness mean you have to pull the plug on a runaway process a lot faster than on a PC, and neither Apple nor Google is immune to this.

Chrome on Android works great and experiences literally zero of the issues mentioned for Safari.

Chrome for Android is an app, not a system component, and does not require Android point releases to be updated. It is frequently updated on a regular schedule by Google and pushed out to devices.

Using sources like www.caniuse.com, I frequently find that Safari/iOS does not support a feature that is supported on Android browsers and desktop browsers.

When designing responsive in 2015, I limit myself to Safari/iOS, the worst browser I build for, then quickly and effortlessly make sure all other browsers work.

That's my reality, Safari/iOS is the worst platform to develop for for me. I can't even remember the last time Chrome/Android had any issues that weren't also present on Chrome/Firefox/Desktop. Safari iOS though, even with CSS Resets, even with custom CSS, always finds a way to be non-standard with text size, or font weight with bold, or some "feature" that breaks Safari and nothing else.

https://developer.android.com/about/dashboards/index.html?ut...

What about the other 50% of Android users that don't have Chrome or Chrome WebView? I've been working mobile for a few years now and would love to drop anything before KitKat, but that's not something feasible given market share.

In practice, pre 4.4 embedded WebViews have worse support for standards than Mobile Safari. Chrome for Android was in part a system component in order to replace 4.4's embedded WebView, only until 5.0+ did it become decoupled.[1]

Google's evergreen approach reduces fragmentation of a core API and it's been a godsend. I know in the future, Safari will be left alone as a pain point. Just don't misrepresent the present situation, where older Android has worse standards support than Mobile Safari and can't even be debugged in devtools.

[1] https://developer.chrome.com/multidevice/webview/overview

> "pre 4.4 embedded WebViews have worse support for standards than Mobile Safari"

My old Windows XP box also has worse support for standards than Mobile Safari.

OK, so XP also doesn't have market share. But it's hard to blame older versions of Android for not supporting standards that didn't exist when they were implemented, just because people continue to buy low-end devices running those old versions.

Right, but at the same time you can't say that Safari is the only thing holding mobile web development back. Because dropping users on "old" versions of Android isn't an option from a business standpoint, Safari isn't the only thing holding people back. And 4.4 really isn't that old; so there are tons of users on older devices.

The Android browser was a sore joke and didn't support years old standards. It was embarrassing for Google, the top web company, to release a browser that was so impaired and so slow at adopting standards, years after Mobile Safari. With Chrome, google has reverted the situation and they are now bleeding edge.

http://caniuse.com/usage-table

Android Chrome has about 13.3% global usage, and all versions of Android Browser have about 6.5%. If we do not count versions before 4.4, then Android Browser has about 2.5%.

Also worth pointing out that Chrome for Android is over the 1 billion mark (1,000,000,000 - 5,000,000,000)

this. and don't get me started with the whole mess that happens if you dare to use a css transform on a positioned element, which works kind of differently according to every browser already, but is completely different than every other on safari/ios

Have fun abstracting the difference between a relational database and a NoSQL database! That will only work for trivial applications.

There are already abstractions that work over both and work for nontrivial apps, including, IIRC, an indexedDB polyfill using WebSQL.

Going the other way might be harder, but every rdbms is, itself, an abstraction over a nonrelational storage system of some kind, so it's clearly not impossible.

The IndexedDB polyfills over WebSQL are horribly slow and buggy. You'd be hard pressed to do something non-trivial with them. Believe me, I've tried. Still better than using Safari's IndexedDB though!

Nothing you've said here really addresses the problem discussed and really you're looking at this from the perspective of the consumer and not the developer.

> Safari is nowhere near that bad [as IE was in the past]

Doesn't address the problems developers are having.

> I have yet to run across a page that works in Chrome that doesn't work in Safari.

Try any webpage that uses WebRTC, and there's a growing number of these. But really it's because people are doing what they did with IE6 which is here is code that works everywhere, and here is some code to make it work on Safari so the user is none the wiser. The problem is still there.

> Safary, by comparison ... <insert swoon>

This has nothing to do with the post. Great you like Safari, but the problem still exists. Where's the WebRTC support? The Audio API? Right.

As to the original article, I prefer a 4th step not mentioned, just ignore Safari. Apple has a huge iOS userbase, sure, but as the HTML5 disparity between Safari and other browsers increase it's becoming increasingly not worth considering and really do iOS users even expect the HTML5 features that don't work in Safari? They'd probably prefer a native app for that.

Desktop users can use Chrome or Firefox when a site doesn't work in desktop Safari, and if that makes them mad, good. Maybe Apple will fix their shit then.

Edit:

Regarding downvotes: I know engineers are ignoring Safari. I ignore Safari, and other people I know ignore Safari. A convenient sample sure, but as this article points out developers aren't happy. Downvotes or no. Deal with it.

> Nothing you've said here really addresses the problem discussed and really you're looking at this from the perspective of the consumer and not the developer.

That's entirely the point: developers and users have different needs. But the developers will follow the users to whatever browser the users feel is best. Apple's priorities are on improving battery life, page responsiveness, etc. If users value Apple's browser development model that prioritizes user-facing features over developer features, then the developers will simply follow the users. If you want to build a product around features that a major browser doesn't support, go ahead.

To use the dreaded car analogy, you don't build a car to be easy to work on just to make the mechanics happy. You build a car that consumers want to buy, and it's the mechanic's job to figure out how to work on it.

> then the developers will simply follow the users.

That didn't happen with IE6. I think the web as platform is bigger than Apple as big as it may be. It's amazing to me that you're OK with a single company holding back the entire platform because of a single device. People use the web with machines that don't even have batteries.

Really to a developer who cares about the open web and standards, just throwing the whole concept of the web out of the window for the sake of Apple's priorities is so, so bad and it will never happen. At least that's my hope and prediction. The open web as a platform will guide my behavior with regards to how I engineer applications that run in the browser, whether Safari is on board or not.

> That didn't happen with IE6

Yes it did...but anyway, the detail is irrelevant; it's the point you're refusing to acknowledge:

A developer, building a product, is obsessed with growth metrics, OR, a slave to the pedantic demands of a client they're working for.

Either way, those demands require that a site be available to as many people as justifiably possible. The questions you have to ask are:

1) Is the the $ value of a customer using IE6 worth the time taken to make the site work in it? (No, almost certainly not)

2) In IE8? (Hopefully not, but you know, there are still a lot of these guys, and it's almost always a demand in the .gov space...)

3) In Safari? Yes. There are tonnes of these guys, especially on mobile where they don't have a choice, and no matter what fancy javascript 0-day API you're in love with, you can work around it without any significant effort.

The point:

Is safari holding things back? Yes.

Is it OK? Not really. It sucks.

Can you ignore safari and pretend it doesn't exist, and lose those customers? No. No you can't.

We're webdevs, sucking it up is what we're good at. We've had years of practice.

Suck it up.

The path forward, I think we'll find in the long run is going to be less native apis, more WebAssembly-style low level polyfills to implement new 'universal' features that run on all js runtimes.

> Can you ignore safari and pretend it doesn't exist, and lose those customers? No. No you can't.

Actually we can, and where I work we do. Never has anyone complained about it. SO everything is just fine. So I don't need to "Suck it up".

Maybe you can, because either you work for yourself, or you work for some who doesn't care... but you're mistaken if you think you fall in the majority in that.

> That didn't happen with IE6.

Yes it did. That's the entire reason IE6 was such a headache: IE6 was by far the worst browser platform out there, but everything in the corporate world was written with IE6 in mind. This made it a nightmare to support these sites -- because they didn't work in Firefox or Chrome. So when IE6 was finally deprecated, it was a mad scramble to try to patch internal tools (or hack an unsupported install of IE6) so your HR person could access payroll.

Rather then just downvote you, let me say that I (20+ years webdev) and my colleagues use our audience to determine what browsers we support, not our personal preferences. My job is to provide visitors to my clients websites with the best possible experience, not judge them on their technical choices.On the site I support, hundreds of thousands visits a year are from Safari users. Based on your comment ("deal with it"), you pretty clearly are not the kind of web developer I would ever hire. Or your engineer friends.

Yeah, the choice of which browsers to support is a business requirement informed by marketing, not a technical decision. Business requirements should inform the selection of technology, not the other way around. When you let technical requirements drive your business requirements, you end up with a product that is a poor fit to user's needs. It's hard enough to get users for a new product without engineering imposing arbitrary technical limitations.

Without having practically any serious web dev experience (just some minor freelance here and there) I can imagine a world where you both are right.

They might've done the math and realize that the amount of safari users they might gain is not worth the cost of the extra development (time & money).

You obviously do.

> significantly less power

This is the big issue for most people, I think. I would love to use Chrome, but when I do, (a) thighs burn to a crisp if my machine is on my lap directly and (b) the battery depletes, literally, 1.5x as fast.

I've noticed this using Chrome on Ubuntu. Is Firefox the best alternative, (is it significantly more efficient?) or can you suggest something else?

Chromium has a bit less bloat than chrome, but less features correspondingly. Aside from that, firefox seems to be the big contender.

Epiphany works pretty well for me, I've been forced to customize the User-Agent string to that of Chrome to make certain things like Outlook Web App treat it like a Real Browser(TM), on occasion I have to use Firefox still (Plex doesn't work in epiphany) but overall it works fine.

I should note that Epiphany is the only Linux web browser that seems to interact with touch screens correctly, drag-to-scroll works wonderfully on my XPS 13 meanwhile Chrome and Firefox just keep trying to highlight text.

Epiphany is also based upon GtkWebKit, which is a Gtk port of the same engine that runs Safari.

why is that? does safari use some undocumented api, or that chrome sucks up more computing power in the name of rendering speed/responsiveness?

It's the latter. From what I've noticed, Chrome engages the dedicated GPU to speed up rendering. This by itself will cause a spike in power usage.

Yet Safari must be doing something with the GPU too, it scrolls quicker. I guess there's just more incentive to optimise a platform for Apple.

I think it's just a lack of optimization for battery usage on OSX Chrome. Google seems to have recently realized it is an issue though and is making progress on improving things: https://plus.google.com/+PeterKasting/posts/GpL63A1K2TF

Safari's speed is a tossup for me, in that opening new tabs and typing in the address bar both are often preceded by several second (!) delays before the UI responds. This persists across multiple instances of clearing all of my browsing data and even migrating to a new laptop. That I continue to use it over Chrome in spite of that implies a lot about the sorry state of browsers in general right now.

That's right Apple, can do no wrong. Where do these guys get off criticizing them? How dare they.