再談 Go 語言在前端的應用前景

12 月 23 日，七牛雲 CEO & ECUG 社區發起人許式偉先生在 ECUG Con 2018 現場爲你們帶來了主題爲《再談 Go 語言在前端的應用前景》的內容分享。

本文是對演講內容的實錄整理。

今年是舉辦 ECUG Con 的第 11 年，以前我談的基本都是服務端的開發實踐。從去年起我開始不談後端而是談前端。固然，去年我沒有說爲何我會關注前端。今天再談 Go 語言在前端的應用以前，我先簡單聊一下思路脈絡，爲何我今天會關注前端。

前端的演進

最先的 PC 時期，常見的設備主要是臺式機、筆記本。這兩類設備是 PC 時代主流設備，用的操做系統主流的是三個，分別是 Mac 、 Linux、Windows。前二者市場佔有率很是少，基本是 Windows 一統天下。瀏覽器早期由於 Windows 的流行，主要是 IE，但在今天 Chrome 市場佔有率很是高。另外還有 Safari、Firefox，你們也都耳熟能詳。

從蘋果發佈 iPhone 爲標誌，咱們開始進入移動時期。這個時期的設備主要是手機和平板，以手機爲主。操做系統基本是安卓和 iOS，像 Windows Mobile 之類的佔比很是少。瀏覽器不是 Chrome 這類桌面瀏覽器，而是從微信小程序開始，有了移動時代的瀏覽器。在國內小程序的種類很是多，包括支付寶小程序、頭條小程序等等。我認爲這才真正是移動瀏覽器戰爭的開始。

比較奇怪的是，爲何移動瀏覽器之爭沒有在美國開始，而是在中國開始，這也是比較有意思的地方。小程序相關的技術，不管是谷歌仍是其餘公司，也都在琢磨，固然也多是我孤陋寡聞，我沒有看到國外出現移動瀏覽器的跡象。爲何我說 Chrome 這些不是移動下的瀏覽器，是由於操做手感差異很是大。微信小程序是第一次試圖讓 BS 結構的應用和 Native 應用手感無差異，這是很是重要的嘗試。

我也暢想了一下將來，移動時期設備還比較少，筆記本、手機、平板是最主流的設備。臺式機今天不太見獲得，但筆記本你們常常會用。ECUG 是在 2007 年，差很少蘋果發佈第一代蘋果手機時開始的。在那時候，我作了一個判斷，將來是一個強悍的服務端加上多元化的終端，其實就是前端。但今天在我看來，前端多元化尚未真正意義上的出現。

在 ECUG 的第 11 年，能夠看到這個多樣化的趨勢已經愈來愈趨向於現實，包括手機以後下一個前端戰場，在我看來是汽車。汽車很是火爆。固然，會有更多設備，不少人都會認爲下一個是所謂的物聯網時代，咱們沒必要談這麼抽象的名詞，也能預測到將來前端的趨勢會很是多元化。這個多元化和 PC 時期、移動時期都很是不同，由於屏幕的尺寸在前端交互裏佔很是關鍵的因素。除了汽車，今天手錶也蠻多，但普及率可能還不如手機和平板。手錶是一個很特別的東西，它在這麼小的屏幕上，要把前端玩出花來，實際上是很是難的事情。將來操做系統到底會是怎麼樣的？今天仍是未知狀態。

前端的演進跟設備演進很是有關聯。因此前端的演進是大起大落的，這和服務端很是不同。服務端的發展很是穩健。操做系統偏 Unix 係爲主，到今天仍然如此，不太劇烈變更。但前端因爲終端變化，致使操做系統的演進很是劇烈。

雲計算的演進

雲計算的演進，我分三個階段：第一階段，以亞馬遜的 EC2 爲典型表明的，我叫作機器計算階段。虛擬機（VM）爲基礎構建了整個體系結構。虛擬機和物理機沒什麼區別，如今你們摸不到虛擬機，但從操做一臺虛擬機手感來講和物理機區別不大。

今天看到不少不同的地方，由於容器興起了，從 2014 年開始興起到今天典型的標誌是 Kubernetes 一統了容器操做系統的天下。以這樣的基礎，能看到雲計算演進到了第二階段。容器計算時期和機器計算時期的計算不太同樣，容器會愈來愈關注運維的自動化以及相關基礎支撐，它最終要達到的目標是讓服務端基本趨向於免運維。之後你們作業務時，基本不用太在乎服務端的事情。

