[jaredcwhite]

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. While I never agreed with the nonsensical "Safari is the New IE" meme that was going around, I did fear that Apple's tendency to develop things in a vacuum would continue to harm WebKit relative to Blink, Gecko, etc. But all signs are pointing to good things to come. Perhaps Apple's major open source initiative in the area of Swift language and the Swift ecosystem is also benefiting their approach to WebKit now as well.

[crabasa]

Safari IS the new IE. Proof? IE executed a "developer preview" strategy leading up to IE9 6 years ago. I should know, I was a PM on that team.

http://arstechnica.com/information-technology/2010/10/ie9-pr...

This entire episode is just a rinse and repeat of what MSFT did years ago in response to negative developer sentiment.

[coldtea]

>IE executed a "developer preview" strategy leading up to IE9 6 years ago. I should know, I was a PM on that team.

That (Safari adopting "developer previews" now) doesn't mean much regarding whether Safari is the new IE. When people say that phrase they don't mean their both trying (or having tried) developer previews. They mean whether Safari is as backwards and holding the web back as IE6 was for ages.

Which is not. IE9 was years behind Safari at the time you talk about (6 years ago) --and really first version of IE that started to really compete at all for the modern web--, while Safari was, and still is (the preview) at the top of the heap regarding ES6 compliance, etc.

And while much smaller in userbase, Safari grew along with the modern web, introducing major new features that IE hasn't done since 2000 or so (Canvas, CSS animations, etc), being the basis for Chrome, and getting the JIT treatment right along the 2 other modern browsers (Chrome, FF).

As for the mobile space, Safari has been lagging in some features (compared to desktop browsers), but was always ahead of the pack in lots of areas, to the point one cannot say mobile Chrome is that better. In fact, maybe the opposite:

https://blog.runspired.com/2016/03/25/the-chrome-distortion-...

[nailer]

It is backwards. HTML5 clipboard isn't implemented. Webcrypto is buggy. Those are just from the top of my head because my app uses them.

[crabasa]

> They mean whether Safari is as backwards and holding the web back as IE6 was for ages.

Safari is holding back the mobile web the exact same way IE held back the desktop web for the exact same reason: native apps.

> while Safari was... at the top of the heap

Lol? I know very few (none?) web developers who uses Safari as their primary target browser. ES6 support or not.

> cherry picked pro-Safari blog post

https://joreteg.com/blog/why-i-switched-to-android

[coldtea]

>Safari is holding back the mobile web the exact same way IE held back the desktop web for the exact same reason: native apps.

That's a classic tinfoil theory, but with absolutely no substance.

