[博文]评论：为何说 Firefox 57 将是 Mozilla 有史以来最好的正式版本

这篇博客文章的作者是之前已多次介绍的活跃的 Mozilla 人员，德国人 soeren hentzshcel。
文章地址：https://www.soeren-hentzschel.at/firefox/kommentar-wieso-firefox-57-mozillas-bester-release-aller-zeiten-wird/
由于原文是德文，google 翻译为英文后我再尝试理解翻译，所以原文一些信息可能会理解有误，望大家理解指教。原文较长，没法完整翻译，只是提取作者主要观点翻译。


作者认为 Firefox 57 将会是 Mozilla 有史以来最大而且最重要的发布版本，会是 Firefox 回到顶尖水准的基础。但有些人却不太满意。作者在下面文章中分几点详细说明他为何支持 Firefox 57。


一、传统扩展将会停止使用


第一个观点：凡事都有两面性。

目前扩展有两种架构，一种是老旧的 XUL 扩展，可以修改 Firefox 任何方面，一种是新的例如 Bootstrapped 扩展、基于 SDK 的扩展和最新的 WebExtensions 扩展的架构。而其中前三种被称为传统扩展。

一些人坚持认为传统扩展才是 Firefox 最强大的地方，但是作者认为这是有代价的，最强的优点往往也是 Firefox 最大的弱点。

传统扩展可以修改任何地方，给了开发者无限可能性，但也让扩展变得不可控，因为开发者可以随心所欲。这对所有人来说都是一个问题。对于 Mozilla，他们无法开发出一个可迁移的固定框架，因为 Firefox 内部代码和扩展使用的代码无法区分开来，而其他厂商的框架非常灵活。对于开发者，Firefox 每次更新后往往扩展会出现兼容性问题，开发者需要不断调试扩展进行适配，非常烦人。对于用户，他们的扩展经常都会突然无法工作，得一直等待更新修复，甚至根本就等不来更新。


第二个观点：Mozilla 的错误也许是 SDK，而不是 WebExtensions

一些人认为 WebExtensions 扩展无法像传统扩展那么强大，这是这些人不欢迎的原因。但作者认为 WebExtensions 才是正确的、唯一的能让 Firefox 始终保持顶尖水准的方法。

真正的问题早在 Firefox 4 引入 Add-on SDK 时就产生了，Mozilla 简化了扩展的开发的理念是对的，但当时没有进一步使其变成如今的 Webextensions。Webextensions 提供了明确的框架规定哪些能开发那些不能，提供了权限授权模块且用户界面性能优异。而 Add-on SDK却有大量的性能上的问题，甚至浪费了多进程模式下的每个 content 子进程的带来的性能提升，因为每多个子进程都会产生性能问题。综上所述：Firefox 4 就已实现了类似 Webextensions 的架构，它后续如果演化出一些 Webextensions API，哪怕开发有些迟，也对于  Firefox 57 实现 Webextensions 来说也有帮助，也有优势。

但你会说 Mozilla 也是人，不可能一开始就设想完美。所以从这个角度出发，SDK 也带来了很重要的体验，也为 WebExtensions 架构开发做出了贡献。


第三个观点：很多人根本不使用扩展

很多人认为使用 Firefox 的一个主要原因就是用它的附加组件，所以一旦大量扩展突然不能用，Firefox 就会完蛋。但实际上超过 40% 的用户一个扩展也没安装，40%到50%之间用户只装一个到两个扩展。到了 Firefox 57，很可能这些扩展就已兼容 WebExt。很多用户甚至都不知道自己装了哪些扩展，也不会注意到扩展不能用了。或者知道有些不同，但说不出个所以然。作者认为这不是个别情况。

因此作者认为这次架构改变会是安全的，因为超过半数用户完全都察觉不到扩展的变化。改变带来的优点大大超过带来的缺点。会吸引更多新用户使用 Firefox。Webext 会带来侧边栏界面等更多 Chrome 所不具备的界面。Chrome API 是 Webext 架构开发的起点，Firefox 不会受到限制，会做的更多。

