对于用户来说体积从来不算啥问题。Tauri 据说到现在生态也跟 Electron 不可同日而语。更何况 rust 的学习曲线可比 js/ts 陡峭多了。从老板的角度上来说，用 Tauri 不仅不能为产品增加任何的优势，还得去想方设法招聘靠谱的 Rust 开发，徒增研发成本。着实得不偿失。

Tauri，只是一个胶水框架，跟你用什么前端框架没有关系。我第一次听说用户不关心体积，打扰了，不是同一个频道。

你不相信是你不相信的. 事实上只有电脑发烧友和开发者们会在意软件的体积. 绝大多数使用计算机的人连浏览器跟操作系统都分不清, 软件体积对他们来说本来就是一个模糊的概念. 不信你可以问你们楼下小卖店老板, 你问问他们收银机那台电脑上的收银软件多大的体积启动之后占用多大内存, 你看他们有没有概念.

作为一个互联网上的人, 应该永远对自己熟知的概念抱有怀疑的态度. 因为任何一个你觉得理所应当显而易见习以为常的概念, 都有可能是信息茧房的结果.

你是不是说的是rust啊🤔，打包成桌面electron和tauri都是对于react应该都是差不多的吧，起码前端框架都是需要精通只不过工具不一样吧。而且对于桌面端未来的展望确实rust会有更大的优势，起码在串口通信操作系统交互方面是这样，而且启动速度，未来潜力都是rust较好，electron应该是社区完善容易上手的优势吧

擦 还真是 打错了 是 rust 不是 react... 总把这俩的名字搞混...

如果纯粹的串口通讯的话，纯js就已经可以支持了。electron的弱势点在于调用 native lib. ffi-napi 说实话不好用。所以大部分 electorn 软件都不涉及 NAPI ，涉及到 NAPI 的桌面端程序一般都是用 C# 做。WPF / Avalonia 用 P/Invoke 调 native 就易如反掌了。
原理上说，这俩的核心都是用 web 技术渲染界面。而 tauri 跟 electorn 比还需要开发者额外了解 rust。而且由于 Tauri 用的是 webview，因此对 Windows 7, Linux 等系统的支持都不如 electron (Windows 7 下需要手动安装 Webview, Linux 下需要 webkit2gtk)。这对分发成本来说显然是个 debuff。

所以 tauri 这东西与 electron 相比没有明显的优势。但是 debuff 倒是有。
所以还是期待未来 tauri 能不能改善吧，

兄弟，你的方向搞错了，建议你自己先去做几个Tauri项目，上了架才来发言，你提出的那几个问题，都不是问题

如果你只是想卖给小卖店的老板，用什么都无所谓。

但是如果你想用自己的模型，用QUIC，或者要在几ms内解析100多M的文件，你推崇的electorn能搞定吗。显然你并不了解。

偏低别人不会让自己变得高大，不要学长城汽车啊

怎么不是问题，Tauri 能保证开发者在完全不懂 rust 的前提下展开工作么？而且如果有这种大量数据处理的需求我会选择 WPF, 执行性能不算差，而且比 rust 好招人得多，人力成本相比 rust 也会低不少。

所以我是站在需求方的角度，或者说老板/项目负责人的角度来说的。而你是站在开发者的角度上说的。说的都不是一码事。

你非要抬扛，我就多啰嗦一下。如果你的要求是“开发者在完全不懂 rust 的前提下”，这个没有问题，Tauri只是一个胶水框架，你完全可以用你喜欢的JS/HTML构建你的应用，不用写一行rust代码都行。

一下子Electron，一下子WPF，话说你真的了解这个项目的需求吗，又为什么能站在需求方/老板/项目负责人的角度来说教呢。你这种思维根本就是反工程设计，是按需求去找人，不是根据人去定需求好不好。

楼主要求的是 Electron. 既然人家要求 Electron, 说明人家肯定是评估过的, 不涉及到什么1秒需要处理 100M 数据的需求. 真有人家也不会选 Electron. WPF, QT 等都是更好的选择. 更何况 Tauri 你可以保证不写 Rust 纯用 js 完成 1s 处理 100M 数据的需求么？？我说的是这意思懂吧.

还有 Tauri 能脱离 Rust 开发这个只能是理论上可以。实际上不行的。比如监控电源状态 powerMonitor，Tauri 只能手写 Rust 实现类似功能。再比如拉起设备摄像头读取摄像头画面，以及监听麦克风声音 (这在很多教育类软件里都是必备功能，例如猿辅导，楼主做教育类产品，很可能就会涉及这个功能)，Tauri 基本上要么加载 https 网页，要么写 rust 代码实现，要么就是 rust-plugin-media. Electron 就不需要。这玩意直接内置。再比如 Electron 可以通过 session 和 webRequest API 修改请求头或代理网络请求，非常灵活。但是 Tauri 想要修改请求头之类的或者挂代理就只能用 Rust 封装一下再说。

