屠龙少年终成恶龙，前端转产品的我给前端挖了个坑

前端转产品3周左右，把自己的一些感受通过《我转产品了-前端转产品是一种什么样的体验》这篇文章与大家分享，评论区惊现一波大佬。由于比较忙，不知不觉好像转眼间已经又过去一个多月，这次趁着周末没有开成会，给大家分享一下最近的『趣事』。

目前在并行中的一个项目主要是类似文件管理的功能，在这个项目中主要是旁听的角色，这个项目的产品和需求是由公司的一产品朋友来做。在文章中产品功能描述部分由于众所周知的原因，我只会粗略的提一下。

客户说的

用于简化传统 OA 系统的某些繁复操作。最好能编辑、预览，如果没有的话也可以，先上一版。

我们准备给客户做的

我们给客户画了第一批原型，浏览器登录一个网址，注册一个账号、密码…… 然后在文件系统中可能在线预览图片、PDF、word、excel 之类的。

客户其实想要的

在演示的时候，第一个界面，客户质问为什么我们的系统还需要输入网址？还需要登录？大家一脸懵逼。然后解释因为数据是服务器器上的，在浏览器里输入地址，就能访问我们的系统了。然后如果不使用用户名和密码登录的话就不知道谁是谁。

客户说：『我们云桌面对每个人都是唯一的啊，不需要再搞一个账户……』

我们说：『因为我们系统是在浏览器里的，浏览器是访问不了操作系统里的用户信息的，所以需要注册一个用户密码……如果觉得麻烦，我们也可以后台先注册后，然后登录之后记住登录状态，就不用每次都登录了。』

客户：『行吧。』

然后讲业务流程……

当讲到某文档的审核功能时，比如如果审核人需要对 word 进入批注，需要下载，然后添加批注，再上传到审核意见附件中。

客户：『为什么要下载？』

我们：『因为我们的是浏览器。』

客户：『行吧。』

矛盾分析

经过了几周、几轮之后的演示，客户还经常时不时问一些为什么我们系统不能直接进行某操作的想法。想要不用写到这里大家都很清楚了，客户想做的东西其实是一个便于操作的文件管理系统。要实现最大的便利性，最好是与操作系统打通。

但我们这边技术栈主要是 B/S 架构的经验较多，桌面程序的经验基本没有。并且应该我们这边认为浏览器里的文件管理操作也是很常见的，比如各大网盘都可以在浏览器里进行文件操作。

我们调研的方向都甚至是通过各种 js sdk 实现浏览器中预览 word、excel 的功能。

一些自己的想法，不知该如何讲

这个产品讨论会来来回回5-6次到现在还没结束，虽然从第2次我基本就确定客户这种应该使用桌面端来实现比较好。但是这种东西不好讲，这是产品和技术人员去决定的东西。

不能随便讲的原因在哪里：

• 角色只是旁听者就不要去定一些方向性的东西。

这个应该大家都明白，角色问题。

• 每个方向最小和最大会有什么后果，团队是不是能承担？

这个也比较清楚，难度问题。首先讲，如果做成桌面端，团队没有这方面的经验，遇到操作系统相关的 API 调不起来怎么搞？兼容性怎么搞？我了解的前端肯定是实现不了，虽然 node/electron 可以与操作系统交互，但当前前端团队无相关经验的人。虽然后端 java 可以与操作系统交互，但我不可能给客户说这东西我们这边后端 java 能做。

所以我的想法是：如果他们与客户能达成使用浏览器完成这个系统的共享，清楚浏览器与桌面程序的能力边界。那么何乐不为呢？

我方开始妥协

第6次演示原型时，客户又讲到，那如果一个文件要下载也行。但使用这个系统的人可能年龄都比较大了，下载到哪里自己经常都找不到。

这也确实，每个文件都要下载来操作再上传已经很麻烦了，再像在垃圾里去翻刚刚下载的文件，就更麻烦了。客户问能不能下载的位置我们系统可以指定的？

我们再次说下载位置是浏览器规定的，系统指定不了。然后客户提到，实现不行像 ftp 这些工具一样，能把文件传到某个指定的位置也行……

然后我们技术负责人说，那这样的话，看能不能把两台设备互通，当浏览器里要下载某文件时，向后端发起请求，后端从服务器上操作客户端电脑。客户说可以啊！

我理解上一段话下来是这样：

客户端与服务端有某个通道，允许服务端操作客户端，比如文件创建、删除。然后客户端的浏览器里要下载某个文件到 C 盘时，向服务器发起请求，服务端去后台下载文件到客户端的 C 盘。

看起来到也可行，这对前端浏览器而言还是一样的。直接向服务端发请求就行了。

但是我的想法是这样的：？？？

准备好了吗？坑要来了

上面说的功能结果是可行的，并且客户也是接受的，而且前端也是一样的只需向服务器发起请求即可。但是我有以下想法：

• 有点绕。
• 服务端要如何远程操作客户端？这是个问题。在客户端上装个自己写好的 curd 操作的程序？服务器通过 telnet 等现有工具远程后台操作客户端？

据我所知有一种从天而降的掌法，叫 electron，主要是前端来弄，可是这东东体积太大了，当然体积在当前客户这里不是首要问题。首要问题是这东西虽然很厉害，但这里的前端不会 node。还有一些方案，浏览器插件配合、WPF 这些也都不用讲了。

