上周推特爆炸性地爆发了关于“微前端”的讨论，强烈的争论和强烈的意见在双方都有所突破。我认为就像JS中的CSS一样，根据您的项目和组织约束，存在真正的权衡和差异。实施微型企业也有很好的方法和糟糕的方法。
首先，微前端究竟是什么？
“微前端架构”是一种构建以微服务为模型的前端应用程序的方法。将您的前端拆分为一组可独立部署的，松散耦合的应用程序。然后将这些应用程序组装在一起以创建单个面向用户的应用程序。
这样做的技术方法各不相同，不同的公司做不同的事情，从服务器端转换到iframe到JavaScript元框架和Web组件。
优点
与微服务非常相似，微前端的拥护者强调了减少跨团队依赖性的组织优势。好处包括：
- 单独部署单独的服务
- 自主团队独立迭代和创新的能力
- 能够围绕业务部门或产品组织团队
所有这些都是有效的好处，特别是对于大型和复杂的项目，但即使是较小的应用程序也可以从独立部署等方面获益。
当我在2010年开始使用电子商务应用程序（微服务前）时，我一直担心由于无关的变化而以某种方式破坏结账。我们建立了广泛的测试框架来防止这种情况，但回想起来，孤立服务+微前端对于这种情况来说是完美的。
坏：操作复杂性
当我们从编辑静态文件到复杂的构建系统以及大型框架时，获得正常运行的前端环境的复杂性已经大大增加。微前端进一步加剧了这种趋势，现在在整个应用程序中进行任何类型的测试可能需要多个协调的前端，更不用说用于将它们拼接在一起的任何工具。
微服务的挑战同样适合微前端：
- 需要在开发中运行许多不同的应用程序来测试完整的体验
- 跟踪和调试整个系统的问题
- 处理整个系统的版本控制
基本上，我们在单个前端中简化整个系统的复杂性。
丑：性能，不一致的体验
下面是看起来很糟糕的问题：
- 每个团队都有自己的技术选择，浏览器最终可能会下载多个框架并重复代码
- 用户不会孤立地体验您的公司或产品。这是反对完全确定组件范围的论据之一 - 对于完全分离的团队，问题可能更糟。
- 微前端的一些实现（特别是嵌入iframe）可能会导致巨大的可访问性挑战。
虽然倡导者会说，这些不具备的情况发生，这种做法似乎并使其更容易，我们会看到这些问题。
妥协：微前端体验的范围
这些优点或缺点如何取决于您和您的情况。对于一个小型的、共同的团队和相对简单的产品，微前端坏处大于好处，而对于大型多方面产品和多个分布式团队，其好处可能开始超过挑战。
还有一系列方法可以在没有所有缺点的情况下获得许多好处。
通过坚持单一框架选择并利用像Single-spa.js这样的协调框架，您可以通过共享资源和仅下载一次公共代码来减轻大部分性能损失。
使用共享组件库，您可以消除许多用户体验不一致问题。
当然，在每一步中你都会放弃一定程度的独立性。在某些时候，您根本不再拥有微前端架构。对您有意义的切入点取决于您的产品和组织。
这有点重要 - 工程学就是权衡，而微前端为你提供了另一个可以进行权衡的维度。