从编程模型的角度来说，使用声明式语言声明样式和布局，使用功能完备的编程语言编写业务逻辑，算是GUI程序的一种最好的实践了。
最近要写一个个人项目，于是我自然想到使用前端来写界面。通过electron就能使用前端技术开发桌面端程序。它实际上就相当于内嵌了一个webkit浏览器核心，只是做了些裁剪和优化。
此外，前端框架使用我所熟悉的vue，无论是界面代码还是核心代码都采用typescript编写，它的静态类型系统很强大，综合了静态语言和动态语言的优点。
<!--more-->
npm install --global @vue/cli # 2. 创建一个新工程，并选择 "Manually select features (手动选择特性)" 选项 vue create idocumentation
勾选上typescript，其它的按需勾选。
Vue CLI v3.0.0-rc.3 ? Please pick a preset: Manually select features ? Check the features needed for your project: Babel, TS, Router, Vuex, Linter ? Use class-style component syntax? No # 是否使用class风格的组件定义 ? Use Babel alongside TypeScript for auto-detected polyfills? (Y/n)Yes ? Pick a linter / formatter config: TSLint ? Pick additional lint features: Lint on save ? Where do you prefer placing config for Babel, PostCSS, ESLint, etc.? In dedicated config files # 分离配置文件
这样，vue脚手架就自动帮你初始化好typescript + vue项目的结构了，可以进去看一看。
TSLint会对代码的格式和规范做检查，帮你规范格式，同时也会帮助你避免不好的习惯带来的bug。
不过默认的配置有点严格，这可以修改tslint.json来做到，下面是我的配置：
"rules": {
"quotemark": [false, "single"],
"indent": [true, "spaces", 2],
"interface-name": false,
"ordered-imports": false,
"object-literal-sort-keys": false,
"no-consecutive-blank-lines": false,
"eofline": false,
"prefer-const": false,
"no-console": false,
"trailing-comma": false,
"max-classes-per-file": false
}如果你觉得某个检查太严了，可以关掉，具体的字段参考这里： https://palantir.github.io/ts...
首先安装：
npm install -g electron # 全局安装方式 npm install electron # 本地安装方式 推荐
然后编写electron主进程的入口代码，这里有个参考，将它放在项目根目录的main.js中：
https://github.com/electron/e...
注意到其中有一行：
mainWindow.loadFile('index.html')这是electron启动时加载的前端页面文件，当然，也可以让electron改为从url加载，就像用浏览器打开一样：
mainWindow.loadURL('http://localhost:8080');一般的工作流是，使用vue的开发服务器启动vue的开发服务器，vue开发服务器会监听在8080端口。
该服务器会监听文件系统事件，当修改了项目代码后，它会重新编译、打包。
所以，开发时，让electron从vue的开发服务器加载主页面，则开发起来更方便。
最后在package.json下加入：
"main": "main.js",
// ...
"scripts": {
"electron": "node node_modules/electron/cli.js ."
},其中，main字段指定项目的入口文件，也就是刚才编写的main.js。
scripts配置的含义是，当在终端运行 npm run electron时，会执行：
node node_modules/electron/cli.js .
这段代码会
首先，在终端里执行：
npm run serve
它会启动vue的调试服务器，一般监听的是8080端口。不过，这个服务器比较智能，如果发现8080被占用会主动换端口。如果和electron搭配使用时调试的时候要注意这一点。
如果这个时候在浏览器打开http://127.0.0.1:8080也能正常访问，但是最好还是要在electron中调试。因为electron项目可能涉及到操作系统相关库的调用如fs，使用浏览器是不支持的。
其次，终端再开一个tab，执行：
npm run electron
如果一切顺利，electron的GUI就正常打开了！
但是，上面的配置还有一些问题。我们来看vue项目的流程：
首先你编写的vue项目被vue的开发服务器检测到
开发服务器会将其编译、打包
electron访问vue开发服务器，拿到网页和代码，类似浏览器一样
网页和代码在electron环境里渲染、执行
那么，如果一个库要想正常使用，需要满足：
vue的开发服务器打包时需要将该库打包进来
electron环境中需要支持该库的运行
然而，默认的vue打包配置是针对浏览器的，不会也没有必要把操作系统相关的库给打包进来，如果这时直接调用fs等库，会出错。
解决方案是修改webpack的配置，编辑vue.config.js，内容为：
module.exports = {
configureWebpack: {
target: "electron-renderer"
}
}electron项目中引入sqlite真的是一种折磨！啊啊啊啊！配置出了问题，代码都没法写，写了也没法运行。
搞了我一下午的时间，目前我还没有完全解决这个问题，如果谁有好的方案请告诉我，谢谢！
目前引入sqlite会遇到两个问题。
第一个问题则是sqlite由于是C编写的，安装时会遇上编译、链接的问题。
如果直接：
npm i --save sqlite
那么你引入sqlite包时，肯定会报错。因为electron无法调用sqlite的native二进制库。
即使你解决的了问题一，这还没完，还有一个更大的问题。
前面说过vue程序代码是需要被webpack编译、打包的，然而webpack打包并不能打包native模块，像sqlite这种的。
这里提到，这不是bug，这是feature：https://github.com/mapbox/nod...
是不行的！你还需要将sqlite的二进制库文件链接到electron的二进制文件上去，对的，就像你配置C或C++程序那样恐怖。好在有现成的工具，执行：
npm i --save-dev electron-rebuild ./node_modules/.bin/electron-rebuild
它会重新编译链接electron。至于能不能成功，看运气吧。
我在Windows下尝试了下，一会说需要python环境，一会网络链接又不行要下什么预编译包，总之事情很多。
后来在linux环境下尝试了，成功了。之后在electron的主进程里，也就是前面说的main.js入口文件中，尝试了下发现可以使用。
方案一解决了问题一。那么还有问题二没有解决。
我们梳理下现在手上的问题：
sqlite库能够在electron主进程运行。
sqlite库由于webapck的原因无法在渲染进程中运行。
那么，一种很自然而然的想法是，让实际的sqlite调用在主进程执行，渲染进程通过IPC方式和主进程通信。
如果把这种过程封装起来，即渲染进程中调用某个包装类来调用sqlite3，而包装类会将对应的调用信息通过IPC发送给主进程，主进正调用sqlite3模块来完成操作。
这种方式封装了就是远程过程调用（RMI）了，如果需求不高也可以不封装。
方案三则是用其它的替代思路了。有一个叫做sql.js的库，也能够操作sqlite。
这个库很有意思，它纯粹用js实现的。怎么做到的？性能能好吗？
准确的说不是js。这个库不是手写的代码，它是使用Emscripten将sqlite的C语言实现编译成asm.js。
而asm.js是一个js的严格子集，模型上和C更能对应上去，一旦js引擎发现运行的是asm.js，就跳过语法分析直接转为汇编语言。
但是它有几个缺点：
只能操作内存中的数据库，无法操作文件系统
性能和原生实现的sqlite相比，很显然，不高
如果在electorn中要拿它暂时用一用，则需要把数据库完全读入到内存中操作。处理不好，内存会爆炸的。
好在我这里需要用的sqlite只是存存元数据，几十k大小，还是能勉强用用到。先临时用这个顶上，封装一层，写后续的代码。前端和node发展很快，等以后有人弄出easy的解决方案了，再切换回sqlite模块。
方案四则是看看能不能改下项目的技术选型，要不换个其它的嵌入式数据库？
electron的优点在于大大降低了开发成本，本身前端的方式开发界面就是一种良好的实践的，而前端蓬勃发展的今天又有大量的框架和组件库可供直接调用。
记得大学里写过GTK和Qt的图形界面，对比之下，传统的Qt写界面非常麻烦费事，而且也远远没有前端漂亮，动态性也差一大截。
不过electron的缺点在于打包后体积太大，而且运行性能不高。不过一般的场景中，这点缺点问题不大。
下载本文