火狐正在做不可想象的事情。也許我應(yīng)該說，火狐正在做不可思議的事情。也許我應(yīng)該就說，火狐在做開頭非常正確，但是結(jié)果可能非常錯誤的事情。

　　它在積極擁抱Chrome。

　　但不是直接擁抱。它所做的是擁抱WebExtensions API，這是與Blink兼容的新API。Blink恰好是由Chromium項目開發(fā)的一種Web瀏覽器引擎，它是WebKit的WebCore組件的一個分支。

　　明白了嗎?

　　這已引發(fā)許多傳聞盛傳于坊間。其中一個傳聞是，火狐會扔掉自己的插件，改用谷歌Chrome的附件。這在某種程度上來說是錯誤的。Mozilla基金會已決定，讓插件開發(fā)與Web開發(fā)更加保持一致。換句話說，這是某種“開發(fā)一次，由許多瀏覽器運(yùn)行”的方法。

　　Mozilla的渠道經(jīng)理Kev Needham在官方聲明中說：

　　“我們希望附件開發(fā)更像是Web開發(fā)：同一代碼應(yīng)該可以在多個瀏覽器中運(yùn)行，遵守由標(biāo)準(zhǔn)確定的行為，還附有多家開發(fā)商提供的全面的說明文檔。”

　　無論從哪個角度來看，這應(yīng)該被視為向前邁出的很重要的一步。首先，開發(fā)火狐插件總是比Chrome和Opera來得復(fù)雜。原因何在?因為火狐目前利用XUL和XPCOM之類的技術(shù)，用JavaScript開發(fā)插件，以便可以訪問底層的功能特性。那老一套正在被逐漸淘汰，改用新的Jetpack SDK(它并不使用任何較低層的API)。

　　一旦這一步落實(shí)到位，Chrome和Opera附件的開發(fā)人員就比較容易將應(yīng)用程序遷移到火狐，從理論上來說是這樣。

　　然而，開發(fā)人員會面臨一大障礙。自從火狐42起，所有插件在部署之前先由Mozilla進(jìn)行審核和簽名。由于WebExtensions API，這個審核過程將縮短至最多五天(從理論上來說是這樣)。

　　對于那些擔(dān)心青睞的插件在新系統(tǒng)下無法正常運(yùn)行的人來說，其中一些擔(dān)憂并非完全沒有道理。原因何在?因為許多現(xiàn)有的插件不得不從頭開始重新編寫。這并不意味著它們到時會從頭開始重新編寫。插件是不是重新編寫以便在新框架下正常運(yùn)行，這將取決于每個插件的開發(fā)人員。Mozilla的確計劃與開發(fā)人員合作，讓這個遷移過程盡量順暢，但是這無法保證所有插件確實(shí)會進(jìn)行遷移。

　　這可能意味著你青睞的插件到頭來并不包括在內(nèi)，這里的“可能”是個關(guān)鍵詞。實(shí)際上，這個“可能”也許是這整個變化失敗的原因。為什么?因為Mozilla的工作人員還沒有辦法解決所有的問題，哪怕公布了這則宣布之后。開發(fā)人員現(xiàn)在毫無動機(jī)來更新插件，因為知道一年后，他們不得不完全重新編寫代碼，我們怎么看待這個事實(shí)?如果開發(fā)人員不想遷移到新的API(因為Mozilla可能允許將來在一定程度上可以訪問XUL)，又會怎樣呢?Mozilla又如何吸引開發(fā)人員做出改變呢?

　　對于未來我的看法是，Mozilla會有辦法解決這類問題，然后宣布做出如此重大的變化。眼下，火狐不太受待見。Mozilla最不想看到的一幕是，所有插件開發(fā)人員棄船而逃，改用一項針對未來制定明確計劃的技術(shù)，也就是Chrome。

　　別誤會我的意思，我認(rèn)為這對火狐這款開源瀏覽器來說是積極的變化，當(dāng)然取決于這個變化確確實(shí)實(shí)奏效。如果***我們看到火狐可用插件的數(shù)量(和質(zhì)量)同時上升，那么這種遷移將會是值得的。另一方面，要是沒有多大的變化，或者我們發(fā)現(xiàn)高質(zhì)量插件的數(shù)量比較少，這可能無異于為火狐敲響了喪鐘。

　　為了成為更***的火狐，火狐看起來越來越像Chrome。這是向前邁出的正確一步嗎?坦率地說，現(xiàn)階段(加上所有這些迫在眉睫的問題)，我不能說是正確的一步。如果開發(fā)人員決定支持新的API，火狐會迎來復(fù)興。然而，如果開發(fā)人員棄船而逃，那么結(jié)局也就可想而知。

　　作為一名火狐用戶，我希望這是Mozilla基金會方面做出的明智舉動。你有何觀點(diǎn)?這到底是明智舉動，還是更像是喪鐘?