基於熱替換技術推想將來的 Web 開發技術

微博上寫了幾段, 想一想太長, 仍是寫成文章發出來, 這事對我還挺重要的
本來是在反思本身爲何興趣所在的前端項目竟然蔓延得那麼廣
甚至致使技術不專注, 不少細節作很差. 其中的緣由何在? 我認爲前端太廣
因而想到總體發展的趨勢上, 因而認爲背後還在更深層的事件
按這點進行推想, 也就是站在熱替換這點往前眺望, 有種可能性
背後的想法已經挺長時間了, 臨時想到整理成文章

文章章節拆分:

• 熱替換技術的現狀

• 後端熱替換的能力

• 熱替換的要求和限制

• 推想一種將來的開發方案

• 須要着手填補的短板

• 總結

熱替換技術的現狀

這是 Elm 和 Webpack 燒起來的很旺的一把火, 隨着 React 燒得更遠了
很快你們看到對於前端 React 應用, 或者 React Native, 都有了
這種狀況下能夠一邊寫代碼, 而且預期在模擬器當中直接查看改變
若是代碼有錯, 可能作到直接把靜態檢查的錯誤直接提示出來
那麼開發人員直接修復錯誤, 直到代碼正確, 代碼進行熱替換

目前熱替換, 前端方面有 Browserify, Amok 之類, 而 Webpack 支持前端後端
在 cljs 方面基於 boot-reload 能作前端, 基於 figwheel 作前端後端
Elm 能作前端, 只不過不像是前二者那麼通用
而 Webpack 和 cljs 我在過去幾個月作了幾回嘗試, 效果是能夠的
我最多作到在阿里雲跑開發環境, 遠程編輯, 前端後端熱替換, 直接加功能

前端熱替換主要基於 MVC 分離的思路, View 與 Model 分離, 能任意調用
全部的界面數據, 要麼做爲 global Store, 要麼抽象爲組件 states
只要保證 store 和 states 能在替換代碼過程當中能保持, 就有整個界面
而 View 代碼想要替換就替換掉好了, 替換完成從新運行就行了
方案主要基於 React 和相關有 virtual DOM 框架. 其餘 Vue 也能夠

另外 Time Travel Debugging 還有存儲每一個數據操做方便重演的機制
相關的資料較多, 應該已經都注意到吧

後端代碼

好比 Webpack 也能作後端代碼的打包和熱替換
也就能作到在 WebSocket 不關閉而狀況下直接替換代碼
所以結合兩點以後, 實際上已經能作先後端同時熱替換代碼
好處就是不須要整個重載程序, 從新鏈接 WebSocket, 更快更方便

我後端經驗很少, 前面試驗的代碼是用前端 MVC 的思路寫的
也就是抽象出內存中的一份 Database 做爲個人 Model,
同時把客戶端對應的 Store 做爲 View, 而 View 是容易替換的
那麼代碼更新過程當中, Model 不受影響, View 部分輕鬆替換
Webpack 替換的代碼是局部的, 因此說 WebSocket 不受干擾

以前問過, 後端開發對熱替換彷佛興趣不大, 畢竟自己就作了解耦
數據都在 DB 當中, 不受程序的重啓而影響, 因此整個重啓就好
因此說不受影響, 即使生成環境全部服務器進程進行重啓, 也正常
我以爲這種方式畢竟, 各類 IO 都要從新建立, 有點開銷, 並且有點慢
再者, 有 WebSocket 的話, 仍是須要方案來保證 WebSocket 穩定

熱替換的要求和限制

對於 React 來講, 熱替換比較明顯的問題在 states 處理上
因爲 React states 是私有狀態, 不像 Store 管理起來方便
不過這是個老問題, 我也明確了是有解決方案的, 好比設計全局組件狀態
能解決就很少講了

而後是熱替換對程序狀態的影響, React 中而錯誤代碼會致使進程沒法繼續
緣由就是代碼錯誤, 致使 React 內部記錄的狀態出錯, 於是程序故障
這也是已經有辦法的, 主要是靜態檢查, 在程序執行之間作一次篩選
作得好的好比 Elm, 能分析到具體的類型, 最終能編譯經過就很難報錯
我沒寫大的 Elm 程序, 而是用 cljs, cljs 的變量檢查已經比較實用了
基本能明確類型設計得更舒服, 在這一點上會明顯改善

對抽象的影響, 這就涉及到編寫程序時整個程序如何設計的問題了
React 帶出的 pure render, stateless, 跟這個直接相關
爲了程序能更好地熱替換, 其實要求了更嚴格的對反作用的限制
好比渲染代碼會在代碼替換時被執行, 那麼就不能隨便插入數據操做在其中
也就是限制反作用, 而讓無狀態因此可替換的代碼能直接更新掉
因而不少從前的開發習慣就須要轉變思路

