摘要：前面不短時間持續(xù)投入了時間在做應用架構(gòu)方面的考量一個是冒險進行了一次應用架構(gòu)的調(diào)整另一個是跟進了的進展當然實際上是同一個事情也許錯過的比收獲的還多一些不過能走到現(xiàn)在也算幸運了畢竟單頁面應用還面臨很多不成熟之處國慶長假過去不少現(xiàn)在的想法估計會

前面不短時間持續(xù)投入了時間在做 React 應用架構(gòu)方面的考量
一個是冒險進行了一次應用架構(gòu)的調(diào)整, 另一個是跟進了 Redux 的進展
當然, 實際上是同一個事情. 也許錯過的比收獲的還多一些
不過能走到現(xiàn)在也算幸運了, 畢竟單頁面應用還面臨很多不成熟之處
國慶長假過去不少現(xiàn)在的想法估計會淡忘了, 所以好歹留點筆記

我昨晚因為要修 Todolist 特意看了下 Wunderlist 里的拖拽效果
iPad 上搜 Todo 的時候還看見了上家公司 Appest 的應用
當時大概就是被 Backbone 折騰得身心俱疲, 也算挺無助的啦
還有老板 Facebook 的朋友來分享, 可惜跟 React 團隊關(guān)系不大
想想 Todolist 依然是單頁面的標志性的應用, 各種 TodoMVC 層出不窮

大致兩年的時間, 社區(qū)的變化很不小了, 現(xiàn)在到處都是 React
除了 React Angular 其他的框架很少說, 特別 Backbone 幾乎沒影了
Vue 的作者分享的也都是 Meteor, 總之很多的概念都已深入人心
不過不變的大概是每年都會冒出大量的框架出來, 都不想去聽了
我參與社區(qū)的熱情也降低了, 也就論壇微博 QQ 群看人扯扯淡而已
時間也都放到公司產(chǎn)品還有自己的技術(shù)探索當中, 也沒從前那種激情

一方面是工作久了, 接觸多了, 自己獨特的想法越來越少
無論想到什么, 都能想到說哪個新聞有提過, 而且已經(jīng)很成型的想法
而且也來越認識到底層原理的重要性, 漸漸苦惱算法跟編譯原理沒學好
雖然我也不指望學校能教好. 然而隨著框架規(guī)模擴展, 少不了這些技能
或者僅僅是工作多了, 創(chuàng)意少了, 人變得圓滑, 或者成熟, 之類的

最初學習 Backbone 的時候看到 MVC 和 MVVM 這些詞覺得高大上
后面翻多了資料, 發(fā)現(xiàn)存在 N 個版本的實現(xiàn), 概念都開始變混淆了
結(jié)果我又不肯花大工夫研究一遍每一種實現(xiàn), 最終看起來依然挺模糊
只是當初 MVC 常常說的是數(shù)據(jù)和模板引擎分離, HTML 和 CSS 分離
有了 Virtual DOM 以后整個似乎變了, 是數(shù)據(jù)和 DOM 分離

原本是 Backbone 和 Handlebars 糾結(jié)著的組件復用問題
本來, Web Components 規(guī)范已經(jīng)讓人歡欣鼓舞了
誰知道了 Polymer 折騰了好久, 只是圍著 Google 自家搞得火熱
社區(qū)里遲遲沒進展, 很快風頭被 Facebook 搞出了 JSX 搶光了
Twitter 上 Polymer Summit 好像還蠻熱鬧, 但我們好像就沒動靜

不過 React 軟肋還蠻明顯, 白天還聽同事說 Angular 的 Service 怎么完善
反觀 React, Flux 基本上被否了, 單項數(shù)據(jù)流的 Redux 成了熱門
然后呢, 開始對付網(wǎng)絡問題, 立馬分裂了, Relay 跟 Falcor 都不知道怎么跟
雖然單向數(shù)據(jù)流的原則已經(jīng)明確, 但是這種流中間各種異步怎么整
而且一下子連數(shù)據(jù)庫的奶酪都要去碰, 甚至牽涉到 N 種語言的開發(fā)實現(xiàn)
說實話我真不知道我們的數(shù)據(jù)層代碼怎么寫才是對的, 兩個方案都不能直接用

我在圍觀 Clojure 社區(qū)稀奇古怪的發(fā)明的時候, 總有種張牙舞爪的感覺
晚上看 Om 作者演講, 就說著 Relay 怎樣, Falcor 怎樣, Datomic 怎樣
然后前面兩個方案都否掉, 或者只是覺得不好, 開始大肆介紹 Datomic
然后就是 PHP 社區(qū)跟 Node.js 社區(qū)接受 Clojure 社區(qū)背后調(diào)戲的感覺
我也分辨不出來怎么才是對的, 然而總是覺得什么方案可肯定是存在問題的
無論 Relay 介紹自己的時候說自己怎么好, 換個社區(qū)就挑出很多刺了

