现在不管是国内还是国外都在用Electron做跨平台开发
https://www.infoq.cn/article/UsFEXJyrVBiTYocM3BkS
连招商银行的个人银行PC版也在用
但是Electron版APP和PC软件太卡，体积大-体验差。
QQ前两年也用Electron重构
https://www.36kr.com/p/2329529869966977
表示C++&Qt人才少，招不到。
那可以招Java啊！
Java好像除了不能跨iOS，Win&Mac，Linux，Android都能跨，后端更没问题。
可以AOT编译运行，速度也很快，就是安装包大点，但对比Electron算苗条了。
每个平台虽然还要调整适配，却带来了运行效率的大幅提升，还是值得的。
但很少见到采用Java跨平台开发的，见过少部分还是金融等传统行业，To C消费端没见过。
是不是因为Java开发的UI不好看？
只有一些自己使用过的经验:
也有用 webview 代替 Electron 的方案 (webui, webview), 缺点就是用起来貌似多多少少还有一些小 bug 需要自己调整 (webview 是没有很好的多窗口和菜单栏管理, 不知道新的有没有修正), 没有 Electron 那么成熟.
理论上实现一个小服务器 + webview 做前端, 后端啥语言都可以 (比如 Common Lisp 的 CLOG).
或者可以有更加 “异端” 的, 用 Emacs 来做前端 (论坛里面好像有作为数据库的前端的帖子, 可以找找看). 以下是一个简单的例子:
;; Example:
(with-widget
"Widget Buffer Name" (local-var1 local-var2)
(widget-insert "Example:\n")
(widget-create 'radio-button-choice
:value "balabala"
:notify (lambda (...) ...)
'(item "balabala")))
;; with-widget
(cl-defmacro with-widget (buffer-name local-variables &rest body)
`(progn
(switch-to-buffer ,buffer-name)
(kill-all-local-variables)
,@(cl-loop for local-variable in local-variables
collect `(make-local-variable ',local-variable))
(let ((inhibit-read-only t))
(erase-buffer))
(remove-overlays)
,@body
(use-local-map widget-keymap)
(widget-setup)))
好处就是 Emacs 在哪里哪里就能运行, 以及开发也挺简单的 (心虚), 作为类 TUI 来使用效果极佳, 坏处也挺显然的…
(但 Electron 确实更省心? 没怎么深度使用过…
Java也很笨重，UI也不好看，跨平台app开发没有优势。electron 门槛低，UI漂亮，好招人…… 虽然我也很反感它，但确实方案算是比较成熟的。目前只有VSCode优化还算可以，其他都慢
Graalvm 是不是比起 C++ 来一样不好找
看标题我还以为你会说些其它流行点的跨平台方案，java…那玩意写界面除了jetbian用得还可以，还不如 pyqt 这种方案来着实在。
现代语言的图形技术跨平台适配又不是啥难事了，何必用java这种罗里吧嗦，性能体积还没有太大优势的语言。web方案嫌弃electron太大，还可以选择cef这种，或者更简单一点套一层webview + native 的混合方案也比你java去写gui来得划算吧。
那玩意想做的事情，我越看越像是再搞个.net平台。想搞多语言统一到一个工具里，结果最后还是主打一门，就像.net搞了个统一的运行时，结果还就csharp能流行。同理graalvm也只能主打一个java。
那倒不至于，实际上 graalvm 对 Java, Scala, Kotlin 支持都很成熟，因为都是先编译成 JAR 的。 Python，JS，Ruby 的支持倒可以是当成附送的，因为这些都不是原生运行在 JVM 上的。
快并不代表跨平台细节。
很多抱怨electron的人并不关心自己用的其他平台。
跨平台不是js，而是不同系统的窗口管理和底层细节，目前没方案做的比electron好，要不大家早换了。
你说的那几个都是jvm生态的，除了java都挺小众的（在国内）。所以我才说它可能最多只能做成个jvm版的.net生态。
主要还是因为前端开发可以直接转桌面开发，能提高人效——可以利用 Web 前端的生态，Web 前端和 互联网产品经理/UX 的设计习惯都可以迁移到 Electron 这套东西上去。
不确定我的比喻对不对，我理解现在 Electron/Chromium 那套东西有点像 “静态连接”， 每个 App 都 copy 了一份浏览器内核。不知道以后有没有机会，所有 Electron 应用共享一份 Chromium 内核。不过转念又一想，那不是和 ChromeOS 也没区别了吗。
每个 App 都 copy 了一份浏览器内核。不知道以后有没有机会，所有 Electron 应用共享一份 Chromium 内核。
技术上没有难度，microsoft edge webview 和 qtwebengine 都是类似的用 chromium 内核做桌面应用的技术，都支持共享运行时。但是 electron 团队不想做共享运行时罢了。
统一运行时会遇到兼容性和升级的问题，估计electron团队不想搞？瞎猜的
我最近观察到 tauri , GitHub - tauri-apps/tauri: Build smaller, faster, and more secure desktop and mobile applications with a web frontend. ， 得物商家客服从Electron迁移到Tauri的技术实践_tauri 发送消息通知 notification-CSDN博客 得物使用tauri。 上手挺快的
最近又发现Clojure/Java的这个项目，
用的是 同一团队下开发的 Java Window Manager for OS integration (simple, common ground, embrace the differences)
不知道有没有搞头
应该是这样的，闭源/商业软件开发者肯定也更倾向于 bundle 打包的方式，避免用户自己去折腾 chromium runtime 的版本兼容问题。
tauri 是用系统的 webview ，electron 是自己打包了一个 chrome 。所以 tauri 写的应用还是要关注一下跨浏览器的问题，而 electron 就完全不用担心了。不过我也是尽量不安装 electron 的应用。
对，主要是提高人效。Electro是厂商综合成本最低的方案，用户体验也不算太差。
如果只是为了跨平台而不考虑成本，有太多方案了。用游戏引擎做应用都比Electro强，比如QQ音乐就是用 cocos creator 做的。
考虑成本，当你想做一个漂亮的UI，electron实在是最快的。
这年头，对搞互联网的老板来讲，原型的快速交付，以及快速的产品迭代才是最重要的，需求文档都显得多余，计划没有变化快。除非你是搞一些工业软件。
如果能选，我倾向原生 UI 控件，可以保证文字渲染、输入法、HiDPI 支持完美一致。