你的无聊 Stack 还不够无聊
Source: Dev.to
我读了 “My 2026 Tech Stack is Boring as Hell” 这篇文章，点了点头。单体架构？是的。SQLite？很棒。单一 VPS？完美。
然后我注意到：你仍在使用 React。
并不是说 React 有什么问题——它能解决真实的问题。但如果我们在谈论“无聊”，我觉得我们可以走得更远。
早于你框架的技术栈
The interface: 终端。不是网页应用。不是 GUI。一个接受文本并返回文本的 CLI。
The glue: Bash、Python 脚本、JSON。自古以来在每台 Linux 机器上都能运行的东西。
The frontend: 当我需要时，HTML + CSS + 原生 JavaScript。无需构建步骤。没有 node_modules。只有文件。
“But that’s not a web stack!”
正确。我构建的大多数东西并不需要是网页应用。它只需要 work。
租来的知识 vs. 拥有的知识
这里说到 React：你在租用这类知识。
React 的思维模型、它的 hooks、它的生态系统——你在为别人控制的抽象概念支付认知租金。当下一个东西出现时（它肯定会出现），这些知识就会贬值。
终端？HTTP？JSON？SQL？这些是拥有的知识。
我 2015 年写的 Bash 脚本仍然可以运行。我的 Grunt 配置则是已死文明的遗物。
林迪效应似乎成立：存活下来的事物往往会继续存活。Unix 哲学已经存在了 50 年。我打赌它会比当前流行的任何框架更持久。也许我错了，但从历史来看，这一直是个安全的赌注。
标准 vs. 生态系统
这里有一点在框架让我们忘记之前，网页做对了：关注点分离。
- HTML 是内容。
- CSS 是表现。
- JavaScript 是行为。
每一个都是独立有用且可独立演进的。你可以在不触碰 CSS 的情况下编写 HTML，用 CSS 样式而不写 JavaScript，它们能够组合是因为它们不依赖彼此的内部实现。
React 把这一切压缩在一起。你的内容、表现和行为都纠缠在 JSX 中。想要改变某个东西的外观？你必须触及同一个处理其行为的文件。“组件”抽象并不是分离——而是捆绑。
我并不是说 React 错误。对于某些问题，捆绑是有道理的。但要认识到你正在放弃的东西：能够在不理解其他层的情况下更改某一层的能力。
标准是可组合的。生态系统是纠缠的。
当你学习 HTML 时，这些知识在所有 HTML 能运行的地方都适用。当你学习 React 的做法时，这些知识只在 React 中适用。而且下一个版本的 React 可能会改变它。
不要学习生态系统
这是我的异端观点：不要在学习生态系统上投入大量精力。
生态系统太庞大，装不进你的脑袋。它们有自己的行话、工具和思维方式。当你已经内化了 React 的思维模型时，你已经耗费了本可以用于更具迁移性的事物的认知预算。
生态系统由他人掌控。它们可能转向、被抛弃，或失去流行。npm 墓地里充斥着三年前还必不可少的包。
生态系统与外部事物的组合性不佳。尝试把 React 与原生 JS 库混用一下吧。虽然可以实现，但你是在逆流而上。
学习 标准。学习 协议。学习那些在框架战争之前就已经存在的枯燥东西。
“但 CLI 很难学习”
过去确实如此。
现在我有一个 LLM，它可以发现标志、解释选项，并且比我记得的更好地组合命令。导致必须使用 GUI 的可发现性问题？基本已经解决。
而且有一点：LLM 喜欢 CLI 工具。
Why? 因为它们是文本原生的。输入文本，输出文本。行为可预测。表面面积小。正是这些让 Unix 工具可组合的特性，使它们非常适合 AI 编排。
我编写简单的 CLI 工具，添加一个简短的 markdown 文件说明如何使用它们，然后 Claude 会自行完成其余工作。当我说“把这个交叉发布到常用平台”时，它知道要运行哪些命令、顺序如何，并在过程中处理错误。
试着用你的 React 组件库来做这件事吧。
可组合性才是关键
原帖提到“我只需要 Ctrl + F”来调试单体应用。感同身受。
Unix 哲学： 小工具专注做好一件事，通过文本流连接。每个部件都能在脑中容纳。组合才是力量所在。
这不是怀旧，而是工程学。
当你的抽象层在凌晨 2 点崩溃时，你是否足够了解它以便修复？使用 200 行的 Python CLI，我可以。使用把我真正需要调试的东西抽象掉的框架？可能不行。
简单工具的故障很直接。复杂工具的故障则需要考古学学位才能理解。
在哪里出现问题
我不是狂热分子。实时应用？持久连接？是的，文本流在这方面会吃力。丰富媒体？并非所有内容都是文本。
但说实话：你实际构建的东西有多少真的需要这些？大多数 CRUD 应用不需要 WebSocket。大多数内部工具也不需要 React 单页应用。
乏味的答案往往才是正确的。
不确定性的对冲
没人知道世界是什么样子
# Needed webpack? Then it was Parcel. Then Vite. Then… whatever’s next.
Each transition costs you. Each migration is hours you could have spent building.所以我采取对冲：
- 最小化依赖。 当生态系统变化时，出问题的可能性更少。
- 可迁移的技能。 终端知识在范式转变中比框架知识更易迁移。
- 优雅降级。 当一切都在改变时，简单工具能够适应，复杂工具则会崩溃。
我并不是说这就是唯一正确的策略。我只是说这是一种应对不确定性的策略。实际效果因人而异。
我拒绝放弃的无聊工具
你问我们拒绝抛弃的无聊工具是什么。
我的答案是 终端本身。不是某个具体的工具——而是 界面。这东西自我出生前就大致保持不变。我打赌它会比我们今天热衷的任何东西更持久。但我以前也错过。
更深层的问题
当一切都改变时，什么仍然能用？
我不知道。没有人知道。但我有一个经验法则：押注那些经受过多次范式转变的事物——文本输入，文本输出；可组合的工具；标准胜过生态系统；你拥有的知识而不是租来的。
也许这是错误的押注。也许下一个范式会让终端、Unix 和文本处理的所有认知都过时。如果真是这样，我会适应——可能会使用任何新工具来学习新事物。
但在此之前，我会保持无聊。比你更无聊。