Is Apple stifling progress in Web standards?
timkadlec.com
timkadlec.com
Here's the ES6 support table: http://kangax.github.io/compat-table/es6/
Safari and IE were laggards, but future IE is going to be very solid while future Safari is still going to be terrible.
Here's the HTML5 support table: https://html5test.com/results/desktop.html
Safari and IE are laggards, and both continue to lag.
Safari used to be a Chrome/Firefox-level "modern" browser, while IE was the consistent laggard, with its slow release cycles and bad standards support. The most optimistic thing you can say about Safari now is that it's on IE's level; and realistically, it's even worse than IE -- certainly the IE team is a lot more transparent about future plans than the Safari team is.
For better or worse, Internet Explorer has a far longer release cycle. But right after release IE is often ahead of the other browsers in some regard (CSS calc and the ECMA Internationalization API come to mind).
Safari hasn't done that in a while.
Apple doesn't seem to be doing much of anything to keep up with Firefox and Chrome on those charts. Which isn't even the problem! Apple will not allow Firefox or Chrome's rendering engines onto iOS. Even in the darkest days of the IE/Netscape war, Microsoft never even contemplated not letting users install Netscape.
It's the combination of "lagging behind standards" and "wholly locked-down platform" that threatens to stagnate the web, and it's only Apple that's in that position.
Yep, here's the press release: https://blog.mozilla.org/press/2014/12/designing-a-firefox-e...
The actual work is going on here, but it sounds like it's only at the experimental stage: https://github.com/mozilla/firefox-ios/ I'm kindof curious to build it and see if it works.
I read that the only issue with getting competing browsers onto iOS is the developer agreement says you can't provide a program with a proprietary javascript engine in it. Frankly, iOS is so big now, I would argue that that restriction strays into competitive advantage territory, and the OP is proof of that. If I were a lawyer at Apple, I would suddenly become magnanimous and get the developer agreement changed such that competing web browser programs _only_ may host their own JavaScript engines.
The first problem is political - firstly Apple make it so that you have to use the Webkit rendering engine for any third party browser. The second problem is more technical - iOS has memory protection that means you can't take a writeable page and make it executable. This means that you can't (for example) JIT compile Javascript (or any other language). Their built in exception to this is Safari. This is why Safari is faster than webviews.
But missing functionality is a deal breaker.
* WebRTC - web peer to peer connection: Chrome & Firefox yes, IE 11 incompatible by design (bought Skype for 11b, based on it), Safari no (would be Facetime competitor)
* WebSQL - web relational database: Chrome & Safari (also 95% of all smartphones) yes, Firefox & IE no (declared dead by Oracle and MS devs (biggest SQL vendors), in favour of complicated NoSQL API IndexedDB on W3C mailing list)
* IndexedDB - complicated NoSQL API: Chrome & IE 11 yes, Firefox yes but slow (implemented on top of SQLite, refused to implement WebSQL API, FirefoxOS is the only smartphone OS with no SQL API), Safari yes but buggy
* WebGL - OpenGL 3D accelerated graphics: Chrome & Firefox & Safari(since iOS8) yes, IE 11 barely (old 0.9 instead of 2.0 API, few extensions)
* CSSRegions - desktop publishing stylesheet features like Adobe InDesign/MS Word: Safari & Firefox yes, Chrome yes but removed again, IE 11 yes but older draft
* ContentEditable/HTML editor - a bug free implementation would make MS Word WebApp & Google Docs obsolete: IE 11 yes (invented, based on Frontpage, old HTML4), Firefox & Chrome yes but bugs, Safari barely useable (especially on iOS)
So basically every browser vendor is guilty to some extend. Apple protects its AppStore walled garden, FaceTime and "Pages" word processor, Microsoft its Skype/Lync, Office and DirectX/XBox eco-system, Google its GoogleDocs and Hangout, Mozilla community has some sponsored devs from companies with their own agenda (e.g. against WebSQL API, while using SQLite in Firefox to implement NoSQL API IndexedDB).
Mozilla had really good reasons for shooting it down. Calling them out on it is meaningless without specifying why you think they've been wrong. You can say anything about IndexedDB, but at least it has a spec.
* Also the argument of them that it's "hard" to sync a client side database with a server side database is nonsense. But the two argument basically stopped Web SQL as HTML5 API :( The developers who voted against Web SQL were (former) employees of two big server side SQL db vendors (see the related mailing lists and blog).
Nowadays with the rise of NewSQL movement of people who burnt their fingers with NoSQL, one can only hope someone gives some love to Web SQL.
To sum up, NoSQL has it's place and SQL has one too.
We had this discussion already this week, hopefully W3C board members and Mozilla devs read this: https://news.ycombinator.com/item?id=9082847
Nobody ever said WebSQL was intended to require a specific version of SQLite. But nearly every browser would have used SQLite, and experience has shown that when you expose functionality to the web, sites start depending on specific implementation quirks - check out all the gibberish people used to feed to IE6's CSS parser to trick it into behaving.
Also, note that SQLite is not what most people think of when they talk about SQL databases, if only because of its very "manifest typing". Maybe SQL92 is flexible enough to permit such things, but code written for SQLite is very likely to break horribly on other SQL implementations.
* Beside that even if Microsoft would use JetRed (http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine) or JetBlue (http://en.wikipedia.org/wiki/Microsoft_JET_Blue) database engine and use a slightly different SQL dialect, everyone else would use SQLite anyway (and even Microsoft products like several Xbox games and Tools use SQLite). It's the same like supporting different XHR/AJAX API versions (like the ActiveX API calls of < IE9) or many other glitches. One could use a shim.
Without WebSQL support one has to compile SQLite via emscripten to asm.js -> 3 MB big JS file.
And is completely irrelevant to WebSQLDB, which specifies "the SQL dialect supported by SQLite 3.6.19" -- not SQL-92 -- as what implementations must support. The SQL dialect supported by SQLite 3.6.19 does not include all of SQL-92, and includes extensions to SQL-92, so supporting SQL-92 would be neither necessary nor sufficient, from a supported SQL standpoint, to conform to the WebSQLDB spec.
> everyone else would use SQLite anyway
That does not make it a web standard and after 25 years of web evolution, I can't believe we are still having the same problems. The web has been extremely successful for some obvious reasons, yet we keep forgetting those reasons. One of the web's primary traits is that it's based on documented standards and has multiple implementations. SQLite fails that test.
> One could use a shim
Or you could not have this problem in the first place. And technically you could implement WebSQL on top of IndexedDB.
You mean like every iOS app that uses Core Data? And web apps will kill native apps with an approach like this?
No, the idea that WebSQLDB was not tailored to a specific SQLite version is nonsense. See Section 5 of the last version of the WebSQLDB spec [0]:
User agents must implement the SQL dialect supported by Sqlite 3.6.19.
> SQLite supports the official SQL92 standard
SQLite version 3.6.19 does not support all of, or only, the SQL92 standard. WebSQLDB did not mandate support for the SQL92 standard, or any other standard version of SQL, it specified the dialect supported by SQLite 3.6.19.
About 95% of all mobile devices already support WebSQL (iOS & Android & WindowsPhone (via official Microsoft sponsored extension)). And all desktop Chrome, Safari, Opera support WebSQL too. The only missing browsers are IE 11 and Firefox/FirefoxOS.
Everyone does not know this. Some people believe this, other people believe it should die in a fire. But whatever one things about the current state of the abandoned WebSQLDB spec, that is what WebSQLDB is, and you can't talk about -- honestly, at least -- it and pretend that it specifies SQL-92 as the required SQL dialect when, in fact, it specifies "the SQL dialect supported by SQLite 3.6.19".
You are essentially arguing that WebSQLDB should not have been abandoned based on the content of an imaginary WebSQLDB spec that never existed. If WebSQLDB had specified a (explicit, well-defined, use-case appropriate, single-user subset of) SQL-92 that would be different than what it actually specified, and the discussion would be different.
Yes, they are embedding SQLite. That's not a standard, it's a hack.
> The only missing browsers are IE 11 and Firefox/FirefoxOS
Which is why I'm glad they are still relevant.
"Bugs" I get, but what do you mean by "non-standard behavior" mean here?
My perspective, having had some experience with some pretty sophisticated DB adapter layers in the past: SQLlite and other nominally-SQL DBs all have only a very superficial level of SQL-level compatibility. Aside from closely related DBs (e.g. forks) it's not like there's any actual ability to exchange character-for-character identical SQL or DDL between DBs. All kinds of things like quoting, namespacing, and so on have subtly different syntax. It's pretty easy for a human to switch between SQL-x and SQL-y systems, but not so much when you're talking query generation. Even Rails has a pile of different backends for Active Record, and AR's backend is pretty darn simplistic.
http://www.sqlite.org/datatype3.html
It should be compatible with most DBs, but SQLite has more dynamic types, and supports more things, in ways that are "odd" for almost all other DBs. As you correctly said, in general, no two DBs are easily interchangeable, and SQLite is no exception, perhaps it is even more of an outlier in fact.
That means that to implement SQLite, not using SQLite code, means you need to carefully reproduce that behavior, and all aspects of it - in practice, including bugs - to be a compatible web browser. For a web standard, that's just unacceptable.
GoogleDocs v2, Word WebApp and iCloud Pages use a JavaScript based page layout engine that renders one DIV per line and don't use the contenteditable. Even the blinking cursor is a DIV. Though, even they do not support text-columns - something that would work out of the box with contenteditable. (GoogleDocs v1 used contenteditable, as well as SharePoint content editor and its first Word WebApp incarnation)
Implementing such a complex page layout engine plus internal document format (XML based?) is a lot of work and afaik there is no such open source JS library exists.
Pages actually uses SVG for most of its layout. It makes me suspect that Apple has an XCode back end for compiling Cocoa/IB code to Javascript.
That said, I use Mobile Safari a lot and it seems pretty good. My experience of Android browsers pretty much ended when my Nexus 7 died, but certainly it did not seem superior in any respect -- and it was markedly inferior in some -- to Mobile Safari.
Apple might one day be fairly accused of holding up web standards, but so far they're still at least 80/20 implementing new proposals. It might be unpopular but it is actually the responsibility of browsers to somewhat govern what standards do or do not move forward.
For example when IE decided not to do WebGL due to security concerns and then successfully got the standard altered as a direct result [0]. That was what browsers are meant to do. That's what Apple does in some cases too, however their primary focus appears to be battery not security.
[0] (end of article) http://www.techradar.com/us/news/software/applications/why-m...
It was a Firefox issue, not a spec issue. AFAIK, Microsoft never explicitly detailed what their security concerns were.
It was only later they finally caved and implemented WebGL in ie. If they truly were only concerned about security but otherwise ok with WebGL they would have joined the WebGL committee and cooperatively influenced the spec.
1. http://arstechnica.com/tech-policy/2011/12/is-apple-is-using...
An underappreciated point. Browser developers incl. Apple also have a responsibility to recognize that it's a mobile world. A compute cycle might look like it's getting cheaper, but a mobile CC is vastly more expensive than a desktop CC because of the cost of energy.
We might have three monitors plugged into 100A mains, but the typical end user has a 1900mAh battery and 7.5 seconds between Starbucks and the car door to send log in to the school's website to approve a field trip permission. It will be a while before mobile web standards can progress in the blue sky fashion we'd prefer.
It is impossible to ship e.g. Chromium on iOS right now. We just collectively buy the arguments put forward by Apple to support that position without appreciating the ramifications of not allowing market forces to drive healthy, competitive development.
In that process we made Apple the gatekeeper of web standards development. They can ship whatever they want, when they want and there is no way to build or work around it (e.g. 'Download this alternative browser!').
All we can do is wait, hope or complain. Apple knows the power it wields. I figure Google understands that too hence their position wrt Pointer Events.
So if anyone wants to build a version of Chromium that uses JavaScriptCore instead of V8, you could presumably ship that.
"Apps that browse the web must use the iOS WebKit framework and WebKit Javascript"
Which is already close to prohibiting other browsers (like Firefox for instance).
When the limitations are just technical, you can try to work around them, but when they are a flat policy, like Apple does, there is nothing you can do.
No. Some people buy androids too. Quite a few, last time I checked.
Developers limiting themselves to support apple's modern msie are not allowing the market forces to drive healthy competition.
What? When androids browsers were lagging, locking them out from websites en masse was OK. By the same standards we should be locking out apple laggards this time around? Or are we going to be hypocrites about it?
Even at this point, Apple's apps can replace all but some long-tail usages. So, despite the fact that suppressing the progress of the web will hurt the user experience of its own web browser users, that affects users of all operating systems fairly equally. But in the meantime, Apple can keep improving their OS, the app development process, &c; and they could steadily crowd out the web until iOS becomes the primary (or, if Apple gets it way, the solitary) source of networked information distribution/consumption. And after a while, all of what are currently thought of as web or web 2.0 companies would all be at the mercy of Apple. They would, for all intents and purposes, privatize the web.
If it became too difficult for them "Charge Facebook $100mm" they would replace support with a lower quantity web app and blame Apple.
The reality is that Apple don't have as much interest in the web anymore, they have achieved their goal with web standards (removing enough of a dependency on Flash so they didn't have to support it). They have no need to make the web a successful app platform, so why waste effort on it.
For Google it's part of their core business, look at Angular, Closure tools, Dart, GWT etc...
No, it's not.
https://investor.google.com/financial/tables.html
Total Advertising Revenues: $59,056,000,000
Total Other Revenues: $6,945,000,000
All of this happens though the web. Native apps and things like android are just a way to drive people back to the web.
Now consider Google have chromebooks, where those apps must run on the web.
This depends entirely on how you measure scale. If you do it just by number of apps/sites, sure, the vast majority of web URLs don't have a matching iOS app.
However, if you scale each app by the total amount of time users are on it, you'll find that most of humanity is spending their time on a very heavily weighted small slice of the Internet.
From that breakdown, the fraction of human-hours that is covered by sites that also have native iOS apps is much larger.
If the next version of iOS didn't even have a browser, you would be astonished at how little that impacted most users. As long as they can still run Facebook, Instagram, Threes, etc., they'd be fine.
If time spent in an application is your criterion, true.
But that way you hugely underestimate the importance of, for instance, that daily (or even weekly) Google search the average user performs in their browser. It takes little time compared to your average social feed, but definitely impacts their lives. Just one quick example: a local business' phone number lookup.
I don't think it's useful to downplay their influence.
Yeah some long-tail usages like everything those 90% of phone and tablet users do that are not on iOS. And 100% of what desktop users do. And 100% of what laptop users do.
I'm not an iOS user so I might be a little off - but of your list Apple's apps do Email, chatting (for their protocol anyway), maybe they have a news app?
You can do pretty much everything outside the long tail with apps - usually with the better experience (outside of the long tail again) but they're mostly not Apple's apps.
To some, very limited, parts of the Web.
I think this statement is very telling in terms of illustrating how people's perception of "The Internet" has shifted over the years, along with the notions about is its overall purpose. Ad frankly, I liked the old notion (the one that centered around communication, rather than "apps and services") much better.
First of all, iOS market share in 2014 was 15%. You can actually stop reading here if you like.
Second, we only use tens of apps, but most of us use hundereds if not thousands of websites per year, because most provide content, not applications. Installing an app for each of them does not scale.
And third, apps are currently uncrawlable and hence there is no way to search for server side content inside and across them. It's not unimaginable for the App Store to solve this one eventually.
My experiences with Web Components, at least, do seem to suggest they're not very proactive and/or dedicated in the standards department, at least. They did put Shadow DOM into their spec at one point, but then removed it. The template tag is in at least, but that is a very, very simple tag (inert content until added to dom).
(I also found IE11 to play much nicer compared to Safari as compared to bug in my apps, not standard support, although that is really an indication of IE11's quality rather than Safari's laggardly standard support.)
Pointer Events is an odd case. It's a Microsoft-backed spec that only Microsoft supports. Apple won't implement it, Google won't, Mozilla's implementation is unfinished. Touch Events is also weird: only Google supports that.
Exactly, you've hit the nail on the head.
It seems a bit strange to single out Apple when there are plenty of other vendors also not implementing it.
That said, I know very little about the history of mobile browser development; have Apple historically dragged their feet on mobile Safari?
Yes. Here's another example: http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-B...
Every other browser supports IndexedDB for years, then Apple finally releases support for it and it's completely broken in multiple unfathomably bizarre ways. Still hasn't been fixed.
Here's my experience from building a fairly complex app that VERY heavily uses IndexedDB. If you follow the IndexedDB spec, you'll wind up with something that is 99% working in Firefox and Chrome. If you happen to run into that 1%, you'll find that Firefox and Chrome devs are very responsive and want to make it work. IE is a little buggy and is missing a couple features, but it's not impossible to work around them. Unfortunately the IE dev team is less responsive and it's not clear if/when they will fix things. But to support Safari, you'd have to do things that are utterly horrifying. It's basically not worth even trying.
Pointer Events was first proposed by Microsoft as an alternative solution. It was also a more general specification; while Touch Events was designed for touch and touch alone, Pointer Events allowed developers to use similar code to handle touch, stylus/pen, and mouse inputs. Pointer Events also addressed certain problems with Touch Events, such as a 300 millisecond delay before responding to taps in order to disambiguate between single and double taps.
Then the patent issue was resolved — W3C determined that Apple's patents didn't cover Touch Events anyway so they could release a Touch Events spec. All this time work on Pointer Events continued in parallel, backed not just by Microsoft, but also by Mozilla, jQuery, and Google.
Mozilla Firefox and Internet Explorer both implement Pointer Events. In 2012 Microsoft contributed code to WebKit, the rendering engine then used by both Chrome and Safari. While Apple never enabled the code, Google offered its support, and this continued even after Google forked WebKit to produce its Blink engine. It looked as if three of the four major browsers were on track to support the specification.
Then Google pulled support in August. Their stated rationale was that because Apple was unlikely to ever support Pointer Events and Apple is the dominate force in the mobile web; Touch Events would always be required. It's a decision that hasn't gone over well with web developers, just look at the comments on the Chromium bug tracker.
That's only one of their reasons.
https://code.google.com/p/chromium/issues/detail?id=162757#c...
https://docs.google.com/presentation/d/1qRqLKQjOnGgrM-UkMAb2...
In particular, see the notes in slide 6. They have several reasons that include performance, flexibility, and compatibility.
Very briefly, pointer events has 3 main drawbacks relative to the alternative:
1) Mobile-first web: Pointer events would likely never supplant touch events on the web (especially without support from Safari). Since touch events are here to stay, supporting another largely redundant input model has a high long-term complexity cost on the web platform.
2) Performance: The hit testing model required by pointer events imposes a non-trivial performance penalty (hit test on every movement event) that neither Android, iOS or touch events has. We're not willing to add any feature that increases the web's performance disadvantage relative to native mobile platforms.
3) Richness: Pointer events requires that scrolling and event handling are mutually exclusive. This precludes some UI effects which are common on on mobile platforms (eg. pull to refresh). Recently strong developer feedback has lead us to change Chrome in the opposite direction here - enabling event handling while scrolling (see issue 293467 ).
Amazing how some things have changed in just the last decade between the browser makers.
I just hope that Mozilla will get a proper implementation of Pointer Events so I can use that. It's sad to see Apple leveraging it's market share like this, but I can't say I'm surprised.
No need to single anyone out. They're all equally guilty.
Google, per the Chrome rep quoted in the article, prefers PE from a technical perspective, and only doesn't support it because it won't be universal because of Apple's resistance.
Unfinished means WIP, it doesn't mean that Mozilla doesn't support it the way Apple doesn't. Apple is the only barrier to adoption here.
See below: the Chrome team have other (performance) objections.
So it's a case of Not Invented Here? or more accurate: Invented By the Enemy?
Notably: - Network access. You can't write a BitTorrent or IMAP client in HTML. You could have with Java or Flash, but those have been axed (Apple was a major contributor to that). Of course there were good technical and security reasons for that, but it is a "convenient" side effect. - Last time I checked at least, touch input and rendering (WebGL/Canvas) was inferior to native.
Now, I'm not convinced there is a concious decision to keep HTML apps limited, but I do believe it plays a role when it comes to Apple supporting certain features and disallowing others.
How come nobody rants about that? (genuine question)
Um, that's an assertion, without which the rest of the piece makes no sense. I would have expected a little evidence to back the assertion up, or are we all supposed to get our pitchforks out on Tim's say-so?
That being said, let's assume that Tim is actually right, and that Apple are being capricious and trying to hold back the Web, because they can. Apple are within their rights to decide to not implement a standards-proposed API. If that API is the greatest thing since sliced bread, web developers will start using it, and Apple will be forced to follow suit or be left behind. If that API is rejected by web developers, then why should Apple waste time implementing it?
Obviously if Apple throw their weight behind an API, that makes developer support much more likely, but I don't see why they should be obliged to expend resources championing an API they don't like, and which is not yet being used by developers. Let browser implementers that see the value in the API do the experimental work, and if it turns out to be popular, Apple can follow along later. I don't see that anybody is being harmed or "stifled" by such a course of action.
No one will use a standard that's not available for 30% of the users, the point is to unify things, not to make yet another useless standard. Also unfortunately.
So we like it or not, Apples participation is kind of important here. I would risk that its more important than the quality of the standard itself.
How, exactly, would you expect the OP to present evidence of Apple not showing interest? What would that "evidence" look like?
I can't provide evidence that my golden retriever doesn't have an advanced understanding of quantum mechanics, but I don't think that would get him a job at CERN.
The list of proposed standards that have been blocked/delayed by one of more of the big browsers is huge. Blocking proposed standards isn't uncommon, if anything it's the norm. mathml, websql, pointer events, h264 video, nacl, flexbox, webgl, jpeg2000, webm, mp3, ogg vorbis, theora, webp etc etc.
Because of its origins as a way of displaying untrusted documents the web has no 'escape hatch'. It's a very tight sandbox. Flash and Java used to fulfil that role but they are on the way out. The web has a very basic trust model - all pages are untrusted and there is no other level of trust available. So if what you want to do hasn't been blessed by all the browser vendors then you are screwed. Does one of the main browser vendors compete with your product? It's quite likely that they do. Yet you want to give them full control over how your code can run all on all users machines?
If you don't like the idea of a corporation being able to veto a web standard then you need to seriously ask yourself if you actually like the idea of open web standards at all. Political vetoing is integral to the idea of open standards created through consensus and it isn't going to go away no matter how much people fantasise about it.
"If we had Apple on board with PE, we’d still be on board too."
... anything else but a lame excuse? It's deeply unfortunate that Apple won't budge on this because I think PE is a step in the right direction, but Google using Apple as a crutch is just as ridiculous.
https://code.google.com/p/chromium/issues/detail?id=162757#c...
They make a compelling technical and business argument against it; a reason the author acknowledges and dismisses because doesn't align with his thesis.
First iOS devices tend to upgrade their software more often, and are more likely to be running a recent version of the web browser.
Second support for features may exist on Android, but we have been unable to use those features because they did not perform in an acceptable manner for what we were attempting to accomplish. We've had a lot of issues with things like 3D/2D CSS transforms. In fact we've had to sniff out Android user agents and provide a substandard experience for certain features due to the abysmal performance.
Apple may be moving slower than the cutting edge on Android, but the cutting edge is so far removed from the reality of what we have to support and work with that it's basically irrelevant.
FF is working on it and even MS has "under consideration" status.
Even if there were some issues with driving Shadow DOM standardization by Google I suspect that not supporting it by Apple is more defending iOS walled garden than real tech issues with specs.
We have a recurring situation where all vendors (save for Apple) show interest in standard, but because Apple does not express that same interest, the standard gets waylaid.
That is literally not true – Google, by some metrics the biggest vendor, has also shown no interest in PE.
Frankly, I don't see that much of a problem with Webkit and its' adherence to standards. Broadly speaking, it adopts new features and standards somewhat later than FF and Chrome, primarily I expect because of the slower release cycle, but it does seem to eventually come on-board.
No argument that PE is more elegant. If we had a path to universal input that all supported, we would be great with that, but not all browsers will support PE. If we had Apple on board with PE, we’d still be on board too.
Surely the only way to put pressure on Apple to implement PE is to go ahead and do it regardless, like all of the other vendors?
You entirely missed this quote in the article. How do you explain that?
I'm not happy with Apple's decision, but I'm even less happy with Google using Apple as some kind of feature implementation oracle.
As a web developer, Google would have to use Touch Events because that's all that Apple supports. Chrome already supports Touch Events. That covers the overwhelming majority of their touch-enabled users, with code they already have. Rewriting that to use a newer modern standard everywhere is one thing, but writing a second implementation with no path to sunsetting the first is much harder to justify.
Coming full circle, if Google's web developers aren't going to use Pointer Events for the forseeable future, it is hard to justify Google the browser developer putting them high on their priority list.
https://code.google.com/p/chromium/issues/detail?id=162757#c...
https://docs.google.com/presentation/d/1qRqLKQjOnGgrM-UkMAb2...
Look at the slide notes on slide 6. They make a compelling technical and business argument against it; a reason the author acknowledges and dismisses because doesn't align with his thesis.
They have shown no interest in Web Components.
They have shown no interest in WebRTC.
They have shown no interest in Service Workers.
They have very little ES6 support.
Let's not focus on the one example given in the article, this is a pattern.
Safari is now the "third best browser" behind Chrome and Firefox, looking at this through the prism of adopting web standards. That's irritating, especially when Webkit did so much to push standards forward.
I don't disagree at all about Safari lagging behind — like I just said. It also seems like this has got worse lately — but I suspect a lot of that is down to the Blink fork, and the subsequent reorganisation that is taking place.
I expect this will get a little better soon, otherwise it's a valid point that web developers will start complaining more and harder.
What if we had a "meta app" which encapsulated individual browsers and created a specification allowing developers to define which browser type to use when opening their web page?
Not saying this can't be done today, but where the transition was seamless. I'm unaware of anything that allows us to do this today. I do recall a project that allowed one to do something similar (IE tabs in Chrome), but I think it wasn't the same in terms of seamless transition, and there was no way for the developer to control the transition.
To me, iOS apps don't feel like a threat. Apple does not even have a monopoly like Microsoft had.
Not too long ago, Microsoft used to display similar arrogance. Look where they are now.
The answer? No.
[1] http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines
There and elsewhere I was/am STILL having to spoof my desktop user-agent to pretend to be a phone to get around "Flash is REQUIRED to view this content" roadblocks.
Ideally Flash needs a bullet to the head, but I credit Apple with the best strike on it so far.
Flash not being on iOS was not a point in time, but a continuous good thing.