在扩展脚本方面，用户为何不太愿意接受 Python ?

[MegatronKing]

大家好，我是Reqable的开发者，给大家分享我在推广 Python 作为程序扩展脚本时遇到的一些问题和思考。如果大家对这个方面有想法和建议也非常欢迎一起讨论，不甚感激。

先说下大体的背景，我的产品 Reqable 是 API 抓包和测试一体化工具。这一类工具基本上都会用到扩展脚本，比如 Fiddler 使用了 FiddlerScript 作为扩展脚本，Postman 和 Proxyman 等使用 Javascript 。用户可以编写扩展脚本来动态地修改请求或者响应数据，相比静态功能来说，提供了更多的可能性。

在设计 Reqable 的时候，我考虑了两种方案：方案 A 是 Javacript ，方案 B 是 Python ，最后定下来方案 B 。谈谈我当初的考虑，Reqable 本身是基于 Flutter 而不是基于 Web 引擎，如果需要支持 Javacript 需要像 React Native 一样额外引入 JSCore 来解释执行 Javacript ，技术实现上来说稍微麻烦点但难度也不大，包体积会大一些但也还好。对于 Python 而言，主流 Windows 和 Mac 上系统默认都已经预安装了，用 Linux 的基本上也会安装，所以可以直接借助用户的 Python 环境来执行脚本，不需要引入额外的库。另外，我考虑到 Python 的在用户宽度可能会更广，比如测试工程师、安全工程师、爬虫工程师等等，而 Javacript 在前端会更加流行。综上原因，最终我选择了 Python 作为扩展脚本语言。

但是想法虽好，用户却不是很买单。有些用户建议我支持 Javacript 脚本，还有一些说 Python 直接劝退。这些反馈让我不得不重新审视之前的想法，考虑是否需要增加 Javascript 作为扩展脚本。当然，维护两套扩展脚本框架我不是很情愿，这个会极大地增加后续维护和迭代的工作量。技术实现难度反而是其次，大佬 Levi 也很贴心地给我提供了他产品目前使用 Javascript 作为扩展脚本的方案： https://zhuanlan.zhihu.com/p/672772729 。

说回目前的困境，大家不太能接受 Python 的原因，我的个人的反思和调研出来的是以下几点：

• Python 作为扩展脚本不多见，或者和用户的技术栈不匹配。
• Reqable 内置的代码编辑器功能不完善，无法流畅编写 Python 代码。
• 生态不佳，大家更喜欢现成拿来就用的而不是自己去编写。

针对这几个原因，我做了一些努力和尝试，希望能再挣扎几下：

第一点：技术栈的问题目前无解，但我还是相信 Python 的用户宽度更广。当然，如果能熟用 GPT ，技术栈也不是什么问题，直接提需求让 GPT 写。

第二点：确实是一个很大的问题，例如代码编辑器缺少代码提示和补全，调试功能不方便。针对这个问题，我完善了代码编辑器，加上了代码提示和补全功能。对于调试，则提供了日志控制台功能，当然断点调试目前还不知道怎么去支持。

第三点：对于拿来主义，我的设想是提供一个开源的公共模板仓库，将一些常用的脚本放进去，用户可以直接在 Reqable 里面 Fork 并使用。例如，我写了个利用 Python 扩展脚本自动生成并添加阿里云 OSS 资源访问的签名头部。

我暂时就想到了这么多，效果好不好目前还不确定，如果大家还有想法和见解，欢迎补充。

上午起来一看，大家给了很多中肯有价值的回复，我来回认真看了几遍，做个简单总结，就不一一回复了，感谢大家。

1. Windows 预安装的问题，确实是调研失误了。Windows 自带的 python3.exe 等是 placeholder ，从命令行跳转应用商店引导安装的，安装完成后链接到真实的 python 可执行文件。有可能我的设备早期按照这个方式安装了 python ，一直以为是预安装的。

2. 从大家回复内容来看看，支持 Javascript 的确实远比 Python 要多，明年可能确实要再提供 Javascript 的扩展脚本支持。

