相信看到「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」中來？！

治理混亂，反混沌，不是我一個人的事兒，是大家的事兒。

我願充當先行者！

本文其他閲讀地址：個人網站｜微信公眾號