共计 2896 个字符，预计需要花费 8 分钟才能阅读完成。
置信看到「Future.js」这个名字，会想起之前某厂间断开源的好几个前端相干我的项目之一的「Modern.js」——没错！就像「Fxxk Design」一样，这个名字也是受「启发」而起的，也是把一些正在建设中与布局要做的我的项目进行了「概念包装」。
从目前的理解来看，Modern.js 是要建设「大而全」的体系和打造「事实标准」。这种指标我是反对的，但拥护由商业组织牵头，尤其是国内的，应该由非盈利集体 / 组织发动并牵头主导与社区共建——不会呈现 KPI 开源等状况。
「大而全」的体系和打造「事实标准」是相辅相成的，一个「大而全」的体系和一系列「事实标准」能够让以后凌乱的 Web 前端变得更加有序，让技术深耕技术，令业务专一业务——这也是「反混沌」要做的事件。
业界现状
在 React/Vue、Babel/Webpack 等呈现并风行之前的 jQuery 时代，前端开发是「面向页面」的，并且简直没有构建工具的参加，这时的范式能够说是「手动」或「人工」——DOM 的操作和数据的更新都要写很多代码去解决。
当 React/Vue、Babel/Webpack 等流行起来后，前端开发转为「基于组件」的，不仅代码的内聚性大幅晋升，DOM 操作也不必费神了——React/Vue 这一类库 / 框架将视图构造的变动与状态进行了绑定，状态变动时视图构造就会跟着变动。
与此同时，掀起了「工程化」潮流，构建工具链越发成熟，谱写了「流程自动化」的序章——能够认为当代的范式是「半自动」。
随同着 Node.js 的问世与倒退，前端一直地扩大着本人的能力边界——从 GUI 到 CLI，从运行时到编译时，从前端到后端，甚至是跳到 Rust、Dart 等非 JS 系的语言去了……
然而，这些层出不穷的技术对于业务开发人员来说无疑是不友善的——
最间接的影响就是扩散注意力。业务开发人员的次要关注点应该是业务相干的事件，如畛域常识、业务需要的落地等，而不是三天两头的「新技术」轰炸。搞得人人都很焦虑，巴不得多买点课程抓紧时间学，连吃饭拉屎都在学！
而后就是进步了业务开发的复杂度。回忆一下当初新立个我的项目都须要做啥，与当初比照下，哪个让页面跑起来更容易更简略些？哪个呈现问题了排查起来更好找些？说实话，我听到 Babel/Webpack 就青筋抽动。
下面所列的是以后很显著很有影响的两个问题，为前端开发带来了凌乱——这是（我认为的）下一代范式要着重解决的，同时也是「反混沌」的使命——促成前端工业化过程，打造拆卸导向的工业流水线。
最近这几年也有其他人 / 团队在向相似方向摸索，例如飞冰。但它们的一些要害个性不是我想要的——锁定在某个视图库 / 框架上，并且是背靠商业组织。
Future.js
要治理这凌乱局势，有两个关键点——将零碎（狭义的）各个档次、各个环节之间的通信规范化、标准化，这就须要一个「大而全」的体系和一系列「事实标准」；足够的形象和封装，让下层业务开发人员无需太去关注具体用的是什么技术以及怎么去用，并帮他们更好更快地实现业务需要。
兴许有人会说：「都规范化、标准化了，你让那些做业务开发的还怎么跳槽？！」我只想说：「真想进步本人的话，疾速把业务需要实现之后用那省下来的工夫去参加规范和基础设施的建设不好吗？」
作为「反混沌」体系的子体系之一，「Future.js」就是「大而全」的体系和「事实标准」在工具层面的体现。
名字中「Future」的含意不是它代表本人是「将来的做法」、「将来的方向」，而是「Future-oriented」，即「面向未来」。因而，它不是一个「大而全」的「框架」，而是「大而全」的、可自由组合、渐进式的「生态矩阵」。
「Future.js」的指标不仅是让前端开发变得有序，更是要做好前端的「本职工作」——连贯（产品、UX/UI）设计与后端。在这一点上，「Future.js」的方向是「配置驱动」。
总的来说，「Future.js」外表上是一套 JS-based 的解决方案，在有些场景会借助于其余语言的能力。与「Fxxk Design」一样，该体系下的我的项目将采纳分层、低耦合的架构作为根本准则。
建设中的
最先要解决的就是配置化开发中后盾前端利用，目前与「Fxxk Design」体系相结合的局部架构为——
图中所示架构的思维在「聊聊中后盾前端利用」系列文章中曾经阐明，这里不再赘述。能够看出，整体分为底层的 Organik 和下层的 Handie 这两大部分。
Organik 是一个配置驱动，或者说元数据驱动的逻辑引擎，次要作用就是收集各类元数据，如数据类型形容、模型形容、UI 组件形容、渲染类型形容、视图形容、模块形容等，依据须要将它们进行关联生成各种上下文。
Handie 则是一个包装在 Organik 和 Petals 里面的「壳儿」，间接面向业务开发人员。其外部又分为三层——技术栈无关的 handie；连贯技术栈的 handie-vue 与 handie-react 等；将上下文与 UI 组件连贯的 @handie/bulbasaur（Vue）和 @handie/squirtle（React）之类。
Handie 的定位是「渐进式元数据驱动中后盾前端利用开发解决方案」，所以说，它反对在已有中后盾前端利用的根底上逐渐革新为齐全的配置化开发。
在上文中提到，React/Vue 通过将视图构造的变动与状态绑定，做到了视图构造的响应式更新，让下层开发人员将关注点聚焦于状态的保护。
Handie 要做到更进一步的简化——用更简略的形式从对状态的保护变为对业务规定的保护，将关注点更加聚焦于业务自身。
布局中的
前端的国土很广大，「Future.js」所处的畛域只是其中的一部分。尽管曾经做了有段时间了，但将视线拉到更远处，只能说当初仍处于「刚起步」的阶段，还有很多事件须要做。
以后的 Organik 和 Handie 再加上「Fxxk Design」中的 Petals 与 Kokiri，只做了一些三层架构中的逻辑层和体现层的事件，数据层能够说还一点没做。因而，在它们比较完善了之后首当其冲去做些数据层的工作。
在当初，光有运行时的引擎不能说本人是一个「框架」，配套设施得跟得上啊！所以 CLI 工具、脚手架、IDE 插件、装璜器等都要安顿上！
再略微往远点看，基于 Web Components 的解决方案、可视化编辑等等都要做。
看到这，必定会感觉：「咦？等等！这不就是飞冰嘛！」
哎……这就是「范式转移」带来的一个问题——范式是变了，但需要并没有变，因而要在新的范式领导下把旧的范式下做过的货色再做一遍——就像一个业务零碎用新语言或新技术重写一样。
总结
下面列举的并不是全副，拍脑袋想想，「Future.js」的边界大略就是低代码 / 无代码工具 / 平台了吧！具体蕴含哪些，要做什么，设想空间很大！但，这些都是表象——「Future.js」的实质是「大而全」的体系和「事实标准」。
那些被「新技术」轰炸焦虑得人都要变「蕉绿」的，终日喊「学不动」了的，想要晋升又不在大厂或平台类部门苦于没有机会的，还不参加到「Future.js」中来？！
治理凌乱，反混沌，不是我一个人的事儿，是大家的事儿。
我愿充当先行者！
本文其余浏览地址：集体网站|微信公众号