一我的的 ClojureScript 技術棧

做者：題葉
連接：https://zhuanlan.zhihu.com/p/24425284
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

今天(昨天)分享完關於 ClojureScript 的話題, 算是如實重負. 我嗓子很差, 以前分享過 React, 但相比在網上老是差不少, 此次分享也是緊張, 會場的 Keynote 沒有按照預想放在挺高的地方, 也沒有下一頁的預覽, 看着大屏幕銜接沒作好. 可是說真的內心仍是忐忑的, 提問的同窗很犀利, 幾個都在點子上, 關於 Redux 還有深度傳遞的屬性, 以及全局 state 問題, 其實我並無想清楚, 我有本身的方案, 但並無足夠說服別人的方案.

實際上個人角色是轉述國外社區的方案, 而後加上我本身的理解來強化對於技術的解釋. 通過一層轉述畢竟是很差的. 提問當中相關的問題, 其實 David Nolen 都提出過方案, 全局 state 和相似 GraphQL 的問題. 我沒吃透卻是真的. 有機會仍是建議去 Youtube 上刷一遍大會上關於 ClojureScript 的視頻.

我有信心篤定函數式編程是對的, 首先國外已經有人實踐了, 其次我本身使用下來感受可靠. 主流前端不看 Clojure 大會的視頻, 其實不多有渠道報道可以獲知報道的. 我由於當初挖 React 和 Haskell 的緣由專門去看了, 因此我知道. 顯然國外也不是稀罕事. 可是在中文技術社區就不多這方面的聲音, 更不用說閒着蛋疼去寫 ClojureScript 代碼了. 但我須要. 我以前推廣 React 結果面對那麼多期待以外的複雜度, 我亟需一個解釋, 我須要找到本身的支點和方向. 維護和平, 防止本身世界觀崩潰.

個人世界觀確實蠻脆弱的, 跟不少從小鎮進入大城市上學工做的人同樣, 整個過程就是世界觀瓦解和重建的過程. 到了編程也差很少, 從最開始 CSS, 到會寫代碼, 到發現編程範式, 到挖函數式編程的歷史, 我花費了好大的力氣避免本身崩潰. 我應該是很少的身爲 JavaScript 程序員, 卻長時間混跡 Clojure, Haskell, Elixir 圈子的人. 按照個人判斷, 這三門語言將來會愈來愈重要, 至於會不會進語言榜前十, 我並不在意, 影響力是方方面面的, 好比 Haskell 的研究看似漫無邊際, 實際上已經影響到 C# Swift CoffeeScript 等等語言的設計了.

知乎上關於 D2 有同窗提到我很孤單, 其實我一想一想這這麼以爲. 雖然未必是正確的方向, 可是我真的走了好遠好遠, 真的有孤單的感受. 平時我遇到 Clojure 問題要去英文社區問 ClojureScript 的維護者們, 這還正常, 可是我用的 Stack Editor 全世界恐怕只有我一我的在用, 而後維護者說你的東西好奇怪, 跟咱們日常的都不同因此幫不了你... 就這樣我被一門小衆語言的開發者吐槽說個人東西很罕見... 除了 Stack Editor, Respo 的狀況也相似, Respo 的功能覆蓋不全面, 固然別人是不樂意用到生產環境的. 雖然有幾個特性很新奇, 但結果仍是我一我的用.

我還在 GitHub 上一我的創建團隊維護的個人項目, 開幾十個倉庫, 結果就是我一我的龜速堆代碼. Respo, Cumulo, Cirru 是其中最嚴重的幾個. 固然介紹已經很多了. 我對本身的定位原本不是前端, 但這些年在後端和設計方向上我能夠說進展微渺, 已經沒了信心, 就算說年輕, 光是編程上的坑就能拖着我很久了. 看整個的歷史, 好像也應該是這樣的, 你們都看到了前面的曙光, 可是走在前面的人會先填了近的坑, 結果累了慢下來, 新人就趕超到前面去了. 我如今作一些亂七八糟的東西, 後面會有不少不少人作比我牛逼不少的事情, 而本來我期待出那種風頭的是我.

