標籤：

如何評價 TypeScript？

01-05

有人說：「TypeScript 讓 JavaScript 又變成了 Java，而我們不需要另一個 Java，所以我們不需要 TypeScript「。

這樣說的人一定不知道，TypeScript 的類型系統中有：

  • Intersection Types
  • Union Types Discriminated Unions (aka "Algebraic Data Types.")
  • String Literal Types
  • Polymorphic this Types
  • Index Types
  • Mapped Types
  • ...

這些吧。特別是 Generic Types 組合上 Mapped Types 描述能力爆表。

如果你的代碼超過 1000 行，而且你不打算浪費時間，那麼試試 TypeScript。當然前提是你是有經驗的開發人員，如果是編程初學者，建議還是先從 JavaScript 開始。

ts用了1年半，首先因為學過java，c#，actionscript，本身從事js開發，慣用的ide是vs，所以完全平滑的使用；在原來公司的時候，在室內推廣，帶頭重構了幾個項目；

後來自己創業，用ts寫node，網頁，app，當然越用越順手，深深覺得那些帶有顏色看待M$的工具的人這次走寶了，ts是有shi以來最好的js開發工具（沒有之一）。

－－－－－－分割線，第一次在知乎碼長字－－－－－－－－－－－

寫js快10年了，我算是個技術宅，在一家大型互聯網公司呆了6年（懶的跳），算是比較早的一批純js開發人員吧。跟很多資深jser一樣，隨著工作的年限越長，對js技術了解也從懵懂到精通，網頁開發腳本 －&> es,dom,w3c -&> 精通http協議什麼的 -&> 前端工程化，隨著行業的興旺，有幸從公司第一個純jser到後來我們團隊以js為第一語言的開發室最多有近30個js開發人員，所以js的代碼規模是可想而知的，我們的產品也是前端密集型，用戶有4億＋。

當前端開發人員熟悉了他的開發語言和開發工具，那麼更多的是處理業務上的各種需求（從入門ajax開發，到使用跟公司業務相關的不停增長的各種WebAPI），從web開發的環境註定jser（前端工程師）是個永遠折騰不斷的崗位，什麼時候公司產品大面積升級，就會有幾十萬行的代碼重新寫，這樣的情況我大概經歷了3次（每次大概會折騰半年，會有較多的加班），每一次大版本的重構都會應用一些新的技術框架，當然也會廢棄一些老的做法。

4，5年前，公司的產品大面積移動化，剛好有個機會使用nodejs技術（原本作為純前端，在一家技術分工很細的公司，服務端甚至不是我的工作範圍，但是程序猿的生命可能在於不停折騰），當時雖然有一些反對聲音，但是因為我速度快，把這個東西變成既定事實（主要是當時確實也沒好的解決辦法，公司應該給配的後端開發人員在計劃時間內沒到位，並且也不可能短期內解決問題，我太熟悉那套API了，三下五除二就把事情給解決了，也就是把傳統的web spa大應用搬到移動端，因為環境不同，需要服務端多做點封裝），由於這幾年node確實火起來了，證明我當時沒有做錯。

當年反對node技術的就跟現在反對使用typescript一樣，不了解實情是沒有發言權的。一個js開發人員如果弄清楚es和dom的關係，那麼應該清楚，js只是一門簡單的嵌入式腳本語言，即是小小的開發工具，由於js設計的先天不足，造成的影響是十分深遠的（web的發展造就了js，而不是js那些特性），js本身可以被替代，只要dom api的使用方法方法跟原來保持一致就行了，所以在這點上從js到使用ts開發的轉變只需要幾分鐘，所有js代碼在ts里都是可「運行」的。

typescript絕對是好東西，不過推廣是有難度的：

1、TS是微軟製造，最好的開發工具是VS，想想有些人就激動了（什麼vi流，sublime流，macbook流，雖然也能寫ts，但你無法跟他們說用vs寫有多麼好）；

2、即使你告訴他們TS有多好，但是幾十人的團隊里總有一半以上的人不想學新的東西（當然我沒有權利說不學新東西的人應該全部滾動，因為互聯網打工的是大爺，想跳槽隨便找工作）；

3、JSer很多沒有學習OOP開發經驗（特別是從設計／頁面重構轉過來的）；

4、很多人接觸TS前根本沒學過JS，經常有人問「使用TS如何寫元素拖拽」這樣的問題（那是DOM API好伐，不過你跟初學者很難解釋明白）；