First, Apple sells hardware, first and foremost, not apps (it's the inverse with Microsoft). Their app store profits are negligible compared to all else.

Second, Apple has consistently made the best mobile web browser for many years -- Android had the horrible crippled Android Browser which was not even competing, before Chrome became competitive there.

That's not what you do when you want to cripple mobile apps -- which few users care about anyway, the money (for developers) and the convenience (for users) are at native apps.

Do you see "mobile apps" thriving in Android or MS Phone compared to native apps? Because I do not.

>Lol? I know very few (none?) web developers who uses Safari as their primary target browser. ES6 support or not.

What Lol? Safari's engine is what Chrome has been based on, and for most of its life it has been one and the same codebase.

Developers just don't prefer Safari's developer tools compared to Chrome's -- and of course Chrome is more popular (and cross platform), so it makes sense to use what most users use. Back in the day all developers used FF and its dev tools too, for similar reasons.

[crabasa]

> First, Apple sells hardware

If you think that consumers are purchasing iPhones so that they can rock out on Safari and Mail, you are mistaken. A year ago over the App Store hit 100B cumulative app downloads:

http://www.statista.com/graphic/1/263794/number-of-downloads...

Native apps drive hardware purchase decisions for consumers. That's the lesson of Windows Phone.

> Safari's engine is what Chrome has been based on, and for most of its life it has been one and the same codebase.

You misunderstand how a browser is constructed. Browsers are much more than just a rendering engine like Webkit. Chrome and Safari have different JavaScript engines, support different web standards (no WebRTC for Safari!) and are architected in completely different ways. You might find this a helpful place to start:

http://arstechnica.com/information-technology/2013/04/does-w...

[Natanael_L]

Fennec / Firefox Mobile

[matt4077]

What does "Primary target browser" even mean? Many (me included) prefer Chrome as a dev browser because the dev tools are better and many extensions are only available for chrome (react dev tools etc.). But at the end of the day, you need to support Safari (which usually isn't a problem).

Off topic tip: I've had success with the Safari dev tools on some issues that I couldn't debug on chrome. Sometimes it's worth trying both.

[om2]

Despite the similar name, Safari Technology Preview is a very different product concept from the old IE9 Developer Previews. It's not a series of one-shot early betas, but rather a live evergreen view onto coming developments.

In that respect, it's much more like Chrome's Dev Channel or Canary, or Firefox's Developer Edition, then like these old preview builds.

[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.

[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.

[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.

[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.

[blackkettle]

IMHO, until they decide to provide proper HTML5 support - particularly access to the getUserMedia and general WebRTC APIs - or at least allow 3rd party vendors like Google and Mozilla to do so by themselves, this is not a believable sentiment.

[om2]

Media Capture and WebRTC are in development in the public WebKit repository.

These features aren't really part of HTML5 though. And while some web apps really need these features, most would not use them at all. So I'm curious why this in particular is your litmus test.

I think an even wider range of web apps will benefit from our IndexedDB revamp, Shadow DOM, ES6, fast tap, font-feature-settings, picture element, CSS Variables, and other cool stuff we shipped recently or have in the works.

[therealmarv]

what steps? Any prove? BTW here a good example how Chrome & Safari team cannot communicate and everyone of them implements their own HTML standards. Here gesture support (pinch and zoom, trackpad) on desktops https://bugs.chromium.org/p/chromium/issues/detail?id=596689 for what reason we have W3C/WHATWG etc. ?

[masklinn]

https://webkit.org/status is one, this very article above is an other, the much more significant than usual mid-cycle Safari 9.1 is a third. These are 3 things which happened in the last 3 months or so and are more progress than Apple had shown in the last what, 3 or 4 years at least?

[ryanjshaw]

I'll take them seriously when they release something that runs on Windows.

[Longhanks]

WebKit runs on Windows. It's not Apple's task to package it nicely for you.

Chrome was using WebKit a long time, Blink is a WebKit fork. Both run on Windows.

[ryanjshaw]

> WebKit runs on Windows.

WebKit != Safari or Chrome or anything else.

Safari has quirks that you cannot experience without using Safari itself, which you still cannot run without a Mac. When you've wasted hours trying to track down one of these issues and realise it's a Safari quirk you'll understand my annoyance.

> It's not Apple's task to package it nicely for you.

I'm not sure where you get this idea from given that it contradicts the article: "Safari Technology Preview is a standalone application that can be used side-by-side with Safari or other web browsers... It’s a great way to test upcoming WebKit features and give feedback to the people building them when it’s most useful." I'm pointing out my opinion that they cannot meaningfully achieve that result without a Windows implementation.

[karmelapple]

It would be nice if they did release even a developer-focused version of Safari for Windows to help with testing for devs that prefer Windows.

However, this same problem exists outside of just web browsers. I help create native Android apps in Java. I wish every hardware manufacturer created a nice emulator for me to test the specific kinks out on their device. If Google enforced this policy, even better.

But that's not happening.

I guess the question is: should we expect / demand it to happen?

To make software that runs well on an Android device, my best bet is to have that device in my hand, just like having a Mac in hand (or one into which you can remote) is the situation today. It's not great, but it's not isolated to Apple and Safari.

Thankfully both mobile devices and browsers have services online where we can get screenshots of an app or website running on a real device or driver, without us laying out cash to buy them all.

[abiox]

what constitutes "meaningfully achieve that result"?

[yuhong]

I was wondering what is the current status of WebKit for Windows since the Blink fork for some time now.

[tangue]

I've never had the courage to build Webkit on Windows but Midori (which is webkit based) works quite well on Win 8

[mrweasel]

Why? Don't you take Microsoft serious either? Edge isn't exactly running on Mac... or Linux.

[chris_wot]

Plenty of people haven't taken Microsoft seriously for some time now :-)

[gapchuboy]

If they do, would you use it on you mac, linux or even on windows?

[ryanjshaw]

I don't understand your comment. I was responding to the parent stating: "Apple's been taking a number of steps over the last few months to show that they take Safari/WebKit development seriously." I'm annoyed because there are Safari-specific issues that as a Windows user I cannot debug, thus my comment that I cannot take Safari seriously. Like it or not, Windows is the dominant desktop platform.

[Skinney]

I think what the parent is getting at, is that you've got the same problem regarding IE on Mac. There are IE specific issues that I as a OS X developer cannot debug.

[comex]

At least Microsoft offers free VM images for precisely this purpose. Meanwhile, OS X barely works in a VM due to the lack of graphics acceleration (plus, running such a VM on a non-Mac is illegal).

[skybrian]

Cross-platform means you have to test on multiple machines. A company that's taking web development seriously also needs Mac, iOS, and Android devices to test on. Or borrow them every now and then, or sometimes virtual machines will work.

(I do often skip testing on Windows and iOS for hobbyist stuff since I don't normally use them, but I don't blame other people for it.)

[matthewmacleod]

They did release Safari for Windows. Nobody used it, and I guess they figured the cost of upkeep wasn't worth it.

[sandis]

While it was pretty bad, I remember Safari for Windows rendering text much nicer than any Windows browser (or app) at the time - particularly, the font smoothing. I recall using Win Safari to take "marketing" screenshots of an web app.

[niutech]

I agree. Sleipnir claims to still provide this font smoothing on Windows. http://www.fenrir-inc.com/us/sleipnir/

[vardump]

What? While font shapes might have been more true to the original, Safari on Windows had very blurry font rendering, nowhere near as sharp as native.

It was very painful to read.

[MBCook]

As an end user it was pretty bad (with all the libraries they were using). It mainly seemed to exist so Windows only shops could develop/test their websites on iPhones and iPads without having to own that hardware.

As iPhones and iPads became ubiquitous (as well as the popularity of Macs with developers) that didn't seem to be enough reason to keep it going.

I don't think Apple ever intended to win the browser war, I assume it was a means to an end. Maybe I'm wrong and someone was somewhat delusional. As a Mac lover who had a strong PC at the time it was quite pokey to try to use.

[mrpippy]

Yep Safari for Windows was released at WWDC 2007 (~2 weeks before the iPhone went on sale), and I'm sure part of the rationale was for Windows developers to be able to test their web sites with it.

Also note that Google Chrome wasn't released until September 2008, so there was a year+ where Safari was the most prominent WebKit-based browser on Windows.

[runjake]

They did release Safari for Windows and virtually nobody used it so Apple discontinued it. What are they supposed to do?