一、应用场景框架
三大框架：Angular、React、Vue
其他框架：Ember、Backbone 或 Knockout
Web Components 标准框架：Svelte、Aurelia
与服务器端对应的框架 NestJS、NextJS 或 Nuxt，Svelte 对应的 Sapper
非 JavaScript Web 框架：Django、Spring、Laravel、Rails 等
框架之上的框架：Quasar、SolidJS
Web 组件框架：Stencil、Mitosis、skatejs
NCDP：无代码开发平台，No-Code Development Platform
CSS 框架：Bootstrap、Tailwind
二、多样性框架带来的困惑
1、一个应用程序到底使用哪个框架合适，如何选型
2、开发组件的选型，哪个更适合满足开发项目要求
3、每个框架的标准，学习的成本和代价
4、框架升级后，对相关框架的影响代价
三、框架的迭代
项目刚开始时，可以选择最流行的框架。对于一个短期的项目来说，这可能是可以接受的，但对于长期项目来说，需要侧重于稳定性、框架的熟悉程度等综合考量。
在 Web 平台上，使用标准 Web API 可以降低你的投入风险，因为它们可以在大多数浏览器上运行。浏览器兼容性上，可以通过 polyfill 来弥补。
现代Web 组件在各浏览器的兼容性相差无几，组件封装成任意的 HTML 元素。具备更好的性能（自定义元素、阴影 DOM、HTML 模板）作为浏览器的一部分运行，并且是原生的。
四、框架标准
要评估在不使用框架的情况下构建应用程序的难度，我们要明白：它不像构建框架那么困难，因为以下这些不是我们的目标：
- 构建专有的组件模型（实现特定组件生命周期的容器）；
- 构建专有的插件或扩展系统；
- 构建一个奇特的模板语法（JSX、Angular HTML 等）；
- 实现通用的优化（变更检测、虚拟 DOM）；
- 特定于框架的工具（调试扩展、UI 构建器、版本迁移工具）
标准 API 属于“好的框架”：
- 具备可移植性：它们在任何地方都可用，如果不可用，可以通过 polyfill 的方式实现。
- 具备互操作性：它们可以与其他标准交互，并被用在专有代码中。
- 长期存在：由多个行业参与者设计，而不只是一个。它们被设计得很好，一旦发布就会一直存在，使用它们的风险较小。
- 在大多数情况下在浏览器中都是立即可用的，避免了下载过程。在某些情况下，你可能需要下载 polyfill。但是，与专有框架（注定会越来越不流行）不一样的是，它们的可用性会越来越高（逐渐降低下载的必要性）
很多编程语言描述成 JavaScript：TypeScript、CoffeeScript、Elm、Kotlin、Scala.js、Haxe、Dart、Rust、Flow 等，代码增加不同的价值（类型检查、额外的抽象、面向对象、语法糖）
- 遵循语法：大多数编程语言都强制要求这么做（CoffeeScript、Elm、Kotlin 等）。但需要注意的是，它们是 JavaScript 的超集（TypeScript、Flow），你仍然可以用纯 JavaScript 编写你选择的某些部分。
- 如果你使用的是非常旧的编程语言（包括 JavaScript）版本，就需要升级，但升级频率比框架低很多。
- 需要学习它们的语法。不过，你可以循序渐进地学习超集编程语言，因为你的代码的某些部分可以继续使用传统 JS。
- 对于非超集编程语言来说，离散化技能确实是一个风险。因为它们的编译具有普适性，可能不是最优的，而你可能没有意识到这一点。也许你可以使用更简单和高效的 JS 代码来完成同样的操作。
- 需要对缺点做出妥协，因为我们无法改变转译成 JS（或者使用 tsconfig.json 做一点定制）或编译成 WebAssembly 的过程。有些语言可能还会忽略 JS 的一些概念。
- 具备可移植性，因为通常代码可以转译到 ES5（但有时你不得不妥协，即使你想要转译到 ES6）。WebAssembly 很新，所有现代浏览器都支持它。
- 提供与其他 JS 代码的互操作性。例如，Typescript 可以被配置为支持 JS