從 Coffee 的使用之廣泛來看，TypeScript 必然也是一個很有意義的項目。

與 CoffeeScript 相比，它們在「解決 JavaScript 糟粕」、「提高可讀性」等目標上相似，並且都是以預編譯的方式工作。不過，TypeScript 有一些先天的優勢：

  • 高度兼容原生腳本語法（甚至可以混著寫）
  • 對語法的破壞性較少，即使沒接觸過的人，也能很快上手，初次閱讀也沒有什麼障礙
  • 如名字所述，它講究基於介面的強類型，因此非常適合原本的伺服器開發者使用
  • 提供了大量編輯器的集成，有現有大量庫的 .ts 元文件可用

這是一個好玩而有用的工具，由於它是對腳本的預創建過程，並不給項目造成什麼大的改動（除了一些新增的 .ts 文件）。

不過，要在項目中大量推廣，還需要有項目成員的配合使用（在腳本文件的相互引用時，最好至少有 .ts 元文件），這可能存在一定的阻力。

在不少開源項目中，已經見到很多人在應用 TypeScript 了。

怒答。

TypeScript 是 JavaScript 的強類型版本。然後在編譯期去掉類型和特有語法，生成純粹的 JavaScript 代碼。由於最終在瀏覽器中運行的仍然是 JavaScript，所以 TypeScript 並不依賴於瀏覽器的支持，也並不會帶來兼容性問題。

TypeScript 是 JavaScript 的超集，這意味著他支持所有的 JavaScript 語法。並在此之上對 JavaScript 添加了一些擴展，如 class / interface / module 等。這樣會大大提升代碼的可閱讀性。

強類型語言的優勢在於靜態類型檢查，具體可以參見 flow.js/typescript 這類定義參數類型的意義何在？ - vilicvane 的回答。概括來說主要包括以下幾點：

1. 靜態類型檢查

2. IDE 智能提示

3. 代碼重構

4. 可讀性

TypeScript 雖然是強類型語言，但是如果對象被聲明為了 any 類型，就會忽略所有的類型檢查。這種靈活的結構保證了他可以在保證整體有強類型檢查優勢的同時，在一些細節問題上保持弱類型的靈活。

TypeScript 本身是開源的，這意味著開發者可以自由修改其源代碼，同時 TypeScript 的架構設計也很優秀，提供了充分的 API 介面方便開發者進行進一步擴展。順便說一下，TypeScript 編譯器本身是用 TypeScript 開發的。構建流程是先用舊版本的 TypeScirptCompiler.js 將新版本的 TypeScript Language 的 TypeScript源代碼編譯成新的 TypeScriptCompiler.js，聽起來很厲害的樣子。

由於其開源性，通過 TypeScript Compiler API，開發者可以自己實現編譯器（比如添加增量編譯和自動編譯，大幅提升編譯速度），自定義語法檢查，以及自定義輸出結構等。 由於編譯器核心靈活的結構，開發者只需要簡單的添加一些代碼，就可以在 IDE 中支持 TypeScript 的諸多特性。

順便打個廣告，白鷺引擎是基於 TypeScript 的開源 HTML5 遊戲引擎。白鷺引擎的後續版本會利用這些特性不斷完善引擎自身。舉例，我們的 IDE Egret Wing 就利用了 TypeScript Service API 實現了了代碼智能提示等功能。文檔生成工具也是通過擴展 TypeScript Compiler API 實現的。

總結：

我認為 TypeScript 是一項非常值得學習的新技術，由於他是 JavaScript 的超集，對 JavaScript 開發者來說入門門檻很低（相對於 Dart / CoffeeScript 等其他 JavaScript 變種來說 ）。

如果一定要找出幾個不用 TypeScript的原因。我能想到以下情況：

  1. 需要在 HTML 里大量嵌入 JavaScript 代碼，而非 HTML 和 JavaScript 分離。
  2. 熟練運用原型繼承，不喜歡 class 關鍵字
  3. 項目中大量依賴了第三方 JavaScript 類庫，並且這些類庫沒有 .d.ts 文件
  4. 「微軟雅黑」

TypeScript作為EcmaScript的子集，我覺得給javascript加上編譯期而不是運行時的類型檢查，有助於在相當程度上杜絕手賤發生的錯誤。而且class和interface的功能顯然比你手寫javascript要方便得多。最重要的是，TypeScript並不是強制要求類型的，所以所有javascript的代碼都能混在一起編譯，十分方便。

