对精简软件的呼吁（1995）
程序员们在当今这些缓慢、吃内存的应用面前重新审视尼古劳斯·维尔特 1995 年的《对精简软件的呼吁》，认为现代工具和框架常常为了些许便利而浪费了硬件性能的巨大进步。许多人将责任归咎于奖励发功能而非性能的组织激励、Electron 这类沉重技术栈的兴起，以及对广泛、通用依赖的依赖，而不是选择聚焦且充分理解的组件。也有人反驳说，更丰富的功能、Unicode、远程编辑和复杂系统基础设施本就不可避免地会增加负担，而对许多用户和公司来说，只要感知速度“够快”，这种权衡仍然是可以接受的。
操作系统、后台服务与用户控制
- 许多人抱怨商业应用自动启动后台服务（VPN、Steam、聊天应用），这些服务主要是为了更新/遥测，而不是给用户带来价值。
- Windows 因让这类服务难以禁用、以及会撤销用户设置（例如 AV 策略）而受到批评；相比之下，macOS 被认为更可由用户控制。
- 有人建议由操作系统层提供更新服务，让应用去注册，但也怀疑开发者会不会愿意放弃自定义更新器而采用它。
编辑器、功能与感知中的臃肿
- 过去只占几 MB 的老编辑器，如今被重新解读为相较于 VS Code/JetBrains 等现代工具而言“精简”。
- 一方认为现代功能（Unicode、emoji、丰富的远程开发、LSP 分析、预览）本就必然带来更高的资源消耗。
- 另一方反驳说，这些功能完全可以用更少的代码实现；大型框架和浏览器引擎往往是默认选择，而非必要选择。
- 响应速度和输入延迟被强调为比原始内存占用更重要。
依赖、库与 Electron/web 技术栈
- 共享库与打包捆绑之间存在争论：DLL 地狱和分发痛点推动许多人转向把一切都打进一个大包里。
- 有人主张小而专用的库；也有人偏好主流库（例如大型字体渲染器），因为它们更可靠、维护也更共享。
- Electron 成了争论焦点：它被视为加速迭代和跨平台开发的赋能者，但也被看作浪费的象征（嵌入多个浏览器、高 RAM/CPU 占用）。
- PWA 被建议作为折中方案，不过若没有额外机制，它们缺少原生 API。
组织激励与流程
- 有人说大型组织奖励的是功能和乐观，而不是性能；微小的变慢不断累积，直到系统变得难以忍受。
- 敏捷/企业流程、沉重的 CI/CD 以及大团队被批评为在几乎没有真实产出的情况下，成倍放大了工作量和代码行数。
- 性能作为核心功能只存在于少数领域（交易、搜索/广告），因为在那里时间能直接变现；其他地方往往被置于较低优先级。
硬件、用户与测试
- 有人认为“硬件便宜，时间昂贵”，因此重一点的工具也说得过去。
- 但也有人指出，许多用户机器配置普通；同时运行多个重型应用（Slack/Teams、IDE、浏览器、Electron 工具）会让系统变得迟缓。
- 在低端或老旧硬件上测试，被提议作为一种保持软件精简的纪律。
责任与精简软件精神
- 一些人坚持开发者必须对性能负责，选择从设计上就快的架构，避免不必要的抽象和通用框架。
- 另一些人则强调生态和经济力量（共享依赖、工作激励、管理文化）在结构上偏向臃肿。
- 对一场以性能为导向的反向运动，人们抱有谨慎乐观，但也怀疑它能否在更大范围内扭转臃肿趋势。