我电视也没联网，因为用不到，直接 HDMI 接入网红某宝的外贸盒子。
平时就看看 B 站视频，美滋滋。

强迫症患者表示，写个 VFS 不香吗？服务器一堆小文件，等到要异地备份的时候，完全受不了。

用 SSR 啊，学 memcache 做中间层缓冲，用 websocket 实时响应客户端的树状结构点击展开事件，然后把 DIFF 部分塞入 DOM 返回给前端。
直接无脑把 3.4G 的数据放到客户端，不卡才怪。

制作工具还是有必要的，我都自己写过一个 base64 工具页面，无脑点点鼠标，难道不香吗？

@Actrace 我的观点和你相反，mini 相当于台式机，目前来说 arm64 M1 还是缺少，能搭建齐后端开发环境的能力。
M1 的特色是移动静音省电，宁可加钱买静音本。写写前端移动办公，肯定是毫无压力。

我没事去看了一下官方 youtube M1 演示视频，比我想的要强不少。有用户评论说，测试以 1440x900 分辨率+中等图形配置运行，一点都不卡，可玩性很高。
可能游戏优化确实好。

楼上提到 LLVM 也是未来的一个亮点。
就如当年大神用 LLVM，让 Linux 运行在浏览器上一样。以后当 Electron 发展到足够强大，能打通语言障碍，能一键发布移动端，能用 LLVM/WebAssembly 桥接任何原生软件内核的时候，也许又会刮目相看。

@charlie21 “随着时间发展，在小公司里写 Electron 的开发者会逐渐把写 native 的开发者给替换掉，饭碗都砸掉 ”
有了 nodejs 后，仿佛前端，后端，客户端，移动端无所不能。事实真的如此吗？并不是吧，本帖提到的卡顿就是最好的证明。
任何语言都是有其擅长和不擅长的，比如 C++擅长计算，JS 擅长界面。一个项目里，用户需求总会随着时间推移，不断变多，等大量新需求硬塞到前端框架里，最后必然变慢变卡，遇到性能问题，这谁都阻止不了。JS 诞生的时候，也不是为了来解决超级大项目，是 nodejs 促成了这个契机。
至于你提到的 native 码农会被替换，在很早之前，调用 API 逻辑层码农，就是铁打的兵营，流水的兵，换了一批又一批。不变的，只有那些写核心 C++的底层代码的老人。

@cmdOptionKana "需求不一样才是根本原因。"
我就是觉得什么需求都往前端里加，代码量成倍上去后，前端代码才会变成翔山。
这和用什么框架关系不大，就是没有合理的软件上下分层。
比如密集型计算，以前是放后端在服务器运行，现在也搬到客户端也可以运行，但毕竟 JS 也不是万能的啊，各种乱七八糟不合理的需求加一起，才是 Electron 质量低下的根本原因。

@abcbuzhiming "前端三大框架和各种脚手架的诞生产生的一个负效应就是前端写翔山比过去容易多了"
其实前端 js, 天生就不太适合处理很复杂的逻辑。可是偏偏现在 APP 盛行，主流重前端轻后端的方式，硬上巨型体量的框架（看看 V 站的 VUE 加班贴，就知道了）
以前 C++都会提到软件工程学，有一套完整的理论来整理大量代码。可前端并没有啊，等到 js 代码多到不可控的时候，翔山早晚会崩盘。
Electron 承载的代码只要不太过笨重，个人体验还是可以的。

我觉得你们把原始开发想的太简单了，不光是投钱就能解决的事情，有钱也不一定能找到合适的人。
所谓隔行如隔山，前端和 C++原生 API 之间的鸿沟，真不是资本家出点小钱，就能填平的。

KVM 显卡穿透用户表示，黑苹果还是太嫩了点。

@MengiNo 原生开发不好维护吧，你 electron 只要管好前端就可以了，招人接手也方便。
真换成 C++跨平台，开发成本上涨不说，几年后相关人员离职了，后续谁来继续维护啊。

不是 electron 好，而是你想发布 nodejs 客户端程序，没别的便捷方案可选。
至少 electron 给前端开了一扇门。以前传统桌面软件开发，没几年摸爬滚打，想都别想。

rsa 可以加密，但 rsa 算法非常慢。cpu 资源浪费在这上面，没必要。

我一般用红轴，没用过静音轴。楼上说不上噼里啪啦的青轴，就没有用机械键盘的感觉，我想说办公室那么吵，就不怕同事真人 PK 吗？