如果你今天要开始开发一个新的 Firefox 插件,你会继续使用 XUL/JS 还是开始使用新的插件框架 Jetpack?
XUL 创建附加组件的方式将继续存在于 Firefox 4 上,但 Jetpack 显然正在建立蒸汽,我想它将成为未来创建附加组件的唯一方式。
现在是时候开始寻求切换/迁移到 Jetpack 了吗?
如果你今天要开始开发一个新的 Firefox 插件,你会继续使用 XUL/JS 还是开始使用新的插件框架 Jetpack?
XUL 创建附加组件的方式将继续存在于 Firefox 4 上,但 Jetpack 显然正在建立蒸汽,我想它将成为未来创建附加组件的唯一方式。
现在是时候开始寻求切换/迁移到 Jetpack 了吗?
JetPack 和 XUL 并不相互排斥。JetPack 是一组 API,您可以随附加组件一起提供这些 API,这些附加组件经过 Mozilla 测试并保证可以正常工作。我建议你从 JetPack 开始,如果你需要做一些更强大的东西,你可以开始添加 XUL 和其他 JS 文件来完成你所需要的。JetPack 旨在更简单,但您也可以毫无问题地进入扩展开发的可怕世界。
我还不知道 Jetpack,但两年前我使用XUL为 Firefox 编写了一个大型扩展程序,这真的非常非常痛苦。
我认为 Jetpack 必须更好、更简单,值得一试。
这取决于您的附加组件的大小和范围。如果你认为它相当简单,那么我会从 XUL 开始,只有当你碰壁并发现自己说“一定有更好的方法!”时才切换到框架。
我没有使用过 Jetpack,但我同意这里的其他人的观点,即 XUL 并不总是令人愉快的。令人惊讶的是,文档经常丢失一些明显的关键信息。Jetpack 可能会为您解决这个问题。或者,您可以帮助改进文档。:)