从“XML一统天下”聊聊我所经历的技术炒作

【编者按】身处技术圈我们，时常会听到“XX 已死，XXX 将一统天下”的论调，本文作者分享了自己入行以来，所经历的各种技术炒作。

原始链接：https://www.bitecode.dev/p/hype-cycles

未经允许，禁止转载！

作者 | Bite code  译者 | 明明如月

责编 | 夏萌

出品 | CSDN（ID：CSDNnews）

我最早接触到的一个技术炒作是 “用可扩展标记语言（XML）解决一切问题”。这个经历让我有幸见证了前端技术的爆发，微服务的滥用，以及诸多荒诞的趋势。

我刚接触编程时，很多人预测 XML 将一统天下。HTML 将被 XHTML 取代，使用 DTD 进行校验，利用 XSLT 实现转换和展示，借助 SOAP 进行通信。

面向对象编程（OOP）的热潮我并没有亲身经历，那是我上一代人的事，但我读了很多文章，它们警告我要小心，因此我把这种心态应用到了 XML 上：在全身心投入之前，我们应该先观望，看看事情是否真的如所预期的那样美好。

结果显示，XML 并非未来的主流。它更多的是技术债务。

对于文档等事物，它是有用的，我认为它最大的成功案例就是 MS Office 和 LibreOffice 的文件格式。它们其实就是 XML 的压缩包。

我很幸运，职业生涯早期就学到了这个教训：没有完美的解决方案，任何工具，不论多么优秀，都要从工程的视角来评估其优劣。每种工具都有其代价，也需要作出妥协。这其实是一个投资回报的问题，如果没有足够的经验，评估起来会非常困难。

总的来说，时间再次证明了其公正性，没有什么能代替观察复杂系统的演变，不管你对世界套用什么样的模型。

最重要的是，我了解到极客们虽然自认为是理性的生物，但他们实际上深受噪音，营销，以及他们自身情绪的影响。他们甚至比普通人更容易受到影响，因为他们总以为自己不会受这些因素影响，从忽视了这个盲点。

当 MongoDB 出现时（它有强大的拓展能力），似乎啥需求都可以用 NoSQL 。即便是两个毫无共同点的 NoSQL 系统也要硬挤在一起。这就好像把一个国家定义为“非英语国家”。即使当时 MongoDB 是一个可能损坏你数据的劣质产品也无妨（他们已经解决了这个问题，现在它是一个非常优秀的数据库）。大部分使用它的人并不需要自由复制，他们的数据完全可以放在 SQlite 文件中。

于是，我们看到新手可能会将没有固定结构、没有严格一致性要求以及可能存在错误或不完整的数据存储在一个大的数据块（blobs）。这就导致了许多项目的失败。

此后，Node 时代来临。在前端与后端使用同一编程语言成为大热，你必须采用相同语言，将所有请求异步化。但 JavaScript 品质不高，许多 JavaScript 项目仅为避免撰写 ES5 而出现。缺少 import 与命名空间,范围混乱, this 具双重性质，基于原型继承，弱类型等等问题甚多! 因此，我们先后见到 CoffeeScript、Babel、Webpack、TypeScript、React+JSX 等技术的出现。

我们被告知要跟上最新的技术生态，这意味着我们需要应对每两个月就会有重大改变的情况。这也是实现最优化的树摇技术所需要付出的代价。同时, 出现类似"left-pad" 问题也不足为奇，因为 map 文件生成错误，无法调试和排错，进一步增难问题。

在这个时期，所有的应用都被要求采用单页应用的方式，并具备客户端路由、不可变数据结构和一种特定的存储方式。也就是说，如果你需要在 flux，redux，alt，reflux，flummox，fluxible，fluxxor，marty.js，fynx，MacFly，DeLorean.js，fluxify，fluxury，exim，fluxtore，Redx，fluxx 中作出选择。这可不是我胡编乱造。

但是，因为你仍然需要通过线路传输大量的数据，并且所有的事物都必须在客户端上，因此 GraphQL 随之诞生。当然，这些会导致可访问性差，SEO 问题以及首次渲染时间长，这又催生了 服务器端渲染 的大流行。服务器端渲染（SSR）在构建 Web 应用程序时，执行了一种类似于公共网关接口（Common Gateway Interface，CGI）的过程，其中服务器在接收到客户端请求时执行一些额外的步骤来生成动态内容。前端开发社区为了解决服务器端渲染和客户端渲染之间的差异，还引入了 hydration 技术，以实现更好的性能和用户体验。

这导致了复杂性的增加，并且产生了大量一次性代码库，最终导致，项目的失败和资源的浪费。

因为, 大部分这些任务其实可以使用 Ruby on Rails、Symfony 或者 Django，配上一点 jQuery 就可以完成。至少，它们可以用这些“老牌” 技术来实现项目。相反,失败的项目开始积累,每一个精美的 Figma 背后都隐藏着许多公司墙壁后无人敢提及的失败案例。

讨论由于过度复杂性和使用新技术而导致的问题是被视为禁忌。你就会被视为那个无法理解或接受这些新的技术和趋势的人。

当人们在构建基本的增删改查应用时引入过多复杂性时，可能会感到困惑或不解。

然而，全球各地的团队却让这个问题变得越来越严重，给自己带来更大的挑战。

首先，"一切都应该是微服务" 这句话开始流行起来。每一个小型网站都有至少一个提供 RESTful API 的容器,再加上一个负责前端的容器，以及一个负责数据库的容器。各层之间叠加，为了这些层之间的通信，何不加入一个微型的消息队列呢? 如 ZeroMQ、RabbitMQ...... 还需要一种优秀的交换格式，比如 gRPC 和 protobuf。

