Is Apple stifling progress in Web standards?(timkadlec.com)

292 pointsby w1ntermute11 tahun yang lalu144 comments

Is Apple stifling progress in Web standards?

http://timkadlec.com/2015/02/apples-web

33 comments

mkozlows11 tahun yang lalu

People are getting really bogged down in specific standards, but you don't need to talk about pointer events or flexbox or indexeddb or whatever, you can look at this at a macro level.

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.

frik11 tahun yang lalu

> you don't need to talk about pointer events or flexbox or indexeddb or whatever

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

bad_user11 tahun yang lalu

WebSQL is SQLLite and making that a standard is very hard without including SQLite's bugs and non-standard behavior.

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.

saidajigumi11 tahun yang lalu

> SQLite's bugs and non-standard behavior.

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

azakai11 tahun yang lalu

SQLite is kind of different from other DBs, in various ways. For example, data types,

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.

frik11 tahun yang lalu

* The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others. Also Firefox already ships with SQLite for its "awesome bar" and bookmark feature. SQLite is in public domain, so every company can use it (even Microsoft products already use it!)

* 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

dragonwriter11 tahun yang lalu

> The argument that WebSQL was tailored to a specific SQLite version is nonsense.

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.

[0] http://www.w3.org/TR/webdatabase/#databases

frik11 tahun yang lalu

Everyone knows the "Web SQL Database W3C recommendation" document should be re-evaluated, better formulated and improved. Richard Hipp, the creator of SQLite, stated that the dialect won't change (removing syntax) in SQLite v3 during the WebSQL W3C standardization in the mailing list.

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.

dragonwriter11 tahun yang lalu

> Everyone knows the "Web SQL Database W3C recommendation" document should be re-evaluated, better formulated and improved.

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.

bad_user11 tahun yang lalu

> About 95% of all mobile devices already support WebSQL

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.

thristian11 tahun yang lalu

> The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others.

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.

frik11 tahun yang lalu

* There is a common misconception about SQLite3 dynamic type system. It can be done using SQL statements: http://stackoverflow.com/a/2762020, http://www.sqlite.org/datatype3.html . The browser vendors could enable static typing by default by adding a few lines of code or just a flag afaik. Beside that there are other SQL db engines. SQL-92 was the third revision of the SQL database query language. It's the common dialect that every SQL engine supports: http://en.wikipedia.org/wiki/SQL-92

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

bad_user11 tahun yang lalu

Or you know, one could use IndexedDB, because you don't need a freaking relational model, unless you're planning to execute ad-hoc queries and aggregation on a significant amount of data, data that would do well to fit the relational model, which would be a stupid idea to do in the browser.

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

empthought11 tahun yang lalu

> unless you're planning to execute ad-hoc queries and aggregation on a significant amount of data, data that would do well to fit the relational model, which would be a stupid idea to do in the browser.

You mean like every iOS app that uses Core Data? And web apps will kill native apps with an approach like this?

dragonwriter11 tahun yang lalu

> SQL-92 was the third revision of the SQL database query language.

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.

Tloewald11 tahun yang lalu

I've done a ton of work with contenteditable and it's not especially good on IE (it was especially bad on IE up to IE8) nor especially bad on Safari (it's kind of horrible, but it's horrible everywhere).

frik11 tahun yang lalu

I edited my text, I meant: Safari on iOS. The touch interface introduces bugs that haven't been fixed for years. Desktop Safari is as buggy as Chrome, both originally based on the same Webkit code.

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.

Tloewald11 tahun yang lalu

Agreed, contenteditable is terrible in Safari for iOS.

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.

jqm11 tahun yang lalu

Agreed. For instance, IE (11 at least) doesn't permit <td> cells contenteditable. There are some workarounds, but then other browsers seem to have problems.

realityking11 tahun yang lalu

To be fair, if you compare IE11's with other browsers at the time of its release, they have stellar support. There is still no other stable browser that supports let, and the only other browser with support for const is Firefox 36 (released yesterday).

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.

cwyers11 tahun yang lalu

The kindest thing you can say about IE is that they seem to be well aware of the problems with their release cycle, and are taking steps to remediate this -- they refactored out large amounts of compatibility code from Trident to make EdgeHTML, and I think they plan to up the release cadence of updates to EdgeHTML significantly once they release Spartan.

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.