之前用egret寫遊戲的時候，去學了下typescript，作為javascript的超集，引入了class的寫法，並且定義變數和方法的時候要聲明數據類型，這個確實給javascript注入了一些活力，尤其是webstorm這種神IDE，支持了typescript，但是在學習成本上，讓一些沒有接觸過後台語言的前端們，形成一種思想可能會有些吃力。

官方定義：TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. Any browser. Any host. Any OS. Open source.

個人定義：TypeScript = Type + ES6

Type（類型）

靜態（static）：無需運行，根據程序代碼就能確定結果。

動態（dynamic）：只有運行才能確定結果。

類型：對某個數據所具有的性質進行的描述。如它的結構是怎樣的，能進行什麼操作。

靜態類型：數據擁有類型，且僅有數據擁有類型。

動態類型：數據擁有類型，存放數據的變數、表達式也擁有類型，且類型在編譯時是固定的。

表1：靜態語言和動態語言的比較

從表中可見，動態語言和靜態語言各有優劣，而TypeScript提供了靜態語言強類型支持，同時兼容動態語言弱類型的語法，使用者根據項目需求自由選擇。

這種動靜結合的特性，目前還沒在其他語言見過。

ES6

表2：ES6推薦特性一覽

來源：使用ES6進行開發的思考

現在ES6已經不是什麼新鮮技術了，編程語言的進化無疑會大大提高程序的健壯性、可維護性，提升程序員的開發效率。尤其是面向對象、模塊化等特性的語言級別支持，為JS開發大型應用提供了更多便捷。

TypeScript順應歷史潮流，全方位擁抱標準，其官方聲稱未來將持續支持ES6/7的新特性，這基本就避免了學到偏門技術的窘境~

有消息稱，新標準ES8將採用TypeScript的類型方案，如果屬實，也就是：TypeScript = Type + ES6/7 ≈ ES8

所以，個人還是比較看好TS的發展前景的，有興趣有項目的同學可以試試水~

----------------

以下為補充：

* 前面很多同學提到寫類型麻煩，其實藉助一些工具可以簡化這一工作，例如：VS Code 插件，JSON to Type

* 對後端同學來說，強類型、ES6這些特性都很習以為常了，但在前端領域，這些技術卻都是有里程碑意義的！在語言層面上，前端確實落後很多語言一個身段，好在近幾年發展很快，頗有點彎道超車的感覺~

* 要注意到，TS的競爭對手不是dart/coffee，而是Babel ！

* 最近發現，apple的swift也有動靜結合的類型特性，看來這是端語言以後發展的方向。swift的語法更是簡潔，感覺沒有一絲的多餘~

scripting language 雖然多沒有強制類型，有很多好處，但type同樣是極其有用的，沒有type，基本上programming by contract是不可能的事，項目越大越關鍵。這是為什麼PHP，Python後來都把類型系統加回來的原因：http://stackoverflow.com/questions/32557920/what-are-type-hints-in-python-3-5，http://php.net/manual/en/functions.arguments.php#functions.arguments.type-declaration

javascript也是一樣，因為現在的JS項目已經不是簡單寫個onclick = fn這麼簡單了。

時間證明，程序員需要type system，他們不喜歡強制的type system，optional types 是能走得很遠的中間道路，因為有了抽象能力，魯棒性，又不犧牲執行效率，開發效率，是魚和熊掌兼得的策略。

最近在用，個人覺得還不錯。

語法簡單易懂，功能豐富，工具鏈齊全。

缺點包括和JavaScript庫的整合問題（需要對每一個庫都有一個typed definition），不支持abstract class和mixin，默認庫不夠強大等

知道為什麼叫TypeScript嗎？就在於這個「Type」上，TypeScript最大的亮點就是強化了類型系統，這是ES 6不具備的。同時，TypeScript的類型推斷能力也很強。

TypeScript至ES5的代碼轉換器也是精心設計的，能把TypeScript代碼轉換成為所有瀏覽器都支持的ES 5代碼。

最愉快的暢想就是，哪一天再在JVM上搞個位元組碼編譯器出來。就能用TypeScript寫Java平台程序了。

簡單點說：一用就離不開。現在寫傳統的js都沒手感了。用 TypeScript，可能幾分鐘就重構一次，從沒有因為重構而出問題。傳統js嘛……你懂的。

@Canto Ostinato ：一個 Unsound 的語言還有什麼討論的意義嗎？你們這群人就是沒品。