從大體上說, 單頁面應用演進的方向還是明確的, 客戶端緩存同步數(shù)據(jù)
這個數(shù)據(jù)會越來越大, 需要在客戶端有數(shù)據(jù)庫管理, 當然客戶端已經(jīng)這么做了
單頁面應用能上不著天下不著地吊了好多年, 終于瀏覽器性能開始跟上
所以一個方向是整個客戶端方案在瀏覽器當中重新用 JavaScript 造一遍
另一個是服務端渲染跟客戶端渲染無縫銜接, 一邊打開應用一邊下載數(shù)據(jù)和代碼
對于二十年前設計的的語言來說, 硬件升級都變天了, 真夠嗆的

Web 這個奇葩的平臺. 像 React 的代碼熱替換橫掃三個平臺的事情, 誰都想不到
本來還是編譯半天, 連前端開發(fā)應用刷個很多秒, 前端建構(gòu)分鐘算的
突然一下子代碼熱替換又起來了, 還助推了一個很難上手的建構(gòu)工具
現(xiàn)在說 Webpack 已經(jīng)能搜到很多教程了, 連移動端開發(fā)都沾上了邊
我還很短的代碼山寨完 Redux 和 redux-router, 自己都驚訝了
這些東西放在兩年前完全不會這么想, 也就當蘋果設計師膜拜膜拜就完事的

因為開發(fā)的需要, 所以一直在追 Chrome 開發(fā)者工具新功能
相信每天看幾百遍的同學看到里邊多個奇怪功能心情跟我類似
每年 Addy Osmani 都放幻燈片和演講出來介紹, 晚上剛看新的幻燈片
能看出來前端開發(fā)對細節(jié)的要求已經(jīng)越來越精細了, 以及性能上關(guān)注
我在這方面大概剛起步, 只是開始初步對付過 React 組件優(yōu)化的坑
做了一輪以后對 Chrome 開發(fā)工具的感想又上層了一個臺階, 功能太多

在最初學前端的時候動畫是給我提供動力的主要的因素, 因為好看嘛
然而說回到和游戲比起來, 應用當中的動畫是小兒科了
我也看 Dribbble 上悶騷的人做的很多嚇壞程序員的 motion
或者看看 Mathbox 作者甩一堆的不知道超前幾年的動畫
還有特別震撼的有人在 VR 當中用 ClojureScript 和 Unity 搞的 live coding
應用里的動畫真是小兒科了, 而且偏偏已經(jīng)很小兒科還那么難寫
然后是各種兼容性問題, 或者奇葩的組件化問題, 我都不知道在干些什么

跟動畫同樣郁悶的還有拖拽這種無比自然的交互方案
當然, 更自然的是 Hololens 或者更早的第六感科技的手勢捕捉技術(shù)
總之, 在桌面瀏覽器上一般是沒有的事(這個也許是工作范圍的原因)
我到昨天細看了 Touch Events API 才了解兩者差別究竟怎樣
我已經(jīng)完全覺得鼠標是個技術(shù)不足的時代的替代品了, 或者行業(yè)專用
有筆刻畫細節(jié), 有手勢快速交互, 為什么要用帶線的盒子在桌上摩擦