EdSharkey11 tahun yang lalu

I thought Mozilla said they were going to land some form of Firefox on IOS.

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.

azakai11 tahun yang lalu

It is "Firefox", but it's still using the Safari rendering and JavaScript engine under the hood (like Chrome for iOS does), because there isn't an option to do otherwise.

CHY87211 tahun yang lalu

There are two problems.

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.

smackfu11 tahun yang lalu

Does Apple release HTML features updates to Safari in between OS releases? It feels like they freeze the features in July at WWDC, so they would be pretty out of date by February.

Tloewald11 tahun yang lalu

Seems like a weirdly anti-Safari summary, including assumptions about "future Safari" being inferior to "future IE".

wavefunction11 tahun yang lalu

I consider Safari to be the worst browser out there, especially when you include "Mobile Safari" in that assessment of Safari.

Tloewald11 tahun yang lalu

While your opinion is of course paramount, you should try the Kindle Fire's browser. (I have the original Kindle Fire; newer models are probably better off -- that said, my original iPads still work fine and their browsers are perfectly usable, if slow.)

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.

wavefunction11 tahun yang lalu

This is from a "developing for the web and dealing with Mobile Safari" perspective, so take that for what it's worth.

UnoriginalGuy11 tahun yang lalu

Honestly, not yet.

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

malchow11 tahun yang lalu

"it is actually the responsibility of browsers to somewhat govern what standards do or do not move forward"

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.

greggman11 tahun yang lalu

That's quite the spin there. I wouldn't say that's why ms originally decided to bash WebGL. It's far more likely they wanted to both scare users away from browsers supporting WebGL and at the same time try to prevent an OpenGL like API from gaining any traction vs directx as targeting directx makes your app ms platforms only.

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.

randomfool11 tahun yang lalu

The security issue noted appears to be https://blog.mozilla.org/security/2011/06/16/webgl-graphics-..., from June 2011 (FF bug was actually fixed May 26th, 2011).

It was a Firefox issue, not a spec issue. AFAIK, Microsoft never explicitly detailed what their security concerns were.

shmerl11 tahun yang lalu

Not applicable here. Apple just want to retain the usage of their patented API in this case[1]. I.e. they are simply being greedy jerks who don't care about the Web.

1. http://arstechnica.com/tech-policy/2011/12/is-apple-is-using...

chc11 tahun yang lalu

It's hard to imagine that battery concerns are the reason for their extremely spotty ES6 support.

[deleted]11 tahun yang lalu

richtr11 tahun yang lalu

What is difficult to argue against, and I'm surprised isn't mentioned in this article, is that Apple have completely eliminated market competition from happening around web standards on the iOS platform.

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.

josteink11 tahun yang lalu

> It is impossible to ship e.g. Chromium on iOS right now. We just collectively buy the arguments put forward by Apple

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?

shmerl11 tahun yang lalu

Why can't Apple be slapped with an antitrust lawsuit for that? MS was targeted for something very similar.

hyperpape11 tahun yang lalu

Apple has a minority market share.

shmerl11 tahun yang lalu

Not if they can control Web standards this way. It means they have way too much influence.

cududa11 tahun yang lalu

That's not how the Sherman Anti-Trust act defines monopolies, and that's the law they'd have to be prosecuted under. A republican congress probably isn't going to pass laws designed to sanction the most valuable country in the world.

millstone11 tahun yang lalu

To be fair, it's also impossible to ship Firefox on ChromeOS.

air11 tahun yang lalu

To be really fair, out of the four biggest browser vendors (MS, Apple, Mozilla, Google) only Google makes it possible to use the other browser engines on their mobile platform.

azakai11 tahun yang lalu

Preventing other browsers for technical reasons is very different than doing so for policy reasons. iOS prevents other browsers in both ways. ChromeOS (and FirefoxOS, and others) might limit you technically, but do not limit you by policy.

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.

magicalist11 tahun yang lalu

Actually, it would take quite some work to port Firefox, but you could run a NaCl-compiled browser just fine.

pcwalton11 tahun yang lalu

Not realistically. The NaCl APIs to support dynamically-generated code have to revalidate every time, so they're too slow to support the heavily self-modifying nature of compiled JavaScript.

eridius11 tahun yang lalu