有回复多次提到市场和用户角度，我补充下我的想法。对于前端工程师，选 JS 毫无疑问；对于测试工程师，选 Python 应该也是毫无疑问；对于后端工程师，到底是会 JS 多还是 Python 多，我确实不清楚，Java 应该是很多的，Java 作为扩展脚本同样不多见，好像 BurpSuite 是 Java 。总的来讲，产品的用户到底是使用哪种语言居多，产品研发前很难去调研，Reqable 现在有一定的用户量，我确实需要做个问卷调研。

有回复说 Postman 使用 JS ，那么 JS 一定就是用户的主流语言，这种观点看我其实持怀疑态度的。Postman 选择 JS 不一定是根据市场需求，而是产品自身的技术栈，Postman 是基于 Electron 开发，扩展脚本语言自然是会选择 JS ； BurpSuite 是基于 Java 开发，扩展脚本语言选择了 Java ； MitmProxy 是基于 Python 开发，扩展脚本选择了 Python 。Reqable 基于 Flutter 开发，如果扩展脚本语言使用 Dart ，我也只能加个🐶。从技术实现的难易程度和扩展脚本的生态来讲，JS 无疑是主流。当然，头部产品 Postman 等对用户习惯的培养来说功不可没。

JS 是主流，为什么不选择 JS 呢？我当初的想法是，差异化竞争。我认为做个一模一样的产品没有前途，需要一定的差异化。当然，用户量起来了，后面丰富下不同用户的口味是非常有必要的。纠结的点在于，维护和升级成本，按照我的 Roadmap ，扩展脚本除了提供预请求/预响应处理外，还会提供单元测试，自定义 UI 等功能。维护两套语言 API 对于我一个人来讲确实比较吃力，有人建议开源，实际上目前的 Reqable Python API 是开源的，但并没有他人的一点代码贡献。

3. 扩展脚本依赖和运行环境的问题。Python 的依赖管理确实比较坑，但是实际上 Python 标准库已经非常完善了，我觉得可以支持 99%以上的扩展编程，不一定需要额外安装依赖。相比，JS 标准的问题则比较多，必须需要额外提供 crypto 等库。另外，就是运行环境。内置 Python Runtime ，通过 FFI 调用技术上没什么问题，但是万一有用户需要用到非标准库的依赖呢，是个很麻烦的问题，这个就和 JS 一样。

另外，关于Python在作为扩展脚本语言方面的实际使用，看回复大多都持有负面的看法。如果有兴趣的，希望能帮我的产品 Reqable 的Python扩展脚本功能做个实际的测评，用户体验、流程、痛点、难受点等角度都可以，非常感谢。

方便测评，我提供一些许可证的免费兑换（90天）：

• GT-G6DGA-YBKHL-HHZPL-4VXX8-4VPP8
• GT-2X4E6-LL5AZ-9ZY3Y-AUKYD-FMUCP
• GT-QKY84-ZU9CX-ENTZY-MTTX5-8PACU
• GT-UMHLE-AEGG7-4ACQ5-WE4MR-HYHBJ
• GT-5947B-VYNG5-947KF-ULZRH-4Z8Y3
• GT-575UX-8UT8D-28HFT-QFSQU-GVGWQ
• GT-CWMFU-VU4TB-GDBU3-4WU7Q-GS4U7
• GT-VK8BE-CG4AZ-SW2NA-SS6CS-ABQLY
• GT-BA5BN-7X44Z-SZQRF-XHDQ5-PGD75
• GT-JE3M3-6H2KS-Z8CGL-WP6AC-LDUDM
• GT-MFGKB-EQJS8-U8ZBT-GWG6F-WKTVJ
• GT-K5VMX-XULS4-9MLSL-FMVMU-QYMHF
• GT-SPFDP-Y7A29-H2CBC-9FS24-YQ7P3
• GT-ZYH7Y-LBPV7-MEKRE-5ZR3V-8NT35
• GT-7GS2W-BN43K-37HK5-9EZVU-YCERN
• GT-TD2HZ-UYJGC-VWEG7-E346G-9589E
• GT-MA8EC-Q6W8E-XVDZB-Y5QN8-Z6ABS
• GT-KLG3Y-Z5YDH-639WX-ERHT4-6DTDN
• GT-R2GXS-ASFZE-R4P63-Y52ZE-9M9RZ
• GT-68YUK-ESU3Y-6H8PA-JU8DW-KCRPH

