1. 发展历程
1990 年浏览器诞生、1991 年 W3C 组织诞生，标志着前端技术的开始，也拉开了前端技术光速发展的序幕。
在前端发展的最初期，并没有前端这个概念，更没有前后端分离这个说法。所有的 HTML 页面都是由后端生成，浏览器仅做展示。
1995 年，JavaScript 的诞生，才开启了前端发展的新历程。
最初的 JavaScript 主要用来进行表单校验或者一些简单的计算工作，直到 1999 年 W3C 发布新的 HTML 4.0 标准，加上各大浏览器厂商都实现了 XMLHttpRequest 来进行浏览器与服务器之间的通信。2005 年 AJAX（即“Asynchronous JavaScript and XML”）一词被正式提出。
2006 年，jQuery 发布。jQuery 内部提供了大量的浏览器兼容方案，并采用“链式调用”的形式，打破了当时的前端开发者的编程思维。并降低了当时的前端开发的入门难度。
虽然 jQuery 的出现使得前端开发更加简单和轻松，但是也带来了两个问题：
- 页面引用插件太多，导致 script 标签过多，影响页面解析
- 插件太多造成全局污染
为解决这个问题，当时的前端大佬们决定从后端技术中取经，引入“模块”机制。随着 Node.js 的发布和 RequireJS 的诞生，前端新技术层出不穷，前后端分离的述求愈演愈烈。
从 2009 年开始，各种 MVC/MVVM 框架横空出世，最终以 React、Vue、Angular (SPA, single page application, 也叫单页面应用) 三分天下结束。
2. 什么是微前端
微前端（中文概念见 Micro Frontends）。
是一种类似于后端微服务、应用于前端浏览器的技术架构，旨在将单一“SPA巨石应用”拆分为互不影响、能独立允许和部署的小型应用，也就是“微应用”。
微前端的中心思想是：复杂的 Web APP 或者网站，都应该是由不同的独立的功能模块组合成为一个整体，但是各模块相互独立，可以由 不同的团队 利用 不同的技术 来完成针对 特定业务领域 的功能开发。
实现一个微前端架构，首先要满足以下条件：
- 与技术栈无关，不影响各应用的原有技术体系
- 应用独立，各个应用之间不应该存在强关联，都可以独立开发、运行、部署，并且各应用的数据、样式等都应该完全隔离
- 不影响用户体验，各应用切换应该流畅，应用状态缓存，正常的加载过渡动画等
3. 为什么需要微前端
上面说了微前端的核心目的是拆分“巨石应用”，如果你的项目只有几个几十个小页面，那么微前端可能不怎么适合你。
而当一个项目足够“大”，功能足够“多”时，那么微前端就能帮你极大的降低开发“难度”。
qiankun 技术圆桌 - 你可能并不需要微前端 一文中大概解释了哪些情况下你可能不那么需要微前端。
- 你/你的团队 具备系统内所有架构组件的 话语权
- 你/你的团队 有足够动力去治理、改造这个系统中的 所有组件
- 系统及组织架构上，各部件之间本身就是强耦合、自洽、不可分离的
- 极高的产品体验要求，对任何产品交互上的不一致零容忍
那如果你需要使用微前端，除了用最原始的
Iframe来解决之外，你还有下面几种选择。
4. 微前端开源框架(国内)
single-spa算是最早开源的微前端框架之一，于 2015 年发布 1.1.0 版本，通过给每个微应用添加生命周期函数，并在主应用路由中注册。 在主应用调用registerApplication时开始注册和下载一个微应用，并在start()时开始初始化，根据当前路由来调用不同微应用的bootstrap和mount函数。
qiankun则算是国内最知名也是使用率最广的微前端框架。于 2019 年 8 月发布 1.1.4 版本，底层也是依赖single-spa进行的二次封装，在其基础上封装了沙箱隔离和数据共享的机制，并对部分 API 进行了简化。
5. 总结
以上 8 种微前端框架，大致采用的都是以下几种方案：
- 通过基座应用加载子应用
umd.js格式入口文件，模拟 Iframe 实现css沙箱隔离
- 采用浏览器新特性
Web Components，但是兼容性很差
- 采用
ES Module与CSS Module实现，但一样有兼容性问题
Webpack 5的新特性联邦模块Module Federation
所以不管是从 Star 数量还是兼容程度，以及国内前端大环境，首选还得是
qiankun
