Wednesday, March 23, 2016

批踢踢實業坊 Browsers 板: [-Fx-] 火狐還有未來嗎orz

批踢踢實業坊 Browsers 板

// via fulltextrssfeed.com

[-Fx-] 火狐還有未來嗎orz
http://www.ptt.cc/bbs/Browsers/M.1458663067.A.4C2.html
Mar 22nd 2016, 23:02


作者danny0838 (道可道非常道)
看板Browsers
標題[-Fx-] 火狐還有未來嗎orz
時間Wed Mar 23 00:11:05 2016
最近 Firefox 不少政策帶給開發者和使用者非常多麻煩,甚至不曉得 Firefox 未來能不能存活下去。爬了點文看到不少版友對此有疑惑,但相關討論並不多, 中文的更少,所以在下稍微拋點磚,或許各位老的與新的 Firefox 支持者有所 瞭解後能做些什麼以突破困局;再不然,早點認清現實以免被套牢也好。 不知不覺寫太長了,先講一下重點: Firefox 打算讓舊方法寫成的套件未來無法使用,強迫所有套件開發者改用新 API 寫套件,新 API 和 GC 擴充元件的 API 語法幾乎一樣,也一樣功能受限 。問題來了:有 Firefox 特色的套件幾乎都是有複雜功能,GC 上寫不出來,才 會成為 Firefox 特產,也就是說,這些特色套件十之八九無法用新 API 寫出來。 Firefox 聲稱會和目前特色套件開發者溝通,並適度強化新 API 的功能性,讓 目前特色套件能做的在未來也能用新 API 做到,不過說是說,目前還沒看到具 體案例。況且,許多特色套件的開發者並沒有多餘的時間和精力去鑽研新 API 與新寫法,這些套件可能成為絕響。目前使用者選擇 Firefox 的理由幾乎都是 因為有功能強大的套件,一但套件無法再支援新版,未來恐怕就沒人用火狐了。 以下是落落長廢話,有空就看看吧XD Mozilla 近來有四大政策: http://j.mp/1RiwaPh 1. 引進 WebExtension API WebExtension API 是一種和 Chrome extension 相似度極高的 API,因此理論 上開發者只要加入一些特定的相容性程式碼,就可以讓一個套件能在 Chrome 和 Firefox 上運作,而不用為兩者各寫一套。 如果不看其他幾項,這項基本上是有利無弊。 2. 引進多程序系統 (Electrolysis,簡稱 e10s) 所謂多程序系統是讓瀏覽器界面和每個分頁的界面切開各跑各的,這樣能帶來的 好處是當分頁當掉或程式碼跑太久時,瀏覽器不會因此整個當掉。但是它可能會 比較吃資源(看看多程序的 Google Chrome...)。 此外多程序系統有個很大的問題是把分頁和瀏覽器界面分開,當它們本來是一體 時,附加元件可以直接存取瀏覽器界面,當它們分開了,瀏覽器套件就不能直接 存取頁面內容,也無法修改它們,而必須使用其他方式,比如聯絡頁面的程序並 在裡面載入腳本,然後透過互相傳訊交流訊息。 這樣的改變就造成了很多本來在單行程系統運作的套件必須大幅改寫架構才能做 到相同功能,且大體而言新架構要考慮比較多東西,會比舊架構複雜、難寫很多 。 除了程式碼架構變複雜以外,Firefox 的開發者工具在換到多程序系統以後也不 正常,本來可以直接 console.log 輸出除錯訊息的,換到多程序系統可能會看 到除錯訊息變成 undefined 或 unavailable,因為它們是來自另一個程序,內 容無法直接存取。 Firefox 自 42.0 版開始支援 e10s,使用者可以自由切換,不過即將改為預設 使用多程序,未來甚至可能再也不能切換為單程序。不能在多程序系統上運作的 舊套件,如果開發者不去做功課再及花時間改寫套件,將再也不能使用。 這就是開發者會不爽的理由之一:為什麼要花一大堆時間去研究新寫法、大幅改 寫舊套件?而且這樣改寫幾乎沒什麼好處,只是為了相容新版而已。還有,為何 一定要改成多程序?難道繼續讓使用者可以選擇單程序與多程序不行嗎? 此外,改為多程序會比較順暢嗎?我目前的觀察是沒有,目前的多程序 Firefox 還是常有莫名的卡頓,有時還會整個視窗凍結(雖然是沒有當掉,但 還是不能操作啊XD)希望這只是短暫的 bug 囉 XD 3. 套件強制簽署 自 Firefox 42.0 開始,沒有在 AMO 上架、通過審核、取得簽署的套件,將無 法安裝。目前使用者還可以在 about:config 修改設定值覆蓋此設定,但預計在 Firefox 46.0 以後將無法覆蓋設定,換言之,沒取得簽署的套件將再也無法安 裝。 這就是開發者和使用者都會不爽的理由:對使用者而言,為什麼要禁止未簽署的 套件?秀個警示訊息讓我知道套件未簽署且可能有安全風險難道不行?對開發者 而言,開發和測試套件要簽署也太麻煩了吧? 開發者可以做的是改用其他發行版的 Firefox ,目前只有正式發行版以及 beta 版會強制簽署且無法覆蓋設定,其他像 Firefox Aurora、Firefox nightly、以及開發者版本則可以設定成不強制簽署,所以想要裝一些 AMO 不放 行高端功能的玩家可以這樣做,不過這些發行版更新比較快、也可能較不穩定。 4. 棄用 XUL 及 XPCOM XUL 和 XPCOM 是深植於 Firefox 及核心渲染引擎 Gecko 的組件。XUL 是定義 使用者界面的一種 XML 語言,其中有個稱為 XUL overlay 的特性是讓開發者可 以用一個 XUL 的界面覆蓋另一個 XUL,這技術讓開發者可以直接改寫 Firefox 的核心界面,比如瀏覽器界面 chrome://browser/content/browser.xul。 XPCOM 則是一整套集網路連線、檔案系統存取等功能於一身的組件。 XUL 和 XPCOM 是 Firefox 之所以功能強大、能做多許多 CG 不能做的事的理由 ,但 Mozilla 宣布他們即將在一至兩年內棄用,理由是 XUL 和 XPCOM 能夠整 個改寫核心,造成安全風險,此外也讓不同套件之間的衝突很難偵測,也讓審核 者很難審核。 照說注重安全是好事,換掉這套架構也會讓未來開發與相容性處理更輕鬆,但最 大的難題是──開發者和使用者之所以會選擇 Firefox ,就是因為它有功能強 大的套件,能做到 chrome、opera、safari 等瀏覽器根本做不到的事,如果拿 掉 XUL/XPCOM,Firefox 豈不和其他瀏覽一樣功能不足?這樣的 Firefox 還值 得使用嗎? 目前 Firefox 有三種套件系統: 1. XUL overlay 套件:就是之前說的,用套件的 XUL 覆蓋原來的 XUL 界面, 並插入額外的樣式或腳本。棄用 XUL/XPCOM 以後當然是整個 GG 2. bootstrap 套件:自 Firefox 4.0 引進。使用 bootstrap.js 腳本控制套件 安裝、載入、卸載、移除時執行些什麼,因此安裝、更新、卸載時可以不用重新 啟動 Firefox。bootstrap 不能使用 XUL overlay,但基本上還是透過修改 XUL 元素來改變界面,棄用 XUL/XPCOM 以後也是 GG 3. Addon SDK 套件:這是一種用 node.js 寫成的模組,開發者寫好程式碼以後 ,可以用 Addon SDK 執行測試環境,也可以把程式碼打包成 .xpi 安裝檔。 由於 Addon SDK 會處理很多低階的打包任務,讓開發者能夠用比較簡潔的程式 碼開發想要的功能,而不必像 bootstrap 套件一樣親自去控制許多安裝、卸載 要執行什麼東西,或者像 XUL overlay 去親自控制系統核心。 但 Addon SDK 也有很多問題: 1. 只能在 Firefox 38.0 以後執行 2. 由於 SDK 只針對 Firefox 設計,Addon SDK 套件不能在其他基於 Gecko 的 瀏覽器上運作,比如 SeaMonkey 和 Pale Moon。這對想開發跨平台套件的人是 個困擾。 3. Addon SDK 功能相當有限,官方聲稱會支援高階 API,開發者只要繼續使用 高階 API,就可以在未來及現在的 Firefox 上運作,但其實有非常多功能是高 階 API 根本不提供的,必須使用低階 API,而官方沒有保證低階 API 未來不會 變動或無法使用。 其他還有我遇過的問題是多語系翻譯總是不正常,我明明有提供 zh-TW 語言包 ,執行時卻總還是英文 orz 4. 無論是高階或低階 API,其實打包後都是 bootstrap 套件,其調用的模組最 後還是會調用 XPCOM 組件,如果 Firefox 要棄用 XPCOM 組件,未來Addon SDK 怎麼可能還能用? 這點 Firefox 開發者也沒給明確說明,我之前詢問時有人員回答:政策上的棄 用不等於技術上的棄用。言下之意似乎是說所謂棄用 XUL/XPCOM 並非技術上而 是政策上,也就是它們未來還是可以跑,只是 AMO 會把審核這種套件的優先度 壓低、甚至拒審。而這些拒審應該也是有條件的,比如既有套件的升級或修 bug 應該不太會拒審。 如果是這樣,就能解釋前面的問題,也會是超大的好消息──這表示目前的 XUL/XPCOM 套件開發者可以繼續原來的做法,AMO 願意審就審,不願意審那就 改用允許不強制簽署的發行版XD 是否有那麼樂觀,可能也無法確定,因為有另一種可能是 Firefox 真的打算把 底層的 XUL/XPCOM 全部抽掉,Addon SDK 只是保留 API,但中間的打包階段全 面修改,讓它能在新的 Firefox 上編譯成不基於 XUL/XPCOM 的程式碼,但這樣 針對新版 Firefox 包出來的套件可能會不能在舊版 Firefox 上運作,這會違背 當初說 Addon SDK 「跨版本相容」的保證 。 這可能性高不高我無法確定,不高的理由是現在 Firefox 核心架構整個都是 XUL/XPCOM,整個抽掉談何容易;高的理由是 Mozilla 已開始開發新的瀏覽器 引擎 Servo,有可能會想用它取代 Gecko(但也可能只是給行動平台使用,而現 在的 Firefox for Android 本來就不使用 XUL 而是使用 Android 原生界面指 令) 還有另一點是連 Addon SDK 也不一定有未來,畢竟在 WebExtension 發展起來 後,我真的想不出有什麼理由去寫 Addon SDK。況且 Mozilla 有前科:Addon SDK 前身是 python 開發的 cfx,它現在已經被棄用了。 身為開發者,如果是技術上棄用 XUL/XPCOM,我會非常不能諒解──增加 WebExtension 支援是很好,但為什麼要把自己的特色砍掉?把以前一向運作良 好的套件殺死? 第四種則是上述的 WebExtension,它的主要問題是: - 只支援 Firefox 45.0 以後版本,老一點的都不行 - 目前功能非常有限,GC 寫不出來的東西幾乎都寫不出來 - 有不少 BUG 總之現在 Firefox 套件開發者可說怎麼做都不討好: 1. 使用 XUL、bootstrap 可確保現在能跑;如果需要比較強的功能,更是目前 唯一能做的。但人家都放話說一兩年內要棄用,你敢繼續寫嗎? 2. 改用 Addon SDK,但這架構功能非常有限,許多關鍵功能仍須調用不穩定的 低階 API,甚至直接調用 XUL 與 XPCOM,而這麼做一樣無法免於棄用威脅。還 有,在 WebExtension 起來後這東西有未來嗎? 3. 改用 WebExtension,但目前這系統和 Chrome 一樣功能有限,寫不出什麼高 端東西,而且因為還在起步階段,可能會有很多 bug(在下試做時就遇到了一兩 個)。 老實說,可以用 WebExtension 寫的東西,大概早就能在 GC 上寫出來了,而目 前所有 Firefox 有特色的套件,幾乎都是 GC 無法寫出來的。 據某些開發者所言(如 NoScript 開發者),Firefox 確實有在向熱門套件的開 發者徵求意見,且據說會據此擴充 WebExtension 的 API 使它能做到許多 Firefox 以往能做到的強大功能。如果這是真的,或許未來 Firefox 在加強版 WebExtension 的加持之下還會有一定地位也說不定。 所以,開發者現在能做什麼呢? 1. 持續向 Firefox 團隊反映意見,讓它們把 WebExtension 功能擴展到夠強, 否則 Firefox 未來可能會是隻和 GC 差不多弱的死狐狸。 2. 只要可以,乾脆先跳槽去寫 GC 擴充元件,等 WebExtension 成熟點再移植 過來XDD 或者現在就移植,不能移植就報 bug。 3. 透過各種手段說服開發團隊不要真的技術上棄用 XUL/XPCOM,政策上棄用就 暫且吞下去吧... 4. 透過各種手段說服開發團隊不要在未來廢除單程序 Firefox 5. 早點洗洗睡了,蹚這灘渾水那麼久也是醉了吧? 6. 其他?有等高人指教........XDD -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.243.229.128 ※ 文章網址: https://www.ptt.cc/bbs/Browsers/M.1458663067.A.4C2.html ※ 編輯: danny0838 (111.243.229.128), 03/23/2016 00:16:24 ※ 編輯: danny0838 (111.243.229.128), 03/23/2016 00:18:11
推 kenwufederer: 時間問題而已 03/23 00:25
→ kenwufederer: 就我使用習慣,chrome已經完全取代Firefox 03/23 00:26
→ kenwufederer: 要不是OS是FreeBSD,Firefox根本沒優勢啦 03/23 00:27
※ 編輯: danny0838 (111.243.229.128), 03/23/2016 00:31:59
推 randy123: 目前自己使用是沒遇過沒有非fx專有的套件,仔細找找還是 03/23 00:39
→ randy123: 有可取代的 03/23 00:39
你們很幸運。其實我也覺得一般使用者用GC就好(至少比IE好), Fx留給要高功能的人去折騰就夠了XD 不過,如果未來 WebExtension 搞起來,GC 的套件也都能在 Fx 使用, 那或許可以反過來說,GC 相對於 Fx 根本沒優勢了。^^" ※ 編輯: danny0838 (111.243.229.128), 03/23/2016 00:47:14
推 randy123: 相對GC我還是喜歡FX,但fx開大量網頁會卡頓(記憶體使用超 03/23 00:52
→ randy123: 過1G),GC開啟網頁反應快多了,session buddy套件又好用 03/23 00:52
→ randy123: 就回不去了呢 03/23 00:52
推 Seventhsky: 想到DTA 作者就是被火狐政策搞到惱羞就直接放棄開發 03/23 01:03
補連結:http://j.mp/1U5tmLk 看來這些作者的不滿比我還粗暴XD 不曉得如果 WebExtension API 有提供 DTA 需要的功能後他們還願不願意做... ※ 編輯: danny0838 (111.243.229.128), 03/23/2016 01:22:31
→ hijacker: 反正到時走不下去的話 就再走回頭路就好了 03/23 01:35
希望開發團隊懂得審時度勢, 當初說要 Fx 42.0 強制套件簽署, 結果現在延到 46.0 才要實施。 也許棄用 XUL/XPCOM 發現短期不可行會再延後, 等 WebExtension 等架構成熟到現有套件可以轉移才會實行吧。 (本來就應該這樣不是嗎XD) 原來的開發者還願不願意花心力遷移會是個問題, 如果他們做不到,或許 Mozilla 自己派人來改寫?
→ hijacker: 但不管怎麼發展 fx的市佔只會越來越小 03/23 01:36
→ hijacker: 尤其未來的戰場是在行動裝置 android被google把持下 03/23 01:36
→ hijacker: 其他瀏覽器機會沒幾乎 除非google跟M$一樣犯傻 03/23 01:37
→ hijacker: 幾乎沒機會 03/23 01:38
其實不一定欸,像 Android 瀏覽器據我所知只有 Firefox 可以裝 Addon。 WebExtension API 如果可以跨桌面和行動版 Firefox,那會有潛力。 即使不談 Addon,目前在 Android 上我個人也是用 Firefox 作為主要瀏覽器, 據我觀察一般功能及瀏覽效果 Firefox 表現是比其他瀏覽器好。 ※ 編輯: danny0838 (111.243.229.128), 03/23/2016 01:47:05
推 hiroki03: 我覺得Android上的Fx,優勢的確是可以自訂插件,能辦到其 03/23 02:02
→ hiroki03: 他瀏覽器做不到的使用體驗 03/23 02:02
→ hiroki03: 但我也覺得有安裝插件的Andorid版Fx,耗電程度比其他原生 03/23 02:03
→ hiroki03: 瀏覽器來的高 , 我本來手機也都使用Fx為瀏覽器,但明顯電 03/23 02:04
→ hiroki03: 力能瀏覽的時間變短了,最後在手機上還是換回了GC,畢竟手 03/23 02:05
→ hiroki03: 機還是以持久瀏覽為考量 03/23 02:06
→ hiroki03: 當然PC上還是使用FX為主,GC為輔 03/23 02:07
耗電的問題我沒注意過,不曉得把套件停用會不會改善? ※ 編輯: danny0838 (111.243.229.128), 03/23/2016 02:19:52
→ mindsteam: 用Fx的人不見得是因為套件很多。我主力使用的Fx只裝了 03/23 02:20
→ mindsteam: "No Script"這麼一個套件而已。 03/23 02:20
同意,多不多不是重點,有沒有想要的關鍵功能才是重點。 ※ 編輯: danny0838 (111.243.229.128), 03/23/2016 02:22:18
推 zhtw: 選項五,洗洗睡吧XD 03/23 02:56
→ zhtw: 把自己的優點都砍掉,chrome沒有的fx不能有,這才是mozilla的 03/23 02:56
→ zhtw: 政策吧! 不離不棄被當北七。 03/23 02:56




You are receiving this email because you subscribed to this feed at https://blogtrottr.com

If you no longer wish to receive these emails, you can unsubscribe here:
https://blogtrottr.com/unsubscribe/1m3/ztjvfC

No comments:

Post a Comment