前端微服务化(二)：对比
普通的前端单体应用
微前端架构
分包与微前端
觉得分包还是不同于微前端，分包可能会更加大，而微前端可能粒度更小，那么可不可以认为更细粒度的分包即是微前端？
一体化的前端
垂直化组织方式
什么是现代化前端应用
在介绍中我使用了措辞“构建一个现代化前端应用”，让我们先给出一些这个术语有关的设定。
从一个更广泛的角度来看，Aral Balkan 曾写过一个相关的博客，他把这个概念叫做文档-应用连续统一体。他提出了一个滑动比例尺的概念，在比例尺的最左边是一个网站，由静态文档构成，通过链接相互连接；最右边是一个纯行为驱动的，几乎没内容的应用程序，比如在线图片编辑器。
如果你把你的项目定位在这个范围的左侧，那在 Web 服务器级别的集成会比较合适。在这个模型中，服务器会收集页面中各个组件的内容并将其 HTML 字符串连接起来返回给用户。内容更新则采用从服务端重新加载的方式或者通过 ajax 进行部分替换。Gustaf Nilsson Kotte 针对这个主题写过一篇综合性的文章。
当用户界面需要提供及时反馈时，即使采用不可靠连接，一个纯粹的服务端渲染网站也不够用。为了实现 Optimistic UI 或 Skeleton Screens 这样的技术你需要在设备本身对 UI 进行更新。Google 提出的 PWA 巧妙的描述了这种兼顾各方的做法（渐进增强），同时提供 App 一样的性能体验。这种类型的应用在上面的比例尺中位于文档-应用连续统一体中间的某个地方。在这里纯粹的服务端方案已经不再够用，我们必须将主要逻辑放到浏览器中，这正是本文会重点描述的。
DOM 就是 API
Custom Element
自定义元素 Custom Elements 面向 Web 组件规范中互操作方面，在浏览器中是一个适用于功能集成的基本元素。每个团队采用自己选择的 Web 技术构建他们的组件，并将它们封装到一个 自定义元素 中(比如 )。这个特定元素的 DOM 声明(标签名、属性和事件)对于其他团队来说体现为一个协定或者叫公共 API。这样做的好处是其他人可以使用这个组件及其功能而不需要知道实现细节，他们只需要能够和 DOM 交互即可。
但仅仅自定义元素是不能满足解决方案的所有需求的。为了处理渐进增强、通用渲染或路由我们还需要软件的其他部分。
本文分为两部分。首先我们会介绍页面组合(Page Composition) —— 如何使用不同团队提供的组件组合成一个页面。然后我们会给出一些示例展示客户端页面转化(Page Transition)的实现。
页面组合
除了采用不同框架编写的客户端或服务端代码集成，还有很多副主题需要讨论：隔离 js的机制、规避 CSS 冲突、按需加载资源、不同团队共享公共资源、处理数据获取和思考提供给用户的加载状态。我们将会依次讨论这些主题。
浏览器支持
采用了 Custom Element 规范 V1 版，目前已经在 Chrome, Safari 和 Opera 中得到支持。但是通过 document-register-element 这个轻量级且经过大量测试的 polyfill 可以让该特性在所有浏览器中运行。在底层，它使用了广泛支持的 Mutation Observer API，所以并没有在背后使用 DOM 树监听这种侵入式的 hack 方法。
框架兼容性
因为自定义元素 Custom Element 是一个 Web 标准，所有的主流 JavaScript 框架都支持，比如 Angular、React、Preact、Vue 或 Hyperapp。但深入到细节时，就会发现有些框架依然存在实现上的问题。可以访问 Custom Elements Everywhere 这个兼容性测试套件，Rob Dodson 把没有解决的问题都高亮显示了。
子父元素或兄弟元素通信 / DOM 事件
对于所有的交互来说从上至下传递属性是不够的。
组件和组件通信的效果他们可以构建一种内建的 JavaScript API 进行通信。但这样就需要组件实例之间相互了解，同时也违背了隔离的原则。
一种更加干净的方法是采用发布者订阅者机制：一个组件可以发布信息，其他组件则订阅指定的主题(topic)。幸运的是浏览器内建了这个特性，这也正是 click、 select、 mouseover 等浏览器事件的工作机制。除了这些本地事件，还有一种可能性是通过 newCustomEvent(…) 来创建更加高级别的事件。事件总是绑定到它们创建或者分配的 DOM 节点上，大部分本地事件也支持冒泡的特性，这让监听 DOM 中特定子树节点的所有事件成为可能。如果你想要监听页面上的所有事件，将事件监听器附加到 window 元素上就 OK 了
服务端渲染 / 通用渲染
在浏览器中采用自定义元素 Custom Elements 来集成组件是个绝好的做法。但实际在构建一个 Web 中可访问的站点时，很可能是初次加载性能才是关键点，在所有的 JS 框架全部加载并执行之前用户只会看到白屏。另外，还有一个值得思考的是如果 JavaScript 执行失败或者被阻塞时网站会发生什么。Jeremy Keith 在他的 ebook/播客 Resilient Web Design 中解释了这个问题的重要性。所以能够在服务端渲染核心内容才是关键。不幸的是 Web 组件规范根本没有讨论服务端渲染。JavaScript 没有，Custom Elements 也没有。
微前端的几种实现框架
Single-SPA
优点：跨技术栈、
缺点：粒度不够小，与其叫它微前端不如称其为微应用，因为它针对的是页面级的，通过管理路由整合其它应用；
每个子应用需要满足约定好的方式进行开发，不便对原有项目进行改造
Project Mosaic
优点：完全细粒度到组件
缺点：整体非常复杂
Open-Components
优点：细粒度到组件
缺点：需要部署registy库
通过约定方式发布组件到registry中，客户端直接使用发布的组件地址调用；
个人认为这种方式与发布到npm，然后加载umd包的方式没有太大区别，前者在发布时貌似处理了umd包依赖冗余的问题。