应用框架何其多，但核心要素不会变

上期视频中，我们介绍了构建用户界面的几个要素：CSS 框架、UI 框架和组件库。

这一期我们来聊聊不同生态的应用框架，以及常见的应用架构方案。

使用 UI 框架足以制作一个好看又好用的前端应用了，

但为什么我们还需要应用框架呢？

随着前端业务越来越复杂，我们会在 UI 框架之外做很多看起来和 UI 无关的事情。

比如引入状态管理方案、做一套统一的布局、抽象一个更好用的数据请求方法、优化打包效率等等。

而这些看起来很通用，UI 框架做起来又很费劲，正是应用框架会考虑的事情。

应用框架的覆盖面较广，

有基于 React 生态的 Next.js、UmiJS、Modern.js，有基于 Vue 生态的 Nuxt 和 Quasar，也有自成一体的 Astro 和 Angular。

有专注于桌面应用的 Electron、Tauri，也有适用于小程序的 Taro、uniapp，应用于移动原生应用的 React Native、Flutter 和 Ionic。

虽然应用框架看起来很多，但几乎都包含这些功能：路由（Routing），样式（Styling），数据获取（Data Fetching），测试（Testing），插件（Plugin）和部署（Deploying）。

路由（Routing）规定了页面的组织方式、布局和跳转方式，也可以帮助框架更好地进行分包，以提升运行时的加载效率。

样式（Styling）是框架提供的一组 CSS 开发方案，通常会包含 CSS 预处理器、CSS Modules、CSS-in-JS 和 CSS 框架。

数据获取（Data Fetching）通常包含内置请求库，缓存，服务端渲染等经过框架优化的方案。

测试（Testing）则是专为框架定制的一套环境和测试工具，方便开发者更优雅地编写测试代码。

插件（Plugin）是框架为了方便开发者扩展其功能预留的口子，通过它可以自定义构建行为，来尽可能满足定制化需求。

部署（Deploying）是框架提供的生产应用上线方案，包含不同构建产物的生成配置，静态资源部署，全栈应用部署方式等。

应用框架是从小型业务过渡到大型业务的必经之路。

许多大厂会在开源应用框架的基础上，再做一层定制封装，增加适用于自身业务特点的功能，比如对接内部各种服务的插件。

蚂蚁集团内部的 Bigfish 框架就是在 UmiJS 的基础上添加了许多 Plugins 来扩展功能。

说了应用框架，就不得不提应用架构。应用架构是应用的组织范式，更关注不同范式间的优缺点。

现代前端常见的应用架构方案有 MPA、SPA、PWA、Micro-Frontends 和 Islands 这几种。

MPA 全称 Multi Page Application，即多页应用，这是最传统的网页组织方式。

不同的页面对应不同的 HTML 文档，

许多移动 App 内部的 H5 页面都会采用这种架构。

它的好处是业务划分清晰，迭代变更影响面较小。坏处是每次打开一个新页面都要等待加载。

SPA 全称 Single Page Application，即单页应用。

顾名思义，它在同一个页面上通过路由状态改变，来模拟不同页面的切换。

相比多页应用，它在一定程度上解决了用户在多个页面间切换需等待的问题，但带来的缺点就是首次加载时白屏时间较长。

PWA 全称 Progressive Web App，即渐进式 Web 应用。

相比普通 Web 应用，它采用了 Service Worker 和离线缓存技术，

它是最接近于小程序的架构形式，提供了类似原生应用的体验，且白屏时间较短。但最大的缺点是它依赖浏览器，无法像小程序一样访问原生平台功能。

Micro-Frontends，即微前端，简称 MFE。

它是一种将多个独立开发的前端应用组成整体的架构风格，在许多大企业内部的后台项目中比较常见。

它主要起到两个作用：帮助巨型单体应用持续迭代，以及提高跨团队协作开发效率。

它的缺点主要是技术复杂度较高，用户体验差以及调试困难等。

Islands 即群岛架构，是一种比较新的架构范式。

它和微前端比较像，但它的粒度可以细化到组件级别，并且拥有更好的性能。但缺点是目前支持群岛架构的应用框架还较少。

同一种应用框架可以支持不同的应用架构。

比如 UmiJS 支持 SPA、MPA 和 MFE 架构，Quasar 支持 SPA、PWA、Electron 架构，Modern.js 支持 SPA、MFE 架构，Astro 则专注于 Islands 架构等等。

本期我们介绍了应用框架和 UI 框架的不同，它的核心功能以及常见的应用架构方案，下一期我们聊聊前端开发最重要的事情：用户体验。

如果你从这期视频中获得了新知识，记得点个赞，我是小麦，我们下期再见。