出品 | CSDN（ID：CSDNnews）
作為 Javascript 的一個超集，Typescript 在微軟內部沉淀兩年后，帶著彌補 Javascript 在開發大型應用中遇到的種種問題的使命，于 2012 年 10 月正式面世。然而，近幾年來，曾經如日中天的 Typescript，接連受挫，遭到各個社區與應用的摒棄。前有 Svelte 創建者 Rich Harris 選擇從 Typescript 轉向 Javascript 和 JSDoc，今有 Ruby on Rails 的創建 DHH 在多平臺發布聲明，宣布「再見了，Typescript！」這也讓眾人深感好奇，Typescript 怎么就成為了開發者眼中“不值得”的技術之一？DHH 發布聲明：Turbo 8 正在放棄 Typescript！在開發圈，也許不少人對 DAVID HEINEMEIER HANSSON（簡稱 DHH）并不陌生。他被人們視為軟件天才，以開發了開源項目 Ruby on Rails 而被眾人熟知，Hulu、GitHub、早期的 Twitter 都使用了這種框架。同時，DHH 也帶來了一款軟件即服務的產品 Basecamp，擔任 37signals 的 CTO，是一位長期活躍的社交媒體用戶和暢銷書籍的作者。他官宣棄用 Typescript 后，這一決定首先會應用在 Javascript 庫 Turbo 8 身上。Turbo，是一種用于傳遞 HTML 頁面的框架，指集成了幾種技術以創建快速的、現代的、漸進式增強的 Web 應用而不需要使用太多的 Javascript。借助 Turbo，你讓服務端直接發布 HTML。對此，DHH 表示，“從各方面來看，Typescript 對微軟來說都是一個巨大的成功。我看到很多人因為 Javascript 中加入了可由編譯器檢查的顯式類型而歡欣鼓舞。但我從來都不是它的粉絲。五分鐘后不會喜歡，五年之后也不會喜歡。因此，我非常高興地宣布，我們將在 Turbo 8 的下一個大版本中刪除 Typescript。”Typescript 替代不了 Javascript相較之下，DHH 坦言，他其實更喜歡 Javascript。「我甚至可以說它是繼 Ruby 之后我第二喜歡的語言。不過，更早之前并非如此，但自從 Javascript 中有了適當的類，以及 ES6 之后的所有其他改進之后，編寫 Javascript 就成了一種真正的樂趣」，DHH 寫道。Javascript 雖然不適合在網絡應用程序的服務器端所做的大部分工作，但現在擁有如此強大的 Javascript，瀏覽器無需編譯器就能解釋它，這是讓 DHH 感到非常幸運的地方。現如今之所以放棄 Typescript，和過往很多人一樣，DHH 透露主要是因為 Typescript 的「類型」。他的博客中寫道：對我來說，Typescript 就是個障礙。不僅因為它需要一個顯式的編譯步驟，還因為它用類型污染了代碼，給我的開發體驗帶來的快樂少之又少，而且經常會帶來相當大的痛苦。本應簡單的事情變得困難，而困難的事情變得"無處不在"。不過，這并不是要讓任何人改變什么。正如我在《編程類型與思維方式》一文中所討論的，通常很少有程序員有興趣改變他們對類型的看法。大多數程序員都會在職業生涯的早期就發現自己強烈地傾向于或不傾向于 Typescript，然后在余下的時間里向自己和他人解釋 "正確的選擇"。這就是 Javascript 與 Typescript 二分法的魅力所在，Typescript 的支持者意識到完全替代 Javascript 是不可能的，所以從一開始就必須實現完全兼容，這一點值得稱贊。Turbo 8 棄用 Typescript 并不意味著你不能用它編寫客戶端代碼，或使用任何其他采用它的庫。我們可以混搭使用，這很好。這也是必要的。因為 Javascript 與 Ruby 等語言不同，后者是服務器端的首選語言，而 Javascript 則是客戶端的必需語言。雖然你可以將方言編譯到 Javascript 中，但你仍然必須接受這樣一個事實：在瀏覽器中運行代碼就意味著運行 Javascript。因此，在這種情況下，能夠不使用任何工具、不使用任何強類型來編寫 Javascript 是一件幸事。所以，再見了，Typescript。愿你為你的部落帶來更多嚴謹和滿足，同時讓我們其他人享受 Javascript 最初設計時的光榮精神：沒有強類型。因為”類型“，越來越多的人加入了放棄 Typescript 的隊伍事實上，DHH 并非是第一個宣布不想再用 Typescript 的開發者。早在 2020 年，Deno 宣布棄用 Typescript，還給出了五個理由：
- 當更改文件時，Typescript 的編譯需要幾分鐘，這使得項目文件的連續編譯非常緩慢。
- 在創建實際的 Deno 可執行文件和面向用戶的 API 文件時，使用的 Typescript 結構會造成項目運行的性能問題。
- 事實證明，Typescript 本身對 Deno 代碼管理沒有幫助，并且 Deno 團隊正經受著相反的效果。在項目的議題列表中就提到一個問題：在兩個不同的位置產生了相同的獨立主體類。
- 必須手動保持內部代碼和運行時 Typescript 聲明的同步，因為 Typescript 編譯器對生成 d.ts 文件沒有幫助。
- Deno 團隊需要去維護兩臺 TS 編譯器主機：一個用于內部代碼，另一個用于外部用戶代碼，盡管兩者的目標相似。
除此之外，也正如文章伊始所提及的，Svelte 創建者 Rich Harris 認為 Typescript 對開發庫來說“不值得”，所以讓團隊選擇從 Typescript 轉向 Javascript 和 JSDoc。在他看來，“類型確實很棒，但 Typescript 有點麻煩……一旦用上了.ts 文件，就必須同時使用支持它的工具……所以我逐漸覺得，使用 Typescript 這樣的非標語言并不值得。于是，我們開始將所有類型都放入 JSDoc 注釋，這樣既保證了類型安全，又回避了缺點。畢竟這只是 Javascript，所有內容都在注釋當中，只要運行代碼就行。我們在 Sveltekit 代碼中就是這么做的，效果非常好。所以對于 Svelte 4.0，我們也將采取同樣的思路、借此加快開發速度。”不久之前，redux-saga 的工程師 Eric Bower 發布了一篇《Typescript 對于庫開發人員來說很糟糕》的文章，其中他從 Typescript 的說明文檔、調試、復雜性、測試等多個維度分享了對 Typescript 的不滿。Eric Bower 表示，”類型會給庫添加大量代碼......我發現相較于編寫庫代碼，我花在類型調整上的時間要多得多。我精通 Typescript，但我不是專家。令人沮喪的是，在花了多年時間編寫 Typescript 代碼之后，我仍然不具備作為庫開發人員使用 Typescript 所需的知識。精通似乎是一個上手 Typescript 的門檻。這里的萬惡之源就是類型，它讓 js 庫維護變得困難重重，斷絕了后續開發者的貢獻參與通道。“不過，并非所有開發者都對 Typescript 的類型避而不見，在 HN 上，也有很多程序員展開了激烈的討論。其中，一位名為 waterluvian 的用戶表示：多年來，我一直對 "會拖慢我速度的額外復雜層 "有抵觸情緒，后來我采用了 TS，現在我已經離不開它了。因此，作為一個粉絲，當我讀到這樣的事情時，我會盡力去換位思考，試著從他們的角度去理解。但在這種情況下，我真的很難做到。我知道它增加了一些復雜性。但如果沒有它，你又能得到什么呢？這并不是說類型會消失。它們不會消失。它們只是變得隱蔽了。它把計算機擅長的東西塞進了你的大腦。正如很多人指出的：類型更多的是一種文檔。但除了這些（我覺得這是最重要的一課）：當支持率達到 100:1，你可能就錯了。但有時你最多只能說："我根本不了解你們這些人，但你們是絕大多數，所以不管我喜不喜歡，我都必須保持現狀"。對于 DHH 此次棄用 Typescript，在 GitHub pull request 板塊，也有用戶評論道：“我不確定刪除 Typescript 是否是最好的方法。對我來說，Typescript 對我的貢獻確實很大，而且我覺得在庫級代碼中使用它仍然很有意義。你從中獲得的 DX 真的很有價值，實際上有助于捕捉 bug。但我也明白，在某些情況下，它很快就會變得很煩人。但完全刪除類型（即使沒有 JSDocs 和/或 .d.ts 文件）對于庫用戶和貢獻者來說都是一種退步。”
參考：
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01
https://devclass.com/2023/05/11/typescript-is-not-worth-it-for-developing-libraries-says-svelte-author-as-team-switches-to-javascript-and-jsdoc/
該文章在 2023/9/13 15:15:43 編輯過
400 186 1886
