从微前端说起，预测未来5年大型前端项目的技术路线。

小伙伴问我 iframe 搞微前端有什么一棍子打死的办不到的事情吗?

想来想去只有一个性能问题，那就是框架组件库和全家桶无法共享，多个仅仅参数不同的 iframe 内代码重复 parse 有性能问题。那么这部分代码的复用，难在哪？

不管是作为模块引入，还是作为组件引入，不过是一个importScript('xxx').then的事情。

js 依赖关系的处理用 module federation 和 minChunkSize 就完事了。http2 + es-module 就更好解决了。

唯一的难点不过是样式隔离。

那么问题来了，凭什么样式天然它不是隔离的，难道它不就应该天然隔离吗？把样式关系转化成 js 的依赖关系，不就变成和处理 js 依赖以及动态加载一样的问题了吗？

考虑一个原子样式对于一个 Application 的本质，它就应该是一个 singleton，考虑一个复合样式对于一个 Application 的本质，它就应该是由原子样式组合而成的。

对于一个 Application，视图结构和样式同属于 view，那么它们就应该合在一起。html 和 css 本就应该是一体的，但这个一体不是 inline-css 而是组合成一个 view。

css 和 html 分离本身就是过时的设计。

那是网页 = 文档时代的设计

在网页 = Application时代，html和css是不应该分离的。

合并为 view 层，样式可以形式上依然用 css 载入，但实质上是类似 styled-component 的使用方式。

其实 emotion 才是目前最靠谱的 css 管理方案，css-in-js是正确的，因为在 Application 中，stylesheet本来就是view的一部分，用对象的方式来接入本来就是正确的。

而对于微前端，只有 css-in-js 的模块，才是可微的。市面上一些插入 html 和插入 css 的实现，总有一天会被淘汰。

同时，依赖管理是微前端的一个重要问题，那么一个应用，如果想实现模块的单独发布单独部署能力，要么 module federation 要么 es-module，在这种情况下，构建工具的 incremental-build 就会是下一个需要解决的痛点。

在所有工具链齐全的情况下， single-repo 可做的显然比多仓库来的更多。多仓库意味着人肉依赖管理或基于webhook的依赖管理。而 single-repo 获得了完全的依赖管理和打包优化能力。

但同样， single-repo 也大大增加了分支管理的难度，增加了代码冲突的几率，对代码架构提出了更高的要求。像现有大多数开发者习惯的在组件里写逻辑，肯定是无法应用在 single-repo 下的。

前端项目采用的全局状态管理和全局分层，而不是 DDD 设计，也必然是与前端模块的“可微”性质相抵触的。

未来5年间，大型项目前端开发会发生（包括但不限于）以下变化：

面向视图开发 -> 面向model开发
面向组件开发 -> 面向接口编程
全局状态管理 -> 分形服务注入(依赖注入)
model,view合并部署 -> model,view分别部署，view层开发一定程度上可视化，设计/产品直接接入workflow，与开发工作在同一个 codebase 下
基于组件的粗粒度复用（如antd） -> 视图和逻辑分别复用（如react-spectrum）
多 git-repo -> single-repo

TotooriaHyperion / blog