马克·吐温曾写道："让你陷入麻烦的，不是你不知道的事，而是你确信无疑却并非如此的事。"他写下这句话时，心里想的是不是软件开发？

当下，软件以多种方式演进。主要是我们主动去改进，并在机会出现时抓住它。有时我们为了挑战本身而迎接挑战，就像"因为它在那里"而去登山。也就是说，我们有时会被一个项目内在的可能性所吸引，径直去追。

而在这场混沌的混合中，我们常常以出人意料的方式返工、重新发现或重新利用一些想法。最令人意外的，是有时这些方式会掉头反噬自身——一个旧想法重新崛起，反超了更新的想法。以下是九个正在当下发生的例子。

语言与数据层：纯JS反超TypeScript，SQL回归

纯JavaScript反超TypeScript。就在你以为某件事已经尘埃落定、板上钉钉时，世界会毫不客气地反驳你。TypeScript原本看上去势要吞并整个互联网的代码库——给JavaScript加上类型这一简单想法，让它成为程序员和企业都极为青睐的选择。

但如今，我们似乎正走向一个JavaScript反过来吸收TypeScript的未来。人们不仅在努力把受TypeScript启发的类型系统变成JS的一项特性（"类型即注释"），还在大力推动把TypeScript降格为类似IDE中一道lint检查的环节。这就是新的"类型剥离"思路：Node.js等运行时在运行期直接把类型替换为空白，留下的可执行产物就是朴素的JS，从而彻底消除了笨重的编译步骤。

简言之，TypeScript正在变成JavaScript的一款花哨linter。

SQL反超ORM。诞生于上世纪70年代的SQL，是数据管理领域的一次重大突破。它与另外一些基础技术一起，助推了互联网的扩张式增长。但与COBOL等其他基础技术不同，SQL有一个我们常忽略的特质——它是一种根本性的、不可再简化的信息操作方式。

当然，SQL不是处理数据的唯一方式。但关系型数据结构给我们提供了一种严谨而通用的方法。因此，在钟摆重重摆向NoSQL数据库和对象关系映射层（ORM）之后，SQL出现复兴——这既令人意外，也在情理之中。

有些人觉得碍事的那种特质——严格的模式约束——恰恰让SQL成为一个稳定的平台。如今SQL正通过WebAssembly（Wasm）进入浏览器，在整个网络上提供统一的数据表达方式。SQL也在重新回到服务端代码库里，JOOQ这类更轻的封装提供了比Hibernate等ORM更直接的SQL访问。

为什么？很简单，因为抽象不可避免会带来摩擦。用SQL的直接性去交换ORM的广泛能力，是一笔风险不小的买卖。

架构与部署：单体、本地IDE与自建机房一起回摆

本地IDE反超云端开发环境。云端IDE是本地开发环境的天然继承者。那我们为什么还死死黏在本地IDE上？

不是惯性，也不只是因为我们习惯了。一部分原因是那种与云部署背道而驰的"买还是租"心态，另一部分原因是本地IDE那种高度个人化的手感。

但还有一个事实：现代笔记本是绝对的猛兽。即便是一台普通的商用笔记本，也能给开发者带来闪电般的IDE迭代速度。尽管开发者仍倾向于依赖远程AI后端来满足无处不在的AI算力需求，但系统其余部分完全可以舒服地待在本地资源里，内存和SSD带来近乎即时的响应。

单体反超微服务。微服务有它自己的位置。当场景需要时，它们威力巨大。但——这是一个很大的"但"——一旦被随意滥用，它们就是过度工程和复杂性的无底深坑。

如果"调试Kubernetes"这个说法还不足以让你打个寒战，那就想想：微服务天然意味着每个服务边界上都有网络延迟。而单体服务器模型从一开始就消除了这两个弊端。

当然，人还是得把单体服务器架构设计好，否则复杂性同样会压垮它的实现。此外，我们也得承认，处理高可用性等服务质量问题会增加活动部件的数量。但单体栈的分层结构（数据/服务/UI）带来了一个简单得多的心智模型。

而且这并非真正的"二选一"。如今大多数应用即便采用中心化的服务端栈，也会接入一些远程服务（无论是内部应用还是第三方应用）。但潮水已经转向，从微服务转向单体的势头出现了明显变化。

实践中，这不过是识别阻力最小的路径——用解决问题所需的最小复杂度——而不是去膜拜所谓的"标准做法"。对简洁的追求，自然会把架构师在合适的时候引向单体设计。

自建机房反超云。当Larry Ellison把云"革命"讥讽为一场毫无意义的时髦时……有没有可能他是对的？

大概不是。但业界冲向云基础设施的那股热情，确实过于极端。有时它几乎像某种狂热，仿佛在自己拥有的铁盒子上跑进程，本身就有哪里不对。

当然，云能带来大量好处。但业界正逐渐重新领悟那个永恒而根本的问题："什么工具最适合这件事？"

