[-Fx-] 四個主要革新(自我毀滅開始?)
相信大家都看到近來模基拉動作頻頻,不斷放出未來計畫的項目新聞稿
面對變革,常常必須面對批評和既有使用者的一片看衰在所難免
這次就稍微整理一下最近在各大科技網站上看到的資訊
標題的梗其實是來自ghacks的文章:
Mozilla’s self-destruct course continues: major add-on compatibility
changes announced
http://bit.ly/1MH9U2c
ghacks編輯馬丁就在這篇文章內就整理四個未來重大的革新計畫
1. WebExtensions
了解更多:Firefox 瀏覽器迎來重大升級:Chrome 外掛可輕鬆移植
http://techcrunch.cn/2015/08/22/chrome-extensions-are-coming-to-firefox/
2. Multi-process Firefox / Electrolysis (e10s)
3. Add-on Signing
4. Deprecation of XUL, XPCOM and the permissive add-on model
了解更多:Mozilla to Depreciate add-ons using XUL, XPCOM, or XBL
http://bit.ly/1U8mgkq
WebExtensions
就是以參考Google的套件 API 來打造一個新的 FX 套件 API,以便取代原有套件架構。
已經有不少使用者不齒這項決定,認為這是一種倒退、舔 G社LP、放棄自己的特色等等
這些理由都可以被理解,但是站在M社的立場來說,提出新的架構出於以下目的
1.接軌G社的套件開發架構
我認為這是無可奈何之舉,或許大家會認為FX強大的地方就來自於套件
套件的自由度高使得套件所帶來的效益極大,是FX的財富之一
此舉簡直就是壞了FX的套件系統,讓開發者出走(*節流失敗)
但或許M社看到是如果可以讓兩者的轉換成本降低,則有望吸引G社的套件
開發者把他們的套件上架到AMO(*開源成功)
FX的套件有特色、能做的事情多是既有的事實,但是更可怕是近來已經有
越來越多的套件只開發GC版,遠得不說,就說LINE網頁版好了
Evernote的套件也勤於在GC上更新甚至開發專屬的套件
這是不可否認的現實,市場占有率高就是老大,一切都是商業導向
如果你認同FX,希望他繼續活下去,而不是被GC鬥垮,那你應該支持革新
ASK:這樣不就放棄原本的高自訂化的套件架構了嗎?
ANS:稍後解釋。
2.E10S
一個新穎的程式架構,目的是為了讓程式可以更加穩定,瀏覽器本體、分頁、
套件之間的處理程序相互獨立,不會因為分頁當掉整個瀏覽器更跟著一起當。
這個爭議不大,而且多數使用者應該算是滿期待這項更新的。
但是這項重大的更新因涉及架構層,因此現有的套件若沒有做出調整則會導致
在E10S啟用時,失去作用。目前仍沒有具體在穩定版上線的計畫,不過
開發團認為應該會落在今年12月中的43版。
回到WEBEX上,它是完全相容與E10S的套件架構,因此開發者如果使用
新版的套件開發架構,就表示套件可以在E10S啟用的狀態下執行。
3.Add-on Signing
這個東西很討厭,連我也這樣認為。但是一樣基於安全性考量,它的出現有其
必要性。會來這個版的使用者基本上都有能力自訂瀏覽器,判斷網路上可能
的危險,但是其他90%的主流使用者是沒有這個能力的。禁制未簽名的套件
安裝將可能大幅減少使用者因誤點第三方惡意散播的連結而安裝有威脅的套件
。
目前的套件審核仍然採用人工的方式處理,未來如果WEBEX啟用,審核的
流程將可以加快。看到這裡你或許會發現,第一項被罵得半死的WEBEX架構
怎麼突然對(2)和(3)都有互助的效果。不是要幫M社說好話,但他們也不
是省油的燈,配套組合拳打出來有效果,對M社、開發者、使用者都有好處,雖
然過渡期必然會面對一些困境,但撐過去就好了。
而且未來針對不想被綁手綁腳的使用者也會推出一款沒有簽名限制的瀏覽器,如
你真的不喜歡,用第三方編譯版也是一個選項。再說如果你用的都是上架的套件
又何必擔心這個問題。所以簽名的事情我認為問題不大。
4.Deprecation of XUL, XPCOM and the permissive add-on model
這應該是最被詬病的一項,反對者都認為原有架構代表著FX套件的精神,絕對
不能放棄,而且認為一旦WEBEX和套件簽名啟用後,原有的高自訂套件就成了
絕響,舊的用不了,新的架構也開發不出來有這麼高自訂程度的套件,然後就
是FX已死,有事燒紙。
真的是這樣嗎?
直接來看看馬丁做的總結(http://bit.ly/1KepmlX):
.模基拉鐵了心要棄用XUL、XPCOM和permissive add-on model。
.WEBEX仍在開發中,它是基於GC的套件API,但絕非完全照搬。
.模基拉打算新增讓目前當紅的FX套件可以轉移到新架構的API,好讓他們不
會猝然失效。
.API當然不會像目前能做到的一樣強大。
.有多少套件會因為新架構的啟用而無法運作是一個未知數,端視他們的開發者
是否放棄開發或沒有把它們對應到新的架構中。
一些當紅的套件譬如 NoScript 和 Classic Theme Restorer 都是M社絕對
會重視,這些套件財富他們或許比使用者更加緊張。
當然一些較為小眾的套件可能最後仍會落得無法運作的結果,加上簽名的問題
也不能繼續使用。但是從長遠的角度來看,這樣決定理應是Z>B的,起碼官方
是這樣認為。
懶人包:
使用者不需要對新套件架構WebExtensions、棄用XUL、XPCOM、套件簽名有太多的擔心:
1. WEBEX架構完全相容於E10S。
2. WEBEX有助於讓原本專屬GC的套件出現在FX上。
3. WEBEX將針對當紅的套件實作API讓他們可以繼續使用,譬如CTR。
4. 未來會有不限制套件簽名的FX版本,也可以選擇第三方編譯版。
與其唱衰FX,不如期盼這套組合拳可以打出氣勢、打出機會。
最後補一個:
推
08/23 16:33,
08/23 16:33
看你怎麼想,如果你為GECKO最後會被棄用就算是下個一個PRESTO,那它應該有很高
的機會是,因為SERVO這個後浪遲早會讓 GECKO 死在沙灘上。
當然兩者不可等同視之,因為一個革新,做出更好的來取代,另一個我不想多說。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.113.73.123
※ 文章網址: https://www.ptt.cc/bbs/Browsers/M.1440359964.A.8C2.html
※ 編輯: t7yang (140.113.73.123), 08/24/2015 04:03:26
※ 編輯: t7yang (140.113.73.123), 08/24/2015 04:14:57
推
08/24 06:05, , 1F
08/24 06:05, 1F
→
08/24 07:15, , 2F
08/24 07:15, 2F
推
08/24 08:24, , 3F
08/24 08:24, 3F
→
08/24 08:28, , 4F
08/24 08:28, 4F
→
08/24 08:29, , 5F
08/24 08:29, 5F
→
08/24 09:18, , 6F
08/24 09:18, 6F
→
08/24 09:33, , 7F
08/24 09:33, 7F
推
08/24 10:29, , 8F
08/24 10:29, 8F
推
08/24 10:57, , 9F
08/24 10:57, 9F
→
08/24 11:02, , 10F
08/24 11:02, 10F
→
08/24 11:04, , 11F
08/24 11:04, 11F
→
08/24 11:08, , 12F
08/24 11:08, 12F
→
08/24 11:09, , 13F
08/24 11:09, 13F
推
08/24 12:48, , 14F
08/24 12:48, 14F
→
08/24 13:20, , 15F
08/24 13:20, 15F
→
08/24 13:21, , 16F
08/24 13:21, 16F
→
08/24 13:22, , 17F
08/24 13:22, 17F
推
08/24 15:12, , 18F
08/24 15:12, 18F
→
08/24 22:37, , 19F
08/24 22:37, 19F
推
08/24 23:04, , 20F
08/24 23:04, 20F
→
08/24 23:04, , 21F
08/24 23:04, 21F
推
08/24 23:54, , 22F
08/24 23:54, 22F
→
08/24 23:59, , 23F
08/24 23:59, 23F
推
08/25 10:43, , 24F
08/25 10:43, 24F
→
08/25 11:41, , 25F
08/25 11:41, 25F
推
08/25 17:51, , 26F
08/25 17:51, 26F
→
08/25 18:02, , 27F
08/25 18:02, 27F
推
08/26 12:09, , 28F
08/26 12:09, 28F
推
08/26 12:09, , 29F
08/26 12:09, 29F
推
08/27 21:14, , 30F
08/27 21:14, 30F
推
08/27 22:24, , 31F
08/27 22:24, 31F
→
08/28 23:55, , 32F
08/28 23:55, 32F
→
08/28 23:56, , 33F
08/28 23:56, 33F
→
08/29 00:26, , 34F
08/29 00:26, 34F
推
09/02 21:48, , 35F
09/02 21:48, 35F
推
09/29 02:04, , 36F
09/29 02:04, 36F