总之，截止2025年上半年，Tauri 提供的 Api 跟 Electron 比还是少。好多常见功能仍需要 Rust 代码。脱离 Rust 开发让纯前端用 Tauri 的话，风险非常大。

还有，Electron 的也不是像你想的那样又卡又吃内存，下限贼低任何复杂的东西都处理不了。真说1s处理100M数据，纯 js 执行效率不理想，也完全可以通过 ffi-napi 调用 C++ 的函数解决。这点跟 Tauri 是一样的。虽然确实没有 Tauri 调 Rust 那么顺滑，虽然确实不好用，但是肯定是能用的。楼主的要求里也要求会 ffi-napi。新版的腾讯 QQNT 就是这种做法，上面薄薄一层 presentation 用的 Electron，底层 IO, 通讯等全都是 C++ 做的。中间通过 ffi-napi 调用 C++ 写的东西来完成数据交换。启动起来一点都不慢，启动也就 200 多 M 内存占用。QQ 十多个群各刷几万条聊天记录一点都不卡。早期 QQNT 能通过一些手段打开 DevTools，监控 Network 可以看到基本只有表情包，图之类的静态文件下载，XHR 一个都没有。更何况我本人也做过通过 Electron 直接调爱普生，美松小票机驱动 DLL 的活儿 (某市人民医院自助机)，怎么就“复杂一点的就做不了”了？

还有你口口声声 Tauri 可以不用会 Rust，但是又拿必须后端语言 (Rust/C++) 才能实现的需求举例子。你到底是想证明 Tauri 可以脱离 Rust 开发完整产品啊？还是想证明用 Tauri 必须会 Rust?

前面我已经说得很清楚，脚本语言天生弱势是性能低，碰到计算密集型的场景无能为力，最后优化，还是要转成静态语言。基于Electron的项目，要么找别人开发好的ffi，要么自行开发，而项目切换，导出导入，调试和开发效率很低。而Tauri项目优势在于所有代码都在同一个工程中，调试完即是开发完，丝滑得很。

不会Rust的话，那为什么要用Tauri？你说" Tauri修改请求头，只能用 Rust 封装"，说明你根本就没有完整的Tauri项目经验，你的JS基础知识也很弱， JS本身就可以自行修改请求头，这个关Tauri个屁事？不懂的东西，就不要唧唧歪歪了，越抹越黑。

Tauri，就是官方或第三方提供的，已经满足不了项目需求，需要自己实现。
用拿来主义者的白嫖思维去看待Tauri，或者自己能力不足，你为什么要用Tauri？

我就只是问了一句，是否一定要用Electron，居然劳费你百度那么久，还找了那么多所谓的问题来证明自己的论点。

再跟杠精讨论，那我肯定是sb:)

我只是等级低，每天回帖的次数有限罢了。。。

你真的有用过Tarui吗，直接跟Electron一样为window7打包一个Chromium 内核不就行了，哪里来的好太多。
这么说吧，Tarui的下限是Electron，而Electron受限于脚本语言做不了复杂的功能需求。

没用webgl吧， 有人测试webview2性能下降50%，微软github webview2feedback有记录，快四年了至今未解决😏，因此被迫转回electron，利用napi-rs将rust打包成node模块集成在项目中使用。

你这个是张冠李戴。Tarui只是调用系统的WebView，本身不参与渲染，跟用不用WebGL有什么关系？又跟性能有什么关联？你描述的这个问题，很显然他开发机上Electron使用的Chromium内核效率要比同期的系统自带WebView组件高，这跟Tarui没有半毛关系啊

额？ 哥们你先把原理搞清楚

汗，大哥，你到底有没有正眼看一下自己贴出的官方文档？到底是哪一句话让你认为我的理解是错的

同一台Windows电脑，用electron（自带内核）用webgl canvas可以很流畅，比如30帧。 用tauri（webview2） 就很卡，大概只有15帧，同一环境性能低50%。 请问我该用electron还是tauri？我这样解释可以理解吗

无语，我上面已经说很清楚了，这个问题跟Tauri有毛关系~~
使用的东西都不一样，哪里来的同一环境的说法？

显然你并不了解WebView，代码再烂也不太可能有50%的性能差，除非微软的工程师个个都是sb。如果真有这个差值肯定是没有开启硬件加速。

无语。要不你自己实践一下…

已经反复跟你说过Tauri只是调用，不管渲染，就算你说的这个问题是存在的，又能证明什么？难道你是要证明Tauri的性能比Electron差？你说的案例最多是说明测试机上系统自带WebView组件性能比最新的Chromium内核差而已，这个黑锅也要Tauri来背？

无语至极。好好看一下这个架构图，你要么是看不懂官方文档，要么是在抬扛。
没有必要再讨论下去了，不是一个层次~

好的好的。tauri是神圣的，不应该给微软背锅。 当你的用户问你为什么软件这么卡的时候，你也这么跟你的用户和领导解释哈。 完结…

人家都已经指出问题在哪里了，还不知道如何解决，还在扛，无语......

欢迎，请发送简历至邮箱

欢迎，请发送简历至邮箱