這也會帶來另一個問題，再下一階段雲計算會走向哪裏？在我看來是應用計算。由於雲已經隨着容器技術的發展愈來愈標準，雲計算下一階段應該會偏向於業務，和業務作愈來愈強的融合，再也不只是關注基礎架構，而是關注應用自己的業務架構。應用業務架構裏，端佔很是大的成份。雲計算和端並非割裂的。

雲+端的演進趨勢

在我看來，雲計算會使得後端的技術棧愈來愈標準化。後端的大部分技術難題均可標準化解決。每個公司都有一個基礎架構部，而云計算就是把技術架構部從公司裏面搬到外面。這個標準化是天然發生的。正由於如此，業務的難點和挑戰會愈來愈向前端轉移。服務端沒太大的挑戰。服務端從支撐業務的角度看，挑戰愈來愈少。但從服務端的體系，可能側重點會愈來愈偏向於業務運營體系的標準化，就是 BI （商業智能）方面的東西。但這個事情的標準化比前端更難。

今天我爲何會談前端？當下咱們仍然在很努力地推動後端技術的標準化，但在我看來，在能夠預期的幾年內這個事情就會被解決，更遠的將來必定會把精力花在前端。

不少人都知道七牛雲跟 Go 語言很是有淵源，我本身大概在 2012 年也比較狂妄地作了一個預測，認爲 Go 語言必定會進語言排行榜第一，我設的時間是 10 年左右。2012 年到如今差很少進入第 7 個年頭。Go 是很專一的語言，用 Go 的人基本都集中在後端的開發，並且是偏向於後端 API 層面的開發，Web 佔比相對少不少。Go 的專一使得它今天基本佔領整個雲計算領域。不少雲計算公司技術棧，Go 在裏面的佔比會愈來愈高。這樣的專一也讓 Go 語言在今年裏程碑式地進入前十的排名。

Go 語言的演進

專一後端開發是沒辦法讓 Go 排到第一的。緣由很簡單，後端開發尤爲是雲計算致使後端技術愈來愈標準化後，會使得 Go 語言愈來愈沒有用武之地，由於不少問題的複雜性被雲計算公司解決掉了。大部分公司都是作本身的業務就行了，沒有必要關心高併發、高可用這種服務端的複雜性。服務端的挑戰，隨着雲計算的影響會變弱。這樣 Go 語言今天所處的位置，若是是一個公司，應該有危機感，還要突破下一個戰場。在我看來它必定會進入前端，也會讓 Go 語言更偏向於通用語言，領域會愈來愈泛。這樣的一個變化纔可以讓 Go 成爲真正意義上語言排行榜的第一。

爲何 Go 語言適合作前端？

前端需求量最大

前端是開發人員最多，需求量最多的工種，對語言的要求必定是入門門檻比較低，心智負擔最小。而這個很是適合 Go。我 2011 年推 Go 時，大部分人不太瞭解 Go，但今天 Go 語言的受衆已經很是廣，你們有很大共識的一點是，Go 語言的入門門檻很是低，心智負擔比較少。基本程序寫出來編譯經過，大機率沒有問題。這樣的特性使得它很是適合前端。

前端須要工程化更強的語言

前端業務量很是大，因此前端代碼量比後端多不少。前端是負責和用戶打交道的，和人打交道的東西是最複雜也最容易發生變化的。今天可能這個知識更好，明天可能換了一種新的知識，尤爲是我前面提到了端的變化。從 PC、筆記本到手機，屏幕尺寸不同，以及過去以鍵盤爲交互主體變成了觸摸屏，再到將來手錶或者汽車。爲何不少公司都關注語音交互，就由於像汽車、手錶這樣的設備，語音交互是一個比較好的手段。但這些都有很大的不肯定性。前端的變化是很劇烈的，而交互的手感以及爲了讓用戶舒服、爽，程序員要付出的努力也會是很是大的。前端的代碼量必定是最多的。

