苹果Safari明显落后它会成为下一个IE浏览器吗

Web开发者Nolan Lawson最近写了一篇文章指出,苹果在实施Web标准方面明显落后于其他主流浏览器开发者。 Safari 缺少许多新兴的 API 技术,Safari 已成为新时代的 IE。

以下为文章主要内容:

上周末,我参加了 EdgeConf,这是一个由许多网络行业领导者赞助的会议。 会议设置了多个研讨会,重点关注新兴浏览器技术。 围绕Service Worker、Web Components、Shadow DOM、Web Manifests等相关技术进行了热烈的讨论。

这10余位与会者堪称网络社区真正的活跃成员。 来自所有主要浏览器的代表出席了 EdgeConf,例如 Chrome、Mozilla、IE 和 Opera。 大家也很感兴趣,纷纷向主流浏览器开发者询问什么时候发布这样那样的API(应用程序编程接口)之类的问题。

“房间里的大象”

有一家公司没有出席,他们是没人愿意提及的“房间里的大象”。 大家都没有直呼其名,而是称呼他们为“加州某公司”或者“某水果公司”。 会议室里几乎所有的笔记本上都闪烁着该公司的醒目标志,但没有人敢说出它的名字。 是的,是苹果。

Web 开发人员普遍认为 Safari 落后于其他浏览器,而参加 EdgeConf 这样的会议会让你更强烈地感受到这一点。 您会对它落后其他浏览器的差距感到惊讶。 上面提到的 API 目前都没有在 Safari 中实现,苹果似乎对此兴趣不大。

即使苹果确实采用了新的 API,他们也常常搞乱它们。 以IndexedDB为例。 IndexedDB 在五年多前就被提出,并于 2012 年开始出现在 IE、Firefox 和 Chrome 上。苹果直到 2014 年中期才推出 IndexedDB,但他们的实现却出乎意料地糟糕,大家普遍觉得它没什么用。

现在,一年后,Apple 修复了 IndexedDB 中的几个大漏洞中的两个。 他们声称 IndexedDB 不值得付出努力,因为它“没有大的用例”。 如果浏览器支持一团糟,当然没有人会使用IndexedDB。

很难理解苹果为什么要这样做。 他们从不派人参加与 Web 相关的会议,他们的 Safari 博客也很少更新。 因此,在一年一度的 WWDC(全球开发者大会)开幕之前,没有人知道下一代 Safari 会是什么样子。 感觉苹果就像圣诞老人一样——他每年都会来一次,为大家送上万众期待的礼物,但无从知道他会送什么礼物。 说实话,这些年的礼物越来越小,没有什么惊喜。

近年来,苹果公司的网络战略充其量只是善意的忽视。 尽管 JSCore 和新的 WKWebView 的性能得到了极大的提高,但 Safari 并没有任何各种新的 Web 平台功能 – 离线存储、推送通知和“可安装”Web 应用程序。 人们很容易将其解读为苹果故意破坏对其应用商店业务模式的任何威胁,但这似乎没有意义,因为这部分业务基本上是收支平衡的。 另一种可能性是,他们只是响应 iOS 开发人员的请求 – 基本上是:1)引入更多本机 API 和 2)快速、快速、快速。 鉴于苹果公司一直对内部事务守口如瓶,没有人能说出真相到底是什么。

另一个IE?

事实上,苹果从来都不是网络的怀疑论者。 2010年,史蒂夫·乔布斯公开嘲笑Flash,称HTML5就是未来。 苹果当时是网络的虔诚信徒。 许多早期帮助Web应用程序赶上原生应用程序的功能,例如ApplicationCache、WebSQL、触摸事件和触摸图标,都受到了开发者的热烈欢迎,其中许多功能甚至源自Apple。

与此同时,当WebSQL被抛弃并被IndexedDB取代时,很多苹果员工居然站出来积极支持,称它对于Web应用程序的高效运行是不可或缺的。 从这些争论中可以明显看出,Apple 在 IndexedDB 获胜后感到了巨大的失望。 具有讽刺意味的是,Apple 几乎为开发人员提供了削弱其专有平台的所有工具,反过来,开发人员对 WebSQL 的拒绝让他们有机会重新思考自己的策略并停止 Web API 的任何新进展。

Application Cache也面临着类似的情况,并且在不久的将来可能会被Service Worker取代。 当苹果公司对网络还很感兴趣时,它曾经赢得了广泛的浏览器支持。 可惜的是,这只是一个半成品,被仓促出来了。 如果苹果还落后于其他公司,恐怕Service Worker也会遭遇和IndexedDB一样的命运。

现阶段,网络社区需要接受Safari已经成为新时代IE的事实。 微软最近改变了方式,谷歌在网络领域处于领先地位,而Mozilla则一如既往地快速前进。 而苹果,却仿佛在独自唱着一首悲伤的歌。 我们是时候公开讨论这个问题了,而不是表现得避而不谈。 苹果是世界上最有价值的公司,他们可以承受一些打击。

怎么处理呢?

那么,当一家完全控制 iOS 平台的主要浏览器提供商仍然坚持其 2010 年模式并表现得若无其事时,网络社区能做什么呢? 我认为主要有以下三个解决机制:

1) 坚持 2010 年的做法,使用 Polyfills 为 Safari 提供动力。 通过使用AppCache和PouchDB,您可以获得与Service Worker几乎相同的功能。 这种方法应该会吸引绝大多数 Web 开发人员。 另一方面,这也是倒逼苹果的一个好办法,让他们有动力升级、强化自己的技术。

2)使用在Safari上效果不佳的技术,例如Service Worker,并将其视为推动行业进步。 Alex Russell 在 Installable Web Apps 研讨会上提出了一个很好的观点:如果我们开发大量使用 Service Worker 的免费 Web 应用程序,并且这些应用程序在 Android 上运行得很好,但只能在 iOS 上使用,那么 Apple 将有兴趣使用 Service Worker 来支持此 API。 然而,虽然这对于整个 Web 社区来说是最好的结果,但要说服开发人员编写只能触及一半受众的代码并不容易。

3) 为WebKit 做出贡献。 毕竟 Safari 的核心仍然是一个开源项目,因此 C++ 开发人员没有理由不自己实现新的 API。 该解决方案的主要问题是 WebKit 不是 Safari,Apple 仍然可以决定不在其旗舰浏览器中实现 WebKit 功能。 说回IndexedDB,Google很早就已经全面实现了它。 苹果在过去几年里本可以直接将其纳入谷歌的实施中,但他们行动缓慢,最终做出了一个充满漏洞的版本。 很难确保他们对其他外部捐款也采取同样的做法。

总而言之,我真的不知道有什么合适的解决方案。

目前许多WebKit开发者所做的事情令人钦佩,但在我看来,面对苹果的最佳策略可能是强硬而不是软弱。 因此,我倾向于采用上面第二点提到的Russell的解决方案,即开始推动新兴Web技术的推广。

如果Web社区能够开始构建一个充满活力的Web应用程序生态系统,将Apple排除在外,那么Apple可能必须像微软那样做出改变。 否则,开发者将不得不生活在 2010 年代的 Web 中,让 Safari 成为另一个可怕的 IE。

广告声明:文章中包含的外部跳转链接(包括但不限于超链接、二维码、密码等)用于传达更多信息,节省选择时间。 结果仅供参考。 所有 IT House 文章均包含此声明。