Why is it impossible? If you want JavaScript support you have to use Apple's JavaScriptCore, but I don't recall any rule that prohibits using a custom web rendering engine paired with JavaScriptCore.

So if anyone wants to build a version of Chromium that uses JavaScriptCore instead of V8, you could presumably ship that.

air11 tahun yang lalu

https://developer.apple.com/app-store/review/guidelines/

"Apps that browse the web must use the iOS WebKit framework and WebKit Javascript"

eridius11 tahun yang lalu

Huh. I haven't actually read through that document in a while. I thought it just had the prohibition against scripting languages other than the iOS JavaScriptCore (i.e. WebKit Javascript). I wonder why it now states that you must use the WebKit framework as well?

shmerl11 tahun yang lalu

> I thought it just had the prohibition against scripting languages other than the iOS JavaScriptCore (i.e. WebKit Javascript).

Which is already close to prohibiting other browsers (like Firefox for instance).

kolbe11 tahun yang lalu

This article's title got me thinking that Apple, as a company, could actually be interested in suppressing the advancement of the web. Their apps are a shockingly effective alternative to the internet, and the store becomes more comprehensive by the year.

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.

romaniv11 tahun yang lalu

> Their apps are a shockingly effective alternative to the internet

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.

Demiurge11 tahun yang lalu

This can't possibly happen because regardless of how big Apple is, it is tiny compared to the Internet and everyone who depends on the open Internet, from Amazon, Facebook, Google, Netflix to whitehouse.gov and data.nasa.gov

kolbe11 tahun yang lalu

That's not what I'm saying. Amazon, Facebook, Google and Netflix would be victims of this. People would still use their services, but they'd use their services through the dedicated iOS app, not through a browser. Then Apple will have become a necessary middle man for the consumption of the content that those companies distribute. And who knows what Apple would be able to get away with at that point. Charge Facebook $100mm whenever the push out an updated version of their app? All Amazon purchases must be made with ApplePay? Who knows.

robmcm11 tahun yang lalu

This would be anti competitive as soon as the app store had a majority market share.

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

empthought11 tahun yang lalu

> For Google it's part of their core business

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

robmcm11 tahun yang lalu

How do they generate such high advertising revenues? People using google services, allowing them to build detailed portfolios to sell to advertisers.

All of this happens though the web. Native apps and things like android are just a way to drive people back to the web.

empthought11 tahun yang lalu

Most of it comes from AdWords, i.e. Google Search. Angular, GWT, Closure, and Dart have nothing to do with it. They're also all essentially abandonware from Google's point of view, because management has rightly realized they have nothing to do with their core business.

robmcm11 tahun yang lalu

What are the tools to manage those services written in? Angular was borne out of AdWords tooling, just as React was from FB advertising.

Now consider Google have chromebooks, where those apps must run on the web.

[deleted]11 tahun yang lalu

munificent11 tahun yang lalu

> it is tiny compared to the Internet

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.

smhg11 tahun yang lalu

> If the next version of iOS didn't even have a browser, you would be astonished at how little that impacted most users.

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.

phatfish11 tahun yang lalu

That sounds great, if we can silo all the mobile users into their own instance of Facebook/Youtube etc. I might start using social media!

r00fus11 tahun yang lalu

I'd like to agree with you on a philosophical basis, but the reality is that Apple is 2x market cap of Exxon and iPhones recently outsold all Android in the US (calendar Q4 2014).

I don't think it's useful to downplay their influence.

xyby11 tahun yang lalu

> apps can replace all but some long-tail usages

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.

kolbe11 tahun yang lalu

Are you kidding me? 90% of what people do in iOS is in an app. Email (app), chatting (apps), Facebook (app), dating (app), Instagram (app), Twitter (app), news (app), games (apps). I could go on for quite a while until I start to encounter things that aren't in an app (e.g. Hacker News).

sbochins11 tahun yang lalu

There are some pretty nice HN apps on iOS.

mcintyre199411 tahun yang lalu

To be fair, the actual claim was "Apple's apps can replace all but some long-tail usages." which is blatantly false.

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.

kolbe11 tahun yang lalu

Read again. I'm not saying that they're Apple's native apps.

xyby11 tahun yang lalu

I said nothing about iOS users. I said: Most people don't use iOS.

fauigerzigerk11 tahun yang lalu