Lisp 在國內缺少聲音, 有名氣的大概田春的 Common Lisp, 王垠的 Scheme, 其餘的不多在社區看到. Clojure 社區咱們固然還有 Lo 姐, 但人家明明在英國過日子. 至於羣裏其餘朋友, 前端圈應該不多聽到了. 可是 Lisp 很重要, 宋鴻兵說過, 看一個國家的如今和未來, 就要看他的歷史, 原話固然是記不許確了, 我想說對於編程而言, 一樣有歷史的因素. 面向對象半個世紀, 函數式編程半個世紀, 若是隻是面對 JavaScript 這幾年的新聞, 實在是窄了一點. JavaScript 也許是迄今發展最迅猛的一個生態, 真是蠻誇張的. 然而面對真實世界的問題, 最終仍是須要尋求依靠, 編程理論和工程經驗是知識的重要源頭, 也就是半個多世紀計算機理論和工程方面的研究.

Clojure 好在哪? 我最在乎的一點是 Clojure 當中的各類功能都是通過深思熟慮肯定的, 我是指語言自己的核心部分, 語言堅持哪些特性, 哪些會作折中, 都作了至關的考慮. 固然這並不意味着 Clojure 沒有問題, 可是對比靜態類型語言編碼的成本和嚴格, 對比腳本語言的散漫, Clojure 在其中維持了挺微妙的一個狀態. 相似的語言固然也還有, 可是在前端使用領域來講 ClojureScript 是除了 JavaScript 以外生態相對完整的一門語言. TypeScript 因爲是靜態類型, 因此不拿來對比. 同時 Clojure 也在函數式編程和操做反作用之間努力尋找平衡, 既要藉助函數式編程提高程序的可靠性, 又要考慮實際操做狀態時如何處理.

我微博上發過, 我以爲 JavaScript 社區其實歸根究竟是大廠博弈的過程. 本來的大廠的競爭, 蘋果有 Objective-C 和 Swift 等等, 微軟有 .Net 平臺大量的編程語言, 微軟是開放的, 雖然蘋果藉助 iOS 再次反超. 但 Mozilla 和 Google 做爲後來者在新的領域發起戰爭, 特別是 Chrome, 點燃了 JavaScript 引擎性能的競賽, 以及一連串的 Web 平臺的戰略. Facebook 也想在 HTML5 上尋找突破, 雖說是失敗了, 可是以 React, Webpack, Babel 目前在社區的影響力, 簡直是開闢了新戰場. 用戶固然是一個方面, 可是誰吸引和控制了開發者, 誰的話語權依然會很大. 而 TypeScript, Dart, Babel 對開發者的爭奪, Angular, React 對開發者的爭奪, 某種程度能夠認爲競爭不會消弭.

兩相對比, 特殊之處, 以前蘋果微軟能夠在語言和操做系統層次進行競爭, 而如今因爲 JavaScript 的特殊性, 戰場很是狹小, 簡直要出現肉搏. ECMAScript 須要有統一標準, 可是不一樣的廠商會有不一樣的技術點的利益的訴求. D2 期間也聽鬼道解釋了一遍, React Native 長時間不接受他們某個特性加強的改進的代碼, 可能因爲涉及較深刻的修改. 但公司利益是公司利益. 當 Google 或者微軟強行在自家瀏覽器增長各類神奇功能時, 也是面臨這樣的尷尬. Facebook 把編譯搞得如此複雜, 由於你們都以爲 JavaScript 是語言, 要按照標準作, 分開 stage 功能, 各類配置項. 而後社區當中也是各類風格相互衝擊, 套路能很少麼.

因此固然我看到 WebAssembly 前兩次更新三家大廠一塊兒更新博客的時候, 我簡直眼鏡都要掉下來了. 態度如此一致! 我估計他們是真的想好後招了. 像是 Clojure 那樣, 一個公司控制好語言的核心, 按照特定的習慣設計好工具鏈, 花點時間打磨一下開發體驗, 把 VS 的成功經驗遷移過來, 難道很差麼. WebAssembly 不只僅提升性能, 同時做爲彙編, 也讓從 CoffeeScript 2009 開始發出的聲音, 終於看到了一個清晰的出路, Web 就是須要一門新的彙編, 而不是單單 JavaScript. 以後你們能夠各自創建起自家完善的工具鏈, 穩定的語法和語言特性, 類型推斷類型檢查, IDE 和各類生成工具, 提供平臺 API 等等. 美好的將來.

