微前端产生的历史背景和作用
本文转载自 知乎-深海潜水员，如需转载，请注明来源
2009年催生了web前端这一新专业。这一年出现了很多新变化，NodeJS的出世，JavaScript开始涉足后端。这一年，AngularJS的发布，给spa项目带来革命性指令时代，不仅大大提高了生产力，还带来了模块化，项目可维护性大幅提高，为云平台技术等大型软件在前端上提供了很好的技术支撑。但同时也要求更多专业人士做这些事。
2011年React出现以来，带来了虚拟dom、模块标签语义化、jsx编程，fiber调度等技术和思想，模块化编程更简洁，更能代表技术发展的方向。React最大优点是标准化、体系化，编程体验应该说是当下最好的。
2012年webpack诞生了，目的是解决打包JavaScript多模块编程的Code Splitting，通俗讲就是对模块的chunk处理。webpack使spa项目的性能得到了较好的管理。webpack在2014年加入热更新功能，开发体验也有了较大的提高。webpack为解决性能加入tree shaking等等，为解决打包慢加入的cache、TerserPlugin等等
2014年结合angular和react等之长产生了Vue，新版本vue3同样借鉴了很多React16的函数式编程思想。Vue绝对称得上是吃百家饭长大的孩子，入门简单，发展的很好。
随着SPA大规模的应用，紧接着就带来一个新问题：一个规模化应用需要拆分。
一方面功能快速增加导致打包时间成比例上升，而紧急发布时要求是越短越好，这是矛盾的。另一方面当一个代码库集成了所有功能时，日常协作绝对是非常困难的。而且最近十多年，前端技术的发展是非常快的，每隔两年就是一个时代，导致同志们必须升级项目甚至于换一个框架。但如果大家想在一个规模化应用中一个版本做好这件事，基本上是不可能的。没办法，我们只能忍受一次次地狱般的改造过程。
最早的解决方案是，根据功能主要模块拆分规模化应用，子应用之间使用跳转。但这个方案最大问题是导致页面重新加载和白屏。
那有什么好的解决方案呢？微前端这样具有跨应用的解决方案在此背景下应运而生了！
2015年thoughtworks这家公司的前端者，提出了一个比较靠谱的方案：single-spa。
微前端从原理上讲，并不是特别难以理解。
首先需要在微前端接口上注册各个子应用入口配置，最核心的包含2个部分：
加载应用程序的代码，可以是子应用的入口js或html
确定应用程序何时处于活动状态/非活动状态，要求每个子应用对应不同路由
single-spa经过上面配置后，它内部劫持了每个应用的不同的路由，根据activeWhen状态控制子应用是否需要响应。这样就实现跨子应用的调度。
single-spa核心是对子应用进行管理，但还有很多工程化问题没做。比如JavaScript全局对象覆盖、css加载卸载、公共模块管理要求只下载一次等等性能问题。
产生很多基于single-spa二次开发的微前端解决方案。比较出名的就是qiankun、Isomorphic Layout Composer。
微前端作用其实与SPA功能一样，解决了跨应用的白屏问题。同时，微前端解决了在规模化应用中，方便拆解为多个相对独立的子应用，并实现独立部署每一个子应用。 这套机制对子应用的控制跟微服务有很多相似之处，所以起了一个很相似的名字，有意抱微服务的大腿。
现在只要提前规划好，当大型项目改造升级时，改动任意一个子应用，对其他子应用完全没有影响，也就非常容易了。
微前端在性能和用户体验上与规模化应用对比如何，关于这一话题留待下篇 微前端优缺点及应用场景 分解。
参考：
相关文章
评论 (0)
- 还没有评论，来第一条吧。