你可能无法相信使用所有这些复杂的技术和工具来构建一个简单的待办事项应用程序会变得异常困难。所以出现了一个解决方案: 使用编排方案。先有 Docker Swarm, 后来又出现了 Kubernetes。

到这个时候，已经投入了很多时间和金钱，人们开始把云服务视为救星：他们可以帮你处理所有这些问题，只需收取相应的费用。你只需要学习他们的各种操作方式，去调试他们即可，被迫局限在他们的生态系统里，然后使用先进的模板化的 YAML 文件，更倾向于使用命令行界面（CLI）或编程方式与云服务进行交互，而不是依赖图形用户界面，仔细优化和配置整个项目。这样，你在托管服务上的花费可能只会增加 10 倍，而不是因为无从下手而增加 10000 倍。

然后，大数据时代的浪潮席卷而来。你需要记录下用户的每一次操作。你还需要进行 A/B 测试，虽然这可能让 10% 的用户感到不便，给技术支持团队带来了巨大的压力和挑战。但现在，你掌握了海量的数据！即使实际情况并非如此，你也要相信你拥有大量的数据，因为你需要建立一种数据湖。或者是时序数据库。又或者是图数据库。总之，你需要某种类型的数据库。

接下来，所有这些现有的系统开始变得迟缓。不是因为技术决策欠妥，让原本每秒只能处理 100 个请求的网站去采纳了适合谷歌这样规模的工程架构。而是因为所采用的编程语言相对较慢。于是，我们开始考虑用如 Go 或者 Rust 重新开发所有代码。

编译过程开始变得异常耗时，以至于连续集成流水线的执行时间已经达到了 73 分钟之久。这无疑成了压垮骆驼的最后一根稻草。于是，开发人员开始逐渐回归简化的方式…… 实际上，开发人员正在大量使用无服务器计算服务（如 AWS Lambda）和可以在边缘运行的软件即服务（SaaS）服务，因为拥有自己的技术栈已经不再是未来的发展趋势。

与此同时，博客文章关于疲劳感的文章数量迅速增加，高层管理者被利润的诱惑所吸引。

如果不走社交化道路，你就难扩大影响力。

使得所有东西更有趣味性，再次提高趣味性。

区块链技术将重塑我们的世界。

你需要加速移动网页。

没有机器学习，你的产品很难在市场中立足。

如果你已经体验过上述内容，你会发现剩下的部分几乎是空壳。

一些“分享” 按钮和“登录方式”。一些积分与徽章系统。各类图表。

这些要么消亡，要么成为所擅长领域的典型代表，正如它们应该成为的样子。

部分则被当下所取代。

我很高兴看到 YAGNI（You Ain't Gonna Need It，一种软件开发原则，强调只在实际需要时才添加功能和复杂性）再度兴起。

像 Vue、HTMX 和 unpoly, alpine.js ，或者仅仅使用原生 JavaScript ，这些项目正在受到越来越多关注。

关于使用 Postgres 来完成大部分任务的讨论也在不断升温。

37signals （一家私人控股的网络应用公司）再次成为人们关注焦点，因为他们已不再使用公有云服务。

当然，这种回归简洁的热潮有时也会被夸大其词。因为简约主义的炒作，毕竟也是一种炒作。

你确实需要依赖云服务、容器、NoSQL、Go、Rust 和 JavaScript 来构建系统。在现代软件开发中，我们需要关注并满足不断变化的需求和期望，利用新功能和特性来打造出色的用户体验。

然而，使用这些技术时要根据具体情况和需求进行评估，而非一刀切地应用于所有情况。

此文一经发布，便引起了众多开发者的共鸣。

一位在美国科技行业工作了 5 年的程序员表示，这个行业总是充斥着各种炒作，新的趋势接连出现，现代化的概念也在不断变化，重构的需求也越来越多。虽然他有自己的工作流程，知道如何构建应用程序，但有一天，运营总监却完全改变了这个工作流程。他需要不断学习新的技术和工具，比如 Terraform、无服务器技术、容器技术、微服务等等。这让他感觉自己仿佛陷入了弗朗茨·卡夫卡的小说中，不断地改变和重复着相同的事情，因为这就是新的工作方式。这种情况让他觉得有些荒谬。

另一位程序员表示，在过去的 5 年里，他曾在两家大型科技公司和一家大型对冲基金工作，这些公司都使用非常过时的技术栈，或者是没有文档的内部技术栈。管理层不允许引入新的技术栈，因为他们认为这样做没有商业价值，他们更关注发布新功能。如果他坚持进行重构并采用新的技术栈，一旦出现问题，他将承担责任。虽然他付出了巨大的努力成功地升级了几十年的技术栈，但这对他的晋升没有产生任何帮助。他表示，除了修复安全漏洞外，没有任何动力去升级任何东西。

还有网友认为，如果技术栈过于陈旧，查找相关资料会变得困难，而且软件也难以维护。也有网友认为，维护成熟的技术比每隔几年就进行全面重写更有价值，公司倾向于在维护和重写之间权衡成本。

还网友表示，虽然现代 Web 开发比以前复杂了很多，需要掌握更多工具和技术，但是这些工具和技术的出现的确使得 Web 应用变得更加强大和丰富,我们才有了 Figma、Spotify、Notion、Photopea 等优秀的  Web 应用。所以,尽管 Web 开发门槛变高了，但是 Web 应用的潜力也因此得到释放。