这次争论让我想到了过去关于“CSS in JS”的争论。由于我对过去“CSS in JS”的争论一直心怀歉意，这次我会更加的客观去看待这个问题。
我认为就像CSS in JS一样，实际的权衡和差异取决于你的工程和代码组织的限制。实现微前端也有好方法和坏方法，让我们看一下好的，坏的和极其糟糕的微前端。
一. 首先，什么是微前端
“微前端架构”就是构建基于微服务的前端应用架构。
其思想是将前端应用切分为一系列可以单独部署的松耦合的应用，然后将这些应用组装起来创建单个面向用户的应用程序。
微前端的实现各不相同，因为不同的公司的技术方案不同，从服务器端页面嵌入到iframes到Javascript元框架(meta-frameworks)和web components。如果你想彻底弄懂微前端的优势和不同方法，我推荐这篇文篇章。
二. 优势：代码组织的灵活性和一致性
与微服务类似，支持微前端的人都强调可以减少跨团队依赖的代码组织优势。微服务的一些优势包括：
单独的服务单独部署
团队自己进行迭代和更新
围绕业务单元和产品单独组织团队
这些都是实实在在的优点，尤其是对于大型和复杂的项目，但是小的应用程序也能够从独立发布带来一些收益。
在2010年的时候，我开发一个电子商务网站，我一直担心由于一些无关的更改破坏整体的代码。为此我们建立了广泛的测试框架保证不会发生这种情况，现在回想起来对于隔离服务和微前端来说是一个完美的应用场景。
三. 缺点：操作复杂
随着我们从编辑静态文件到复杂的构建系统，移植（transpilation）和大型框架，获得功能良好的前端环境的复杂性已经大大增加。微前端进一步加剧了这种趋势，现在在整个应用程序中进行任何类型的测试可能都需要多个协调的前端，更不用说使用什么工具将他们融合在一起了。
微前端老手可能会遇到的挑战：
需要在开发中运行许多不同的应用程序以测试完成的体验
跟踪和调试问题需要跨全部系统
跨系统进行版本控制
本质上讲，是通过前端的简单性换取整个系统（前端/后端）的复杂性。
四. 痛点： 性能，不连贯的体验
在twitter上有许多对于微前端的揶揄
微前端有一些非常糟糕的问题：
每个团队都有自己的选择，浏览器最终可能会下载多个框架和重复的代码
用户不会单独体验你的公司网站或者产品。这也是反对对组件进行完全范围界定的论点之一 ——— 对于完全分离的团队这个问题可能更严重。
微前端的某些实现（尤其是嵌入iframe的实现）可能会带来巨大的可访问性的挑战
虽然拥护者会辩称这些事情不一定要发生，但这种情况似乎确实使我们更有可能看到这些问题。
五. 折中方案： 微前端使用的范围
是利还是弊取决于你和你的环境因素。对于规模较小，位于同一地点的团队和相对简单的产品而言，微前端的好处相对于弊端而言是很小的，而对于大型多面的产品和多个分布式团队而言，好处可能会超过挑战。
还有很多方法在消除不利影响的情况下获取许多好处
通过坚持选择单一的框架，并利用诸如single-spa.js之类的协调框架，您可以通过共享资源和仅下载一次公共代码来减轻很多性能损失。
使用共享的组件库，也可以消除许多用户体验不一致的问题。
当然，在每个步骤中都会放弃一些独立性。在某些时候，就根本不再是微前端架构。在这个范围内那个确切的对你有意义的点在哪里，取决于你的产品和代码组织。