前端很是須要有強工程化能力的語言。今天咱們看到前端最大的代碼量確定是 JavaScript，但 JavaScript 幾乎是沒有工程化支持的。它之因此叫 Script，是由於小，相似於微信小程序。你們仔細想一想，小程序必定不小。在這樣一個不小的東西上，或者代碼量更多的應用裏，須要工程語言更強。JavaScript 爲何流行，是由於它的「壟斷地位」。有個趨勢已經發生了，但今天還不是特別強烈，就是會有愈來愈多語言進軍前端，Go 只會是其中之一。這是由需求決定的，我也認爲 Go 是最有但願的那幾個之一。

前面談爲何我會在 ECUG Con 談前端，今天我講的東西，也許對你們影響不會太大，由於 Go 作前端畢竟還很是初級，但 ECUG Con 我但願它是一個前瞻趨勢探索的會議，我並不傾向於它必定是很是實用的，它不須要今天跟你們聊了，明天就把它用到工程上，我對它並非這樣的定義。我但願 ECUG 自己是一種對將來有預見的社區。

Go 在前端的進展

回顧 Go 在前端的進展，GopherJS 是第一個真正產生了影響力的進展。在 GopherJS 以前有很是多人作前端相關的事情。谷歌也有人推出了一個框架叫作 GXUI，GXUI 今天已經不怎麼維護了。

不少人會試圖作跨平臺的框架，但實際上跨平臺的框架最有但願的必定是瀏覽器。由於瀏覽器就是跨平臺框架。在我看來，像 QT 包括谷歌作的 GXUI，都相對比較侷限。但 GopherJS，我認爲它是在前端第一個真正能立得住腳的嘗試。他就是幹我剛纔說的事情，讓 Go 語言的程序員能寫前端。怎麼寫？它作了一個編譯器，這個編譯器把 Go 代碼翻譯成 JavaScript 代碼，天然而然 Go 就能寫前端了。它是把 JavaScript 做爲前端的一個機器語言，由於 JavaScript 的位置是繞不過去的。

但也不見得真的繞不過去。前端的機器語言在今天的標準確定是 JavaScript，但咱們也看到了另一個東西，叫 WebAssembly，顧名思義它將本身看作是 Web 的彙編語言。但其實這個 WebAssembly 是二進制的，我以爲說它是 Web 的彙編語言，不如說它是 Web 的機器語言。WebAssembly 的覆蓋面比你們想象得要廣，今天全部主流的瀏覽器都已經支持了。JavaScript 的「壟斷位置」已經有一些變化了，它並不會一直這樣壟斷下去。你們可能也聽過 Go 已經支持 WebAssembly，並且是語言內建支持，這對 Go 來講也是很是重要的。

Go 在前端的進展，第二個大里程碑事件是 Go 內建支持了 WebAssembly（https://github.com/golang/go/wiki/WebAssembly）。從 Go 的 1.11 版本開始。這是 Go 官方對 WebAssembly Go 支持的介紹，編譯過程是把 GOOS 環境變量定義成 js，架構選 wasm，這樣就能夠編譯出 wasm 文件，而不是本地的可執行程序。這裏有一些 DEMO，是一些社區的人用 Go 寫的 WebAssembly 樣例。

DEMO 樣例展現：

https://stdiopt.github.io/gowasm-experiments/

https://justinclift.github.io/wasmGraph1/

https://stdiopt.github.io/gowasm-experiments/splashy/

這展現的效果就是後面的源代碼實現的。看起來好像也沒有什麼，但這個支持是很是關鍵的。Go 開始在語言內建就支持 Web 前端的開發。儘管今天它仍是一個經驗版的狀態，但也是很是重要的里程碑。作這件事情的人和前面幹 GopherJS 是同一波人。有那麼一堆人他們在努力把 Go 推向前端。

前面兩個若是你們關注 Go 語言應該比較多人知道，但接下來這件事情應該大部分人都不知道。有一個新東西叫作 TinyGo，它是在嵌入式設備上跑 Go，它是一個剪裁版的 Go（https://github.com/aykevl/tinygo ）。由於 Go 主要是針對服務端開發，因此你們對 Go 編譯出的可執行文件有多大一點都不在乎，但若是留意過就知道它很是大。TinyGo 試圖讓編譯出的文件足夠小，由於在嵌入式設備上磁盤空間很是珍貴，內存也很珍貴。它竟然也支持 WebAssembly，可以作 Web 開發，雖然裁掉了不少 Go 的特性。不知道它後面的演化怎麼樣，由於這個項目還很是新，不到一年。對於新出現的東西，咱們只能關注，也沒有辦法真的用到什麼工程上。

