UI层web性能不足以支撑项目未来发展

[jazzii36]

最近体验了一下项目，整体设计不错，Rust + Vue 的组合也兼顾了开发效率和跨平台能力。
不过作为数据库管理工具，我一直有个疑问：为什么选择 Web UI，而不是尝试全 Rust 的原生 GUI？
数据库客户端和普通后台管理系统其实不太一样。
很多时候用户面对的不是几十条数据，而是：

• 百万级甚至千万级表
• 宽表（上百列）
• 大结果集滚动浏览
• 高频筛选排序
• 实时刷新监控
• 对象树、Schema 树展开
• 这些场景本质上更接近 IDE、数据库客户端、文件管理器，而不是传统 Web 应用。

即使做了分页，实际使用中仍然会遇到：

• 大量 Cell 渲染
• 横向超宽表
• 虚拟滚动
• 列冻结
• 排序过滤重绘
• 大量 DOM 更新
• 浏览器渲染链路（JS → DOM → Layout → Paint）在这些场景下天然会带来额外开销。

尤其当用户：
一页显示 几百行行
同时显示 50~200 列
快速滚动结果集
多 Tab 查询并行时，Web 技术栈往往会先碰到内存和渲染瓶颈。
而数据库客户端又属于长时间运行的软件，用户可能连续打开数小时甚至数天，对资源占用会更加敏感。

项目核心已经是 Rust，如果未来向 Dioxus、Slint、Iced 等原生 GUI 方向演进：

• 避免 JS ↔ Rust 通信开销
• 降低内存占用
• 提升启动速度
• 提升大表格渲染性能
• 技术栈统一
  感觉会比较符合数据库工具的定位。

[t8y2]

感谢建议，这个方向我们也会持续关注。

DBX 目前选择 Tauri + Vue，主要是为了兼顾体积、跨平台、开发效率，以及桌面版和 Web/Docker 自托管版的复用。数据库客户端确实比普通 Web 后台更吃表格性能，所以我们现在已经做了分页、fetchSize/maxRows 控制、结果集 session、以及表格虚拟滚动，避免一次性把大结果集全量渲染到 DOM。

全 Rust GUI 方向有价值，但短期迁移成本会很高，也会影响现有 Web 部署能力。更现实的路线是先建立性能基准，针对宽表、大页大小、多 Tab、长时间运行等场景继续优化，例如横向虚拟滚动、结果集流式/分块加载、单元格渲染轻量化、内存回收策略等。

如果后续真实 benchmark 证明 WebView 表格成为主要瓶颈，我们可以再评估更底层的渲染方案或局部 native/canvas 表格，而不是直接整体重写 UI。

另外，DBX 目前也支持 Web/Docker 自托管形态。若整体迁移到 Slint/Iced 这类原生 GUI，桌面性能路径可能更纯粹，但浏览器访问和 Docker 部署会变得困难，甚至需要维护另一套 Web UI。对 DBX 来说，这不是单纯的性能选择，也是产品形态和维护成本的取舍。

[haseebhussainadeel156-del]

does your application support english language because i am not seeing it in the application and i want to change it.

[t8y2]

Hi @haseebhussainadeel156-del, yes, DBX does support English. You can switch it by clicking the globe icon 🌐 in the top toolbar, then selecting "English" from the dropdown. The app defaults to Chinese on first launch, which might be why you missed it.