That's not going to happen for multiple reasons.

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.

tarkin211 tahun yang lalu

Isn't the Web a competitor to the App Store? Especially when web apps start to catch up with native apps (and Santa tracker and the rest of Google's Polymer apps seem to suggest this is only a year or so away, and FirefoxOS has certainly made huge strides in this direction) and offline support with web workers is ubiquitous?

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

TazeTSchnitzel11 tahun yang lalu

Are they really? Other browser vendors also refuse to implement things sometimes. IE has taken its sweet time on certain technologies, entirely deliberately. Google have tried to force standards with their marketshare.

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.

dragonwriter11 tahun yang lalu

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

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.

TazeTSchnitzel11 tahun yang lalu

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

See below: the Chrome team have other (performance) objections.

eridius11 tahun yang lalu

That could easily just be a justification for not supporting it that sounds better than "we'd rather not support two separate models for touch/mouse events". Especially if they really would rather not support it but feel that they would have to if Apple did jump on board.

mootothemax11 tahun yang lalu

Are they really? ... It's a Microsoft-backed spec that only Microsoft supports.

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?

CSMastermind11 tahun yang lalu

Apple is singled out because they're the driver behind all of this. Touch Events was born from Apple's initial work to touch-enable Safari on the iPhone. W3C moved to standardize it but Apple declined to be involved in the effort. Then they blocked the WC3 from releasing it as a standard using their patents, which they were unwilling to offer a royalty free grant for users of the spec.

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.

54245811 tahun yang lalu

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

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.

shawnhermans11 tahun yang lalu

From the first link:

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

james-skemp11 tahun yang lalu

Thank you for the very detailed history of this.

Amazing how some things have changed in just the last decade between the browser makers.

streptomycin11 tahun yang lalu

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.

anon138511 tahun yang lalu

That's hardly exclusive to Safari. IndexedDB seems to be a buggy mess in all browsers: http://pouchdb.com/2014/10/26/10-things-i-learned-from-readi...

streptomycin11 tahun yang lalu

No, it's very exclusive to Safari. Add up all the other bugs in all the other browsers and it's about 0.1% as bad as Safari. It's almost unfathomable how huge and severe the bugs are in Safari. That's why the PouchDB solution was to simply not use IndexedDB on Safari: http://pouchdb.com/2014/09/22/3.0.6.html

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.

Alphasite_11 tahun yang lalu

I would say Mozilla refusing to implement h254 support was a similar issue, although their reasons were much clearer.

bphogan11 tahun yang lalu

Or Mozilla and MS refusing to implement Web SQL Databases because IndexedDB and NoSQL was better, even though one works on all mobile phones since 2010 and the other is wonky and has a terribly designed API.

No need to single anyone out. They're all equally guilty.

towelguy11 tahun yang lalu

> It's a Microsoft-backed spec

So it's a case of Not Invented Here? or more accurate: Invented By the Enemy?

syoc11 tahun yang lalu

>only Google supports that You should read the other HN post about this issue. http://www.quirksmode.org/blog/archives/2015/02/tired_of_saf...

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.

dlib11 tahun yang lalu

Playing the devil's advocate but isn't Apple hindering web standards a strategy to keep people using the apps from the AppStore. On mobile, where the iOS market share is huge and it's impossible to use any other rendering engine it would be hugely beneficial to stifle progress as native apps and thus the lock-in they provide, will keep the upper hand.

captainmuon11 tahun yang lalu

If I look at what features are provided and what are not in HTML5 (especially on iOS), I also get the impression that some features are "conveniently" missing, with the consequence that certain things can only be written as native apps.

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.

Transfinity11 tahun yang lalu

It's not just browsers. I work in storage, and their NFS client (a 25 year old protocol) is without question one of the worst we've seen. The number of hoops we have to jump through and spec violations we've implemented just to get the server to play nice with Macs is a little disgusting.

taf211 tahun yang lalu

I can't help but wish this was about WebRTC instead of pointer events. I can see so many applications using WebRTC but not so many using pointer events... Still I loath Safari, for locking so many features out of the mobile web.

omeid211 tahun yang lalu

They have conflicting interest with a better web: Apple Store.

alessioalex11 tahun yang lalu

IE is the only browser that STILL doesn't support EventSource, the simplest realtime technology one can use with browsers: http://caniuse.com/#feat=eventsource