Go 2D 遊戲開發引擎（https://github.com/hajimehoshi/ebiten ），實際上 3D 已經出現了，今天沒有列出來。這個遊戲引擎是日本人作的，並且已經拿它作了多款的手遊開發。它是一個已經商業化的引擎。支持的平臺很是廣，用這個遊戲引擎作出的遊戲可以支持 PC 操做系統如 Windows、Mac、Linux、FreeBSD，也支持手機操做系統 Android、iOS，還支持 Web 開發如 GopherJS、WebAssembly。它是一個生產級的引擎。我去年演示的 DEMO，用 Go 寫了一個少兒編程語言 Scratch 的解析器，這個解析器就是用這個 2D 遊戲開發引擎作的。

下一個有趣的東西是 Go 的前端代碼託管（https://github.com/dave/jsgo ）。JavaScript 有不少公開的前端代碼託管，但這裏出現了 Go 前端代碼託管。直接往這裏一扔就直接上雲了。這看起來很小衆，但有人幹這些事情。

這也有一些 DEMO：

這是一個拼數字的遊戲。

https://jsgo.io/hajimehoshi/ebiten/examples/2048

這是俄羅斯方塊。

https://jsgo.io/hajimehoshi/ebiten/examples/blocks

這是一個遊戲，你們以前見過的版本是小鳥，不是土撥鼠。

https://jsgo.io/hajimehoshi/ebiten/examples/flappy

這是一個 To do list 類的 Web 應用。加它只是爲了展現 Go 也能作一個標準的前端開發。

https://jsgo.io/dave/todomvc

Jsgo.io 既支持 GopherJS 也支持 WebAssembly。咱們剛纔看到的遊戲，不是一個 js 文件，是不少個。源代碼裏，Go 會 import 一些 Go 標準庫，好比字符串轉換庫 strconv。字符串轉換 Go 標準庫會直接被編譯成一個單獨的 js 文件。這個作法的好處是第一遍慢一點，但後面的加載會很是快（由於基本不用改）。大的前端應用這樣被拆解以後，從長遠來講加載速度會比較快。它支持分模塊加載，並且咱們不用爲分模塊加載付出什麼努力，Go 的引用最後會變成一個模塊引用，對應到 js 也是一個模塊。這樣編程會很是爽。前端 JavaScript 語言裏，這種模塊化編程並非語言內建支持的。

Jsgo.io 對 WebAssembly 的支持目前還不體完善，跟剛纔的 GopherJS 不同，它目前不能作到分 package 引用，編譯出來的是一個大的 wasm 文件。但這只是臨時狀態，由於這塊的支持纔剛開始作。

前面我也說過，Go 的通用卡平臺 gui 庫不少人在嘗試，但無一不是失敗了結。這並非因爲 Go 引發的，是由於像 QT 這類的跨平臺方案自己並非符合趨勢的東西。最有但願的跨平臺方案仍是瀏覽器技術，基於 HTML5 和小程序，它們是真正的生產級的跨平臺方案。尤爲是小程序的出現，今天看到不少跨平臺庫，好比 React 作出的應用仍是有生硬的地方，但微信小程序是第一個試圖讓 Web 跟 Native 體驗一致的。

Go 在前端的發展展望

Go 跨平臺的遊戲引擎，已經基本接近生產級，它是很是重要的突破口。

在我看來，Go 第一個在前端的突破，必定是從遊戲領域開始。它對 Go 的意義是 0 到 1 的歷史性突破。若是沒有商業公司用它，這個東西就是一個玩具。但 Go 的遊戲引擎不會是玩具，由於會有愈來愈多商業公司用它。未必是這個遊戲引擎，也許會有人作出更牛的，但這是個靠譜的方向。對於 Go 來講，就跟 Docker、Kubernetes 的流行表明 Go 佔領了雲同樣。Go 在前端也須要一個殺手鐗，它就是遊戲引擎。