兑换处：https://license.reqable.com/gift

[kasusa]

@MegatronKing windows 命令行直接装的哪个版本会有各种我问题 非常不好

[Maerd]

js 配置起来相比 python 要简单很多。不过从使用者来说，是 python 生态更好，前端使用脚本的概率要远远低于爬虫和测试，而爬虫和测试更喜欢用 python ，总体来说还是更适合使用 python （不过内置编辑器较弱确实是个问题）

[james122333]

因为你的用户至少懂点编程 语言论战多久都不会停 你还要考量国内外语言使用者人数 你说的第一点就是
第二 我觉得那个扩充脚本依据文档介绍很难满足複杂情况 onrequest onresponse... 不考虑前一个请求输出为下一个请求输入吗 js 虽然不算十分好的语言 但 npm 装一装 lib 搭配本身的 promise 或 async 就可以实现上述 可能有只是我光看介绍不知

[harmless]

@harmless 补充一下，可以给用户提供一个 shell 工具，可以是二进制，也可以是 bat 或 sh 脚本，用户打开这个工具的时候自动配置好环境变量，使用内置 python 环境，用户在这个 shell 里正常执行 pip 命令就可以，这样用户使用成本很低，也没有环境污染的问题

[byzod]

作为一个非 it 工作和专业的轻度用户表示，肯定是 js 更熟悉，至于为什么，因为平时需要写的脚本也就 greasemonkey 比较熟悉（

[prenwang]

你这赤果果的广告啊，但是这么优秀的软件 Reqable ， 可以再多来一打

[IvanLi127]

在 web 领域的 API 么？那首先想到的不是 js 就见鬼了。web 里老生常谈的不就是 html + css + js ，没什么意外情况的话，不选 js 就离谱了。

[yhvictor]

如果想同时支持两种/多种语言，可以使用 grpc 或其他方式描述 API 。
不过让使用者在这个软件里写代码，我觉得有点想多了。大部分人所需要的，仅仅是几行指令实现其对应功能。
不然我自己 junit 写测试 test against server 不香么。

[czy1996]

于我个人而言，写 Python 远比 js 舒服。但是前端人数众多，js 作为扩展语言确认远比 Python 成功，这是事实。有些人提到 Python 包管理的问题，个人觉得和 js 无非是五十步和百步的区别

[tongtongqaq]

我认为一个关键点，那就是这个领域相关和类似软件几乎都是 js 脚本了，就比如我现在把"Surge","Quanx","Postman""Proxyman 各个软件的脚本放到另一个工具使用，直接无脑迁移就好了，最多也就改几句变量。但是迁移到"Reqable"呢？

[tongtongqaq]

很多用户其实根本不在乎是"python“还是"Javascript",甚至他都不知道是什么,他只是需要无脑实现的功能和目的。
所以几乎每个软件都以"插件“,"扩展","模块","脚本"来帮助这些大部分用户实现目的，这个的前提就是基于 js 脚本目前的生态。
比如自动获取 Cookie 签到,去广告,破解,自动根据 jquery 来计算哈希值。
这些的目的就是为了帮助这些大部分根本不懂代码的用户,最简单的来实现他们的功能。
现在一个不小白用户 他就想实现自动修改每次请求表单里的一个值，或者去广告。如果是 js 的话 已经有无数轮子他就只需要无脑安装就好了。但是 Python 目前做不到。

[hmxxmh]

大佬牛皮，试用了一下，很方便我，支持一下

[Elliota]

看到这篇文章入专业版了;
主要看使用人的目的, 如果使用的人是面向前端, 那无疑使用 js 更为合适, 但是前端用这个脚本功能的频率可能并不高
如果对于爬虫 er 来说, 他们使用的语言一般来说都是 Python, 这个功能几乎是必用,也是核心亮点功能.
所以我还是支持使用 Python 作为脚本语言.

[seers]

在调试的时候喜欢 js ，很快就能验证逻辑，调试完了会使用 py 或者其他语言进行实现