我：問題是 JS 程序員比 TS 的還沒品，你要有品就所有 JS 庫都用不了。

用了幾個月的 TS 寫前端。

TS 在 1.4 前是殘廢。1.4 引入的 union types 和 type alias 算是非常重要的。沒有這兩個特性，TypeScript 能提供的編譯期類型檢查甚至還不如 JSDoc 的 type annotation 來得好用。尤其是沒有 type alias 的話，定義一個 callback 都要用 interface，實在蛋疼。

後來我用 TS 寫一個新的項目，把我寫的 TS 編譯成 JS 放到線上後，其他人紛紛表示不會 TS，修 bug 和加特性時直接在編譯出的 JS 的基礎上改了。我後來把變更一點點加回 TS 源文件的時候，不得不 diff 一下 JS 文件的變化，一行一行地在 TS 里對應著改，實在令人唏噓。

其實對我來說 TypeScript 令人不悅的一點是，官方明確指出，TS 不會提供任何 run-time type information 有關的特性。然而 TS 的工作場合就常常涉及把伺服器返回的 JSON 轉成 JS objects、把 cookie 轉成 JS objects 之類的事情，沒有 run-time type information 的支持，實在是最大最大的硬傷。運行時無類型信息這一點更是使得很多東西不得不在 run-time 手動去 cast，這使得編譯期帶來的類型安全保障蕩然無存。這幾點可參見我評論里補充的例子。

如果有 TypeScript 的超集或是擴展能夠提供 run-time type information 的話，那我想必是非常開心的。

UPDATE：

又見一個坑：居然去掉有用的特性…… 這回簡直連 Java 都不如了…… http://stackoverflow.com/questions/29199802/typescript-generics-reference-to-parameter-from-same-parameter-list

TypeScript有很好的工具

TypeScript的最大的賣點就是工具。它提供高級自動完成，導航和重構。擁有這樣的工具幾乎是大型項目的必備要求。沒有他們，改變代碼的恐懼使代碼庫處於半只讀狀態，並使大規模重構非常危險且昂貴。

TypeScript不是編譯為JavaScript的唯一類型語言。還有其他語言具有更強的類型系統，在理論上可以提供絕對強大的工具。但在實踐中大多數人除了編譯器之外沒有其他的東西。這是因為構建豐富的開發工具必須是第一天就明確的目標，它是針對TypeScript團隊的。這就是為什麼他們構建語言服務，可以由使用的編輯器提供類型檢查和自動完成。如果您想知道為什麼有這麼多編輯器具有很好的TypeScript支持，答案就是語言服務。

智能感知和重構提示(例如：重命名變數)對代碼編寫過程和重構過程的重要性是不爭的事實。雖然很難衡量，但我覺得現在之前要幾天時間的重構可以在不到一天的時間內完成。

雖然TypeScript大大提高了代碼編輯體驗，但它使得開發人員設置更加複雜，特別是與在頁面上放置ES5腳本相比。此外，您不能使用分析JavaScript源代碼的工具(例如JSHint)，但通常有足夠的替代品。

TypeScript是JavaScript的超集

由於TypeScript是JavaScript的超集，因此您無需經歷大量重寫即可遷移到JavaScript。你可以一個模塊一個模塊，逐步的遷移。

只需選一個模塊，將.js文件重命名為.ts，然後逐步添加類型注釋。完成一個模塊之後，再挑選下一個重構模塊。一旦編寫了整個代碼庫，就可以開始調整編譯器設置，使其更加嚴格。

這個過程可能需要一些時間，但是對於Angular來說，這還不是最大的問題。逐步遷移的過程，能夠讓我們保持開發新功能的同時來修復轉換過程中的bug。

TypeScript明確了抽象

一個好的設計是關於設計良好的介面。並且以支持它們的語言來表達介面的想法要容易得多。

例如，想像一個銷售書籍的應用程序，可以通過用戶界面的註冊用戶或通過某種API的外部系統進行購買。

正如你所看到的，這兩個類都扮演購買者的角色。儘管對應用極為重要，在代碼中沒有清晰的表達購買者的含義。沒有名為buyeraser.js的文件。因此，有人可能會在不知道這段代碼含義的情況下修改這個代碼。

function processPurchase(purchaser, details){ }

class User { }

class ExternalSystem { }

只通過看代碼來確定什麼對象可以充當購買者的角色，這個角色有什麼方法非常困難。我們不知道，我們不會從我們的工具中獲得很多幫助。我們必須人為推斷這個信息，這很慢，容易出錯。