How come nobody rants about that? (genuine question)

teamhappy11 tahun yang lalu

I've noticed recently that Apple removed support for the High Resolution Time API (performance.now and friends) in iOS Safari 8.1. It was fully supported in iOS Safari 8.0. Not sure if I've ever seen a vendor unimplement a (HTML5) feature before.

antimagic11 tahun yang lalu

"Apple has shown no interest"

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.

kevincennis11 tahun yang lalu

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

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.

[deleted]11 tahun yang lalu

lordbusiness11 tahun yang lalu

The parent makes a solid point, and you're employing this logical fallacy, which is why I am down voting you.:

http://en.wikipedia.org/wiki/Appeal_to_ridicule

heinrich599111 tahun yang lalu

Say what's wrong, but don't call it "that fallacy". Those "appeals to fallacies" are really what destroys useful Internet discussions.

gwern11 tahun yang lalu

Ridicule is not what he's appealing to, rather, the basic evidential principle that absence of evidence is evidence of absence.

csixty411 tahun yang lalu

sly01011 tahun yang lalu

It's not in Apples interest to advance the web. They want less web and more native. Unfortunately.

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.

anon138511 tahun yang lalu

The dream of the modern web is the concept of a single standard/platform that is used for all user facing software. This is a flawed idea and this article demonstrates one of the biggest reasons for that. By definition, features only become part of open web standards if all the main players agree to them. All the players have financial and political incentives to block various things. Corporations can block something that you want to use even though you have no relationship with that corporation. In a capitalist system you have very little leverage against a corporation that you have no financial relationship with. What are you going to do: stop buying the [Apple/Google/Microsoft] products that you already don't use? What's left is people writing angry impotent blog posts against companies that don't care about them in the least.

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.

atacrawl11 tahun yang lalu

How is this from Google...

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

54245811 tahun yang lalu

The author is cherrypicking here. See what Google actually said:

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.

rblatz11 tahun yang lalu

Mobile development is tricky, you have to support the most common devices and browsers that are out there. That means Safari on iOS, and Chrome and the bundled browser on android. Since a large percentage of users will not seek out an alternate browser we have to support the bundled browser. In my experience, we've been limited by Android as a platform than we have by iOS.

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.

shmerl11 tahun yang lalu

Apple are too sick with lock-in mentality, so of course they'd sabotage any effort if that helps them retaining some grip on the market. The fact that they ban competing browsers on their mobile systems clearly demonstrates the point. And their negative attitude to free codecs is known as well. They are too stuck in their petty hate for interoperability.

tkubacki11 tahun yang lalu

Apple is not going to support Web Components (Shadow DOM) as well.

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.

jpea11 tahun yang lalu

WebRTC is a huge one that comes to mind. With the App Store and Facetime in the same wheelhouse, there's no compelling reason to develop this area for Apple. It would be a HUGE win for the general web if they did, but there's zero reason for them to pursue it.

guardian5x11 tahun yang lalu

Maybe once Apple brings the rumored iPad Pro with Stylus support, we will see them supporting it. I guess at the moment they just have no reason for it. Maybe they think they would help MS with the Surface, which would benefit from widespread PE support.

matthewmacleod11 tahun yang lalu

The answer is a gritty, in-your-face "no".

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.

Touche11 tahun yang lalu

They released IndexedDB several years after everyone else (I believe at least 3 years) and major bugs.

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.

kenferry11 tahun yang lalu

Have you seen the WebRTC code? It's 1.1 million lines of gnarly C++. It's cool in terms of features, but that's the essence of bloat. One of the reasons Safari was built off of khtml in the first place was manageable code size.

Touche11 tahun yang lalu

Is there just 1 WebRTC implementation? Do Google and Mozilla not have their own separate codebases?

matthewmacleod11 tahun yang lalu

I specifically didn't focus on the one example given.

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.

ddlatham11 tahun yang lalu

Did you see Google's comment quoted in the article?

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.

matthewmacleod11 tahun yang lalu

I did see that – but it's a pretty nonsense argument, isn't it?

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?

pcx11 tahun yang lalu

> If we had Apple on board with PE, we’d still be on board too.

You entirely missed this quote in the article. How do you explain that?

54245811 tahun yang lalu

The author is cherrypicking here. See what Google actually said:

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.

