把 VS Code“瘦身”96%，这个开源项目想证明：Electron 不是桌面应用的唯一答案
一次很“程序员浪漫”的重写
GitHub 上最近冒出一个挺抓眼球的项目：Sidex。它的口号很直接——“VS Code rebuilt on Tauri. Same architecture, 96% smaller.” 翻成大白话就是：我想用 Tauri 重新造一个 VS Code，而且尽量不推翻原本的架构，但把体积砍到只剩一个零头。
这句话之所以有冲击力，是因为 VS Code 早就成了现代开发工具的“空气”。很多人每天打开电脑后的第一个窗口就是它。可大家也一边离不开它，一边抱怨它：装得越来越多、吃内存越来越狠、启动也谈不上轻盈。尤其在老机器、低配设备，或者只想快速改几行代码的场景里，那种“明明只是个编辑器，却像一整套浏览器内核加 Node 运行时一起起飞”的感觉，确实让人心情复杂。
Sidex 的吸引力就在这里。它不是另起炉灶做一个“受 VS Code 启发”的编辑器，而是试图保留 VS Code 的工作台思路、启动流程和整体架构，再把底层桌面壳从 Electron 换成 Tauri。这有点像把一台熟悉的家用车，尽量不改驾驶逻辑，却把发动机总成和底盘材料重新设计一遍。目标不是炫技，而是回答一个很多开发者心里都盘旋过的问题：如果今天重新做一遍 VS Code，它还必须是 Electron 吗？
Electron 的成功，也带来了它的代价
要理解 Sidex 为什么会被关注，得先理解 VS Code 为什么会变成今天这样。VS Code 的成功，和 Electron 分不开。Electron 当年的历史贡献非常大：它把网页技术带进桌面应用世界，让 JavaScript、HTML、CSS 不只是做网页，也能做跨平台客户端。开发团队可以用一套前端技术栈，跑在 Windows、macOS、Linux 上，迭代快、生态成熟、招人容易。Slack、Discord、Notion、VS Code，都是这条路线的受益者。
但技术世界几乎没有免费的午餐。Electron 的代价也很清楚：它本质上是把 Chromium 和 Node.js 一起打包进应用里。换来的好处是统一，失去的则是体积、内存占用和系统原生感。开发者对 Electron 的态度常常很矛盾：一边吐槽“这玩意儿怎么又是个浏览器”，一边在项目工期面前默默点下 npm install electron。
Tauri 近几年之所以越来越热，就是因为它提供了另一种路线。前端界面照样可以用 Web 技术写，但不再把整套 Chromium 自带进包里，而是更多依赖系统原生 WebView；后端能力由 Rust 提供，应用体积和资源占用通常能明显下降。对于“工具类桌面软件”来说，这种方案很有诱惑力。Sidex 正是踩在这个趋势点上：它不是简单地做个 Tauri demo，而是拿 VS Code 这座“巨型样板工程”开刀，这就让它有了行业讨论价值。
96% 更小，数字很刺激，但真正难的是兼容那套复杂生态
从仓库信息看，Sidex 目前还是早期版本，README 里也明确写着 early release。项目已经有上百次提交，最近几次更新在继续压缩包体积、接入真实的 VS Code workbench 启动流程、补媒体预览、处理安全策略，甚至还提到了移除 Electron/Node/AI 相关死代码。这个节奏说明它不是一句口号式的“概念验证”，而是在认真朝一个可用编辑器推进。
不过，96% 更小这种数字，最容易让外行兴奋，也最容易让内行警惕。因为桌面编辑器从来不只是一个壳。VS Code 真正强大的地方，不在于那个左侧活动栏和熟悉的深色主题，而在于它背后的扩展生态、语言服务、终端、Git 集成、远程开发、调试体系，以及大量围绕 Node 与 Electron 假设建立起来的历史兼容性。你要把这个生态尽量搬过去，难度远比“把窗口显示出来”大得多。
这也是我看 Sidex 时最感兴趣的地方：它其实在碰一堵很多轻量编辑器都绕不过去的墙。你当然可以做一个更快、更小、更原生的代码编辑器，但如果插件不兼容、终端能力缩水、某些开发流派常用功能失灵，开发者转身就会回到 VS Code。开发者群体表面上爱折腾，实际上对生产力工具极其保守。你可以让他们试用新东西，但一旦影响工作流，他们会毫不犹豫地退回老方案。
所以，Sidex 最终成不成，不只是看包体积能不能从 30MB 压到 15MB，或者继续更低，而是看它能否保住 VS Code 最宝贵的那部分“无痛迁移”。这也是“Same architecture”这句口号真正沉重的地方。说出来很轻，做起来非常重。
这件事为什么偏偏在今天有意思
如果把时间拨回五六年前，Sidex 这样的项目会被很多人视为“酷，但不现实”。可放在今天，它反而显得踩中了一个很微妙的时间点。
一方面，桌面软件的膨胀已经引发越来越多反思。过去几年，开发者忍受 Electron 的心态有点像忍受视频网站贴片广告：大家知道体验不好，但因为“行业都这样”，慢慢就麻木了。可随着 AI 编码工具、嵌入式助手、本地索引、语义搜索、代理式工作流不断往编辑器里塞，IDE 正在从“写代码的地方”膨胀成“开发操作系统”。这时候，底层运行时如果本来就偏重，叠加新能力后只会更重。于是，轻量化不再只是洁癖，而是现实需求。
另一方面，Rust 和 Tauri 的成熟度也和前几年不一样了。开发者对 Rust 的接受度越来越高，它不再只是“系统编程爱好者的圣杯”，而是在工程上真的被拿来做工具链、CLI、桌面端和基础设施部件。Tauri 也逐渐从“有潜力的新框架”走向“可以承接真实应用”的状态。Sidex 某种程度上，正是这波工具链成熟后自然冒出来的作品。
还有一个更现实的背景：开发工具这条赛道已经不像从前那样只有“大而全”一条路。Cursor、Zed、Windsurf 等产品都在试图重新定义编辑器体验。有人押注 AI first，有人押注性能，有人押注协作，有人押注原生体验。Sidex 则走了另一条很有意思的线：我不先发明一种全新的编辑器哲学，我先证明“你习惯的 VS Code，也许可以更轻”。这条路线未必最性感，却可能最有普适性。
它的价值，也许不止于做出一个替代品
我不确定 Sidex 最后会不会成长为一个真正意义上的主流编辑器。说得现实一点，挑战 VS Code 不是“把软件跑起来”这么简单，而是要挑战一个庞大的插件帝国、习惯体系和组织惯性。微软自己也并非毫无调整能力；如果社区对轻量化诉求足够强烈，大厂完全可能通过更多原生化优化、按需加载和架构拆分来回应。
但就算 Sidex 最终没有成为下一个明星产品，它依然可能是一块很重要的行业试金石。它逼着大家重新审视一个默认前提：跨平台桌面应用就一定要接受“大包体、重内存、弱原生感”吗？很多年里，行业默认答案接近“是”。可每当这种默认答案被真正的工程项目挑战时，技术演进往往就开始了。
更有意思的是，Sidex 身上还有一种开源世界特有的人味。仓库提交记录里，开发者留下过一句很疲惫也很真诚的话，大意是自己 48 小时只睡了 3 小时，代码语法和质量还有很多要修，希望醒来时能看到更多人觉得它有用，顺手帮忙修修自己“烂代码”。这句话比任何 PR 文案都更像真实的软件史。很多影响行业的软件，并不是从一场闪亮发布会诞生的，而是从某个开发者熬夜、较劲、不服气开始的。
这也让 Sidex 有了超出项目本身的意义。它提醒我们，软件世界并不总是由大公司路线图决定。很多时候，变化来自某个看上去“有点偏执”的开源项目，先把一个大家都在抱怨、却没人真去解决的问题撕开一个口子。
眼下 Sidex 还处在很早期，离“放心装进主力工作流”显然有距离。可如果你长期被 Electron 应用的体积和资源占用折腾过，这个项目至少会让你重新燃起一点久违的期待：原来桌面软件不一定只能越做越大，编辑器也不一定必须越来越像一艘航空母舰。
这或许才是它现在最打动人的地方。不是它已经赢了，而是它让人重新相信，这场仗值得打。