關於下一代前端框架的一些我的想法

斷斷續續想了一個多星期, 想不下去了, 索性寫成文章看看對別人是否有用吧.
中間有好多我不知道怎麼解決的問題, 工具鏈不成熟, 特別是我的能力不夠.
問題是, 下一代的前端框架的是怎樣的, 我如何實現出來?
我原來在想 Facebook 搞 ReasonML 了, 新語言很重要, 那麼我應該努力學,
然而仔細想一想, 問題沒那麼直接, 咱們真的須要那麼強大的語言嗎?
Haskell 甚至 Idris 已經把問題研究到那樣的強大了, 但是對於前端用得着嗎?

須要解決的問題

翻看公司局部的業務代碼, 我注意到邏輯代碼的比例很小, 須要類型驗證的並無那麼多,
一個頁面當中大部分的代碼其實是 CSS, 樣式代碼, 樣式的細節不少,
並且因爲 CSS 天性上抽象能力不夠, 加上業務確實有大量的不一樣, 細節不少,
結果咱們有不少手寫的樣式. 而後是的 HTML 部分, 或者說是 DOM 的描述,
相對而言, 定義組件狀態, 訪問請求, 同步數據到組件狀態, 花費的代碼很小,
並且 UI 須要調試, 從設計稿到最終網站上線存在不小的重複工做.

拋開前端代碼, 當你想要作個簡單的手機頁面, 首先須要的是設計,
先用設計規範好頁面每一個細節, 而後增長交互的能力. 最後提交給用戶.
或者說就像是作一個海報, 打印不少份而後貼出去, 沒有大的區別,
而如今的問題是有交互, 直接打印是不夠的, 就須要人力一點點堆出來了,
人力嘛, 畢竟遠遠比不上機器來的可靠和高效. 可是如今畢竟機器作不到.

極端理想的網站上線流程, 也就是去掉全部重複的機械工做, 只留下須要人作的部分才投入人力,
須要人力的有:

• 定義需求

• 優化視覺(某種程度上將來人工智能也能夠完成一部分)

• 增長基本一些交互

• 增長複雜的交互

• 驗證網站的可用性(部分 UI 測試能夠由測試方案完成)

設計師完成了界面, 而後再程序員用代碼寫一遍, 這是最明顯的重複勞動.
因此天然目標就是用軟件生成界面, 也就是類比以前問題到的 Lottie,
用交互軟件製做好動畫, 導出 JSON 文件, 而後在平臺上用代碼重現出來,
某種意義上網頁上咱們須要的也是如此, 用一個軟件去編輯出來,
而後導出 JSON, 最後頁面上根據 JSON 直接生成網站. 界面作好就行了.

難點: UI 能力有限

這個思路你們都知道, 但順着這條路想下去, 難點也會很明確,
總有不能用圖形直接描述的部分. UI 很容易, 但涉及到邏輯怎麼辦?
編程當中的問題每每是用數據類型和操做模擬問題自己, 而後用計算解決,
也就是說用來模擬的方案一定包含和問題自己那麼大的複雜度.
因此那些包含了複雜邏輯代碼, 用 UI 表示出來依然會同樣地複雜,
真正用了 UI 而簡化, 只是本來抽象不方便調試的 UI 部分.

明確這一點以後, 那些網絡相關的邏輯代碼, 或者狀態相關代碼, 好比剝離,
或者說跟狀態和操做相關的功能, 不該該用界面去生成, 仍是要手寫,
那麼混雜在 HTML 當中的邏輯了, 好比 if, each 這之類的?
固然還有的 filter 之類的, 提及來可能比較含混, 可是跟 MVVM 多少能夠對應.
MVVM 當中大量概念都抽象到相似 HTML 的語法上去了, 貌似很簡單.
在內部, 至關於從新定義了功能. 和 React 那樣嚴謹的方案有很大差異.

順着想下去, HTML 當中邏輯少不了, 那麼結果面對的是相似模板引擎的寫法,
或者說相似 Vue 的 template 部分的寫法, 這是適合用圖形界面來表示的.
同時樣式部分天然而然很容易對應到圖形編輯的屬性操做工具上去.
最終剩下的就是 data, computed, method, filter 這些概念的邏輯定義.
因爲 UI 表達能力有限, 那些邏輯最終仍是代碼的形式去表述更爲合適.

