使用插件还是油猴脚本?

本文最后更新于:2020年5月29日 凌晨

场景

最近吾辈写了一个 chrome 插件,之前也有写过许多 user.js 脚本,所以便想在此谈一下它们的区别,以及如何选择。

简介

user.js wiki, chrome plugin dev doc

user.js 是一个开放的的标准,最早由 Firefox 的一个插件提出,后来在 chrome 得到原生支持。实际上,user.js 只是在用户的浏览器上访问一些网站时,向网站注入一些 JavaScript 脚本,除了顶部的声明信息以及一些 GM_* 的特殊 api 之外,它与普通的 JavaScript 没有什么不同。同时,目前支持 user.js 的浏览器插件很多,最流行的大概就是 TamperMonkey,同时支持非常多的浏览器,在不同浏览器之间实现了 跨平台。当然,为网页注入一段 JavaScript 脚本可以改变网页本身,但普通 JavaScript 做不到的事情,user.js 也基本没法实现。例如 获取所有的浏览器标签页 这种涉及到浏览器本身的操作。

而插件则不同,它是浏览器提供的一种附加功能,借用官方介绍:扩展程序是可定制浏览体验的小型软件程序。它们使用户可以根据个人需要或偏好来定制 Chrome 功能和行为。它们基于 Web 技术(例如 HTML,JavaScript 和 CSS)构建。,它们能访问浏览器众多的扩展 API,实现对浏览器级别的功能定制 – 而非仅限于网站。例如上面 user.js 做不到的事情 获取所有的浏览器标签页 浏览器插件可以轻易实现。

能力/API

相关 API 链接如下,此处就不贴了(太多了)

工程化

在工程化上,user.js 几乎没有工程化的最佳实践,直到目前为止,仍然没有简单可用的打包工具对 user.js 进行专门支持,例如通过 react 编写一些 UI 相关的内容并最终打包成一个 *.user.js 脚本文件是比较困难的。
看看目前的主流打包工具吧

  • rollup: JavaScript SDK 打包工具
  • Webpack: 最强大的打包工具
  • parcel: 开箱可用的打包工具

是的,打包工具有不少,但这三者都对 user.js 没有太好的支持,主要有两点

  1. 保证打包后顶部信息说明注释仍然在最顶部
  2. 支持多入口打包
  3. 支持 TypeScript
  4. 支持 vue/react 现代前端框架

目前最合适的是 parcel,但仍然没有默认解决第一个问题。

与之相比,chrome 插件的工程化就要好上不少,parcel 甚至官方支持了 WebManifest 类型的资源,这对浏览器插件的开发有着极大的方便 – 可以使用现代前端的一切!

发布

user.js 可以发布在任何静态托管服务里,一般可以放在 GreasyFork 上,供需要的用户通过脚本管理其安装。GreasyFork 甚至可以直接导入 GitHub 上的源码和 README 发布一个脚本,同时在后续过程中自动更新。
而 chrome 插件则只能通过 chrome web store 进行分发,而且每次更新或上架都需要被审核,这其实是比较花时间的,并非是即时性的。同时 web store 也有注册费用,必须使用 Visa 等国外信用卡支付 $5,而这对于国内开发者而言是一件比较麻烦的事情。

吾辈知道可以使用开发者模式打开解压缩的插件,但这终究不是一个好的分发策略,不能要求每个用户都执行这种麻烦的操作,同时,每次重新打开浏览器都会进行提示也不厌其烦。

对于使用者

  • 安装难度:chrome 插件安装事实上只能从 chrome store 就意味着国内用户几乎用不了,嗯,这点是一个相当的减分项。而油猴脚本则不太相同,只要支持 user.js 的插件即可添加任意多的 user.js 脚本,事实上,插件只是一个管理工具,chrome 原生支持它!
  • 需求: 如果只是为网站诸如一段脚本修改一些网站的内容,则优先考虑使用 user.js,如果涉及到操作浏览器相关功能,则只能选择插件,本质上 user.js 在插件中就是 content script 功能。
  • 性能:对于一般用户而言,安装一个 chrome 插件会一直在后台开启一个线程,而脚本不会 – 只会在需要生效的网站上应用。

本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!