固然我是心急了. 加上年初有三個月無業遊民的時間, 除了總結下 Respo, Quamolit, Cumulo, Cirru 幾個項目的思考, 我大把的時間都用在熟悉 ClojureScript 的思惟方式上, 到入職個人 JavaScript 封裝仍是原地踏步的狀態, 反正公司直接 ESlint. 因而我用 ClojureScript 搭建了整套我在 React Webpack 當初折騰的熱替換開發環境除出來, 包含純粹 ClojureScript 實現的 React 主題功能也就是 Respo, 還有編碼方式從 Sublime Text 遷移到了 Cirru Light Editor, 到下半年把 Light Editor 升級成了 Stack Editor, 而這已是別人徹底不熟悉的一套工具鏈了.

文章標題講的就是個人技術棧, 後面的篇幅就粗略介紹一下:

Respo

• 主頁 http://respo.site/
• GitHub 團隊 Respo

我用 ClojureScript 實現的 Virtual DOM 方案. 總體採用 pure render 因此對反作用也就是自定義組件等需求支持有欠缺, 可是在 Virtual DOM 操做和熱替換方面舒服不少, DSL 略囉嗦但我以爲還算順手. 性能上我作了很多優化, 整體會比 React 之類框架慢幾倍, 大概應該在一個數量級上. 文檔方面我整理了 API 和術語的解釋, 也編寫了純 ClojureScript 的 examples, 能夠在 GitHub 頁面找到. 其餘 UI 和 router 等經常使用組件由於用到, 也就依照個人 React 經驗堆了一些出來, 固然體量是過小了.

Stack Editor

• 主頁 https://github.com/Cirru/stack-editor

其實就是 Cirru 的項目的 Clojure 形態, 在 DOM 上編輯 AST, 後端生成 Clojure 代碼. 因爲是圖形界面的編輯器, 我能夠經過前端代碼實現簡單的跳轉到定義, 自動生成變量. Stack Editor 最重要的一個想法是, 側邊欄應該顯示函數名或者變量, 並且是根據調用棧顯示, 從而方便具體功能的開發. 從實際使用效果看確實比 Sublime Text 手寫來得快. 我在微博上常發視頻, 有興趣能夠看.

Stack Workflow

• 項目 https://github.com/mvc-works/stack-workflow

因爲 Respo 和 Stack Editor 帶來了模板代碼, 因此我須要一個項目做爲模板項目, 也就是實際意圖了. 經過模板代碼, 個人開發習慣實際上穩定了下來, 而且能增量得改進. 實際上在這個 workflow 當中項目源碼是用 .ir 文件存儲的, src 當中的 cljs 代碼都是編譯出來的. 我想這應該已經超乎不少人想象了.

Cumulo Workflow

• 項目 https://github.com/Cumulo/cumulo-workflow
• 核心優化算法 https://github.com/Cumulo/recollect

Cumulo 項目關係到在分享裏講的服務端到前端的數據同步, 最粗暴的辦法就是直接用 Diff 了, 固然我不是徹底沒優化的那種 Diff, 仍是有基於純函數和緩存的優化的. 這樣我就把 Respo 的 Store 直接搬到了服務端編寫. 固然這相對來講仍是項目很是早期的一個狀態, 性能遠遠不夠. 可是搭配 ClojureScript 的服務端熱替換功能, 開發仍是蠻順暢的, 以前我用 Webpack 服務端熱替換作到了改修代碼 WebSocket 不斷開, 而在 ClojureScript 環境當中更簡單.

除此以外的小工具還有一些, 但都不如上面幾個重要了. 我知道對於別人來講這些項目會是奇葩, 可是對於我來講這是一個不錯的開始.