前言

我的技术栈次要是 vue3、go、java 等。

前端对界面的表达力是最强的，所以暂不思考原生相干的 ui 技术，如 fyne、QT bind。

而单纯的基于 web 的跨端计划，尽管能提供一些根本的零碎级操作，但对于自定义的底层需要还是须要 go 来解决。

我选的技术计划就落在了 vue+go 上，从原理上分为：

• 独立 UI+websocket+ 底层 Go：electron, tauri
• Go 管制的 UI+websocket+ 底层 Go：lorca, webview
• Go 残缺打包的 UI+jsBridge：wails

计划比拟

electron

算是 web 跨端中最具生态和成熟的计划，几年内也陆陆续续用过几次。

但最终也是因为它打包太大、依赖装置常常失败、打包上也遇到不少坑，太过折腾就放弃了。

tauri

https://tauri.studio/en/

底层由 rust 实现，UI 渲染依赖于 webview2 或 webkit，提供 js api 拜访零碎性能、以及和 rust 底层交互。

以前端开发为主视角，tauri 的相干库搁置于前端工程中的 src-tauri 文件，对前端我的项目的侵入性较小。

能打包成一个独立的程序，在 OSX 下测试的成果还不错。

然而在 windows 下搭建环境时会遇到依赖装置谬误，打包工具是基于 node 的，过于折腾就先不去解决了 (穿插编译的反对也在打算内)。

目前 tauri 公布了 beta 版本，go binding 的反对还在打算内，所以如果我要以 go 为底层的话，只能采纳 websocket 或 http 的通信形式。

tauri 还打算公布 android 和 ios 版本，能够期待下。

lorca

https://github.com/zserge/lorca

原理上是从 go 调用了 chrome，而后启动了定制化的 chrome 界面，所以须要依赖 chrome。

这是我用的比拟多的一个，因为间接能够从 go 来管制启动敞开，加载页面等等。

毛病也很显著，开启利用自身是 chrome 的一个窗口，所以不能做过多的定制化。和 go 之间的通信，须要自行用 websocket 或 http。

其兄弟我的项目 github.com/zserge/webview，提供了较多的定制性能，将 webview 内置。然而在编译打包时还是有一些坑，以及有些性能没找到用法（可能得用 c ++？），比方全屏。

wails

https://wails.io/

和 tauri 相似，然而底层为 go，而且是以 go 我的项目的主视角来打包，也是基于 webview2 或 webkit。

目前推出 v2 版本，临时只反对了 windows 的打包（在 windows 中须要 webview2 环境反对）。

v2 的总体应用体验很不错，劣势如下：

• 能够做到前后端拆散开发，打包时只须要在 go 中引入前端打包好的 dist 资源即可。
• 提供了 js 和 go 之间的过程内通信。
• 打包工具是基于 go 的，根本能防止基于 node 打包时依赖装置的“劣根性”。目前在 windows 中打包运行测试很顺畅。

我认为在 go+web 这个方向，wails v2 应该是目前最好用并且符合要求的一款。

小劣势就是还在 beta 中，osx 和 linux 的行将推出。有些浏览器的深度定制没有凋谢进去，比方 webview2 对不平安资源的拜访权限问题，须要底层反对后开发配置进去，不过好在社区响应及时。

总结

我会继续关注 wails 和 tauri 的停顿。

我的项目利用中，将从 lorca 逐渐迁徙到 wails 的形式中。