性能方面, 熱替換自己彷佛問題不大, 畢竟 Erlang 用了也仍是快的
可是在 React 這樣的方案觀察下來, 因爲用了函數式寫法, 就可能有問題
函數式編程首先經過不可變數據和高階函數造成了對內存的壓力
而這在 virtual DOM 方案當中, 又是很難消除的因素
性能問題和明瞭, 也是你們共同的問題, 很少講

一會兒能想到的限制就這些, 估計還有很多瑣碎的問題

推想一種將來的開發方案

在熱替換基礎上, 我嘗試的開發方式已經和以前有不小的區別了
除了前端的熱替換, 我還把後端聯繫到了一塊兒, 讓後端控制 store
因此我能夠在改一段後端代碼, 直接發送 diff 到前端, 界面直接更新
也就是說能作到動態修改 View 代碼, 而網絡鏈接, 瀏覽器頁面狀態都不受影響
Controller 代碼也能更新, 但須要經過其餘方式從新運行查看結果
Model 因爲存儲了程序的狀態, 處理起來會更復雜, 須要記錄每一個操做
大致上是這樣.. 至關於 React 的效果, 對多個客戶端也生效

我想說, 還能走得更遠. 我但願是, 能作到不少人同時一塊兒開發
對, 多人同時開發同一個項目, 而不是每一個人拷貝一份本身開發再 merge
好處應該想得差很少, 新人來了開發環境不用單獨配, 省不少時間
一塊兒作, 相互能熟悉工做內容, 相互也能監督, 下降交流成本
當一個功能有多人同時作, 開發速度也能提升, 相比一我的作不一樣的細節

想法很簡單的, 但如今都沒作起來, 顯然難點有不少
首先, 即使在服務器上用 Vim 或者在線工具編輯, 多人操做也不方便
其次, 不一樣的人寫的代碼相互衝突了怎麼辦, 怎麼開發下去?
一我的寫完了一部分, 重啓服務測試, 影響到另外一我的正在測試怎麼辦?
雖然有其餘問題, 但我認爲影響最大是這些問題

首先多人編輯, 印象裏有看到新聞有在嘗試, 估計不成熟, 待會再回頭說
可是代碼衝突, 功能調試, 我想熱替換已經給了不錯的解決方案了
代碼衝突首先能夠依靠類型靜態分析幹掉不少, 作到代碼有問題不去運行
熱替換技術當中單個文件的類型分析很廉價, cljs 中也算成熟了
而功能測試, 因爲不須要重啓服務器, 相互直接也就少了不少的影響

另外有一點, 熱替換要求程序嚴格控制反作用, 有另外的好處
在 React 而言, 這要求應用的結構, 組件的模塊化, 作得更加嚴格
結果是你們寫的 React 組件抽象出 state, 抽象出渲染方法, 其實相似
而這有利於編程思路編程規範相互之間少一點分歧, 讀代碼更容易

須要着手填補的短板

如今熱替換直接上, 作多人協同編程, 有些難度, 我只是以爲能夠一試
就 React 而言, 我認爲對錯誤的容忍性過低, Flow 或者 TypeScript 應該更好
個人話是 cljs, 雖然不能避免全部錯誤, 但變量檢查已經能幹掉好大一部分數量
我以爲這些主要是加固吧, 爲了讓調試過程更加增量, 影響範圍也更小
多說一句, 我認爲須要引入 Haskell 系的強大類型系統來幫忙, 山寨一個也好
ADT 完整的實現確實門檻高, 可是其中實用的地方拿過來總能夠吧...

編輯器的問題是大頭, 首先就是先後端分離, 跑在服務器上, 瀏覽器端操做
而後, 每一個修改須要是增量的, 這樣方便同步到大量的客戶端
而且, 操做合併應該只有極少甚至沒有衝突, 不然實際操做會很繁瑣
在就是 UI 上要作不少的改進, 講多我的的狀態顯示出來
的以我目前在單頁面的探索來看, 這個事情可能性是達成了的, 雖然難度很多
我能夠基於 Cirru 先搞出這樣的方案來, 先試驗一下效果如何

另外類型檢查, 也是個能改進的地方, 注意到嗎, 類型檢查都打 log
爲何類型檢查不能直接在編輯器上提示, 而後給個選項一鍵糾正?
編輯器是基於文本的, 並非基於圖形界面的, 我估計這個事情麻煩了
若是 IDE 都是像 CSS 這樣用樹形編輯器操做, 我想也許就好多了
而這同時也是前面說的增強類型檢查功能所遇到的問題...
想法還不成熟, 之後再想一想

總結

基於上邊這些討論, 我認爲熱替換帶來了不小的突破的機會多人協同編程的某些障礙, 已經由熱替換技術掃平了, 成了相對次要的問題若是能讓編輯器支持多人開發, 距離多人協同編程就很近了我以爲能夠在 Cirru 上繼續探索一下...如今都已經能直播寫代碼加在線熱替換了, 再開發出編輯功能如何?