为WebExtensions叫好

http://robert.ocallahan.org/2015/08/hooray-for-webextensions.html


Many of the comments on WebExtensions miss an important point: basing WebExtensions on the Chrome extension API does not imply limiting WebExtensions to the Chrome API. For example, Bill already made it clear that we want to support addons like Tree Style Tabs and NoScript, which
 Chrome intentionally does not support. So Firefox addons will continue
to be able to do things you can't do in Chrome (though there will be
some things you can hack into Firefox's XUL today that won't be
supported by WebExtensions, for sure).
WebExtensions is something we need to do and should have done
many years ago, before Chrome even existed. It's what Jetpack should
have been. But better late than never!




然并卵

凭枰：逐步把老功能加回来——opera也是这么说的。回到原帖

然而Opera那是放弃了内核 Gecko内核还是在Mozilla掌控中

逐步把老功能加回来——opera也是这么说的。

考虑转战Chrome。。。

aaaa007cn：xul 本质上也只是个 xml 而已
常用的 XHR 就是 XMLHttpRequest 的缩写
拥抱 html5、切换新内核和继续使用 xul 来构建 ui 并不冲突
只是现在的 mozilla 选择废弃 xul 而已
that'...回到原帖

XUL是基于XML构建的一个技术标准，基于XML构建的标准不少，但死掉的也不少。
部分原因是XML的解析成本和未达到预期，再加移动互联网的流量需求，以及json的崛起。
虽然这些跟界面技术关系不大，但HTML5和json的界面构建冲击是存在的。

【尽管名字里有XML, 但XMLHttpRequest 可以取回所有类型的数据资源,并不局限于XML. 而且除了HTTP ,它还支持file 和 ftp 协议.】

很有冲突。
目前只有Mozilla的界面上采用XUL技术，并不能吸引到新开发者（学了没用）。
Mozilla与三星合作开发的新内核Servo，至今并且未来应该都不会有XUL这种技术的支持。
如果不废XUL，未来的社区和产品分裂不可避免。

XUL的历史不清楚，是否W3C标准，为什么没发展起来。不过竞争者的微软XAML，现在倒是在微软系使用不少。
还有DTD，维基百科说“由于DTD限制较多，使用时较不方便，近来已渐被XML Schema所取代。”（未查证），不知道会不会被废掉。比如改用json，Chrome扩展都这样，dtd（以及.property）真的过于简单了。
XBL，目前也是Mozilla的私有技术，英文维基说，W3C在2012年放弃了该标准……
Mozilla弄的私有/草案标准，好像没成功几个嘛。自己不废掉，就是微软ActiveX的结果，甚至更糟。

如果以上有误，欢迎指教。

yfdyh000：一些个人想法：
XUL早已死去，几乎没有其他人用，Mozilla自己也在2010年禁用了远程XUL的技术（即不允许外部网站使用），并在近年来逐渐淡化去除，如重构XUL编写的一些界面。

所以，如果想拥抱HTML5（以及使用新内核），X...回到原帖

xul 本质上也只是个 xml 而已
常用的 XHR 就是 XMLHttpRequest 的缩写
拥抱 html5、切换新内核和继续使用 xul 来构建 ui 并不冲突
只是现在的 mozilla 选择废弃 xul 而已
that's all

一些个人想法：
XUL早已死去，几乎没有其他人用，Mozilla自己也在2010年禁用了远程XUL的技术（即不允许外部网站使用），并在近年来逐渐淡化去除，如重构XUL编写的一些界面。

所以，如果想拥抱HTML5（以及使用新内核），XUL是早晚要被废掉的，只是力度、方式和早晚的问题。
比如现在这样在Firefox中逐渐废掉，或者把Firefox基本扔掉，直接转向新内核。
我觉得后者好像技术上更容易完成（如同Opera所做），但全面转型造成的各种问题和风险也很高。

早晚要去掉的东西，不去掉就会成为Flash、ActiveX那样的东西，IE也照样去掉了VBS等网页上的专有技术。
不过以上几项基本都是因为安全性原因撤掉的，而Mozilla在主动去掉。
也许是设计上遇到瓶颈（新内核想要兼容实在太难和没必要。XUL本身也留着一些小bug，多年无人解决），为新内核铺路，或者只为了架构改进。


另外，不知道 Thunderbird 等产品会怎么做，也逐步重构重写，还是就这么拖着维护，甚至会不会不要了（像是for Metro那样）。

beast：你的意思是，未来的纯js扩展比xul扩展运行效率更低？回到原帖

没说吧，看发展和编写水平，还能解决些优化瓶颈。Firefox OS就是没有XUL的HTML5，照样能跑的还好。
但是现有的扩展大多都会挂掉，的确很可惜和危险，不知道壮士断腕的结果会将如何。

fiag：Web Extension 需要签名么？回到原帖

需要。但因为API标准化，自动化通过或辅助完成审核的成功率更高，应该是这样。

Web Extension 需要签名么？

aaaa007cn：xul 显然难逃一死
所以 overlay 扩展铁定玩蛋
剥去 xul 部分的 bootstrapped 扩展前景不明，毕竟 Addon SDK（aka Jetpack）扩展说到底也是个 bootstrapped 扩展
二进制扩展已经连渣都...回到原帖