我回頭以短暫散亂的經(jīng)驗揣度, 開發(fā)單頁面應用需要投入研究些什么?
(1 怎樣管理大量的數(shù)據(jù), 瀏覽器中主要是緩存怎樣管理?
(2 怎樣處理異步的數(shù)據(jù), 瀏覽器中主要是請求和推送怎樣設計?
(3 怎樣做界面組件的抽象, 瀏覽器對應 Virtual DOM 和 CSS 怎樣拆分跟組合?
(4 怎樣豐富交互方式, 瀏覽器有點擊, 輸入, 文件拖放, 拖拽等等?
(5 怎樣設計好動畫, 現(xiàn)在這樣 DOM 動畫依靠各種類庫的情況下?
(6 上面的事情都做了, 然后性能跟兼容性怎么辦?

考慮到目前前端生態(tài)的混亂, 我認為開發(fā)新工具來對付問題很重要
然而不管是跟進他人的開發(fā)工具, 或者自己創(chuàng)建新的工具, 都非常困難
前面微博盛傳, 前端建構(gòu)工具兩三年已經(jīng)換的第三茬了
不過看看現(xiàn)在這茬, 被人吐槽配置太復雜啊, 很奇怪啊, 估計還得換
社區(qū)呼聲最高的編程語言了, 版本都刷到 2015 了, 語法很多認不出來的
而未來的方向呢, WebAssembly, 我記得 ASM.js 才不久前的事情對吧
聽說 LLVM 后端已經(jīng)能生成了, 也有 C# 和 OCaml 的初步實現(xiàn)了

我大致覺得新技術(shù)有三個來源, 搞研究的, 為了團隊里方便搞特殊的
還有明擺著是搞山寨的. 第三種主要是學習目的, 點個贊鼓勵下就算了
前兩種會是重要的模塊的來源, 只是前者容易理想化, 后者容易特殊化
實實在在開發(fā)出來, 同時自己團隊能復用的, 比最初估計的少太多了
操作系統(tǒng)的代碼, 還算能廣泛使用, 然而開發(fā)成本一降 N 個 Ubuntu 就冒出來了
對于前端的組件, 各種角色的人都能挑挑揀揀, 重用代碼的情況更需要考慮

我主要想說, 到后邊自己開發(fā)新東西, 新技術(shù), 必不可少的
當然, 從理論層面說, 或者僅僅技術(shù)層面, 也不是真的嶄新的技術(shù)
世界上排除掉山寨語言的幾百種編程語言, 就是各種不同場景的取舍導致的
需要 A 語言的 b 特性, 需要 C 語言的 d 特性, 大量的取舍和權(quán)衡
所以單頁面的渾水, 幾個巨頭好像全摻合進來了, 每個的方案還都不一樣
當業(yè)務中需要一個功能, 跑到 React 的 Issue 列表去跪求, 不如自己做一個

我說這些的重點是, 并不是要用自己開發(fā)的技術(shù), 而是要有那個能力
就像美蘇冷戰(zhàn)要極力避免使用核武器, 然而沒有能力開發(fā)核武器就敗了
在這種時候才突然想起來算法不好, 編譯原理不行, 各種被大神耍著玩
社區(qū)一下開發(fā)新的數(shù)據(jù)結(jié)構(gòu), 一些給編譯器加語法, 過天換種編程模型
兩年時間從 Backbone 到 React, 以及語言, 模塊化, 改了一大片
更郁悶的是自己的能力遠遠不如那些朝三暮四改方案的框架開發(fā)者們
Angular 已經(jīng)改一大片, 如果 React 有一天也改了, 我沒辦法只能乖乖的

太年輕了, 看未來還是很迷茫的, 而且 VR 一出, 開發(fā)平臺也能改一大片
今年 Google IO 上有個分享也介紹過了, 連 Design Guidelines 都出了
我印象比較深說 VR 跟屏幕不一樣, 用戶可以隨意轉(zhuǎn)動移動的, 很難控制視野焦點
而且還要避免各種物體或者運動造成不適感, 還不能把人初始化在物體內(nèi)部
我記得 Mozilla 已經(jīng)有技術(shù)試驗 VR 了, 似乎相關(guān)標準有在推進?
這樣的發(fā)展速度作為用戶蠻開心, 作為程序員我覺得壓力恐怕不會小

我個人觀點, 在界面組件化方面 React 的 Virtual DOM 算是打贏這仗了
而它不擅長的數(shù)據(jù)加載, 還有動畫, 依然存在巨大的想象空間
換個說法, 存在巨大的坑... 所有人走到這里, 要么繞不過去, 要么找別人搭的橋
至少對于單頁面應用來說是這樣, 而且 Meteor 跟 Famo.us 兩座大橋
想想排列組合 famous-react, react-meteor, meteor-famous 挺滑稽了
然而誰知道我得在這個坑中間晃蕩多久呢, 到處是所謂新技術(shù)

短期想的還是跟進技術(shù), 同時加強一下基礎吧, 特別是覺得 JavaScript 搖搖欲墜了
重要的是單頁面背后的數(shù)據(jù)庫原理, 數(shù)據(jù)界面方案, 編程語言底層, 總不至于松動
偏偏這些東西好像是在張牙舞爪的 Clojure 社區(qū)的人手里攥著, 而且不夠?qū)嵱?br>David Nolen 每個演講我都有興趣聽, Rich Hickey 的更加是必須聽
對了 StrangeLoop 2015 大會總共超過 70 個視頻, 怎么可能看完!

全文完. 隨想帶了不少吐槽, 也不嚴謹, 考慮涉及那么多術(shù)語也很難寫清楚了
有興趣的糾錯的同學只求不要寫得像我這么粗略