[chris_wot]

Their time to fix bugs and regressions in iOS is 3 months!

Edit: Again, I write a very unpopular opinion. Yet there are hundreds of regressions that have bit developers. Some of those bugs require workarounds that would be otherwise unnecessary on any normal environment with rapid updates - like Chrome or Firefox. That increases developer effort, and there have been cases that Apple have entirely missed their update and so folks wait for 6 or more months for a fix!

People can be unhappy with my comment (the score is bouncing up and down like a yo-yo!), I really don't care - but having been one of quite a few website maintainers that have had to work around Apple's bugs, it's very frustrating for both the end user and the developer.

[shadowfiend]

Downvoter here: I downvoted early on because you're making an argument that seems to me both not particularly good and off-topic to the post you replied to.

OP posited: “Apple's been taking a number of steps over the last few months to show that they take Safari/WebKit development seriously. This is another positive step in the right direction.”

You basically responded, “They're still not as good as I want them to be!” It's a point that has nothing to do with the original comment, which was about improvement, not perfection, and about how seriously they take Safari/Webkit development, not about their release process (which remains roughly the same as it has been for the past many years).

Additionally, regarding the workarounds you mention: they are unnecessary in a “normal environment with rapid updates” only when those developers decide to fix your bug. Again: rapid updates are only useful if your bug is being addressed. I've got workarounds in my code for issues in Firefox that probably won't be fixed anytime soon, and features that Firefox and Chrome support poorly that they won't support well for a while, etc, etc.

I'm not saying Apple couldn't be releasing bug fixes for Safari on any platform faster—they certainly could. But you made an unrelated complaint as a reply to a specific comment, and your argument seems suspect to boot.

[wyqydsyq]

The problem isn't necessarily Apple's laziness with updating Safari, I think it's more the fact that they insist on using their own JavaScript engine. They could very easily just use Blink and V8 which would significantly cut down the maintenance work in keeping Safari up to date as well as leveraging the work already done rather than trying to reinvent the wheel to nobody's benefit.

For example most ES2015 features have been available in Chrome, Edge and Firefox for over 6 months now, but Safari still doesn't support any of it (other than this tech preview) because it's development time is shared with the rest of Apple's ecosystem.

Unless Apple dedicates more resources to Safari in order to keep pace with the rest of the browsers, they'll be playing catch-up ad infinitum.

[alwillis]

WebKit supports 98% of ES2015, more than any other major browser engine, so keeping pace isn’t a problem for Apple: https://kangax.github.io/compat-table/es6/

Now with Safari Technical Preview, if you want access to all of it in a more accessible package than the WebKit Nightlies, you can have it.

BTW, Apple has been doing what appears to be a amazingly good work on JavaScript Core lately, extending their performance lead: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler....

[justabystander]

You realize that although WebKit supports 98%, Safari itself as of version 9 supports 53%. As is noted in your own link to the compatibility table. So, yes, keeping pace is a problem for Apple, since the other browsers are significantly ahead and the Safari 9 series was released half a year ago. Even Microsoft Edge has been doing better.

You might actually have a leg to stand on when Safari 9.1, released 10 days ago, gets its ES6 state tested and uploaded to the compatibility table. Or it might be more embarrassment about Apple's slow release cycle. It's also unclear as to whether Safari Tech Preview will contain the majority of ES6 code in Webkit or if it will be "curated" into a significantly less compliant and useful state. Once again, tests will tell. What is certain for now is that six months of Safari have left it at 53%, which, among many other examples, has been Safari dragging everyone else down.

Just because they have untested, unsupported code in a development branch doesn't mean that their main browser with a completely different name and a glacial release cycle gets a pass for holding up the class. The Tech Preview is a good starting step, but until these things have a clear release cycle that shows current WebKit ES6 feature support making its way into a release build before the end of the year, we'll continue to be upset at them with cause.

[alwillis]

It's also unclear as to whether Safari Tech Preview will contain the majority of ES6 code in Webkit or if it will be "curated" into a significantly less compliant and useful state.

Apple has been clear from the moment they released Safari Technology Preview: Get a preview of the latest advances in Safari web technologies, including HTML, JavaScript, and CSS. Safari Technology Preview includes the most recent version of WebKit, the rendering engine that powers Safari.

This is from https://developer.apple.com/safari/technology-preview/

Short answer: Safari Technology Preview also scores 98% on the ES6 test.

[justabystander]

The most recent version of WebKit does not automatically mean that it's a scheduled build directly based off of their development branch. I agree that's the most reasonable way to do it, and it's what it implies. And it's easy to assume that's what they're doing. But they could just as easily be putting this in an intermediate tech preview branch and pulling individual commits.