idonthaveaname11 tahun yang lalu

Can you prove the quote was not spin to make Google appear to have the moral high-ground here?

mbel11 tahun yang lalu

It seems worth noticing that this is more political than technological argument. Google choose not to implement Pointer Events and used Apple as a scapegoat.

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.

fpgeek11 tahun yang lalu

This isn't Google using Apple as a feature implementation oracle, this is Google looking at pointer events using both their "web developer" and "browser developer" hats and reaching a disappointing conclusion.

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.

mbel11 tahun yang lalu

Thanks for the reply, honestly I haven't thought about Google as web developer. Another point that I unfortunately missed is that if Apple implemented Pointer Events in WebKit, then the changes could probably be ported very quickly to Blink (I guess both code bases are still largely similar).

pcx11 tahun yang lalu

The OP is also critical of Google. But doesn't make Apple any less wrong.

coldtea11 tahun yang lalu

As a BS excuse?

datashovel11 tahun yang lalu

Just thinking out loud here:

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.

jasonsync11 tahun yang lalu

Safari still doesn't fully support Blob URLs ...

https://github.com/eligrey/FileSaver.js/issues/12

barneybooroo11 tahun yang lalu

The whole "developer relations as Bigfoot" trope doesn't ring true when it comes to WebKit, in my experience. I've had Apple developers reach out to me when I've mentioned WebKit bugs on Twitter. They're very happy to talk about efforts towards standards, and I actually find it to be one of the least cynical parts of Apple's business.

hober11 tahun yang lalu

Thanks :)

xyby11 tahun yang lalu

I saw windows applications come and go. I saw ActiveX come and go. I saw Java applets come and go. I saw Flash come and go.

To me, iOS apps don't feel like a threat. Apple does not even have a monopoly like Microsoft had.

ndesaulniers11 tahun yang lalu

It's interesting; when Google worked with Apple on WebKit, they were able to pull Apple forward. Now that Google has forked WebKit into Blink, Apple is on their own to keep up.

hackaflocka11 tahun yang lalu

Go ahead and do it anyway. May be just what Apple and Google need to be disrupted.

Not too long ago, Microsoft used to display similar arrogance. Look where they are now.

Kiro11 tahun yang lalu

Why do you need touch events at all? Can someone give me an example? I thought mousedown etc worked for touch as well.

towelguy11 tahun yang lalu

Multitouch events perhaps?

[deleted]11 tahun yang lalu

integraton11 tahun yang lalu

Microsoft significantly stifled progress on the web for a decade. Now, after WebKit's progress wrestled away Microsoft's dominance and eventually forced Microsoft to spend years trying to catch up, Microsoft wants everyone to get out the pitchforks because Apple isn't supporting Microsoft's latest pet standard fast enough.

towelguy11 tahun yang lalu

s/fast enough/at all/

integraton11 tahun yang lalu

You can't predict the future, the standards process is messy, and Apple hasn't actively taken a public position, so at this time your comment is disingenuous.

nilsbunger11 tahun yang lalu

Did non-wwbkit browsers really support WebKit css prefixes as this article claims?

[deleted]11 tahun yang lalu

urda11 tahun yang lalu

As always folks, Betteridge's law of headlines [1] is in play here.

The answer? No.

[1] http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines

frou_dh11 tahun yang lalu

As far as I'm concerned, Apple still have a bit of time left to bask in the afterglow granted for mortally wounding Flash by keeping it off of iOS.

ytpete11 tahun yang lalu

Do you think perhaps the same motivation could have been at play there - stifling web competition to their native app store?

frou_dh11 tahun yang lalu

Hard to say to what extent. Remember, at least in the early days before there even was a native SDK, they were very pro-webapp for iOS.

Touche11 tahun yang lalu

Really? That was 7 years ago.

frou_dh11 tahun yang lalu

And yet it was only a few weeks ago that YouTube started serving HTML5 video by default on the desktop (yes I know there was a flakey cookie-based opt-in earlier).

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.

Touche11 tahun yang lalu

You miss my point. You're saying we should forgive Apple of their current transgressions because they did something nice 7 years ago? Give me a break.

frou_dh11 tahun yang lalu

I said "I" not we, and nothing about forgiveness.

Flash not being on iOS was not a point in time, but a continuous good thing.