过去流行的是 Angular，然后是 React，现在是 Vue.js……其他的像 Ember、Backbone 或 Knockout 什么的几乎都快消失了。一些标准，例如 Web Components，则很少被使用。似乎每年都会发布一些新框架，比如 Svelte、Aurelia，而且每个框架在服务器端都有对应的对象（开头那些框架对应的 NestJS、NextJS 或 Nuxt，Svelte 对应的 Sapper，等等）。非 JavaScript Web 框架（如 Django、Spring、Laravel、Rails 等）就更不用说了。甚至还有框架之上的框架（Quasar、SolidJS）、为框架生成组件代码的框架（Stencil、Mitosis），以及 NCDP（无代码开发平台，No-Code Development Platform）。

这种多样性让想知道哪种技术值得学习的开发人员和技术选型决策者感到困惑。

网络上经常会出现一些比较这些框架的文章，好像是在帮助我们解开这种困惑。但大多数作者通常是带有偏见的，因为他们可能“用过这个框架”，但“只尝试了一些其他的框架”。偏见程度较低的作者总是得出“这取决于具体情况”的结论（取决于性能、工具、支持、社区等），这实际上是一种非结论性的结论。

即使一些基准测试基于同一个应用程序对不同的框架进行了比较，也很难获得真实的结果，因为这种基准测试受限于被测试的应用程序（比如待办事项应用程序）。

框架看起来就像是宗教（或者说是政治）：每一个框架都假装自己为开发者提供了解决方案，但每一个又都不一样。它们每一个都声称可以为应用程序提供最好的前景，但关于哪一个真正名副其实的争论又不绝于耳。每一个框架都要求你遵循特定的规则，它们之间可能有相似之处，但要从一个框架转换到另一个框架总是很难。

现在，让我们来看看框架的“无神论”方法：不使用框架。

从哪里讲起？

我有超过 25 年的专业软件开发经验，除此之外，本文还将以构建真实纯 JS Web 应用程序（前端和后端）的经验为基础。

为什么不使用框架？

实际上，这个想法还很新。早在 2017 年，Django Web 框架联合创始人 Adrian Holovaty 就谈到了他的框架“疲劳”，以及他为什么离开 Django 去构建自己的纯 JS 项目。

有人可能会问，为什么会有人想要在不使用框架的情况下开发 Web 应用程序？为什么不在其他人花了数年时间和精力的成果的基础上做开发？或者是因为 NIH（Not Invented Here）综合症导致人人都想构建定制的框架？

开发人员并不会比一般人更倾向于自找麻烦，实际上，他们可能比任何人都懒：他们只会想写更少的代码（这样他们就可以更少犯错），想要自动化（以避免人为错误）……

但他们又想要敏捷，也就是能够轻松、快速地解决问题。

虽然“快速”似乎是框架承诺的东西（为你搭建脚手架，并增加可靠性），但它不是免费的：它们想让你签署合同，同意支付“税”费，并将你的代码放入“孤井”（“税和孤井”的说法来自 IBM Carbon 系统设计团队负责人 Akira Sudhttps://github.com/carbon-design-system/carbon-web-components#readme）。

框架税

使用框架是需要付出成本的：

遵循它们的 API 规则，这样它们就可以向你提供服务。这就是框架的工作方式：你的代码必须遵守某些规则，包括或多或少的样板代码。你每天要想的不是“如何做这件事”，而是“如何让框架做（或不做）这件事”。如果你规避了这些约束，风险就由你自己承担：如果你通过直接调用底层 API 来绕过框架，就不要指望它们能理解你的意图，也不要指望它们的行为能保持一致。所以，框架会让你“专注于业务”是一个虚假的承诺：实际上，框架的事情你也没少操心。

如果你想要以下这些东西，就不得不强制进行升级：

1) 想要一个新功能（即使你不需要所有功能，也必须升级所有东西）；

2) 想要修复一个 bug；

3) 不想失去框架的支持（随着新版本的发布，你的应用程序所依赖的版本将会被弃用）。

如果框架出现了 bug，但没有明确的计划修复日期，这会让你感到非常沮丧（可能还会让项目面临风险）。第三方提供的框架库（如小部件）或插件也不例外，如果你一直使用旧版本，它们与你的应用程序的兼容性会越来越差。对于框架维护者来说，维护向后兼容性已经成为一件非常麻烦的事情。他们发现，开发自动升级代码的工具（Angular 的 ng-update、React 的原生升级助手、Facebook 的 jscodesshift 等）会更有利可图。

• 需要学习如何使用它们（它们能做或不能做什么、它们的概念、API、生态系统、工具），包括了解在新版本中可能发生的变化。如果你选择的是当前最流行的框架，这可能会容易些，但你不可能了解一个框架的方方面面。此外，炒作也从来不会消停：如果你决定在一个新应用程序中使用另一个框架（或者更糟的是，从一个框架迁移到另一个框架），那么你在旧框架上所有的投入都将归零。这就是为什么很多企业项目会缺乏活力，即使每个项目都可能与前一个项目不一样。已故的 David Wheeler 曾经说过：“保持兼容性意味着有意重复别人的错误”。

  将控制权委托给框架，这是对框架缺陷的妥协：你可能无法做任何你想做的事（或防止框架做你不希望它们做的事情）或者你也许不能获得你想要的性能（因为额外的分层、普适性、更大的代码体积或向后兼容性需求)。

  技能零散化。很多开发人员要么不太了解底层 API（因为他们总是使用框架提供的东西），要么活在过去（只知道过时的知识，不知道最新的改进和功能）。“工具法则”常常导致过度设计，为简单的问题构建复杂的解决方案，而构建简单解决方案的知识逐渐零散化。在指南的指导下，我们失去了（或者没有获得）好的软件设计（原则、模式）文化，并失去（或者没有获得）构建重要工程的经验。就像 CSS 框架（Bootstrap、Tailwind 等）的用户缺乏 CSS 技能一样，Web 框架的用户也注定缺乏现代 Web API 和软件设计经验。

一旦你把钱放入框架，就很难把它拿出来。

框架孤井

除了必须支付“税”费来获得框架的好处之外，如果框架没有标准化，它们还会带来另一个问题。

因为它们强制要求你遵循框架规则——而且每一条规则都不一样——这意味着你的应