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

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

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

?

cdn.xitu.io/2019/1/3/1681193686d202cb?w=1024&h=683&f=jpeg&s=527028">

?

今年是舉辦 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 語言的入門門檻非常低，心智負擔比較少?；境绦驅懗鰜砭幾g通過，大概率沒有問題。這樣的特性使得它非常適合前端。

?

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

?

前端業務量非常大，所以前端代碼量比后端多很多。前端是負責和用戶打交道的，和人打交道的東西是最復雜也最容易發生變化的。今天可能這個知識更好，明天可能換了一種新的知識，尤其是我前面提到了端的變化。從 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/wasmGraph2/

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 在前端也需要一個殺手锏，它就是游戲引擎。