Web 前端开发框架收集

Posted 2022-03-28 ejinxian

一、应用场景框架

三大框架：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

参考原文：https://javarome.medium.com/design-noframework-bbc00a02d9b3