火狐正在做不可想象的事情。也许我应该说，火狐正在做不可思议的事情。也许我应该就说，火狐在做开头非常正确，但是结果可能非常错误的事情。

它在积极拥抱Chrome。

但不是直接拥抱。它所做的是拥抱WebExtensions API，这是与Blink兼容的新API。Blink恰好是由Chromium项目开发的一种Web浏览器引擎，它是WebKit的WebCore组件的一个分支。

明白了吗?

这已引发许多传闻盛传于坊间。其中一个传闻是，火狐会扔掉自己的插件，改用谷歌Chrome的附件。这在某种程度上来说是错误的。Mozilla基金会已决定，让插件开发与Web开发更加保持一致。换句话说，这是某种“开发一次，由许多浏览器运行”的方法。

Mozilla的渠道经理Kev Needham在官方声明中说：

“我们希望附件开发更像是Web开发：同一代码应该可以在多个浏览器中运行，遵守由标准确定的行为，还附有多家开发商提供的全面的说明文档。”

无论从哪个角度来看，这应该被视为向前迈出的很重要的一步。首先，开发火狐插件总是比Chrome和Opera来得复杂。原因何在?因为火狐目前利用XUL和XPCOM之类的技术，用JavaScript开发插件，以便可以访问底层的功能特性。那老一套正在被逐渐淘汰，改用新的Jetpack SDK(它并不使用任何较低层的API)。

一旦这一步落实到位，Chrome和Opera附件的开发人员就比较容易将应用程序迁移到火狐，从理论上来说是这样。

然而，开发人员会面临一大障碍。自从火狐42起，所有插件在部署之前先由Mozilla进行审核和签名。由于WebExtensions API，这个审核过程将缩短至最多五天(从理论上来说是这样)。

对于那些担心青睐的插件在新系统下无法正常运行的人来说，其中一些担忧并非完全没有道理。原因何在?因为许多现有的插件不得不从头开始重新编写。这并不意味着它们到时会从头开始重新编写。插件是不是重新编写以便在新框架下正常运行，这将取决于每个插件的开发人员。Mozilla的确计划与开发人员合作，让这个迁移过程尽量顺畅，但是这无法保证所有插件确实会进行迁移。

这可能意味着你青睐的插件到头来并不包括在内，这里的“可能”是个关键词。实际上，这个“可能”也许是这整个变化失败的原因。为什么?因为Mozilla的工作人员还没有办法解决所有的问题，哪怕公布了这则宣布之后。开发人员现在毫无动机来更新插件，因为知道一年后，他们不得不完全重新编写代码，我们怎么看待这个事实?如果开发人员不想迁移到新的API(因为Mozilla可能允许将来在一定程度上可以访问XUL)，又会怎样呢?Mozilla又如何吸引开发人员做出改变呢?

对于未来我的看法是，Mozilla会有办法解决这类问题，然后宣布做出如此重大的变化。眼下，火狐不太受待见。Mozilla最不想看到的一幕是，所有插件开发人员弃船而逃，改用一项针对未来制定明确计划的技术，也就是Chrome。

别误会我的意思，我认为这对火狐这款开源浏览器来说是积极的变化，当然取决于这个变化确确实实奏效。如果最后我们看到火狐可用插件的数量(和质量)同时上升，那么这种迁移将会是值得的。另一方面，要是没有多大的变化，或者我们发现高质量插件的数量比较少，这可能无异于为火狐敲响了丧钟。

为了成为更独一无二的火狐，火狐看起来越来越像Chrome。这是向前迈出的正确一步吗?坦率地说，现阶段(加上所有这些迫在眉睫的问题)，我不能说是正确的一步。如果开发人员决定支持新的API，火狐会迎来复兴。然而，如果开发人员弃船而逃，那么结局也就可想而知。

作为一名火狐用户，我希望这是Mozilla基金会方面做出的明智举动。你有何观点?这到底是明智举动，还是更像是丧钟?