微前端-从入门到放弃草稿
# 什么是微前端？
# 实现方向
目前有两个方向
- 子应用
- 子模块
信任机制
# 为什么不用 iframe ?
https://www.yuque.com/kuitos/gky7yw/gesexv
iframe 最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题。
- url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
- UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
- 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
- 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。
其中有的问题比较好解决(问题1)，有的问题我们可以睁一只眼闭一只眼(问题4)，但有的问题我们则很难解决(问题3)甚至无法解决(问题2)，而这些无法解决的问题恰恰又会给产品带来非常严重的体验问题， 最终导致我们舍弃了 iframe 方案。
举个 tcp 和 udp 的例子就懂了
tcp 由于是稳定的，所以需要丢包重传，而 udp 是不稳定的，但是我们可以借助自己的一套算法来满足自己的目标，不同的算法造就了不同的标准
# 如何解决隔离问题
核心两点：
- 样式隔离
- js 隔离
# garfishjs 原理介绍
https://www.garfishjs.org/guide/sandbox
总结
# 大结局
为什么说前端卷呢？因为上述这些方案纯属 special case hack ，没有计算机理论支撑，学了也很难说有什么成长，无法举一反三
未来几年，我认为 w3c 会出且应该出个提案解决这个问题，这里我先大胆的进行提案预测 ShadowFrame：
# 提案 - VM
无非几个问题：
- 性能
- js 自举实现的 vm 性能略差
- 隔离 安全性
考虑安全性
wip
提供沙盒运行机制，允许调用某些外部方法
样式：允许进行样式隔离
# 社区
前端就是卷
https://mp.weixin.qq.com/s/Rohj17iy7qglDAjheo5aKw
https://mp.weixin.qq.com/s?__biz=MjM5MTA1MjAxMQ==&mid=2651256967&idx=1&sn=8c3cc87ca55d41848acf3d4124f21339&chksm=bd4921038a3ea81537cc3a12d4743b8846f10f0cb6b0344b5216e674faac6170ff1f1407ab8f&scene=21#wechat_redirect