综上：作者认为许多传统扩展能做的事情，Webext 也能做到，或者现在做不到至少未来能做到。Firefox 57 到来后，Webext 的开发也不会停止。而一些 Webext 做不到的，例如各种界面调整，修改设置，可以通过 about:config 修改。就算这类扩展无法通过 Webext 实现，但还是让人可以理解的。

Webext API 也会带来兼容性方面的优势，Firefox 更新后扩展不会失效，因为设计上就避免 API 修改上的不兼容，而这是 XUL扩展所做不到的。Mozilla 也能更致力于加强 Firefox 的开发，使其保持在顶尖水平。毕竟 Firefox 性能明显弱于其他浏览器，扩展开发再好也没意义。



二、全新的主题系统


Firefox 也有两套主题系统，一个是轻量主题，只能修改浏览器外观纹理和配色。另一个是完整主题，类似于 XUL 扩展，可以修改界面的任何地方。

第一个观点：之前的主题系统已经崩坏

在 AMO 目前共有 500 款完整主题，但只有 60 款可以用在当前版本 Firefox 上，这说明原来的主题系统已经崩坏。主要原因是 Firefox 开发速度加快，完整主题的作者必须不断适配，对他们来说要耗费很大精力。而且主题开发文档的缺失让开发变得更难。未来的新主题是否会让开发者满意需要时间来证明，但普遍对现有主题不满意则是肯定的。而轻量主题是永远都不会失效，且使用良好。但主题可实现功能受到严重限制，开发者往往希望能有更多定制的可能。

第二个观点：主题是用户的小众需求

只有 0.089% 的 Firefox 用户在用完整主题。就冲这点，Firefox 就可以完全取消对主题的支持。但 Mozilla 还是坚持考虑这不到 0.1% 的用户的需求，分配资源开发新的主题系统，作者表示很欣赏。

综上：作者认为新的主题系统会取代之前已经失效的主题系统，功能上会受到严格限制，不过也会解决存在的兼容性问题。用户不用担心每次 Firefox 更新后主题会失效，它能够一直正常使用。对于主题开发者，开发更容易，所花的时间也更少。一些人可能会对主题功能受限可定制性少有所不爽，但别忘了可以说几乎没人在用完整主题。而新主题系统则可以吸引更多人使用主题，例如那些不喜欢主题过于简单，希望工具栏图标能有所改变的人。对于那些觉得轻量主题已足够无需改变的用户，这些主题仍可以一直兼容下去。



三、额外的一个优点是更容易从 XUL 中抽身


这次改变另一个优势在于更容易从一项后续困难转变中抽身，这就是彻底淘汰 XUL 语言。由于 Firefox 57 后的扩展和主题无需直接访问 XUL，所以淘汰 XUL 的目标更容易达到，开发者也无需再次适配所有扩展和主题。如果 Mozilla 继续允许访问 XUL 界面，未来数月乃至数年内我们都要重复面对同一问题，就是扩展和主题一次又一次失效。


四、新的 Photon 主题，增加可定制功能


对于新主题的设计，总是有人喜欢有人不喜欢。对于 Firefox 29 引入的 Australis 主题，最多的不满就是弧形标签页以及太像 Chrome。现在 Photon 主题和 Chrome 的就差别很大，即便是坚持认为 Australis 主题抄袭 Chrome 的人也会对 Photon 少一些抱怨。Photon 主题在界面上带来了很多改变，同时也带给用户更多可定制的地方。例如 Firefox 29 取消的可调整空白回归了。

综上：作者认为新主题设计，可以说是有得有失。Mozilla 带来最好的改变就是回归方形的标签页，因为它让许多事情变得简单了。但也无法低估标签形状的复杂性，因为要考虑动画效果以及性能。但想要改变主菜单内容的用户可能会失望，因为主菜单内容现在变成了静态对象。但实际上可定制的选项是增加了，这对于认为 Firefox 的定制性是其最大优势的用户来说是一个加分项。



五、多进程架构


