Tag: 编程

用来用去还是 VS Code 好用……

在写前端项目的时候，Zed 的内存开销相比 VS Code 没有太大优势，但是 VS Code 的插件比 Zed 更好用，即便是同款插件，VS Code 版本的似乎也更智能一点。譬如 Svelte 的组件导入，VS Code 版本的 Svelte LSP 插件的补全提示很快能显示出来，而 Zed 版本几乎只能靠 AI 的 inline hint，插件好像就不会显示组件的补全。

另外 VS Code 的动画会更顺滑一点，不知道是动画还是字体效果的缘故。

因为 vitest 只能用 node 运行，所以 不得不吧 easy-office-2 的里所有直接调用 Bun Api 的代码全部改成兼容 Node Api 的形式。

质疑 node，理解 node，使用 node，但是我依然讨厌 node。

最近清理了一波电脑。浏览器用 Helium 替代了原来的 Chrome。代码编辑器用 Zed 替代了 VSCode。输入法从 Rime 换回了 macOS 原生的拼音输入法。

关于 Zed，我已经在[2025-10-22_20-34-49|我支持用 Rust 重写世间万物提到]过了。这两天实际编码体验非常好，不过我写的毕竟还是 JS / TS ，工具链全部基于 Node，内存开销并不低。Zed 本身的内存占用也不低，启动倒很快。希望 Rust 社区继续发光发热，继续改造 JS / TS 工具链，把 Node 干掉。说到这里我又馋 deno 了……

Helium 和 macOS 原生拼音输入法的体验都不错。Helium 本身是基于ungoogled-chromium，使用体验和 Chrome 差不多，但没有 Google 服务的捆绑，开销更低。

至于 Rime，更像是一段插曲。当初是因为 macOS 原生拼音输入法有 Bug，会导致莫名其妙的死机，我才换到 Rime 的。现在 macOS 原生拼音输入法已经稳定了很多，Rime 高度个性化的优势在我这里也不算优势，从零开始培养一个惯用的输入法对我来说也很麻烦。除了不喜欢 Tahoe 的液态玻璃效果，我对 macOS 原生拼音输入法没有任何不满。

再次尝试使用 Zed。

2 年前刚学编程那会体验了一下 Zed，因为生态不完善没有继续使用。现在 Zed 写 Svelte 已经没啥问题了，也支持 GitHub Copilot。基于 Rust 的编辑器，运行速度没得挑。

原本以为没有 Foam 插件，处理我的 markdown 笔记会不方便，结果发现 Zed 有类似的 markdown oxide 插件，功能类似。

现在编码体验非常流畅，舒服了。

Rust 大法好。我支持用 Rust 重写世间万物。JS / TS 生态就应该用 Rust 重写，把 language server 什么的都重写了。现在电脑里剩下的 node 进程基本都是 language server。

看到一个有趣的类比，将联想记忆法比作数据库建索引，本质上是拿空间换时间，在一个缓冲区里放更多数据，以此减少常∫用数据的索引速度。

Anton Putra在 YouTube 上发了一条视频，对比了 FastAPI (Python) 和 Node.js 的服务端性能表现。第一轮是测试单纯的 Get 请求，第二轮是测试 PostgreSQL 数据库的写入。两轮测试下来，Python 的综合性能表现差不多是 Node.js 的 1/10。

一般来讲服务端的性能瓶颈都在数据库 IO，很少会遇到 CPU 瓶颈。Anton Putra 测试过不少语言和服务端框架，Python 是为数不多能在测试中段就能撞上 CPU 性能墙的。而且撞墙以后也没有恢复，后半段被锁死在 50% 的 CPU usage 上跑完了全程，也不知道为什么。

FastAPI 已经是 Python 生态内性能比较好的框架了，我真不敢想 Django 这种老乌龟得慢成什么样。没有 jit，再加上 gil 的限制，Python 的性能真的……配不上它今天的江湖地位。

最关键的是，Node.js 在 JavaScript 生态内的性能也不突出，甚至可以说是比较拉胯的……

又心痒痒了，想试试用 htmx + Python 写写小项目。

不过 Python 的速度真不行，感觉 Bun 会好很多。

但是 Python 的 Ai 生态更好，JavaScript 生态圈内优质的 Ai 开源项目太少了。

好纠结啊。

所有基于 Electron 开发的软件似乎都会在 macOS Tahoe 遇到水土不服的问题，包括但不限于卡顿、发热。Electron 是最常用的跨平台开发框架，也就是说，包括 VSCode、Cursor 在内的很多常用软件都会中招。

成因似乎是 macOS Tahoe 的 WindowServer 组件有 Bug，在渲染带阴影窗口时存在严重性能回退，所有带阴影 Electron 窗口会异常消耗 GPU 资源。

暂时没有看到关于 Chrome 的反馈，但是我感觉 Chrome 在升级后资源开销也变大了。

苹果 💊。

学习就是拼图。常规路径是从一个起点开始，一块连着一块，慢慢把图拼完。

但是在绝大多数时候，情况没有这么理想。很多突如其来的问题和已知部分的拼图没有关联，但是你又需要将他放到合适的位置。

这个时候，你只能不断尝试，将他和其他拼图连起来，寻找它和已有部分的联系。譬如问人，问搜索引擎。但是因为它和你已知部分没有关联，所以你问的问题可能非常荒谬、可笑、没有意义。

如果对方水平比较高，能从你的提问中猜到你想要什么，给你一个有用的答案，那是万幸。但这是小概率事件，大部分人的运气没有这么好。在大多数时候，即便你问对了人，他也不知道该怎么回答你，或者给出的答案对于你来说毫无意义。

甚至你可能连问题都问不出来，只能自己不断试错。

这个过程是盲目、困难和痛苦的。

我觉得 AI 的出现，能在很大程度上缓解这个问题。因为 AI 的知识面非常广，能从很多不同的角度理解、回答你的问题。它可能不能直接给你答案，但是能从你的提问进行推测和延伸，让你能沿着一个方向继续追问。

我觉得这一点，在和 AI 结对编程的时候体现得非常明显。因为一些库或者包的文档写得非常差，或者根本没有文档，你只能通过试错来使用它们。

这个时候，你把问题甩给 AI，它可能并没有学习过这个库，但是它能从已经学习过的代码中，推测出这个库的用法。毕竟大部分接口的设计都是类似的。

AI 在这里就像一个经验丰富的老师傅。毕竟人类的经验，也是一种大数据。

Astro 是个好框架，但是从实用性的角度上讲，彻底放弃 SSR 好像不太现实 🤔