TypeScript 這十年

【CSDN 編者按】很多時候,僅從名稱上來看,不少人對 TypeScript 與 JavaScript 傻傻分不清楚,或許只知道 TypeScript 作為 JavaScript 的後來者,想要將其取而代之,卻時至今日未能如願。

殊不知,TypeScript 誕生落地發展到當下,已有十年的時間。雖然未能達到 JavaScript 流行的高度,但也彌補了其不少不足之處。近日,微軟 TypeScript 高級項目經理 Daniel Rosenwasser 在官網發文分享了 TypeScript 從早期到時間考驗再到今天的整個演進歷程,也帶來了不一樣的思考。

原文地址:https://devblogs.microsoft.com/typescript/ten-years-of-typescript/

編譯 | 蘇宓

以下為譯文:

今天是 TypeScript 的生日!但是這個生日很特別——10 年前的今天,2012 年 10 月 1 日,TypeScript 首次公開亮相。

早期的情況

早期的情況

當 TypeScript 首次亮相時,有很多人持懷疑態度,這也是可以理解的。對於一些 JavaScript 使用者來說,一個試圖將靜態類型引入 JavaScript 的團隊可能聽起來像是一個邪惡的組織,甚至可視為一個陰謀或笑話。

但是這些功能是有價值的,對嗎?類型檢查,在你保存檔案之前捕捉 Bug,並獲得豐富的編輯器功能,如程式碼完成、導航和重構?我們知道公司內外部的團隊在處理複雜的 JavaScript 程式碼庫時遇到了巨大的挑戰,而且我們知道 JavaScript 將被廣泛使用。因此,誰不希望有強大的工具來幫助編寫它呢?對於團隊來說,TypeScript 初心未變,一如最初在發佈 TypeScript 時所述的那樣,「在大型應用開發中使用 JavaScript 開發!”。

幸運的是,這個願景使得很多的開發者產生了共鳴。在早期,我們建立了一個小而勤奮、熱情的社區,當我們還在迭代、學習和構建一個甚至還沒有達到 1.0 的東西時,很多人就願意參與進來,進行實驗和體驗。我們看到了令人興奮的新努力,如 DefinitelyTyped 項目,新的社區成員在 StackOverflow 和我們的問題跟蹤器上提供幫助,創作者為該語言編寫書籍和教程,以及押注 TypeScript 的新庫。這些有耐心、努力工作、精力充沛的開發者為 TypeScript 社區的發展奠定了基礎。

不過,大多數 JavaScript 開發人員對 TypeScript 仍持懷疑態度。那麼,這個團隊要如何說服 JavaScript 開發者相信靜態類型在動態類型語言中的價值?

“類型與無類型”一直是一個有爭議的話題,這在程式設計界至少可以追溯到半個世紀以前。

但是,我們真的想通過類型的力量來創造令人驚奇的 JavaScript 工具。

這能做到嗎?

經得起時間的考驗

經得起時間的考驗

事實是,這需要一種與我們習慣的完全不同的開發方法,其次是需要大家堅持不懈、拓展性和同理心。TypeScript 必須是免費和開源的,並以真正開放的方式進行。它還必須與現有的 JavaScript 無縫互通,與 JavaScript 共同發展,並且感覺像 JavaScript。

TypeScript 從未打算建立一種單獨的、獨特的、規定性的語言。相反,TypeScript 必須是描述性——圍繞 JavaScript 生態系統中一些模式進行類型系統的創新。這讓我們能夠滿足人們的需求,而且這種理念與項目的設計目標非常吻合。

實際上,TypeScript 的設計目標保持得如此之好,令人驚訝。

例如,一些設計目標:

  • “不會對發出的程序施加任何運行時開銷。”

  • “與當前和未來的 ECMAScript 提案保持一致。”

  • “保留所有 JavaScript 程式碼的運行時行為。”

  • “避免增加表達式級別的語法。”

  • “使用一致的、完全可擦除的、結構化的類型系統。”

所有真正指向 TypeScript 只是簡單地成為 JavaScript 的類型檢查器,只添加類型檢查所需的語法。

