如何评价字节跳动 10 月 27 日开源的 「Modern.js」？

先上结论——我支持「大而全」的体系和打造「事实标准」，但反对由商业组织牵头的，尤其是国内的。

「大而全」的体系和打造「事实标准」是相辅相成的，一个「大而全」的体系和一系列「事实标准」可以让当前混乱的 Web 前端变得更加有序，让技术深耕技术，令业务专注业务——这也是「反混沌」要做的事情。

谁来主导？

有个回答中提到——

你们都在说：前端发展太快；前端轮子太多；前端太卷。但是有没有想过，为什么同样是承担软件 User Interface 职能的 Android / iOS / 小程序技术栈，却是另一番景象 ？至少我在公司很少会听到他们关于轮子的抱怨。

原因简单，这些端技术栈都是背靠大企业/大团队，有第一方制定工程标准的人。并不是说大厂就厉害，而是说有了高度被认可的共识。注意，我说的不是制定技术标准，是工程标准，是这个技术栈下面从需求产生到产品 Lanuch 的整个标准化流程。公司可能不同团队研发多个 APP ，可能几个团队用的工程方案都是差不多的。

这位答主拿 Android、iOS 和小程序为例来佐证「制定标准需要大厂来做第一方（背靠大厂）」这个观点，我无法认同——

Android、iOS 和小程序，它们几个要么是某个平台（OS），要么是平台（应用）提供的机制，它们都是 locked-in 在某个大厂里的，而 Web 前端是吗？

另外，它们的存在就是为大厂的利益而服务，就是封闭的，而 Web 前端技术的初心就是开放的，不是为了某个大厂。

综上所述，「大而全」的体系和打造「事实标准」的事情应该由非盈利个人/组织发起并牵头主导与社区共建——不会出现 KPI 开源等情况。

Future.js

「反混沌」体系下子体系之一的「Future.js」就是「大而全」的体系和「事实标准」在工具层面的体现——没错！这个名字就是受 Modern.js 启发，把我原本在做和规划要做的一些东西进行了概念包装。

「Future.js」的含义不是它代表自己是「未来的做法」、「未来的方向」，而是「Future-oriented」，即「面向未来」。因此，它不是一个「大而全」的「框架」，而是「大而全」的、可自由组合、渐进式的生态矩阵。

「Future.js」的目标不仅是让前端开发变得有序，更是要做好前端的「本职工作」——连接（产品、UX/UI）设计与后端。在这一点上，「Future.js」的方向是「配置驱动」。

相应地，Modern.js 中提到的「范式转移」与「三位一体」在「Future.js」中分别是——

其中，与 UI 组件相关的部分由「Fxxk Design」体系负责。

更多可见文章——

Modern.js

最后，我觉得 Modern.js 要么就封装得更重些，把那些第三方的细节全部屏蔽掉，让使用者完完全全就觉得自己是在用 Modern.js 而不是在用 Webpack 之类；要么就做成一个纯粹的在线研发平台，别搞什么研发框架了。

现在来看，Modern.js 就是在一个不上不下的尴尬位置上。