現在，將其與我們明確定義購買者介面的版本進行比較。

interface Purchaser {id: int; bankAccount: Account;}

class User implements Purchaser {}

class ExternalSystem implements Purchaser {}

具有類型的版本可以清楚的表示，有一個購買者的介面，然後有兩個類實現了這個介面。所以TypeScript介面允許我們定義抽象/協議/角色。

重要的是要認識到，TypeScript不會強制我們引入額外的抽象。購買者抽象存在於JavaScript版本的代碼中，但沒有明確定義。

在靜態類型的語言中，子系統之間的邊界是使用介面定義的。由於JavaScript缺少介面，邊界並沒有在純JavaScript中表達出來。不能清楚地看到邊界，開發人員開始依賴於具體的類型而不是抽象介面，這代碼耦合度非常高。

在開發Angular的過程中，在轉換到TypeScript之前和之後的工作經驗，堅定了我的想法。定義介面，強制我去考慮API的邊界，幫助我去定義子系統的介面，並且暴露出耦合的地方。

TypeScript使代碼更容易閱讀和理解

是的，我知道這看起來不直觀。讓我試著用一個例子來說明我的意思。我們來看看這個函數jQuery.ajax()。們可以從簽名中獲得什麼樣的信息?

jQuery.ajax(url, settings)

我們唯一可以確定的是該函數有兩個參數。我們可以猜出這些類型。也許第一個是一個字元串，第二個是一個配置對象。但這僅僅是猜測，我們可能會錯。我們不知道什麼選項進入設置對象(他們的名字和類型)，或者這個函數返回什麼。

我們沒有辦法在不查看源碼或者文檔的情況下調用此函數。檢查源代碼不是一個好的選擇 - 功能和類的要點是能夠在不知道它們如何實現的情況下使用它們。換句話說，我們應該依靠他們的介面，而不是依靠它們的實現。我們可以檢查文檔，但它不是最好的開發人員體驗 - 它需要更多的時間，文檔往往是過時的。

所以雖然很容易讀取jQuery.ajax(url，settings)，要真正了解如何調用這個函數，我們需要讀取它的源碼或其文檔。

現在，將其與類型版本對比

ajax(url: string, settings?: JQueryAjaxSettings): JQueryXHR;

interface JQueryAjaxSettings {

async?: boolean;

cache?: boolean;

contentType?: any;

headers?: { [key: string]: any; };

//...

}

interface JQueryXHR {

responseJSON?: any; //...

}

它給了我們更多的信息。

  • 這個函數的第一個參數是一個字元串。
  • settings參數是可選的。我們可以看到可以傳遞給函數的所有選項，不僅僅是它們的名字，還包括它們的類型。
  • 該函數返回一個JQueryXHR對象，我們可以看到它的屬性和函數。

鍵入的簽名肯定比無類型的簽名更長，但是：string，JQueryAjaxSettings和JQueryXHR並不混亂。它們是提高代碼可理解性的重要文檔。我們可以在更大程度上了解代碼，而無需深入實施或閱讀文檔。我個人的經驗是，我可以更快地讀取類型化代碼，因為類型提供了更多的上下文來了解代碼。但如果任何讀者可以找到關於類型如何影響代碼可讀性的研究，請發表評論。

與其他編譯為JavaScript的語言相比，TypeScript的類型是可選的，jQuery.ajax(url, settings)仍然是有效的typescript。所以並不是非開即關，TypeScript更多的是增強。如果發現代碼在讀取和理解時沒有類型注釋是微不足道的，請不要使用它們。只有在增加價值的情況下使用他們。

TypeScript是否限制表達?

動態類型的語言具有較差的工具，但它們更有韌性和表現力。我認為使用TypeScript會使得你的代碼死板，但遠比想像的程度要低。讓我告訴你我的意思。假設我使用ImmutableJS定義個人記錄。

const PersonRecord = Record({name:null, age:null});

function createPerson(name, age) {

return new PersonRecord({name, age});

}

const p = createPerson("Jim", 44);

expect(p.name).toEqual("Jim");

我們如何確定記錄的類型?讓我們來定義一個Person介面。

interface Person { name: string, age: number };

如果我們嘗試執行以下操作：

function createPerson(name: string, age: number): Person {

return new PersonRecord({name, age});

}