所以有没有一种方法，不需要会 node，不需要后端语言(比如java/C#)，不需要安装依赖(比如运行库、浏览器插件)、兼容现有前端已写好的页面和接口，如果需要调用系统 API(例如文件、IO、进程)，前端只需要调用 js 方法传参即可，有点像 JSBridge。

就针对于我个人的见识层面和需求层面来说，约等于没有。所以我打算自己弄个（挖坑）。但我不能说我要挖个坑啊？

开始挖坑

我尝试性的问技术负责人，如果使用套壳浏览器的方案，前端正常写，如果要操作文件时，前台能直接调用 js 方法，例如创建文件、打开文件、定位文件等等。您看行不？负责人问，那要检测文件修改上传可以吗？我愣了两秒，说可以（就算不能监控修改，也还有通过获取文件MD5对比的方式）。然后我能说那我会后给您提供一些 demo 你看看。

给出一些 demo，让坑看起来没有坑

为了证明方案的可行性和便利性，我用团队当前技术栈 Vue 为当前文件系统可能用到的操作都提供了示例：

• 进程操作。创造子进程、使用系统程序。
• 文件定位。给定一个文件路径，让资源管理器直接定位到它。
• 文件后台下载。后台下载文件到指定位置。
• 文件后台上传。后台上传上件到指定接口。
• 文件操作。文件创建、修改、重命名、删除……
• 文件打开。以默认程序或指定的系统程序打开指定文件。

定制好图标、描述。打包成这个单独的 exe，体积 1.2M，好像有点大了，将就吧。

实测几次没问题之后，发给技师负责人。

技术负责人：『？？？』

不知道当时负责人心里是不是在想：什么玩意？没事做吗？给我发个 exe？病毒吗？你很能吗？产品试用期过了吗？

// 可以编程式创建窗口。
const view = await new main.View(`http://baidu.com`)
view.form.show() // 显示窗口

前端对该方案的实测效果

也可以指定本地文件，例如 desktop.html 。

{
  "page": "desktop.html",
  "pageShow": true
}

过一会，前端同事转发负责人与他的沟通给我，然后一脸懵逼的问他到底要做什么？沟通一波之后，原来会议内容还没同步给前端同事，讲了好半天客户需求，才慢慢知道要搞一个客户端。但他又再次陷入震惊，我一前端，凭什么让我搞客户端？我不会啊！

我突然感觉我有点难。然后我说：『不是我要你搞客户端。是客户要客户端。我只是提供了一个方案，你看得行不』。

然后让其先把我提供的 dmeo 在他电脑上试试看各功能是否正常。

很感动，果然没有问题。

然后同事问：『那这东西把我现在写的系统放进去能正常用吗？』

真是个问题，我说：『不知道，你试试，建议路由 hash 模式。』

然后同事直接把自己的系统的链接放进去，尝试了一下一些自己原有的功能，是正常的。

然后同事问：『这东西基于什么技术，关键词？』

我答：『webview。』

然后同事搜索了一下甩我一张截图，接着问：『和 edge 一样吗？』

我说：『不严格等于，但约等于。』

也不知道同事看了这句话有没有骂我，搁这给我玩哲学？

同事又问：『客户电脑是 win7 的，客户电脑没装 edge 浏览器怎么办？』

我：『拿我的 demo 上去，能打开就是支持的。』

理论上，如果客户电脑上没有 webview 环境，会自动安装。但客户那边网络环境是不通外网的，所以我让直接试。

然后一会之后，实测下来，还好就是支持的。

接下来就是前端同事尝试在已有的项目中去使用我提供的 api 去操作系统上的内容了。经过一波沟通，实测也是没有问题。

疯狂暗示，我挖的坑，与我无关

一边在沟通如何入坑我的轮子的同时，一边我又提供了前端实现桌面程序的其他方案供其选择，时时不忘提醒，你看哪个合适你用哪个。这个 exe 是我封装的，API 只有示例，详细文档来不及写，桌面程序我也没有太多的经验。

PS：意思就是，方案由你选，如果选择我的轮子，某些功能我也要先研究一会，某些功能我也可能解决不了。还有我现在主要重心在产品上，所以可能没时间研究新功能。 /手动狗头保命。

小惊喜

虽然知道 electorn 麻烦，但我这确实没有文档，也麻烦，但是过了几天，突然收到消息：

然后我邪魅一笑（哈哈哈哈，入坑了！入坑了！入坑了！）。

后记

这个坑不是我故意挖的，是有意挖的。因为有一个想法，开发一个简单的桌面程序，只使用前端语言开发，暂只考虑在 windows 上运行，希望开发体验像在浏览器中一样，然后程序的样子像是本地应用一样，调用本地文件、系统命令、后台运行、托盘菜单这些都没有问题。

我调研了一些常见的方案，发现他们大多数都不喜欢，经常体积太大或要求其他语言，有一 neutralino 看起来实现上是想要的，但 api 太少，所以决定含泪造坑，在 api 设计上会考虑贴近 neutralino 便于两者迁移。

代码仓库在这里 wll8/sys-shim ，如果有愿意的小伙伴，可以 star 支持一下。