The phrase "most recent version" could mean pulling from a dev branch, using the last successful build, pulling from a release branch, pulling from a testing branch, assigning arbitrary numbers and tags to commits and pulling from there, or even working from a staging repo where they cherrypick commits. These are all separate sources that could hve their own version series, and "most recent version" is a very relative statement. Anyone who's seen the divide between development and sales knows that phrase has enough wiggle room to fit a Challenger disaster inside, and marketing is Apple's specialty.

I really hope they start to pull the changes from WebKit. Safari sorely needs it. But Apple's not the kind of company you just take at their word unless it's independently verified. I get it if you want to believe. That's sweet. But I'd rather wait for the tests.

Even then, monthly builds are still not a public release schedule for Safari. It was six months with only minor fixes between 9.0 and 9.1. We're far more interested in a public stable release with usable ES6 support than builds with unstable features that won't be usable on sites this year. If preview builds were what would solve the problem, then the WebKit Nightlies would have been enough.

[coldtea]

Only Safari (betas) have better ES6 support than Chrome ones according to a latest article on Ars.

And Safari saves like 20% to 30% of your battery life over Chrome...

http://bgr.com/2015/08/05/google-chrome-vs-safari-battery-li...

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

And both are due to Apple's own JIT engine...

[gsnedders]

> And Safari saves like 20% to 30% of your battery life over Chrome... > And both are due to Apple's own JIT engine...

I feel like that claim needs a source. I'd be amazed if the JS engine had anywhere near such a substantial effect on battery life.

[om2]

The JS engine is not the only reason for Safari/WebKit's superior battery life but it's definitely one contributing factor.

When loading webpages, one of the most important factors to saving power is reaching an idle state as quickly as possible. For many pages, that requires being fast at executing JS that runs only once or only a few times. Safari dominates on this, thanks to WebKit and JavaScriptCore. You can see this on JSBench, which runs JS modeled on real page loads and interactions: http://plg.uwaterloo.ca/~dynjs/jsbench/

I applaud Chrome's recent work on battery life. But I think it would be fair to say that safari is still the best in this area. And also that our excellent results have inspired Chrome and others to do better, much as in an earlier era Chrome inspired other browsers to get more serious about JS performance.

[gsnedders]

But given most JS code in the real-world is mostly dominated by DOM performance, and not JS engine performance. Certainly JSC's llint gives it a substantial benefit over V8 on cold code, but I'd be surprised if it accounted for even the majority of the battery life gain. I'm not questioning Safari's lead here, just how it's so much better. (I think the lead is clear, with perhaps only Edge getting close, but that's hard to compare.)

[lstamour]

Except the reason Blink forked from WebKit was all the Apple-specific code they could drop. Apple really focuses on hardware integration and getting maximum battery life out of their engine. I can't say the same about Chrome yet.

[chris_wot]

I don't care how much I've been downvoted, especially by someone who contributes their own comments so infrequently to HN, but it's funny how you only now decided to make a comment.

I personally feel that Apple are still not as good as not only I want them to be, but pretty much anyone who uses or develops for iOS. But yes, you categorize my comments and opinions well - Apple are indeed not very responsive, and yes Apple need to do a hell of a lot better. As I say, the votes are bouncing up and down, so I'm not the only one who has holds this opinion.

And no, it's not off-topic. As an end user, I now have to incorporate workarounds that no normal user should have to make to get around their issues - I'm literally running Charles proxy (until iOS 9.3 fixed their issue) and a rewrite rule to get around their ridiculous bug. And I had to run it for 3 months. Firefox and Chrome has an issue like this one fixed within their next cycle - in other words, in no time at all.

All of which means I'm not afraid, ashamed or worried about downvotes from folks like yourself. I've not said anything offensive, sexist, racist or even all that terribly controversial. You've finally come out of the woodwork to make your comment, which I appreciate. If only you had made it sooner, eh?

[dang]

Please don't go on about getting downvoted in HN comments. The guidelines explicitly ask everyone not to do that, because it's tedious.

https://news.ycombinator.com/newsguidelines.html

[chris_wot]

OK, and what about those who tell me that I'm off topic when I'm not? Or those who don't look at my wider point and accuse me of bad faith comments?

My only comment was that my score was going up and down like a yo-yo, and only because I was being accused of making off-topic comments. That's pretty tedious, no? Surely that's against HN guidelines?

[dang]

There certainly are other tedious things besides that tedious thing, but still, please don't do it, even if provoked.

Being a good HN commenter in the long run means learning to eat provocation, which admittedly sucks, but is true community service.

[chris_wot]

Fair point :-)

[coldtea]

>Their time to fix bugs and regressions in iOS is 3 months!

So? There are open bugs, including VERY annoying/visible ones, for Chrome that languish for half a decade on its bug page, despite tons of votes...

[hughw]

Three month bug fixes is distinctly un-IE-like. IE preserved broken behavior for years, as a matter of policy.