TypeScript編譯器就會警告，因為編譯器不知道PersonRecord和Person類型兼容。一些有函數式編程經驗的人會說：「TypeScript只有依賴類型!」。但是不是這樣的。TypeScript的類型系統不是最先進的。但它的目標是不同的。這不是證明程序是100%正確的。它更多的是提供給你更多的提示信息和啟用更強大的工具。所以當類型系統不夠靈活時，可以採取快捷方式。所以我們可以轉換創建的記錄，通過下面這樣：

function createPerson(name: string, age: number): Person {

return &new PersonRecord({name, age});

}

類型實例：

interface Person { name: string, age: number };

const PersonRecord = Record({name:null, age:null});

function createPerson(name: string, age: number): Person {

return &new PersonRecord({name, age});

}

const p = createPerson("Jim", 44);

expect(p.name).toEqual("Jim");

這段代碼能夠正常運行是因為類型系統是結構化的。只要創建的對象具有正確的屬性-name和age，就能正常運行。

你需要以擁抱的心態去使用TypeScript的快捷方式。只有這樣，你會發現使用這種語言非常的愉快。例如，不要嘗試添加類型到一些時髦的元編程代碼 - 很可能你將無法靜態地表達。遇到這種情況，可以配置類型檢查忽略他們。這種情況下，你的代碼不會失去太多的表達力，同時又具有工具化和可分析的特性。

這類似於試圖獲得100%的單元測試代碼覆蓋率。而95%通常不是那麼困難，100%可能是具有挑戰性的，可能會對您的應用程序的體系結構產生負面影響。

可選類型系統還保留了JavaScript開發工作流程。您的應用程序代碼庫的大部分可能會「損壞」，但您仍然可以運行它。TypeScript將繼續生成JavaScript，即使類型檢查器提示錯誤。這在開發過程中非常有用。

為什麼使用TypeScript?

今天有很多選項可供前端開發人員使用：ES5，ES6(Babel)，TypeScript，Dart，PureScript，Elm等。所以，為什麼選擇TypeScript?

讓我們從ES5開始。ES5跟TypeScript相比，他不需要轉換。這樣可以使得你的構建設置保持簡單。你不需要添加文件監視器，轉換代碼，生成source map。它就能工作。

ES6需要一個轉換器，所以構建設置與TypeScript不會有很大的不同。但它是一個標準，這意味著每一個編輯器和構建工具都支持ES6或將支持它。這是一個較弱的論據，它曾經是大多數編輯器在這一點上具有優秀的TypeScript支持。

Elm和PureScript是具有強大類型系統的優雅語言，可以提供比TypeScript更多的功能。用Elm和PureScript編寫的代碼可能比ES5中類似的代碼更簡單。

每個這些選項都有利弊，但我認為TypeScript是一個很好的選擇，使其成為大多數項目的絕佳選擇。TypeScript佔用良好靜態類型語言的95%，並將其帶入JavaScript生態系統。你仍然可以寫ES6：你仍然可以繼續使用相同的標準庫，相同的第三方庫，相同的成語和許多相同的工具(例如，Chrome開發工具)。它給了你很多，而不會強迫你離開JavaScript生態系統。

TS應該算是Js的未來

JSer 就是不願意承認 JS 爛，這是病，得治啊。

不要成為語言的信徒……

TS 是超集啊，超集的意思就是 JS 有的 TS 都有，並額外提供了功能。

買一送一你都不要嗎？

樓上都回答得差不多了。

我只想補充兩點：

1、自從用了 ts 我再沒碰到過運行時錯誤。

2、ts 的多種 target 輸出能力，可以讓它開發的後端代碼從 Node 0.12 直接適應到最新的 Node 8

真的很棒。

如果實踐過上萬行的js代碼寫在一個文件里，然後再試試TypeScript，就會發現簡直是到了天堂！太爽了！！！

肯定前端大一統的未來

小型項目活動之類的用什麼都無所謂

大型項目對開發人員要求比較高的語言都不是好語言，尤其是看似上手快的，需要的東西始終需要

比如javascript 比如python

讓現在面向對象開發者無痛銜接未來的js，而不會弄髒手。

這本應是adobe，ActionScript的使命，結果被作死了，現在看微軟了。

推薦閱讀：

※如何在 React 中運用 CSS？
※如何評價Knot.js?
※為什麼沒有人出JS版的數據結構與演算法？
※JS模塊載入器載入原理是怎麼樣的？
※HTML 標籤屬性的全稱？

TAG:前端開發 | 微軟Microsoft | JavaScript | TypeScript |