坑很大。
很大。
坑的起源：我有一个 idea
今年 7 月，在几个产品 MVP 都无人问津后，我也开始思考下一个产品要做啥。正巧这时候在做一个项目的后端，需要自测，也就要用到 postman 一类的工具。
找了一圈没找到合适的，对我来讲，他们大都有这样的问题：
- 启动时弹窗要登录，或者弹窗告诉你这个版本不被支持了，一定要你升级
- 由于后端开发要对同一接口请求多次，导致历史记录基本没什么用
- 保存请求后，读取这个请求，请求另外一个地址再保存，这个保存的请求会被覆盖掉…… 经常误操作，所以还不如历史记录有用
- 客户端大都基于 Electron
那么，为啥不自己写一个，作为公司的下一个产品？越想越觉得这个点子靠谱。开干！
毕竟没做过桌面端应用，我预想到会有坑，给了自己一个宽松的时间：
两个月半之内（九月底），做一个 postman 替代品，实现环境，文档，同步，支付等功能并上线正式版开卖。
这时我还不知道，被坑支配的恐惧……
坑一：Rust
写 Rust 一时爽，一直写 Rust 一直爽。语言设计充满合理性。函数式编程，泛型，trait 等特性让它写起来完全不像是系统语言，非常像高级语言。亲切的编译器不但会告诉你有问题，还会手把手告诉你问题的原因可能是什么，顺便再教你点你不知道的 rust 规则细节。
那么为什么说是坑呢？
因为在生产项目中运用不熟悉的新技术都是给自己挖坑。而 Rust …… Rust 太难学了。
Rust 的书看得头疼，所有权的概念不好理解，语言设计复杂度高，但真正写起来时…… 会发现比文档里还复杂。
比如说，用一个数组（vec）保存实现一个 trait （类似 interface） 的多种闭包（匿名函数），并写一个函数接受闭包参数并存储在这个数组中，这时需要 1. 数组里，将闭包放在一个容器（box）中，2. 函数里，给闭包加上 + 'static 修饰。
为什么？
-
Rust 中每个匿名函数都属于自己的匿名类型，将这些不同类型的函数放在一个数组中，也就是说必须是动态存储，编译时不知道到底是哪些类型，也就不知道它们的长度大小，必须要用 box 包起来才能保证长度一致。
-
通常情况 'static 是表示一个变量引用的是静态变量，但在这里这是表示这个闭包只会引用静态变量，不会出现这样的情况：一个函数返回一个闭包，闭包引用了函数中的本地变量，函数返回后这个本地变量失效被销毁，闭包调用时又去访问这个无效的变量。
这解释，我自己看着都头疼。
写 Rust 时，时常会遇上这种情况，文档看完了觉得自己懂了，但实际写起来时，会遇到怎么也想不通，怎么写也编译不过的情况，stackoverflow 查无数资料，并筛选掉已经过时的资料后…… 才终于能搞懂。
除了难学，复杂之外，还有两个问题：
问题一：语言虽然稳定了，但也还在积极开发中。也就导致：1. stackoverflow 上有不少过时的答案 2. 重要特性如异步（async）还没稳定 3. 有的库只支持 nightly rust。
问题二：生态还不成熟。如：异步还在完善中，GUI 库刚起步。
坑二：桌面 GUI 和 web 开发差别不小
不同的领域需要不同的技术。
写 web 时，不管前端后端，基本都不用进行手动线程管理，或者考虑各个操作系统的兼容。
写桌面端就不一样了，想异步发个网络请求？新建个线程呗。想异步写文件？新建个线程呗。
想要有回调，async（Promise，future）？嘿嘿嘿，GUI 程序有个消息循环跑在一个线程上，异步一般有个事件循环跑在一个线程上，你可以把异步操作整合到消息循环里去，也可以再开个线程跑事件循环，再写个东西让这它们两能互通。
朋友，你喜欢造轮子吗？
再比如说，web 前端早已从绑定事件 + dom 操作转向了 React 一类的 MVVM 模式，而我所选的 GUI 库的使用方法仍然是事件驱动，手动更新 UI。难道……要自己写一个 React ？
朋友，你喜欢造轮子吗？
坑三：GUI 引擎的选择
GUI 引擎跨平台的有如 wxWidget, GTK, Qt。喜欢自虐也可以用各个平台原生的。
Rust 原生的也有一些，但并不成熟，不用考虑。
和 js 前端框架不同，成熟的 GUI 引擎都有不小的复杂度，很难看一两个教程就了解全貌，也就导致…… 都没用过的话，真不知道要怎么选。
比如 GTK 的架构就包括 GTK+，Pango，GDK，ATK，GIO，Cairo，Glib。他们都是干啥的？比如 Qt 还有个 Qt Quick，有啥区别，有啥坑？
比如 wxWidget 官网里文档导航下第一项是一本 700 页的书。
写 js 时，不管前端后端，基本一个 readme.md 就能搞清楚这个库是干啥的，怎么用，撸起袖子就可以开干。但这些 GUI 库，光是找到文档页就得花一番功夫。
到底怎么选？
此外，C 和 Rust 的内存管理风格差别很大，就算有 binding，也可能会很蹩脚……怎么办？
本着对 Linux 和开源的好感，我一开始准备用 GTK，但 GTK 示例项目在 Windows 下崩溃了，此外，我发现 GTK 3 直到 3.4 才真正支持 Windows，让我怀疑它的跨平台性……
最终选择了 Sciter，一个 5M 大小的使用 HTML 的 GUI 引擎。体积小，内存占用低，还是熟悉的 web 技术，好几个杀毒软件用了它，所以也经过了市场验证。
那么，代价是什么呢？和标准不兼容，要重新学一遍 HTML / CSS，文档很差，坑不少，渲染性能也和 Chrome 有差距。当然也没有 React 给你用。
在被 Sciter 折磨的日子里，我无比怀念写浏览器应用的日子…… 作为用户，虽然我仍然不喜欢 Electron，但我开始理解为啥开发者们这么喜欢它…… GUI 应用开发太难了。
踩坑的代价
开始开发一个月半后，在八月底，开发陷入了泥沼，我的动力也跌到了谷底。
-
开发过程中经历了多次返工重构，新老代码夹杂，比如：代码中存在一种同步和两种异步操作数据库的方法。
-
已完成的部分不少需要修补，比如 UI 太丑需要重做，有些地方错误处理得并不好。
-
离完成遥遥无期。还有很多功能完全没有开始做。粗略估计一下，半年完成当初的预想可能是比较现实的估计……
-
每天开工都想摔键盘。八月有两个周末也接着码代码，不仅没有加快进度，反而透支了精力。
实在太过痛苦，让我已经想要放弃……
从快要烂尾到 0.1.0
如何从坑中爬起来？
-
拆分最初的目标，将“一下推出带文档，同步，导入导出，付费功能的 1.0 版”变为从 0.1 - 0.5 五个版本，先推出功能残废的 0.1 版，再慢慢完善。
-
进一步将 0.1 拆分为四个版本，0.0.1 重新设计界面，清理旧代码，0.0.2 关于窗口，错误提示等，0.0.3 增加 json 代码高亮，聚合开源库的协议等，0.1 自动检查更新，sqlite 数据库路径改为 home_dir，release 版去掉调试相关功能，添加示例项目。
-
每完成一个小版本都给自己放个假，身体是革命的本钱……
终于在十月底，完成了 0.1.0 版并发布，不管怎么样，没有烂尾，可以松一口气。
经验总结
-
超过一个月的项目都最好有里程碑，一步一步慢慢来，不管是个人开发还是团队。
-
编译类语言和解释类语言的差别不小，web 编程和 gui 编程的差别也不小。跨领域要做好心理准备。
-
Electron 也挺好的，虽然我仍然不喜欢它。
-
Rust 是真的香。