因此,我們主要關注類型系統,而避免增加新的運行時語法和行為。這在 10 年後的應用中,體現地可能更明顯,但程式語言經常試圖根據他們的可運行程式碼的樣子來區分自己。此外,很多類型化語言根據類型來指導他們的運行時行為。

但是,這些方法在試圖建立在 JavaScript 的基礎上,並與之整合時,就沒有意義了。沒有類型的 JavaScript 在粘貼到 TypeScript 檔案中時,必須有相同的工作方式,而且將 TypeScript 轉換為 JavaScript 需要像剝離類型一樣容易。我們在早期採取了一些錯誤的措施才意識到這一點,但這是一個學習的機會,並且微軟團隊在 10 年的大部分時間裡都避免了運行時語法。

如今,當 TypeScript 缺少一個有用的運行時特性時,我們不會只在 TypeScript 中添加它。我們在 TC39(JavaScript 標準機構)內開始實踐,指導或倡導新的功能,以便所有的 JavaScript 開發人員能夠從中受益。

另一個成功的原則是,TypeScript 並沒有試圖成為工具箱中的每一個工具。我們的一個非目標是不 “提供一個端到端的構建管道。相反,使系統具有可擴展性,以便外部工具可以使用編譯器進行更復雜的構建工作流程”。

有很多時候,TypeScript 被要求成為一個 linter、一個 bundler、一個最佳化器/minifier、一個構建協調器、再一個 bundler 等等。這些界限並不會每次被明確,尤其是當 TypeScript 作為一個類型檢查器、編譯器和語言服務已經做了很多。在 JavaScript 生態系統中,很多人參與到應用程序開發的最佳實踐爭鬥中,由此 TypeScript 也不斷地保持了靈活性,這一點非常重要。

考慮到過去幾年中,所有不同的捆綁器、不同的運行時、不同的構建協調器和不同的鎖定器,TypeScript 與其中的每一個都很好地整合了,並沒有試圖取代其中的任何一個,這一點也至關重要。我們很榮幸能與這個領域的工具作者合作,因為我們都在努力使 TypeScript 和 JavaScript 更容易使用。

回到今天

回到今天

今天,TypeScript 是一種蓬勃發展的語言,全世界有數百萬的開發人員在使用。在 StackOverflow 的年度調查、GitHub 的 Octoverse 報告和 Redmonk的語言排名等調查和語言排名中,TypeScript 一直處於開發者最常用和最喜愛的語言中的 Top 10。

當然,背景很重要——TypeScript 的使用從根本上與 JavaScript 的使用交織在一起,每個 TypeScript 開發者也是 JavaScript 開發者。值得慶幸的是,即使在詢問 JavaScript 開發人員是否使用 TypeScript 並喜歡它時,比如在 JS 的狀態調查中,答案也都會是 “是”!TypeScript 的成功是一個很好的例子。

今天的成功遠遠超過了核心團隊幾年前對 TypeScript 的想象,更不用說十年前了。核心團隊在 TypeScript 上努力工作,但我們知道,實現這一成功的根本原因是社區。這包括 TypeScript 的外部貢獻者、在 TypeScript 上下注並證明該語言的庫創建者和日常開發者、DefinitelyTyped 的貢獻者、社區組織者、花時間回答問題和教導他人併為新人開闢道路的專家。

也希望 TypeScript 的下一個 10 年能給你帶來好的待遇!

相關文章

Python 與 JavaScript 做比較公平嗎?

Python 與 JavaScript 做比較公平嗎?

在討論應該使用 Python 還是 JavaScript 構建項目時,一般我們都不會說只使用一種程式語言來構建所有的元件。 在現代軟體開發中...

最強 AI ChatGPT 真要取代程式設計師?

最強 AI ChatGPT 真要取代程式設計師?

【CSDN 編者按】ChatGPT 一出,「程式設計師要失業了」、「程式設計師要下崗了」之聲不絕於耳,引得程式設計師們不由得一陣驚慌,最強 ...