转换到多进程架构是 Firefox 历史上最大的改变之一，持续了数年，计划 Firefox 57 的时候正式默认推送给所有用户。默认启用的用户会开启多个 content 子进程，Firefox 56 时候任何使用 SDK 附加组件的用户仍不会开启超过一个 content 子进程。

多进程的带来的优点是稳定性、性能和安全性，也包括更好的支持网页标准。浏览器界面和网页内容分离可以提升性能，避免整个浏览器因网页崩溃或挂起而无响应。最重要的是它的沙盒可以增加安全性，减少被暴露的危险。本地文件也会在独立的进程打开，甚至 WebExtensions 也会运行在独立的进程。多进程默认对所有用户启用将是 Firefox 57 正式版最大的看点。



六、Quantum 带来更大性能提升


Quantum 项目旨在帮助 Firefox 在保持现有 Gecko 引擎的基础上进化为下一代的浏览器。Firefox 53 的 Windows 版本已经正式启用了该项目的图形进程，而 Firefox 57 将会是该项目的第一个重要里程碑。Quantum 项目包括：Quantum DOM 提升 Gecko 响应度，尤其是在打开大量后台标签页时的响应。Stylo 是使用 Rust 语言编写，来自下一代 Servo 引擎的全新 CSS 样式系统，在实现并行计算时具有优势。WebRender 也来自 Servo，用于渲染网页内容，支持游戏图形显卡，但主要用于优化网页内容显示，Firefox
会智判断载入网页资源的优先级来渲染显示。此外，跟踪保护机制在该功能未启用的时候仍可以使用。从网页下载而不是从缓存下载文件的逻辑更快。QuantumFlow 可在 Quantum 项目未涵盖的其他地方继续优化性能，例如优化 UI 性能。至于 Firefox 57 时候有多少提升，大家拭目以待。



七、其他的特性


Firefox 57 还会带来其他的新特性。例如 TestPilot 正在测试的 Activity Stream，用于取代默认的新标签页面。还有正在开发 PDFium 作为默认的 PDF 阅读器。不过具体还要看未来数月的开发情况。



八、最后的结论


作者最后结论是对于 Firefox 57，即便有些用户不满意，它仍是 Mozilla Firefox 再次成为未来最高水准浏览器阵营一员的基础。Mozilla 会取消完整主题，毕竟只有 0.089% 的用户在使用。


浏览器市场竞争是残酷的，Firefox 的市场份额已经持续下降多年了。市场份额不是 Mozilla 主要的关注点，只要用户能自由选择浏览器而不被限制，Mozilla 就算是成功了。但很明显比起只有 1% 的市场份额，如果一个浏览器开发商拥有 80% 的市场份额，那它就会对网页开发具有更大影响力。当然，生意是在竞争中达成的。Firefox 不必追求 80% 的市场份额，如果市场份额能分散在不同浏览器而非单一浏览器独占，这对所有人来说都是好事。

问题是 Mozilla 没有 Google、微软和苹果那么大的财力，也没有办法像用 Google 其高带宽的服务推广 Chrome 那样来给 Firefox 做广告。Mozilla 是一个非营利性组织，主要关注的是数据和隐私保护，Firefox 也是一个开源产品，这才是它最大的宣传标语。大多数用户都不会想去换浏览器，所以 Mozilla 只能通过功能以及性能来说服他们去使用，借此让自己在浏览器市场变得越来越重要。

如果 Mozilla 想要积极变成最好，而不是还不错，有些东西必须改变，改变也会很艰难。Firefox 57 会是迈出的巨大的一步，影响会很大，这一步值得鼓励。当然，这个计划也有可能反复，但作者认为这一步是需要的。Mozilla 也有足够的市场份额来承受。作者相信 Mozilla 走的方向是正确的。也许 Firefox 57 这个版本不会带来多少市场份额的提升，但 Mozilla 会成功的，Firefox 57 将是未来再次成为用户一个选择的基础，而现在则不是。当然，Mozilla 还要在 Firefox 57 的基础上不断进步，未来肯定和今日有所不同。

感谢楼主的翻译~~~

