Hacker News Reader

Comment by rubyn00bie | Hacker News Reader

No and I think your opinion is harmful.

IE literally refused to implement standards, rendered broken dom elements, allowed for proprietary native extensions and had many different apis for them. They had 90% of the market share and no other viable platforms. This meant developers built things which exploited these broken features causing huge compatibility issues when they aren’t (every other browser).

A simple lack of features didn’t make IE... IE. Safari is a pain in the ass but it sure as fuck ain’t no internet explorer.

I think Chrome is propagating lazy developers who think everyone uses their browser. Which means things only work in Chrome and no where else. It’s not as bad as the IE situation yet and hopefully it won’t be with Firefox kicking ass again.

View on HN

Apple is doing similar stuff by refusing to implement the payment request API and instead implementing their proprietary Apple Pay API. So you can use one API to target Chrome and Firefox and another for Safari. This is starting to sound a bit like IE. They were invited to join the working group for Payment Request and decided not to take part.

You can argue that they're not implementing $thing-you-like but lets be real; you can't compare IE to anything if you don't include the market share.

IE was harmful because it had such incredible market share and could do what it wanted with that.

And Apple has a major mobile market share, that HAS to use safari. If I could get away with not supporting safari, I definitely would.

Then you are not a proponent of an Open web, you are a lazy developer.

The Payment Request API is supported in the Safari Technical Preview and enabled by default since Release 44.

https://webkit.org/status/#feature-payment-request https://developer.apple.com/safari/technology-preview/releas...

Apple hasn’t had an monopoly antitrust suit against them for it. Different story, different times.

> IE literally refused to implement standards

Chrome doesn’t implement asm.js (EDIT: I had previously written WebAssembly, but that was a typo), concurrent JS, or autocomplete=off, or the GeoLocation API via HTTP, etc.

> allowed for proprietary native extensions and had many different apis

NaCl, PNaCl. Try running http://earth.google.com/ in a browser other than Chrome. Or the Google Hangouts Video Chat.

> They had 90% of the market share and no other viable platforms

Chrome has reached > 67% of the global market

> This meant developers built things which exploited these broken features causing huge compatibility issues when they aren’t (every other browser).

See above mentioned Google Earth, Google Hangouts, the early releases of Google Inbox, Google Allo, and WhatsApp Web, as well as the early releases of Signal Web.

> It’s not as bad as the IE situation yet

See above why it is just as bad as the IE situation.

Oh, and "IE was preinstalled" – Chrome runs malicious, misleading advertisements everywhere to get users to install Chrome, and when that wasn’t enough, they started paying companies to secretly install Chrome with their installer (same as what the Ask Toolbar, or BonzaiBuddy did – except, now it’s Google offering 30 million EUR to VLC to include it, and that project denying it and publishing that info).

> Chrome doesn’t implement WebAssembly > NaCl, PNaCl.

It does, and both of which are being deprecated and removed in favor of WebAssembly.

At least your point about Google using underhanded tricks to get Chrome in the hands of users is accurate.

Thanks, I meant asm.js instead.

Fair enough, but mind that asm.js is itself being deprecated too, WebAssembly is meant to replace it.

It was as cool experiment by Mozilla for sure, but it's in the same boat as the cool experiments by Chrome: not picked up by other browsers.

Chrome is implementing a standard that pretty much all other modern browsers are also implementing. For example, service workers - implemented by Chrome initially and pretty heavily integrated into Android/PWAs - but Firefox and Safari are also shipping this feature currently. And also most features, such as service workers, can be effectively used with progressive enhancement, still providing a working experience to the user when they are using an older browser. Most sites I've seen that say "Must be used in Chrome" or whatever really have no reason to do that. There is more nuance to the progression of the modern web platform than the OP article gives off.

Sorry, the op is right. Safari IS the new IE.

Service workers is one of the most egregious failures on their part. And I believe it's been done on purpose. With service workers you get full control over building your JS based app, something Apple does not want, they want everyone to got through their store.

Considering that the only way (moving forward) to create an offline JS app now is through service workers, and Apple is just starting to get it working, _maybe_ for the next version of Safari.

https://caniuse.com/#search=service%20workers

What does this mean? It means that it may take one or two more _years_ of _hardware_ updates to get iOS users able to use a javascript feature in their browser.

As far as I know, iOS and Safari are knitted together like MS did to Windows and IE. Try and get a new version of Safari that doesn't match with the version of iOS you are running.

I could go on about the state of local storage and other HTML5 debacles on Safari, but it's total loser and I am only going to make myself upset.

According to this article Service Workers is on by default in the latest Safari Tech Preview: https://9to5mac.com/2017/12/20/safari-preview-46-service-wor...

Yah, I keep tabs on that stuff. But most of my clients actually use Apple hardware for a few years now, and even if this update goes out tomorrow, and all iOS 11 users get it. iOS 10 users and below are out in the cold, and that accounts for 99% of my users.

And you know what it's like trying to use a feature even when 70% of users can take advantage of it, it's still a no-go. So Apple totally blew it on this one.

MS Edge appears to be further along than Apple...

Apple has unusually high adoption (compared to Android) for new versions of their OS, I am not too worried. You can ship a service worker and it will not degrade the experience for users on older browsers.

I have a 3rd gen iPad right here, I can't upgrade to iOS 11. So, it's a forced _hardware_ upgrade to get a browser update. That's just insane.

Since Service Workers were enabled in STP as of a couple of days ago, the next upgrade to Safari in a few months will likely have it—it’s not 1-2 years away as you suggested.

I’m pretty sure I’ll be running PWAs on my iPhone 5s the first half of 2018.

This is the dream, but I doubt Apple will offer any kind of proper home-screen integration like there is on Android. I can only hope tho

Part of what’s required is Web Manifest and that’s on the WebKit roadmap: https://webkit.org/status/#?search=manifest

I respectfully disagree, for one simple reason.

All of those things are true of iOS Safari as well, except that on iOS you literally can't use any other engine so 100% of the browsers on Apple phones and tablets are restricted by whatever limitations or flaws Safari brings.

Reply on news.ycombinator.com