Appearance
Electron 为什么“手感差”？
—— 我自己的体会与一个可能的方向
我做了以下项目：
- 用 Electron + Egret 做了一套游戏编辑器
- 用 VitePress（也是网页架构）做了完整的 wiki
同时也尝试过 ImGui、Qt、Electron + React/Antd 等方案。
越做越觉得：Electron 那种“看得见但摸不着的延迟”， actually 是结构性问题。
这篇不是选型指南，更像是一个开发者走过之后、回头总结出来的思考。
一、为什么 Electron 的 UI 手感天生不如原生？
用户不是错觉，Electron 的链路就是比原生长：
主进程 → 渲染进程 → 虚拟 DOM → DOM → 布局/绘制
DOM 本来就是为“展示内容”而非“高频交互”设计的。
多这几十毫秒，就足够让人觉得“点了没反应”。
更关键的是 心理预期：
- 浏览网页：你默认会等 30ms
- 使用编辑器：10ms 的延迟都让人烦躁
因为网页的本质是“看内容”，
编辑器的本质是“干活”。
这是 Electron 最大的先天矛盾。
二、DOM UI 与工具 UI 不是一回事（重点）
前端世界的“UI”这个词有严重歧义。
展示型 UI（Vue UI、React UI）
- 表格、卡片、弹窗
- 样式复杂
- 目标是“把内容展示得漂亮”
操作型 UI（编辑器 UI）
- 高频拖拽
- hover、double-click、right-click
- 精确焦点管理
- 复杂布局器（面板拆分/合并）
- 即点即亮的响应速度
两者的目标从根本上不同：
- 展示 UI = 让人看
- 工具 UI = 让人操作
于是出现了一个常见误解：
“已经有那么多 UI 库了，为什么 Electron 工具 UI 还是不好做？”
因为展示 UI 无法满足工具 UI 的性能与交互语义。
根本不是一个物种。
三、那游戏引擎 UI 行不行？（Egret / Laya / Cocos）
我自己的答案是：
能行，而且比 DOM 更适合工具。
游戏引擎 UI 天生具备工具 UI 所需的特点：
- 固定尺寸
- 绝对像素布局
- 高帧率渲染（WebGL/Canvas）
- 无 DOM 阶段，手感快得多
但它们的短板也是真实存在的：
游戏引擎 UI 的不足
- 缺少工具常见行为（右键、双击、hover 等需自己补）
- 没有丰富的组件生态
- 默认工程结构较重
- 学习路径需要跨游戏领域
不过这些可以按需自己扩展，
工具体验确实比 DOM 系 UI 舒服太多。
四、为什么很多人愿意学 Qt，却不愿意学 Laya/Egret？（心理差异）
一个非常典型的心理现象：
| 框架 | 技术难度 | 心理阻力 |
|---|---|---|
| Qt | ⭐⭐⭐ | 低（名字就是做工具的） |
| Electron | ⭐⭐ | 中（网页=能做应用） |
| Laya/Egret | ⭐⭐ | 高（名字看起来像“做游戏的”） |
但事实是：
- Qt 要学 C++/QML/信号槽，难度不低
- Laya 的 UI 层反而简单清晰很多
真正阻碍大家的，是“名号”带来的心理预设，而不是难度本身。
五、如果要在 Electron 里做工具，我认为 Laya 比较合适
理由很简单：
Laya 的优势
- 自带可视化 UI 编辑器
- 事件系统独立于 DOM
- WebGL 渲染手感快
- 布局清晰、无 HTML/CSS 的怪癖
- 适合高频操作、固定布局的 UI
唯一的门槛是“让 Laya 跑进 Electron”需要少量配置。
但搞定之后，用起来非常顺手。
六、但整个方向仍缺最后一块拼图 —— PixelUI.js
做了这么多方案之后，我越来越觉得：
真正缺的是一个专门用于桌面工具 UI 的 WebGL UI 库。
它应该：
- npm i 即可使用
- 自绘 UI（跳过 DOM，延迟低）
- 内建工具语义（hover/right-click/dblclick/快捷键/焦点管理）
- 搭配一个简单 UI 编辑器
- 能无缝跑在 Electron
它既不是游戏引擎，也不是网站 UI 库，而是：
第三类 UI：专为桌面工具的高操作密度场景而设计。
目前这个方向几乎是空白。
而它的价值其实非常大。
七、如果未来有人愿意做这个库，我相信会很有意义
说实话，我目前精力有限，只能把这个方向记录在这里。
但我真心认为：
PixelUI.js 这种东西是缺失的。
它一旦出现，会大大提升 Electron 工具开发的生产力。
不是把游戏引擎魔改成工具 UI；
不是把网页 UI 强行拉进工具场景；
而是从“桌面工具”的真实需求出发重新设计。
如果未来有人愿意把这件事做出来，那一定是件好事。
全文完。