现有的xul和架构就像一艘曾经辉煌过的巨舟，还能在大洋与人争雄，但毕竟是老旧的设计了。  
痛下决心浴火重生还有几分重回巅峰的希望，修修补补就只能沉沦海底了。

f大有心了……

看到“但实际上超过 40% 的用户一个扩展也没安装，40%到50%之间用户只装一个到两个扩展。”这句有点在意，就去看了一下原文（同样是借助英文翻译中介）：
Und wenn jemand nicht zu diesen über 40 Prozent zählt, sind es nicht automatisch 50 elementar wichtige Add-ons, die der Nutzer nutzt.
感觉这句意思是这样的：
对于那些不属于这百分之四十多（一个拓展不用）的人来说，他们使用的也只是不到50个基本的重要拓展。

这么一大段翻译辛苦了

50%的用户只用0～1个扩展, 所以推webext不会影响太大？
我觉得对0～1扩展用户来说其实什么浏览器都无所谓吧, 这些人没有换成chrome的唯一理由大概是懒得重新下一个新的——如果哪一天被qq强行安装了qq浏览器作为默认, 估计就变成QQ浏览器用户了, 抛弃其余所有人争取这样的用户真的值得吗？

整个业界都在推webext, 在限制开发者的触手范围, 有没有考虑过有定制需求的人？
Android也推统一架构, 也在限制应用权限, 甚至删个系统文件都得费很大劲, 但是android可以刷包, 可以root, 还有xposed框架可以像userchrome.js一样满足最挑剔的geek需求, webext能吗？

嗯 这句话英文就有一些问题，造成我翻译偏差，不是50%用户只使用1-2个扩展，可能如你所说的。 @myhead

白左：这么一大段翻译辛苦了

50%的用户只用0～1个扩展, 所以推webext不会影响太大？
我觉得对0～1扩展用户来说其实什么浏览器都无所谓吧, 这些人没有换成chrome的唯一理由大概是懒得重新下一个新的——如果哪一天被qq强行安装了qq浏...回到原帖

技术标准是标准，实现又是另一码事
Chrome API 是 Webext 架构开发的起点，但是毕竟不是终点

确实，我遇见不少人连浏览器的设置界面都没打开过

白左：这么一大段翻译辛苦了

50%的用户只用0～1个扩展, 所以推webext不会影响太大？
我觉得对0～1扩展用户来说其实什么浏览器都无所谓吧, 这些人没有换成chrome的唯一理由大概是懒得重新下一个新的——如果哪一天被qq强行安装了qq浏...回到原帖

未来没准能，如果有人写可拔插的模块加载器，就像xposed、uc那样。WebExtension Experiment也能，但目前缺乏文档且有限制。有了加载框架也不容易，编写异步、可靠还安全稳定的模块、脚本。不会成为主流，安全风险高。

如果 PDFium 了，pdf.js 不知道会怎样，逐渐放弃或者转为社区项目吗。pdf.js一直有复制、呈现错位的毛病。
https://bugzilla.mozilla.org/show_bug.cgi?id=1049218 没有消息，内部bug不可见（为了不弄出‘大新闻’？）。

我连广告词都替Mozilla想好了
Firefox, same as Chrome, now for the fools.

yfdyh000：如果 PDFium 了，pdf.js 不知道会怎样，逐渐放弃或者转为社区项目吗。pdf.js一直有复制、呈现错位的毛病。
https://bugzilla.mozilla.org/show_bug.cgi?id=1049218 没有消息，内...回到原帖

有了 pdfium，pdfjs肯定不开发了，耗费大量开发资源还是问题多多，还是学习chrome比较快。

kmc：我连广告词都替Mozilla想好了
Firefox, same as Chrome, now for the fools.回到原帖

看来你不打算用57了 不然就fools了

fang5566：有了 pdfium，pdfjs肯定不开发了，耗费大量开发资源还是问题多多，还是学习chrome比较快。回到原帖

还是喜欢pdf.js

对我而言，升级57最大的阻碍是不能用keyconfig改快捷键。
昨晚研究了一下，发现可以直接修改browser.xul来改快捷键。
于是升级57就没什么大问题了。