V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MegatronKing
V2EX  ›  推广

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

  •  3
     
  •   MegatronKing · 2024-02-05 00:07:05 +08:00 · 15581 次点击
    这是一个创建于 383 天前的主题,其中的信息可能已经有所发展或是发生改变。

    大家好,我是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 条附言  ·  2024-02-05 11:57:02 +08:00
    上午起来一看,大家给了很多中肯有价值的回复,我来回认真看了几遍,做个简单总结,就不一一回复了,感谢大家。

    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 一样。
    第 2 条附言  ·  2024-02-05 12:17:43 +08:00

    另外,关于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

    114 条回复    2024-04-21 00:09:41 +08:00
    1  2  
    kasusa
        101
    kasusa  
       2024-02-05 16:51:30 +08:00
    @MegatronKing windows 命令行直接装的哪个版本会有各种我问题 非常不好
    Maerd
        102
    Maerd  
       2024-02-05 17:07:12 +08:00   ❤️ 1
    js 配置起来相比 python 要简单很多。不过从使用者来说,是 python 生态更好,前端使用脚本的概率要远远低于爬虫和测试,而爬虫和测试更喜欢用 python ,总体来说还是更适合使用 python (不过内置编辑器较弱确实是个问题)
    james122333
        103
    james122333  
       2024-02-05 17:17:51 +08:00 via Android
    因为你的用户至少懂点编程 语言论战多久都不会停 你还要考量国内外语言使用者人数 你说的第一点就是
    第二 我觉得那个扩充脚本依据文档介绍很难满足複杂情况 onrequest onresponse... 不考虑前一个请求输出为下一个请求输入吗 js 虽然不算十分好的语言 但 npm 装一装 lib 搭配本身的 promise 或 async 就可以实现上述 可能有只是我光看介绍不知
    harmless
        104
    harmless  
       2024-02-05 18:50:55 +08:00 via iPhone
    @harmless 补充一下,可以给用户提供一个 shell 工具,可以是二进制,也可以是 bat 或 sh 脚本,用户打开这个工具的时候自动配置好环境变量,使用内置 python 环境,用户在这个 shell 里正常执行 pip 命令就可以,这样用户使用成本很低,也没有环境污染的问题
    byzod
        105
    byzod  
       2024-02-05 19:01:02 +08:00
    作为一个非 it 工作和专业的轻度用户表示,肯定是 js 更熟悉,至于为什么,因为平时需要写的脚本也就 greasemonkey 比较熟悉(
    prenwang
        106
    prenwang  
       2024-02-05 22:37:55 +08:00
    你这赤果果的广告啊,但是这么优秀的软件 Reqable , 可以再多来一打
    IvanLi127
        107
    IvanLi127  
       2024-02-06 00:09:35 +08:00
    在 web 领域的 API 么?那首先想到的不是 js 就见鬼了。web 里老生常谈的不就是 html + css + js ,没什么意外情况的话,不选 js 就离谱了。
    yhvictor
        108
    yhvictor  
       2024-02-06 02:32:10 +08:00
    如果想同时支持两种/多种语言,可以使用 grpc 或其他方式描述 API 。
    不过让使用者在这个软件里写代码,我觉得有点想多了。大部分人所需要的,仅仅是几行指令实现其对应功能。
    不然我自己 junit 写测试 test against server 不香么。
    czy1996
        109
    czy1996  
       2024-02-06 08:52:17 +08:00 via Android
    于我个人而言,写 Python 远比 js 舒服。但是前端人数众多,js 作为扩展语言确认远比 Python 成功,这是事实。有些人提到 Python 包管理的问题,个人觉得和 js 无非是五十步和百步的区别
    LRf5sETzOgzGvk6u
        110
    LRf5sETzOgzGvk6u  
       2024-02-06 15:48:54 +08:00
    我认为一个关键点,那就是这个领域相关和类似软件几乎都是 js 脚本了,就比如我现在把"Surge","Quanx","Postman""Proxyman 各个软件的脚本放到另一个工具使用,直接无脑迁移就好了,最多也就改几句变量。但是迁移到"Reqable"呢?
    LRf5sETzOgzGvk6u
        111
    LRf5sETzOgzGvk6u  
       2024-02-06 16:06:30 +08:00
    很多用户其实根本不在乎是"python“还是"Javascript",甚至他都不知道是什么,他只是需要无脑实现的功能和目的。
    所以几乎每个软件都以"插件“,"扩展","模块","脚本"来帮助这些大部分用户实现目的,这个的前提就是基于 js 脚本目前的生态。
    比如自动获取 Cookie 签到,去广告,破解,自动根据 jquery 来计算哈希值。
    这些的目的就是为了帮助这些大部分根本不懂代码的用户,最简单的来实现他们的功能。
    现在一个不小白用户 他就想实现自动修改每次请求表单里的一个值,或者去广告。如果是 js 的话 已经有无数轮子他就只需要无脑安装就好了。但是 Python 目前做不到。
    hmxxmh
        112
    hmxxmh  
       2024-02-07 09:01:08 +08:00
    大佬牛皮,试用了一下,很方便我,支持一下
    Elliota
        113
    Elliota  
       353 天前
    看到这篇文章入专业版了;
    主要看使用人的目的, 如果使用的人是面向前端, 那无疑使用 js 更为合适, 但是前端用这个脚本功能的频率可能并不高
    如果对于爬虫 er 来说, 他们使用的语言一般来说都是 Python, 这个功能几乎是必用,也是核心亮点功能.
    所以我还是支持使用 Python 作为脚本语言.
    seers
        114
    seers  
       307 天前
    在调试的时候喜欢 js ,很快就能验证逻辑,调试完了会使用 py 或者其他语言进行实现
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2720 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 21ms · UTC 10:08 · PVG 18:08 · LAX 02:08 · JFK 05:08
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.