因此在這個階段面對的問題就是如何, 這個 template 用界面去編輯,
用圖形界面的方式來編輯圖形界面, 顯然是設計師慣用的解決方案,
在此以外, 咱們要引入屏幕尺寸和 Store 相關的代碼, 以便工具可以被使用,
也就是說, 即使是生成的, 它最終獲得的就是前端製做的網頁的渲染效果,
可以響應屏幕的尺寸, 可以根據 Store 內容不一樣渲染不一樣頁面,
也就是用圖形工具來編輯模板引擎, 最終生成代碼可用的模板引擎及其樣式.

難點: 如何組件化連接 UI 和代碼

思考到模板引擎這一步, 能夠認爲用圖形工具是能夠替代模板引擎的功能了,
可是對於真實的程序來講, 特別是面對狀態管理, 固然是不夠的,
好比說子組件的菜單選擇後, 修改父組件狀態, 從而實現菜單選擇的功能,
這裏就會遇到狀態管理, 並且在實際應用當中難以免, 甚至會有更復雜的場景,
咱們能夠作到的複雜組件由開發人員製做, 而後用圖形工具使用, 但狀態管理少不了,
特別是還會存在表單和頁面組合使用的狀況. 表單當中的狀態更不會少.

除了之間內部的狀態, 另外一部分是全局狀態. 也就是須要 dispatch action.
其實處理 dispatch 相對較容易, 由於 action 已經很好地進行了解耦,
解耦以後代碼能夠獨立出來開發, UI 部分和 reducer 或者說 updater 是分開的,
這裏的問題主要在於如何模塊化. UI 部分是一塊兒開發的, 邏輯又是在一塊兒開發的.
注意我並非想在圖形工具當中強行寫代碼, 那麼弊大於利,
寫邏輯代碼仍是應該用文本編輯器, 目前沒有特別合適的其餘選擇.
而這樣代碼和邏輯實際上的是分開的, 須要想辦法分析出來, 進行模塊化.

因此某種程度上咱們須要很強大的編譯器, 來分析代碼的, 處理模塊之間的關係.
我理想化的目標是界面需求用圖形工具完成, 大體對應設計或者產品的角色,
而後由好比 API 開發人員來綁定 API 等操做, 至關於服務器開發人員,
而後中間依靠強大的編譯方案, 保證兩方的合做可以銜接到一塊兒.
同時, 方案須要組件化, 由於有些組件必然靠跨越業務共用的, 不然也損害到效率.
這樣推演下來, 強行脫離代碼首先致使了組件化方案不能靈活使用的問題.

難點: 調試

不方便調試這個問題應該比較好理解了, 設計的方面太多, 定位問題也就更難.
Vue 出現過這樣的問題, 因爲設計了不少 DSL 須要自行解析, 細節很繁瑣,
相對而言, 純粹代碼的描述的 React 能夠直接藉助 js debugger 定位問題,
若是爲了實現圖形化工具引入更多的抽象層級, 調試勢必會成爲大麻煩,
咱們能夠想辦法說打印更多規範化的 log, 增長本身實現的 validation 之類的,
可是調試的麻煩對於效率的傷害仍是很不小的. 確定不會輕鬆了.

結尾

整個方案核心的想法是用圖形工具來修改一個模板引擎之類的 DSL,
這個 DSL 能夠被用在生成 HTML 和更新 DOM 操做, 也就包含一些簡單的邏輯,
理論上作個圖形工具來對於其功能, 也不是多大的問題, 模板引擎自己並不難,
難的地方在於狀態管理難以用圖形工具完成, 最終仍是依賴代碼編輯器,
而這樣以後, 組件化和文件連接等方案面臨重重困難. 一樣也影響到後續的可靠性.
因此結果呢, 卡在這個地方不知道怎麼辦了. 暫時就想到這裏.

爲何說是"下一代前端框架"呢? 比前端這一代好在哪裏? 爲何好了一代?...固然這個東西造不出來的話連可比性都沒有, 如今不就沒造出來麼.只是從推演上說, 前端要解決的問題主要就是網頁的開發效率,從早先的服務器渲染, 到前端模板渲染, 到聲明式渲染, 到同構渲染,這一路走下來改變了不少. 重點就是在開發速度使用體驗上交替改進.而微調界面一直都是前端開發當中的麻煩事, 並且阻礙了設計師獨自發網頁.我認爲, 若是能用圖形工具直接生成出來, 對前端開發來講是有巨大的跨越的.屆時設計師/前端/後端之間的分工也將會發生一些變化. 有點意思.