<code id="ymukc"><xmp id="ymukc">

谷歌為何會選用TypeScript?

前端開發 TypeScript   2018-09-11 09:13:30 發布
您的評價:
     
4.0
收藏     0收藏
文件夾
標簽
(多個標簽用逗號分隔)

我已經使用TypeScript兩年多時間,是時候寫一兩篇文章來總結一下了。

谷歌在很早之前就張開雙臂擁抱Web應用程序,Gmail已經發布14年了。當時,JavaScript的世界是瘋狂的。Gmail工程師不得不為IE糟糕的垃圾回收算法捏一把汗,他們需要手動將字符串文字從for循環中提取出來,以避免GC停頓。最近,我找到了那個時代一個設計文檔,是關于如何“minify” JavaScript文件的,只不過一些工具僅用于Windows平臺。這些事情在今天看來是難以想象的。

多年來,谷歌構建了大量的基礎設施,用于開發大型的JavaScript應用程序。例如,他們開發了一個模塊系統,可以讓源文件自描述它們之間的相互依賴關系,還有一個捆綁器,可以將源文件合并在一起,并縮小為可與瀏覽器兼容的工件。另外還有一個工具,它通過動態加載入口點來分析應用程序的依賴關系圖,并抽取服務的公共子模塊。還有非常常見的服務器端渲染。所有這些概念對于今天的Web開發人員來說都是很熟悉的,但谷歌的技術棧總是很超前,它們并行演進,雖然在概念上很相似,但實際上卻完全不同——不同的流程、工具,甚至名字都不一樣。

另一個有關并行演進的例子:谷歌、Facebook和微軟各自構建了相似但不兼容的編譯器,這些編譯器向JavaScript中加入了靜態檢查。谷歌的編譯器通俗地稱為Closure(不要與Clojure這門編程語言混淆,另外請注意,ClojureScript使用的是Closure編譯器)。

谷歌的JavaScript技術棧非常棒,其中一些部分已經超越了當今最好的技術。例如,Closure編譯器可能仍然是最復雜的JavaScript優化器,可以使用類型信息來優化代碼、跨熱加載塊邊界進行函數內聯,以及將無用的代碼剝離成單個符號。

當然,谷歌的JavaScript技術棧也存在一些問題。Closure是JavaScript的一種帶有靜態類型的變體,通過注釋來引入語言新特性。Closure具有不可預測的語義,它運行速度慢,容易出現bug,除非你很小心,否則它很容易就讓你的代碼變得一團糟。它是開源的,但除了一些能夠招到谷歌前員工的公司之外,行業中很少有公司會使用它。在谷歌內部,我認為JavaScript的聲望并不高,部分原因在于我們的工具,它將靜態語言的冗長性與動態語言的不可預測性結合在了一起。

而在谷歌之外,JavaScript在不斷演進,變得越來越流行。為了解決IE垃圾回收器的問題,我們開發了Chrome,然后v8出現了,繼而nodejs誕生,所以今天的大多數Web工具都是用JavaScript編寫的。模塊系統(UMD、AMD、CommonJS)大肆膨脹,ES6也發明了自己的模塊系統,但由于某種原因,與其他模塊系統不兼容,非常可惜。npm統一了工具和庫的共享方式。Webpack可以在你開發代碼的同時將模塊動態加載到正在運行的應用程序中。

但谷歌沒有使用這些東西。我們有一個類似SASS的CSS預處理語言,只是它不叫SASS,而且沒有人喜歡用它。花哨的塊分割器并不支持第三方JavaScript庫,部分原因是這些工具的出現早于JavaScript的庫生態系統。

這些都已經成為歷史。你可以說我們不應該忘了我們是如何到達這里的,但不管怎樣都無法改變我們已經達到這里的事實。或許我們更應該關心接下來要去哪里。我們有幾個選擇。

第一個選擇是放棄這個已經破敗不堪的星球,去到一個沒有JavaScript的新星球。如果我們在GWT(一個將Java編譯為JavaScript的谷歌項目)或Dart(一個將其他語言編譯為JavaScript的谷歌項目)或WASM或(Clojure?Haxe?Elm?)上做更多的投入,根本就不需要擔心JavaScript!

