最近用Electron弄了个工具原型,察觉到软件复杂性的一些问题,随手写一点。

Electron是个使用浏览器做客户端软件的软件框架,官网在这里:https://www.electronjs.org/

用浏览器技术写客户端,看上去很有吸引力是不是?我也觉得是,所以使用了一回,发现Electron的技术体系,各路天坑是无比的多。

软件包大,这就不用提了。它是塞进了整个浏览器系统进去,版本越新,尺寸越大。浏览器技术多复杂啊。

但是不同的打包工具,打包出来的文件尺寸差别还巨大,难以理解。Electron-builder 在macOS上面打包,就比electron-forge小很多。Electron-forge搞出来的包,能有1.7G。

真正的困难是软件相互作用产生的复杂性。

使用Electron,就会本能的想到:既然使用浏览器做UI,那么前端那么多好的UI框架:React、Vue,是不是直接加进去,就如虎添翼了?对,很多人是这么想的,我也不例外,也是这么干的。我把React框架和一些UI组件塞进Electron里面了。

然后第一个大坑出现了。前端工具链的相互作用,导致配置非常的麻烦。而且其中还有不少矛盾需要解决。

Electron和React的执行环境不一样,配置需求不同,默认的入口程序也不同。

react + electron

首先要翻越的障碍是思维切换。Electron使用的是Node技术结合浏览器,React使用的是浏览器环境。两者的目标是不同的,互相矛盾的。React打包之后,浏览器加载入口页面index.html,连带加载js代码,启动程序。但是,Electron启动的是一个js程序。如果要使用React,就必须在启动后加载打包好的index.html,这是一个两次加载启动的过程。

初次使用Electron + React 的用户,往往难以理解这个概念上的差异。而这还没结束。设置React框架的时候,一般都用官方的”Create-React-App” 脚手架工具包,它默认使用WebPack做打包工具。但是WebPack并没有准备兼容Electron的环境,所以它打出来的包,是无法直接加载的。需要修改打包的“target”为:’electron-renderer’。因为它得按“渲染器”进程来使用。

如果你还想使用TypeScript,那么配置复杂性还得更上一层楼。因为TS默认不能直接执行,需要额外的编译打包。建议初学者打住,先不要自找麻烦。

github上有配置好的Electron + React + others 基础工程框架模板,可以拣选使用,热门的我都看过,配置还是比较复杂,工程文件很多。根据需求的情况挑选吧。

在调试阶段,一般是使用Electron加载React启动的本地服务来进行的。Electron在入口程序中,加载:”http://localhost:3000″。这个时候需要区分Electron是不是调试状态。

然而,一个常见的问题是,调试阶段没啥毛病,打包安装运行,启动就是白屏幕,啥也没有。这个时候,要开调试工具,打开页面的调试组件,看看是不是文件没法加载到,是什么原因。我遇到的问题是,macOS下,打包运行的程序,找不到编译后的React代码。后来发现是electron-builder配置有问题,被过时的文档误导了。

Electron变化很快,版本不兼容的情况很多,所以时间稍久一点的文档,要保持警惕,它未必是对的,很可能误导你。

更让人头痛的是,调试运行正常,打包后运行失败,页面内的组件报错。这种情况,只好分部分,一点一点排查了。React的编译很慢,Electron的编译也有很多麻烦 – 附加的包经常下载不了,国内网络问题。记得这个有效的方案:

ELECTRON_MIRROR="https://cdn.npm.taobao.org/dist/electron/"

添加到Electron编译指令前面,确保从国内下载软件包。

然后一遍一遍的修改、编译、打包、运行,排查吧,一个轮次5-8分钟,简直是煎熬。谁能想到,前端程序的编译打包能耗费如此多的资源和时间?C++时代也没这么离谱过。

你想换个打包工具是不是?跟我想的一样,咱换个Snowpack 或者 Vite 试试看,说是利用了浏览器支持,速度飞快。然后就会发现,掉另外一个坑里面去了。工具链兼容有问题,这个不行那个不行,搞来搞去,还是Webpack兼容性最好,虽然它慢如蜗牛。

从个人观察来看,软件系统的复杂性来源有多种。

业务复杂性是一个,它带来商业逻辑的种种变化。不同的需求带来不同的实现算法复杂性。此外还有一个就是软件环境和软件之间的交互作用带来的复杂性。

在工具链越来越长,使用的工具系统越来越多的时候,这种复杂性指数级提升,甚至可以达到普通用户难以驾驭、很难解决的程度。就看看前端开发那一大堆软件包吧,Node、浏览器、npm及其黑洞、编译器、打包工具,UI框架体系。。。

它们的互相影响导致正确的配置是不容易的,这也是脚手架工具的来源,它帮你整理配置好了。但是不同体系之间的影响,还是需要你去处理,比如Electron + React + 不同的操作系统

简单总结:别低估Electron技术体系的复杂性,不要以为 – 不就是用浏览器和页面写程序么,很简单,远远不是的。它有一堆的技术细节需要用户去处理修正。使用的附加技术越多,互相干扰也就越大,需要解决的问题也就越多。

不要小觑了拼多多,它现在能干翻淘宝
编程语言的类型系统并不是核心问题,不要迷信银弹