Re: [-Fx-] 火狐還有未來嗎orz

看板Browsers作者 (ettoolong)時間9年前 (2016/03/23 12:17), 9年前編輯推噓15(15推 0噓 27→)
留言42則, 15人參與, 最新討論串2/3 (看更多)
※ 引述《danny0838 (道可道非常道)》之銘言： : Mozilla 近來有四大政策： : http://j.mp/1RiwaPh : 1. 引進 WebExtension API WebExtension API 很不錯, 提供這個的話可以讓 Chrome 的套件很容易地移殖到 Firefox 上, 但是如果因為提供 WebExtension API 就把既有的套件系統砍到一個 不剩, 反而是本末倒置. : 2. 引進多程序系統 (Electrolysis，簡稱 e10s) 這個改變只會影響到一部份套件, 不是全部. 套件寫法有可能變得比原本複雜, 這 是真的, 因為有一好沒兩好. 這個不是強制的功能, 使用者仍然可以選擇關掉e10s. 如果真的有個套件在 e10s 下無法使用, 而你又非用這個套件不可, 就可以選擇關 掉 e10s. 使用 addon sdk 開發是另一個選擇, 它處理掉了跟 e10s 有關的問題. 另外, 用 console log 查套件問題是比較陽春的做法, 正常是應該用內建的 debug 工具下斷點, 然後直接查看你說的那些無法直接從 console log access 的物件. 參考: https://developer.mozilla.org/en-US/Add-ons/Add-on_Debugger : 3. 套件強制簽署 這個是保護使用者的方式, 至於有沒有造成開發者問題呢? 我想問題應該不大. 在沒這個機制前, 開發者可以寫一個套件, 放在自己的下載點, 不用放上 AMO, 使用者裝了這個套件, 如果這是一個有問題的套件, Firefox 沒有主動撤銷這個 套件的能力. 接下來看看有這個簽章機制後的情況: 一個套件如果沒有在 AMO 上架, 依然可以 自行加上簽章(請更新你的 jpm 開發工具, 新版可以自行簽章), 然後放在自己的 下載點. 一旦這個套件被回報為有問題的套件, 官方是可以直接撤銷這個簽章, 防堵有問題的套件再被安裝使用. 至於已經在 AMO 上的, 那是經過人工審核的, 有過審議就會自動簽. 也就是說, 對原有的開發者來說, 如果你的套件不放上 AMO, 就是多了一個自行 簽章的動作而已, 這應該不是什麼大問題. 參考: https://blog.mozilla.org/addons/2015/12/18/signing-firefox-add-ons-with-jpm-sign/ 縮: https://goo.gl/toxzPd : 4. 棄用 XUL 及 XPCOM 這確實是一個大問題, 但我覺得那可能是很久以後的事, Servo 引擎要實用化估計 也可能要再一兩年. XUL 是陳舊的包袱, 相對來說, addon sdk 降低了很多開發門 檻. 說真的完全砍掉 XPCOM 的衝擊還比砍掉 XUL 大, 幾個點我覺得可以再討論: XUL overlay 作得到, addon sdk 作不到的功能: 我有幾個 XUL overlay 套件, 功能最複雜的那一個, 用了很多 XUL overlay 的東 西, 但是這陣子試著移到 addon sdk 上, 還沒遇到真的無法搬過去的功能. 你想得 到的介面修改, 應該都還是能用 addon sdk 改出來, 只是這可能會用到低階 API, 之後需要持續關注相容性問題, 但這些問題, 用 XUL overlay 也一樣會遇到. 當然, 還是有可能會有無法移殖的情況, 例如 Firefox UI 層面的大魔改, 只是我 目前還沒有遇到, 也許再多移殖幾個套件後我就會遇到. 用 addon sdk 開發遇到語系問題: 我好像也遇過, 跟語系檔的編碼有關, 還有一次是 profile 被我搞壞掉造成多語 系不正常, 你可以參考看看. 沒了 XPCOM, addon sdk 還能用嗎: 基本上 addon sdk 就是一層介面封裝, 所以只要你用 addon sdk 的高階 API, 基本上不用太擔心 XPCOM 問題, 因為介面不動, 只動底層實作是可行的. 也就是說 如果你只用到高階 API, 就是只用到最上層的介面, 底層的 XPCOM 實作就變成可以 被抽換掉實作而不影響你的套件. 至於低階 API, 裡面當然就有可能用到 XPCOM 或是更多核心元件, XPCOM 被換掉後 確實就有可能不能用, 所以開發者就要多多關心一下相關的核心變動. 但我想這問題就跟你用 addon sdk 開發沒啥關係. 回想一下, 傳統使用 XUL overlay/XPCOM 的套件一樣會有這些隨核心變動而 要處理的相容性問題, 不是嗎? Addon sdk 只有 Firefox 能用: 這可能是個問題, 不過如果是其他社群版的 Firefox, 只要 Gecko 核心版號有跟上 官方 Firefox, 應該就沒問題, 之前有 Pale Moon 使用者來跟我反映套件相容性 問題, 我才發現 Pale Moon 的核心停在很舊的一版 Gecko, 不知道現在是不是還是 這樣. 如果是的話, 就有可能不能支援. cfx 被棄用: 其實 cfx 就只是一個工具, 幫你處理初始化套件, 打包套件這些瑣碎的工作, 你可以想成本來你用記事本寫 code, 現在改用 sublime. 我覺得這沒有什麼問題. 套件不給力的 Firefox 和 Chrome/Chromium二創 還有啥不同: 本質上的不同, Firefox 帶給了使用者選擇的機會, 一個不被 Chrome (來自 Google — 全球最大的廣告公司) 控制的機會, 使用者有了選擇, 選擇 Chrome 或是 Firefox 取決於你自己, 而不是像回到 IE 壟斷的年代, 使用者沒有選擇. Android 上的 Chrome 為什麼沒有套件, 因為類 adb 的套件就是這個最大的廣告 公司最不想看到的. 向 Firefox 團隊反映意見: 開發者的反饋我想還是非常重要的, 如果真的遇到開發上的限制, 可以提出討論, 我想不至於搞到最後變成因為限制而無法寫出重要的功能啦, 至少目前還不是這樣. 想持續關注 Mozilla 的相關議題, 可以來 MozTW 的聊天群組, 當然也會有套件 開發的討論. 可以交流一些使用和開發上遇到的問題. -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.160.11.21 ※ 文章網址: https://www.ptt.cc/bbs/Browsers/M.1458706661.A.C8C.html ※ 編輯: ettoolong (1.160.11.21), 03/23/2016 12:21:41
推
03/23 12:26, , 1F
PaleMoon 停在 Gecko 24
03/23 12:26, 1F
→
03/23 12:28, , 2F
我也覺得 XPCOM 兩年內砍不掉
03/23 12:28, 2F
推
03/23 12:42, , 3F
冒出一個公道伯讓我很不習慣…
03/23 12:42, 3F
推
03/23 12:49, , 4F
e從開發者觀點出發，帶來了很多使用者看不到的問題和想法
03/23 12:49, 4F
推
03/23 12:49, , 5F
PaleMoon其實很..PCX之前吐嘈過 不覺得 PaleMoon比原版好
03/23 12:49, 5F
→
03/23 12:49, , 6F
真的很棒。而且一些非關開發的觀點也闡述得非常好
03/23 12:49, 6F
→
03/23 12:50, , 7F
有時間我也會分享一下我的看法
03/23 12:50, 7F
→
03/23 12:50, , 8F
補充：不覺得比原版好是我說的，不是PCX的吐嘈內容
03/23 12:50, 8F
→
03/23 12:51, , 9F
不過不得不說，有些使用者確實有點過度窮擔心或是太鑽牛角
03/23 12:51, 9F
→
03/23 12:52, , 10F
尖在某些看似似是而非的議題。適度給M社信心，或是去看一
03/23 12:52, 10F
→
03/23 12:53, , 11F
些比較知名編輯（外文）的文章，看看他們是怎麼分析M社
03/23 12:53, 11F
→
03/23 12:53, , 12F
的動作，還有他們的對未來的看法，這樣比較不會自己窮擔心
03/23 12:53, 12F
推
03/23 13:26, , 13F
ES6 這幾年大發展, PaleMoon現在連Promise支援都沒做好.
03/23 13:26, 13F
推
03/23 13:45, , 14F
我是覺得Chromium與Chrome還是要分開來看
03/23 13:45, 14F
→
03/23 13:46, , 15F
Google能控制的部份是Chrome完全控制 但是大家要拿Blink
03/23 13:46, 15F
→
03/23 13:46, , 16F
做成什麼樣子是Google所無法控制的
03/23 13:46, 16F
你說的沒錯, 但是同樣是 Blink 核心這點, 就可以想成這個核心的市占率. 你可以想像, 如果市面上只剩 Blink 核心, 以後 web 的標準是不是可以 Google 說了算? iOS 堅持不開放其他核心的一個原因就是, 只要 iPhone 賣得還不錯的一天, Apple 就可 以保證 webkit 核心在行動平台上有一定的占有率, Apple 對行動平台上的 web 相關標 準制定就可以有一定的話語權(簡單說就是說話比較大聲啦). 開放 Chromium 對 Google 最大的好處就是實質提高了 Blink 核心的市占率, 因此 Google 就可以說話大聲一點. 如果變成一個核心獨大, Google 會不會制定對他們 有利的標準? 反正 Google 說了算. 使用 Chromium 再改造的瀏覽器當然可以作出 Google 不提供給使用者的東西, 但也別 忘了, 真正的核心 Blink 還是在 Google 手裡. 這才是 Google 參與制定 web 標準的 最大本錢. 我不是叫大家不要用 Blink 核心, 我想說的是 選擇的自由 對使用者的重要性.
推
03/23 13:46, , 17F
寫了這麼多 我給你讚 但套件作者還是一個接一個逃跑
03/23 13:46, 17F
推
03/23 13:46, , 18F
推
03/23 13:46, 18F
推
03/23 14:01, , 19F
好文推～
03/23 14:01, 19F
※ 編輯: ettoolong (1.160.11.21), 03/23/2016 14:48:18
推
03/23 15:00, , 20F
如果討論的是核心分歧的話 這個論點是沒錯
03/23 15:00, 20F
推
03/23 15:44, , 21F
03/23 15:44, 21F
→
03/23 15:48, , 22F
現在能跟chrome競爭的也只有safari了
03/23 15:48, 22F
→
03/23 15:48, , 23F
那天要是iphone垮了 web標準大概就是google說了算了吧
03/23 15:48, 23F
→
03/23 15:53, , 24F
不過我是覺得壟斷也只是一時的 看看ie的下場就知道了
03/23 15:53, 24F
→
03/23 16:28, , 25F
可是safari在Windows玩不到新貨啊
03/23 16:28, 25F
→
03/23 16:29, , 26F
而且safari還有主場優勢，規則爸爸(Apple)定的
03/23 16:29, 26F
→
03/23 16:32, , 27F
三國演義說合久必分，分久必合，網路標準好像也是這樣
03/23 16:32, 27F
→
03/23 16:33, , 28F
就算現在看來要"合"了，你也不知道未來會不會因為什麼
03/23 16:33, 28F
→
03/23 16:33, , 29F
契機又"分"了
03/23 16:33, 29F
推
03/23 16:50, , 30F
想請問FX與GC兩者，哪個開發套件比較容易？
03/23 16:50, 30F
推
03/23 17:15, , 31F
正確來說是Blink vs Webkit 但是Blink太容易取得拉...
03/23 17:15, 31F
→
03/23 17:15, , 32F
不過現狀是Blink贏了桌面 Webkit贏了Mobile
03/23 17:15, 32F
推
03/23 20:19, , 33F
原來是有些好處...只是每次UI魔改真的都很痛...
03/23 20:19, 33F
→
03/23 20:21, , 34F
感謝好文
03/23 20:21, 34F
推
03/23 20:40, , 35F
難道Fx只有階段性任務，就是給大家選擇的機會？
03/23 20:40, 35F
→
03/23 20:42, , 36F
你要給大家選擇的機會，也拜託做好差異化吧
03/23 20:42, 36F
→
03/23 20:43, , 37F
若Fx的優勢失去太多，大多數的人會怎麼選？
03/23 20:43, 37F
→
03/23 20:44, , 38F
推動free web和維持優良傳統，並沒有衝突
03/23 20:44, 38F
→
03/23 20:45, , 39F
不是棄守城池後再來說還好還扮演了free web守護者吧
03/23 20:45, 39F
→
03/23 20:47, , 40F
講了很多很好，但新架構套件不給力的問題到底怎麼辦
03/23 20:47, 40F
→
03/23 23:27, , 41F
老實說我現在主力用Fx的原因之一就是因為它的排版引擎
03/23 23:27, 41F
→
03/23 23:28, , 42F
不是Blink……。
03/23 23:28, 42F
‣ 更多 ettoolong 的文章
文章代碼(AID): #1MyXZboC (Browsers)
‣ 更多 ettoolong 的文章
文章代碼(AID): #1MyXZboC (Browsers)