再談 Go 語言在前端的應(yīng)用前景
今年是舉辦 ECUG Con 的第 11 年，之前我談的基本都是服務(wù)端的開發(fā)實踐。從去年起我開始不談后端而是談前端。當(dāng)然，去年我沒有說為什么我會關(guān)注前端。今天再談 Go 語言在前端的應(yīng)用之前，我先簡單聊一下思路脈絡(luò)，為什么我今天會關(guān)注前端。
前端的演進
最早的 PC 時期，常見的設(shè)備主要是臺式機、筆記本。這兩類設(shè)備是 PC 時代主流設(shè)備，用的操作系統(tǒng)主流的是三個，分別是 Mac 、 Linux、Windows。前兩者市場占有率非常少，基本是 Windows 一統(tǒng)天下。瀏覽器早期因為 Windows 的流行，主要是 IE，但在今天 Chrome 市場占有率非常高。另外還有 Safari、Firefox，大家也都耳熟能詳。
從蘋果發(fā)布 iPhone 為標(biāo)志，我們開始進入移動時期。這個時期的設(shè)備主要是手機和平板，以手機為主。操作系統(tǒng)基本是安卓和 iOS，像 Windows Mobile 之類的占比非常少。瀏覽器不是 Chrome 這類桌面瀏覽器，而是從微信小程序開始，有了移動時代的瀏覽器。在國內(nèi)小程序的種類非常多，包括支付寶小程序、頭條小程序等等。我認(rèn)為這才真正是移動瀏覽器戰(zhàn)爭的開始。
比較奇怪的是，為什么移動瀏覽器之爭沒有在美國開始，而是在中國開始，這也是比較有意思的地方。小程序相關(guān)的技術(shù)，無論是谷歌還是其他公司，也都在琢磨，當(dāng)然也可能是我孤陋寡聞，我沒有看到國外出現(xiàn)移動瀏覽器的跡象。為什么我說 Chrome 這些不是移動下的瀏覽器，是因為操作手感差別非常大。微信小程序是試圖讓 BS 結(jié)構(gòu)的應(yīng)用和 Native 應(yīng)用手感無差別，這是非常重要的嘗試。
我也暢想了一下未來，移動時期設(shè)備還比較少，筆記本、手機、平板是最主流的設(shè)備。臺式機今天不太見得到，但筆記本大家經(jīng)常會用。ECUG 是在 2007 年，差不多蘋果發(fā)布蘋果手機時開始的。在那時候，我做了一個判斷，未來是一個強悍的服務(wù)端加上多元化的終端，其實就是前端。但今天在我看來，前端多元化還沒有真正意義上的出現(xiàn)。
在 ECUG 的第 11 年，可以看到這個多樣化的趨勢已經(jīng)越來越趨向于現(xiàn)實，包括手機之后下一個前端戰(zhàn)場，在我看來是汽車。汽車非常火爆。當(dāng)然，會有更多設(shè)備，很多人都會認(rèn)為下一個是所謂的物聯(lián)網(wǎng)時代，我們不必談這么抽象的名詞，也能預(yù)測到未來前端的趨勢會非常多元化。這個多元化和 PC 時期、移動時期都非常不一樣，因為屏幕的尺寸在前端交互里占非常關(guān)鍵的因素。除了汽車，今天手表也蠻多，但普及率可能還不如手機和平板。手表是一個很特別的東西，它在這么小的屏幕上，要把前端玩出花來，其實是非常難的事情。未來操作系統(tǒng)到底會是怎么樣的？今天還是未知狀態(tài)。
前端的演進跟設(shè)備演進非常有關(guān)聯(lián)。所以前端的演進是大起大落的，這和服務(wù)端非常不一樣。服務(wù)端的發(fā)展非常穩(wěn)健。操作系統(tǒng)偏 Unix 系為主，到今天仍然如此，不太劇烈變動。但前端由于終端變化，導(dǎo)致操作系統(tǒng)的演進非常劇烈。
云計算的演進
云計算的演進，我分三個階段：一階段，以亞馬遜的 EC2 為典型代表的，我叫做機器計算階段。虛擬機（VM）為基礎(chǔ)構(gòu)建了整個體系結(jié)構(gòu)。虛擬機和物理機沒什么區(qū)別，現(xiàn)在大家摸不到虛擬機，但從操作一臺虛擬機手感來說和物理機區(qū)別不大。
今天看到很多不一樣的地方，因為容器興起了，從 2014 年開始興起到今天典型的標(biāo)志是 Kubernetes 一統(tǒng)了容器操作系統(tǒng)的天下。以這樣的基礎(chǔ)，能看到云計算演進到了第二階段。容器計算時期和機器計算時期的計算不太一樣，容器會越來越關(guān)注運維的自動化以及相關(guān)基礎(chǔ)支撐，它最終要達到的目標(biāo)是讓服務(wù)端基本趨向于免運維。以后大家做業(yè)務(wù)時，基本不用太在意服務(wù)端的事情。
這也會帶來另外一個問題，再下一階段云計算會走向哪里？在我看來是應(yīng)用計算。因為云已經(jīng)隨著容器技術(shù)的發(fā)展越來越標(biāo)準(zhǔn)，云計算下一階段應(yīng)該會偏向于業(yè)務(wù)，和業(yè)務(wù)做越來越強的融合，不再只是關(guān)注基礎(chǔ)架構(gòu)，而是關(guān)注應(yīng)用本身的業(yè)務(wù)架構(gòu)。應(yīng)用業(yè)務(wù)架構(gòu)里，端占非常大的成份。云計算和端并不是割裂的。
云+端的演進趨勢
今天我為什么會談前端？當(dāng)下我們?nèi)匀辉诤芘Φ赝七M后端技術(shù)的標(biāo)準(zhǔn)化，但在我看來，在可以預(yù)期的幾年內(nèi)這個事情就會被解決，更遠(yuǎn)的未來一定會把精力花在前端。
很多人都知道七牛云跟 Go 語言非常有淵源，我自己大概在 2012 年也比較狂妄地做了一個預(yù)測，認(rèn)為 Go 語言一定會進語言排行榜靠前，我設(shè)的時間是 10 年左右。2012 年到現(xiàn)在差不多進入第 7 個年頭。Go 是很專注的語言，用 Go 的人基本都集中在后端的開發(fā)，而且是偏向于后端 API 層面的開發(fā)，Web 占比相對少很多。Go 的專注使得它今天基本占領(lǐng)整個云計算領(lǐng)域。很多云計算公司技術(shù)棧，Go 在里面的占比會越來越高。這樣的專注也讓 Go 語言在今年里程碑式地進入前十的排名。
Go 語言的演進
為什么 Go 語言適合做前端？
前端需求量大
前端是開發(fā)人員最多，需求量最多的工種，對語言的要求一定是入門門檻比較低，心智負(fù)擔(dān)最小。而這個非常適合 Go。我 2011 年推 Go 時，大部分人不太了解 Go，但今天 Go 語言的受眾已經(jīng)非常廣，大家有很大共識的一點是，Go 語言的入門門檻非常低，心智負(fù)擔(dān)比較少?；境绦?qū)懗鰜砭幾g通過，大概率沒有問題。這樣的特性使得它非常適合前端。
前端需要工程化更強的語言
前端業(yè)務(wù)量非常大，所以前端代碼量比后端多很多。前端是負(fù)責(zé)和用戶打交道的，和人打交道的東西是最復(fù)雜也最容易發(fā)生變化的。今天可能這個知識更好，明天可能換了一種新的知識，尤其是我前面提到了端的變化。從 PC、筆記本到手機，屏幕尺寸不一樣，以及過去以鍵盤為交互主體變成了觸摸屏，再到未來手表或者汽車。為什么很多公司都關(guān)注語音交互，就因為像汽車、手表這樣的設(shè)備，語音交互是一個比較好的手段。但這些都有很大的不確定性。前端的變化是很劇烈的，而交互的手感以及為了讓用戶舒服、爽，程序員要付出的努力也會是非常大的。前端的代碼量一定是最多的。
前端非常需要有強工程化能力的語言。今天我們看到前端的代碼量肯定是 JavaScript，但 JavaScript 幾乎是沒有工程化支持的。它之所以叫 Script，是因為小，類似于微信小程序。大家仔細(xì)想想，小程序一定不小。在這樣一個不小的東西上，或者代碼量更多的應(yīng)用里，需要工程語言更強。JavaScript 為什么流行，是因為它的「壟斷地位」。有個趨勢已經(jīng)發(fā)生了，但今天還不是特別強烈，就是會有越來越多語言進軍前端，Go 只會是其中之一。這是由需求決定的，我也認(rèn)為 Go 是最有希望的那幾個之一。
前面談為什么我會在 ECUG Con 談前端，今天我講的東西，也許對大家影響不會太大，因為 Go 做前端畢竟還非常初級，但 ECUG Con 我希望它是一個前瞻趨勢探索的會議，我并不傾向于它一定是非常實用的，它不需要今天跟大家聊了，明天就把它用到工程上，我對它并不是這樣的定義。我希望 ECUG 本身是一種對未來有預(yù)見的社區(qū)。
Go 在前端的進展
回顧 Go 在前端的進展，GopherJS 是真正產(chǎn)生了影響力的進展。在 GopherJS 之前有非常多人做前端相關(guān)的事情。谷歌也有人推出了一個框架叫做 GXUI，GXUI 今天已經(jīng)不怎么維護了。
很多人會試圖做跨平臺的框架，但實際上跨平臺的框架最有希望的一定是瀏覽器。因為瀏覽器就是跨平臺框架。在我看來，像 QT 包括谷歌做的 GXUI，都相對比較局限。但 GopherJS，我認(rèn)為它是在前端真正能立得住腳的嘗試。他就是干我剛才說的事情，讓 Go 語言的程序員能寫前端。怎么寫？它做了一個編譯器，這個編譯器把 Go 代碼翻譯成 JavaScript 代碼，自然而然 Go 就能寫前端了。它是把 JavaScript 作為前端的一個機器語言，因為 JavaScript 的位置是繞不過去的。
但也不見得真的繞不過去。前端的機器語言在今天的標(biāo)準(zhǔn)肯定是 JavaScript，但我們也看到了另外一個東西，叫 WebAssembly，顧名思義它將自己看做是 Web 的匯編語言。但其實這個 WebAssembly 是二進制的，我覺得說它是 Web 的匯編語言，不如說它是 Web 的機器語言。WebAssembly 的覆蓋面比大家想象得要廣，今天所有主流的瀏覽器都已經(jīng)支持了。JavaScript 的「壟斷位置」已經(jīng)有一些變化了，它并不會一直這樣壟斷下去。大家可能也聽過 Go 已經(jīng)支持 WebAssembly，而且是語言內(nèi)建支持，這對 Go 來說也是非常重要的。
Go 在前端的進展，第二個大里程碑事件是 Go 內(nèi)建支持了 WebAssembly（https://github.com/golang/go/wiki/WebAssembly）。從 Go 的 1.11 版本開始。這是 Go 官方對 WebAssembly Go 支持的介紹，編譯過程是把 GOOS 環(huán)境變量定義成 js，架構(gòu)選 wasm，這樣就可以編譯出 wasm 文件，而不是本地的可執(zhí)行程序。這里有一些 DEMO，是一些社區(qū)的人用 Go 寫的 WebAssembly 樣例。
DEMO 樣例展示：
這展示的效果就是后面的源代碼實現(xiàn)的?？雌饋砗孟褚矝]有什么，但這個支持是非常關(guān)鍵的。Go 開始在語言內(nèi)建就支持 Web 前端的開發(fā)。盡管今天它還是一個經(jīng)驗版的狀態(tài)，但也是非常重要的里程碑。做這件事情的人和前面干 GopherJS 是同一波人。有那么一堆人他們在努力把 Go 推向前端。
前面兩個如果大家關(guān)注 Go 語言應(yīng)該比較多人知道，但接下來這件事情應(yīng)該大部分人都不知道。有一個新東西叫做 TinyGo，它是在嵌入式設(shè)備上跑 Go，它是一個剪裁版的 Go（https://github.com/aykevl/tinygo）。因為 Go 主要是針對服務(wù)端開發(fā)，所以大家對 Go 編譯出的可執(zhí)行文件有多大一點都不在意，但如果留意過就知道它非常大。TinyGo 試圖讓編譯出的文件足夠小，因為在嵌入式設(shè)備上磁盤空間非常珍貴，內(nèi)存也很珍貴。它居然也支持 WebAssembly，能夠做 Web 開發(fā)，雖然裁掉了很多 Go 的特性。不知道它后面的演化怎么樣，因為這個項目還非常新，不到一年。對于新出現(xiàn)的東西，我們只能關(guān)注，也沒有辦法真的用到什么工程上。
Go 2D 游戲開發(fā)引擎（https://github.com/hajimehoshi/ebiten），實際上 3D 已經(jīng)出現(xiàn)了，今天沒有列出來。這個游戲引擎是日本人做的，而且已經(jīng)拿它做了多款的手游開發(fā)。它是一個已經(jīng)商業(yè)化的引擎。支持的平臺非常廣，用這個游戲引擎做出的游戲能夠支持 PC操作系統(tǒng)如 Windows、Mac、Linux、FreeBSD，也支持手機操作系統(tǒng)Android、iOS，還支持 Web 開發(fā)如 GopherJS、WebAssembly。它是一個生產(chǎn)級的引擎。我去年演示的 DEMO，用 Go 寫了一個少兒編程語言 Scratch 的解析器，這個解析器就是用這個 2D 游戲開發(fā)引擎做的。
下一個有趣的東西是 Go 的前端代碼托管（https://github.com/dave/jsgo）。JavaScript 有很多公開的前端代碼托管，但這里出現(xiàn)了 Go 前端代碼托管。直接往這里一扔就直接上云了。這看起來很小眾，但有人干這些事情。
這也有一些 DEMO：
-
這是一個拼數(shù)字的游戲。
-
這是俄羅斯方塊。
-
這是一個游戲，大家之前見過的版本是小鳥，不是土撥鼠。
-
這是一個 To do list 類的 Web 應(yīng)用。加它只是為了展示 Go 也能做一個標(biāo)準(zhǔn)的前端開發(fā)。
Jsgo.io 既支持 GopherJS 也支持 WebAssembly。我們剛才看到的游戲，不是一個 js 文件，是很多個。源代碼里，Go 會 import 一些 Go 標(biāo)準(zhǔn)庫，比如字符串轉(zhuǎn)換庫 strconv。字符串轉(zhuǎn)換 Go 標(biāo)準(zhǔn)庫會直接被編譯成一個單獨的 js 文件。這個做法的好處是慢一點，但后面的加載會非?？欤ㄒ驗榛静挥酶模４蟮那岸藨?yīng)用這樣被拆解之后，從長遠(yuǎn)來說加載速度會比較快。它支持分模塊加載，而且我們不用為分模塊加載付出什么努力，Go 的引用會變成一個模塊引用，對應(yīng)到 js 也是一個模塊。這樣編程會非常爽。前端 JavaScript 語言里，這種模塊化編程并不是語言內(nèi)建支持的。
Jsgo.io 對 WebAssembly 的支持目前還不體完善，跟剛才的 GopherJS 不一樣，它目前不能做到分 package 引用，編譯出來的是一個大的 wasm 文件。但這只是臨時狀態(tài)，因為這塊的支持才剛開始做。
前面我也說過，Go 的通用卡平臺 gui 庫很多人在嘗試，但無一不是失敗告終。這并不是由于 Go 引起的，是因為像 QT 這類的跨平臺方案本身并不是符合趨勢的東西。最有希望的跨平臺方案還是瀏覽器技術(shù)，基于 HTML5 和小程序，它們是真正的生產(chǎn)級的跨平臺方案。尤其是小程序的出現(xiàn)，今天看到很多跨平臺庫，比如 React 做出的應(yīng)用還是有生硬的地方，但微信小程序是試圖讓 Web 跟 Native 體驗一致的。
Go 在前端的發(fā)展展望
Go 跨平臺的游戲引擎，已經(jīng)基本接近生產(chǎn)級，它是非常重要的突破口。
在我看來，Go 在前端的突破，一定是從游戲領(lǐng)域開始。它對 Go 的意義是 0 到 1 的歷史性突破。如果沒有商業(yè)公司用它，這個東西就是一個玩具。但 Go 的游戲引擎不會是玩具，因為會有越來越多商業(yè)公司用它。未必是這個游戲引擎，也許會有人做出更牛的，但這是個靠譜的方向。對于 Go 來說，就跟 Docker、Kubernetes 的流行代表 Go 占領(lǐng)了云一樣。Go 在前端也需要一個殺手锏，它就是游戲引擎。