事实就是，有时一个组织把计算、存储或网络放在自建机房里更划算。本地部署有诸多优势，例如内部专业能力、成本可控、账单可预测以及数据主权，这些都足以让天平偏离"必须去开通和管理云资源"一侧。

工具链与运行时：黄金路径、Wasm与"爷爷辈的Java"

开箱即用的黄金路径反超拼接集成。把经过充分测试的工具集成为一个内聚的整体，比打造一套面面俱到的定制方案要聪明得多……不是吗？

过去几年，"Jamstack"（JavaScript、API与标记语言）和"现代数据栈"（组合各类最优云数据管理工具）正是这一理念的典范：凡是能租到的，就不要自己造。我们被告知要把十几个专业SaaS平台混搭起来——一个管认证、一个管数据库、一个管搜索、一个管托管，等等——再用API把它们粘在一起。

但这种做法的现实是沉重的集成负担。高级开发者不是在写业务逻辑，而是整天写胶水代码，让第三方API之间能说上话。当某个服务更新了它的SDK，这座纸牌屋就开始摇晃。

如今业界正重新倒向"电池已内置"的框架。Rails和Django开创、并由Next.js和Spring Boot等框架现代化的那套理念，正在重新占据上风。这意味着我们依赖一个高度有主张的生态——一条"黄金路径"。像Next.js或Spring Boot这样的元框架，也许没有自己的专有数据库，但它提供了深度集成的脚手架（如NextAuth或Spring Security），给开发者一个内聚的、预接好线的环境。数据库或认证服务仍需你自己带，但框架彻底消除了脆弱的胶水代码。

在多年对厂商的疲惫之后，开发者正在意识到：接受一个统一而带有主张的生态，才是通往速度的终极路径。

Wasm反超Docker。Docker曾是一个伟大且有影响力的想法：造一个可移植的处理单元，随手就能丢到任何地方。但在实践中，Docker可能变得相当笨重，它的配置文件也够琐碎。事实上，有时我觉得整个心智模型都有点笨拙：你有一套实际软件和它的各种环境需求，而Docker横在中间，成为额外一层抽象。

再看Wasm。Wasm把你的代码精炼成一个可移植的二进制文件（类似原生可执行文件）。就这样，完事。它的直接程度，就像上世纪90年代在DOS里跑一个exe。简单。

而且它快。Docker必须启动一个Linux用户空间和虚拟化文件系统，而Wasm运行时是为最小开销而设计的，其中一些甚至能编译成机器码。

当然，Docker已是企业里被充分理解的一部分，周边工具生态丰富，它仍将是一个重要工具。但Wasm已经走出实验阶段、积蓄起势头，如今正在成为一项真正具有颠覆性的创新。

Java反超Node、Go、Rust等。已有三十年历史的Java，一直背负着"老古董"的名声。人们说，它是个笨重、啰嗦、满是样板代码的庞然大物。人们想，既然有了Node.js处理异步I/O、Go做轻量并发、Rust追求极致速度这些现代生态，谁还需要"老Java"或"爷爷辈的Java"呢？

但事实证明，爷爷知道他自己在做什么。

诚然，为了跑一个小程序就得写public static void main之类的抱怨完全合理。但再仔细看，你会发现一些最先进的特性。尤其让Java成为服务端猛兽的，是虚拟线程（以及结构化并发等相关升级）。虚拟线程把线程管理推给JVM，由平台替你调度。这让并发变成一种服务，就像内存管理一样。

虚拟线程让Java服务器仅需改动一个import，就能扩展到潜在数百万个并行请求。而且，虚拟线程与更早的线程API完全兼容。

奇怪的是，2026年最值得一试的语言，也许是那个诞生于上世纪90年代的语言。

分工与心态：专业化胜过全栈，保持开放

专业化工程反超全栈开发者。这算不上新鲜事。你不可能精通被称为Web开发的那只多头蛇的每一个方面。全栈开发者的典型职位描述读起来像一整个IT部门。这根本不是人力所能及。如果你把CSS网格布局掌握得滚瓜烂熟，那数据库设计的知识就会被挤出活跃记忆。

自然，世上确实有能同时打鼓、弹吉他、吹小号还唱得动听的天才。但对我们大多数人来说，这做不到。我们需要依靠他人来补上短板。无论这座桥是一个AI智能体、另一个人，还是一个库，我们都可以用这些资源聪明地组装出一套完整技术栈。

当一个人成为资深工程师时，他的双手一定已经摸过软件技术工具箱里许多不同的部件。这显然极具价值。从这个意义上，你可以称他们为"全栈"工程师。但我们真正想说的是：他们对所有部件如何相互咬合有很好的理解，并且能有效地把这些部件组合起来。

这也是为什么真正的全栈开发者通常不"退休"——他们去做了管理者。

最后作为一名在门廊摇椅上晃悠的老家伙，我的建议是保持开放心态。我刚开始写Web应用时，看上去CGI和Perl会永远占据王座。

各位，在外面保持敏捷。另外，一定要试试HTMX。