简论微前端的意义与发展
PS：以下言论部分整理于网友
先说一下为什么需要微前端
我抛出两个场景，大家思考一下：
1.新入职一家公司，老板给你一个5年，甚至于10年的老项目，需要你在这个项目上加入其他功能
2.你们起了一个新项目，老板只给了一个要求，要这个项目的架构在3年甚至于5年后依旧保持活力，不论为遗产项目
第一个场景我们初步一想，可以啊，我只需要把新功能用 react/vue 开发，反正他们都只是 ui library，给我一个dom 节点我想怎么渲染怎么渲染。但是你有没有考虑过这只是浮在表层的视图实现，沉在底下的工程设施呢？我要怎么把这个用 react 写的组件打出一个包，并且集成到原来的用 es5 写的代码里面？或者我怎么让 webpack 跟 之前的 grunt 能和谐共存一起友好的产出一个符合预期的 bundle？
第二个场景就不用想了，react15和react16都不兼容，你怎么保证一个项目几年之后还能充满着活力？
这两个例子，很典型，另外值得一说的是，目前为为前端发声的公司，都是像银行这种需要一直维护单个项目的公司，他们的业务越到后期越复杂，越到后期越需要兼顾，系统改版一次是很痛苦的，像一些中小型企业，这样的改版是致命的，这里就抛出了一个问题，如何确保我的遗产代码能平滑的迁移，以及如何确保我在若干年后还能用上时下热门的技术栈？
引入微前端
为了解决上面所提到的问题，我们引入了一个新的概念，微前端，至于什么是微前端，下面我会详细介绍
**首先我们需要在主系统构造一个足够轻量的基座，然后让各部分子系统按照一定的协议和规则去运行，去执行，当然了还有一点就是系统和系统 之间还需要通信
**
**我们提出的这些问题基本iframe都能解决，从宏观来讲的话，它确实是一个完美的方案
**
iframe 最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题。
- url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
- UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
- 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
- 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。
其中有的问题比较好解决(问题1)，有的问题我们可以睁一只眼闭一只眼(问题4)，但有的问题我们则很难解决(问题3)甚至无法解决(问题2)，而这些无法解决的问题恰恰又会给产品带来非常严重的体验问题， 最终导致我们舍弃了 iframe 方案。（以上出自乾坤文档Why not Iframe）
接下来我们知道了，我们要做一个不是iframe的iframe出来
与技术栈无关才是微前端的初衷
微前端首先解决的是如何解决一个巨石应用，从而解决巨石应用随着技术更迭、产品升级、人员流动带来的工程上的问题。解构之后还需要再重组，重组的过程中我们就会碰到各种 隔离性、依赖去重、通信、应用编排 等问题。
那么微前端的基本概念就可以推演出来
- 技术无关
- 隔离团队代码
- 建立各团队的前缀
- 本地浏览器特性优先于自定义 API
- 构建自适应网站
微前端方案正确的架构姿势
既然技术栈无关是微前端的核心，那么任何违背这一原则的做法都应该被摒弃。
比如我们不能要求子应用或者主应用必须要使用某一框架，某种方式，或者是某一版本
web-component
在不少关于微前端的帖子下都能看到网友对web-component的呼声很高
我个人认为这确实比较好的微前端方案，但它也有缺点：
- 兼容问题，倒不是 ie 的兼容，而是国产浏览器很多都阉割掉了 shadow dom
- 隔离太硬，穿透是世纪难题
上面两点，其实都不是很要紧的问题，兼容问题可以降级（polyfill），而且现在穿透隔离的方式也越来越多
与此而来的是 web component 很多优势，最主要的是它提供了一层 runtime，自带生命周期和双向绑定，可以更方便地做各种操作
最后总结一下：
做到代码的时代和次元隔离并且拥有良好的用户体验，是微前端的核心：随着时间的推移，团队人员的流动，会慢慢发现一些事情：比如原维护团队以react 16.9的视角看 react15.6的世界，就像在看原始人用原始的姿势拉着原始的屎，又或者新人进来以vue看react，鸡同鸭讲理念不同。 微前端的理想状态也许就是用最爽的姿势写最新的业务模块吧