Hacker News Reader

Comment by forgettableuser | Hacker News Reader

The only thing that has doubled down here is the marketing of the fact they are contributing to open source. They have both been large users and contributors to open source since the switch to OS X (NeXT acquisition).

Just off the top of my head, projects they have had a large hand in: WebKit & JavaScriptCore, Objective-C, CUPS, LLVM, Clang, Bonjour/Zeroconf, Darwin, launchd, libdispatch, CoreFoundation, dtrace.

And more recently Apple Lossless Encoder, LZFSE compression, and of course Swift.

And this is only a tiny fraction of what they are users of.

View on HN

It would be nice if some of their contributions were less "throw it over the wall once or twice a year".

It would be nicer still if they stopped thinking their browser only needs to get new features once per year. Safari is rapidly getting a reputation as the new IE6. Fully supporting ES6 means nothing when everything is being transpiled and minified anyway, and the (arguably) dominant mobile browser your (kinda) forced to target doesn't support features that shipped in every other browser years ago, heck many missing features have even stabilised in other browsers years ago. The dev builds on desktop are just a token gesture that further displays how far behind the times WebKit/Safari/MobileSafari are falling.

Here are just a few things not supported in any Apple browser, Including the "Technology Preview" on desktop:

CSS Motion Path; CSS Device Adaptation; Client Hints: DPR, Width, Viewport-Width; inputmode attribute; MediaRecorder API; Network Information API; Web Animations API; Pointer events; Web App Manifest; seamless attribute for iframes; Payment Request API; Credential Management API; Push API; FIDO U2F API; Permissions API; Screen Orientation; Object RTC (ORTC) API for WebRTC; Proximity API; Ambient Light API; Battery Status API; Vibration API; Web MIDI API; getUserMedia/Stream API; WebAssembly; 'SameSite' cookie attribute; Public Key Pinning; XHTML+SMIL animation;

This looked like a pretty long list of unsupported APIs, so I decided to do some research:

- CSS motion path is not an official standard; it is implemented only in Blink (Chrome/Opera).

- CSS device adaptation is a W3C working draft. It is available prefixed in IE/Edge and Opera Mini, but is unprefixed in 0% of shipping browsers.

- Client Hints: DPR, Width, Viewport-Width is an IETF working draft implemented only in Blink (Chrome/Opera).

- inputmode is supported in 0% of shipping browsers.

- MediaRecorder API is a W3C working draft supported in Blink (Chrome/Opera) and Firefox but not IE/Edge or Safari.

- Network Information API is not an official standard; it is supported only in Chrome for Android.

(Source: caniuse.com)

I stopped going through the list at this point. At least from the top of your list, none of these features are "shipped in every other browser" and some are shipped in no browsers at all. I'm not sure how it shows that Safari is "far behind the times."

If anything, the list seems to show that Chrome implements many non-standard APIs not available elsewhere. Combined with its mindshare (if not marketshare), this suggests that Chrome--not Safari--is in some ways the new IE6.

This is exactly what tons of WebKit/Safari haters do — troll through the literally 100s of proposed standards (admittedly sometimes W3C but still) and rile up comment sections w/this false trope astroturfing for half-baked technologies.

It's usually because they had some pet project / approach relying on the "standard" that they couldn't run right in MobileSafari, even though it had no adoption whatsoever, Cupertino is DESTROYING the web for not including it, battery life, privacy, reasonable userspace restrictions, etc BE DAMNED.

Don't believe it.

I'd edit my post to remove the items that aren't standard or even working drafts yet, but unfortunately the time window has passed so I can't now.

But I can't agree that Chrome is in any way the new IE6. Chrome is actively participating in the public view in the process of web standards. Apple seems to 'participate' insofar as they are on lists of participating companies. Apple pretty much adds just one batch of features per year, and does so through a completely opaque process that outside developers are almost completely irrelevant to. Chrome at least listens to outside opinions, while one of the defining traits of the IE6 years was having to work under the umbrella of a "we don't care, just use what we gave you" attitude from the IE6 developers.

Also, the fact I had to open chrome in order to post this comment to HN is an amusing addition to this little "how broken is the web" discussion.

I suspect the reason gp included the IE6 comparison at all was in response to yours, after looking into ES6 support across browsers for features you specifically called out, which I think is fair to do.

As for opening Chrome to post your comment, are you having issues with other browsers when you do so? I generally use Safari in Mac OS X and iOS without a problem.

Web Developers use common lowest denominator with is IE8-IE9 for public facing projects and IE11 for internal...

Your Safari will work just fine, but it is still behind Firefox or Chrome [0]. I am not saying that Safari is new IE because we will struggle with IE11 for years to come.

Before Safari 10 ES6 was supported in 54% then in Safari 10 is 100%. This is wrong approach to web, it is the same approach that MS had in the past. Ignore standards and make some improvement with new version for bragging rights.

[0] https://nolanlawson.com/2015/06/30/safari-is-the-new-ie/