你的意思是，未来的纯js扩展比xul扩展运行效率更低？

fang5566：火狐在用户占有率上现在已经是处于防御状态但仍节节败退，并非扩展不强力，不多样。而是现在格局和用户需求已天翻地覆地变化了，现在已经是简单，快速，轻巧的天下了，一方面渲染引擎的速度不断提高，另一方面浏览器变的更简洁响应更迅速。连微软都抛弃陈旧的...回到原帖

假如新内核的开发计划和进度能早那么一两年，转型或许不会这么困难。
那样的话，下狠心直接把现有的Firefox冷藏（转型ESR；不是没这么干过，如前不久的jpm），全面开发基于新内核的The new Firefox，或许反而快很多，也更容易吸引到新开发者。就像现在的新Opera、Edge，开发进度日行千里，虽然前者前者不温不火，后者前景不明。

目前的情况，Firefox 要考虑加入新的e10s等架构（而且是逐步来），还有废除XUL等过时技术，并要考虑对Firefox OS、Servo等等东西的兼容性，挺困局的。

还有曾经的Firefox for Metro，恐怕浪费了不少精力，应该也算决策失误吧……

fang5566：确实ff可提供给开发者api更多，所提供权限更大，要不然这么多强力扩展。我不是扩展开发者，我希望有大一些扩展的开发者或浏览器开发人员说一下为什么ff每次更新都要改动那么多地方（见每个版本的附加组件兼容性说明，在论坛开发区），为什么有大量扩展...回到原帖

作为小半个扩展和浏览器开发者的想法：
除了数量，Firefox 内部API的向后兼容也的确不那么好，API 的变更比较随意，没有硬性的指标或者退回机制。比如有超过10个扩展在用就必须兼容，比如打破超过10个扩展就必须回炉。微软大概就是这么干的，虽然也会导致组件不断膨胀（见WinSxS），但至少保证发布版本相对稳定。（Windows 10 TP和10525例外，正在改变这种做法，向快速迭代靠拢……）

还有就是，因为Firefox有大约半数的补丁来自志愿者（据 http://areweeveryoneyet.org/ ），代码风格、熟悉程度、补丁质量等均难保证，再加偶尔的审核不严，打破兼容性有时难于/懒得避免（问题急于修复；急于上新功能，想着问题以后再修，如新主题）。
还有Nightly、Aurora测试流程的公开，如果最新的变更打破了API兼容性，有时或许还改不回来，因为部分扩展作者都改了，你不好意思再改成另一种吧。（这条属于猜测）。

还有Firefox的架构方面，不太确定，但或许真的老了，毕竟那么多年了。

代码质量，最近在研究的 toDataURL ，类似功能的截图代码，在不同组件下重复实现了不止五次，而且风格也略有不同（三五种），缺少统一的内部API模块化设计。


归根结底，扩展开发方面还是Firefox的内部API太容易触及，高层API和SDK缺乏（以前似乎几乎没有，好像Jetpack才开始设计的），后来容易因为API变更而疲于奔命。
在Firefox 4之前的阶段，因为发布较慢（半年或几年一次？），所以这种问题才没那么明显。还有曾经的清单文件版本范围，比较蠢笨（那时没有自动完成检测升级，再加上六周一次的升级周期，手动测试并修改的压力太大了），导致改兼容性成为流行，以及扩展开发者的离去。

总之有自己作死的成分。感觉很多是架构师的问题，不清楚Mozilla有没有这个职位和相应能力者。

fang5566：mozilla已许诺会在webext基础上逐渐加回原来功能。虽然不知是否能达到现在状态，比chrome的玩具更强大应该是可以的，这是ff的独特性和立身之本回到原帖

扩展 WebExtensions 是无奈之举
不扩展下怎么支持那些流行扩展？
而且扩展后
理论上，大部分 chrome 的垃圾扩展都可以跑在 firefox 上
而使用了这些扩展 api 的扩展不做额外调整不能跑在 chrome 上
小算盘打得倒是挺好

只能使用 mozilla 提供的 api 限制了扩展可以接触到的内部实现
所以显然做不到可以像现在这样随心所欲的修改 firefox 的内部实现
举个栗子来说
mozilla 现在加入的某些无用功能，比如 pocket
用 overlay 扩展可以很轻松的干掉它们（利用 chrome.manifest 的 override）
禁止 XUL 扩展后
大概得改 omni.ja 才行
但 mozilla 又在逐步增加修改 omni.ja 的难度……

aaaa007cn：chrome 的扩展文档中专门有一个页面描述 api 更动历史
而 firefox api 更新看起来引起的问题更大的根本原因是
firefox 扩展开发者可以使用 api 数量远远超过了 chrome 啊
要不说 chrome 扩展就是儿...回到原帖

确实ff可提供给开发者api更多，所提供权限更大，要不然这么多强力扩展。我不是扩展开发者，我希望有大一些扩展的开发者或浏览器开发人员说一下为什么ff每次更新都要改动那么多地方（见每个版本的附加组件兼容性说明，在论坛开发区），为什么有大量扩展失效让开发者不胜其烦，虽然现在大量失效的情况少很多很多了。