作為編程語言愛好者,我覺得這個主意不錯。不過長話短說,這里有一些問題:首先,采用不同的語言對于我們現有的數百萬行代碼來說并沒有任何意義——“使用新語言重寫”在某些情況下可能是正確的選擇,但很難做到充分利用Gmail工程師的時間。其次,采用不同的語言對于我們想要聘請的前端程序員來說一點幫助都沒有,等于說他們之前的經驗都用不上了。

改變一切的對立面是不做出任何改變。JavaScript世界充斥著業余代碼和leftpad災難。一個優秀的工程師總能適應特殊的前端開發方式,我們總能改進或構建更多屬于自己的工具。我們構建的應用類型——谷歌搜索主頁每天的點擊量超過數十億次——與其他人構建的網絡應用程序不同,我們的工具不僅優秀,而且都是必需的。我認同這種觀點。我認為存在某種權衡,一方面,構建我們自己的工具是有意義的,另一方面,我們已經遠離了主流,以致于我們的工具變成了一種負擔。關鍵在于,我們現在處于這個權衡的哪個位置上,我相信我們離后者更近。我們從對LLVM/Clang的貢獻中獲益,因為我們依賴于C++,但是我們不會從構建自己的LLVM中獲得更多額外的價值。

我的團隊一直在追求中間那條路:在必要的時候逐步采用一些外部工具。這項任務并不那么有趣——我們不可能只是簡單地把遺留的那套東西直接丟掉——但我喜歡謙虛一些,向外看,而不是向內看。

在谷歌JavaScript孤島和大陸之間架起橋梁的首先是一個靜態檢查器:

(1)它不是我們內部開發的

(2)已經很流行,與我們現有的代碼相似

(3)旨在為JavaScript做橋接

(4)支持大規模開發

這個工具就是TypeScript。Closure編譯器的優勢在于它的優化輸出,而TypeScript具有出色的用戶接口,但不提供優化。這兩個工具是互補的,并且在處理某些任務時可以進行分層式協作。

使用TypeScript給我們帶來了很多好處——從IDE風格的代碼完成到從StackOverflow上獲取相關問題的答案。我們所要做的工作主要是集成:將我們的應用程序逐步遷移到TypeScript,而不是從頭開始重寫。在與谷歌范圍內的構建系統集成時,我們非常謹慎,我們進行增量編譯,這對大型應用程序來說至關重要。一個模塊發生變更,只要不影響公開的API,就不應該導致下游模塊進行重新編譯。與Closure類型/模塊系統的集成意??味著ES6 TypeScript模塊可以導入谷歌模塊系統模塊,反之亦然,而且可以保留大部分類型信息。

在谷歌,現在到處都可以看到TypeScript的身影。如果你在使用谷歌的產品,很可能是在與TypeScript代碼打交道。TypeScript本身就是一系列有趣的方案的折衷,它在靜態類型的編程語言與自由轉換的JavaScript生態系統之間做出了權衡。這就是我們的工程師要做的事情:做出有趣的權衡,嘗試在各種問題之間找到平衡點。我希望后面能夠寫更多文章分享這些年發現的一些有趣的事情,我認為TypeScript在這個領域內達到了很好的平衡。

英文原文: http://neugierig.org/software/blog/2018/09/typescript-at-google.html

感謝覃云對本文的審校。

 

來自:http://www.infoq.com/cn/articles/typescript-at-google

 

六合特码资料
<code id="ymukc"><xmp id="ymukc">
<code id="ymukc"><xmp id="ymukc">

擴展閱讀

TypeScript 入門指南
TypeScript Modules(模塊)
使用 Web API 作為動態 TypeScript 編譯器運行環境
產品前端重構(TypeScript、MVC框架設計)
Angular Starter Kit —— Angular 2.0 遷移準備工具 (TypeScript)

為您推薦

細數Javascript技術棧中的四種依賴注入
使用Visual Studio Code開發TypeScript
給 JavaScript 初心者的 ES2015 實戰
[Node.js] 使用TypeScript編寫Node項目
產品前端重構(TypeScript、MVC框架設計)

更多

前端開發
TypeScript
相關文檔  — 更多
相關經驗  — 更多
相關討論  — 更多