> Before Safari 10 ES6 was supported in 54% then in Safari 10 is 100%. This is wrong approach to web, it is the same approach that MS had in the past. Ignore standards and make some improvement with new version for bragging rights.

How is implementing some of a standard, and then completing work to implement 100% of that standard "ignoring standards"?

ggp: Also, the fact I had to open chrome in order to post this comment to HN is an amusing addition to this little "how broken is the web" discussion.

gp: As for opening Chrome to post your comment, are you having issues with other browsers when you do so? I generally use Safari in Mac OS X and iOS without a problem.

My comment on using Safari is in response to ggp saying Chrome was necessary to post to HN, not about general use or for development. Or am I misreading ggp?

"Safari is rapidly getting a reputation as the new IE6."

And that is just a ridiculous comparison done by people who have never witnessed that period or are having a different agenda.

One of my first jobs (more then a decade ago) as a young developer was being a web developer for an American/Belgian e-commerce site. One of the things that was very important - because every customer counts - that the site displayed and worked perfectly in any browser (IE6, FF/Mozilla, Safari and Opera at the time)

That was a situation that wasn't a lot of fun because you had standard HTML that more or less worked in any browser with the exception of IE6. There where a lot of moments that I really hated my job because of the frustrations that IE6 often brought to the table. That is in no way comparable with Safari today.

And while I would like to have Apple more rapidly implementing new API's, with IE we could only dream of having an IE version that got new features every year. Years have we have witnessed the fallout of IE6, that will never be the case with Safari to this day.

IE6 was a vehicle to create an internet that only worked with Microsoft standards so that others couldn't be a valid alternative hence the IE6 markup vs the rest. You can't do that by dragging your feet when implementing API's, you only price yourself out of the market in that way.

I have lived through those awful IE6 times and imho Safari is the new PITA of web development. Nowadays you don't have to create workarounds for CSS problems or same JS incompatibilities, Safari sucks at implementing even the most basic HTML5 APIs.

It is like with CSS 10 years ago. This nice new CSS feature (HTML5 API) which would perfectly solve your problem? Sorry you can't use it because IE (Safari) does not support it (maybe never will).

> Safari sucks at implementing even the most basic HTML5 APIs

Would you care to give some examples?

The last time this played out on HN, the list of unsupported things was not HTML5, and many were unfinished/unstable, or listed as in-progress by the WebKit team.

https://html5test.com/compare/browser/chrome-52/safari-9.1.h...

But you are correct, not all of those are HTML5 APIs.

Wasn't Battery Status API discovered to be harmful to privacy and on the way out in all browsers?

Sounds like Apple and Mozilla are planning to:

http://www.theregister.co.uk/2016/11/07/apple_mozilla_kill_a...

It was never enabled in any of the Apple-owned ports of WebKit, IIRC it was enabled in the GTK and Qt ports, but I could be wrong there. So Apple killing it isn't really true—they're just deleting code that was already gone at compile-time for them.

It would be nicer still if they stopped thinking their browser only needs to get new features once per year. Safari is rapidly getting a reputation as the new IE6.

-----------------

To be fair, they had a 9.1 release this year, which included: Picture element support

Support for CSS variables

Etc https://developer.apple.com/library/content/releasenotes/Gen...

So if they do this again, we're looking more at 6 month cycles.

The whole safari is the new IE6 stuff is hyperbole which I don't actually hear that many developers saying.. IE6 was bad because it didn't follow any standards, not because it updated slower than the competition.

It would be nice if some of their contributions were less "throw it over the wall once or twice a year".

Some of their contributions are. See Swift.

It would be nicer still if they stopped thinking their browser only needs to get new features once per year.

Safari Technology Preview ships every 2 weeks. I use it as my main browser. It is as solid as any other browser.

Didn't they also take quite a lot from FreeBSD when building OS X?

NeXTSTEP was based on Mach/BSD from the early days so it isn't recent.

Yes, but Apple updated a lot of the OS X BSD with FreeBSD components. It's why many man pages say FreeBSD.

Question is, how much did they give back to it?

All the ones I listed are the ones where they are significant contributors.

The much larger set of where they are mostly users, like the BSD userland tools, curl, Python, Perl, Tcl, Ruby, and so forth, I omitted. There are just too many.

LLVM/Clang and Grand Central Dispatch comes to mind. The MAC framwork is also a shared effort, but I don't know who is doing the heavy lifting. It's something.

And which of these are actually developed with an open source model instead of merely throwing code over the wall months after the official binaries have been released?

I know from personal experience that at least LLVM, Clang, Swift, and WebKit/JavaScriptCore have daily activity and also include non-Apple commit reviewers.

I also suspect CUPS remains pretty active. CUPS (Common Unix Printing System) started a long time ago and is used by pretty much all the Unix platforms. Apple bought the project in 2007. The license remains GPL2/LGPL2 and all the platforms still use it as far as I know.

The open sourcing of Swift was very beneficial. The project moved extremely fast the last years with lots of outside input and interest. I think this shows when OS works best: When it is not done out of obligation (or ideology), but because it can be useful as a tool.

Reply on news.ycombinator.com