TypeScript 紀錄片心得 — 開創微軟的開源之路

在社群引頸期盼下，OfferZen Origins 終於正式推出 TypeScript 紀錄片。這部紀錄片訪談了 TypeScript 的創作者，包含大家耳熟能詳的 Steve Lucco 與 Anders Hejlsberg 以及在 TypeScript 社群有名的開發者們。必須說現在程式界的紀錄片都拍得很精彩，非常推薦大家一看。

在推出 TypeScript 的 2023 年，這個程式語言幾乎是多數寫 JavaScript 團隊的選擇。特別是對大型 JavaScript 程式碼庫而言，TypeScript 讓程式碼更好維護。然而，微軟 (Microsoft) 當初為什麼投入資源開發這個程式語言? 為什麼又選擇開源? 而 TypeScript 又如何成為 JavaScript 開發者的主流選擇? 這個紀錄片很完整地為我們梳理這段歷史

微軟為什麼開發 TypeScript?

要了解微軟為什麼開發 TypeScript，要先從宏觀的角度看。TypeScript 是在 2012 年正式被推出的，在那之前微軟的 Words、Excel 等產品，都是用 C++ 寫的，基本上跟 JavaScript 沾不上邊。更早以前 JavaScript 基本上只是被用來處理瀏覽器中簡單互動的程式語言，因為瀏覽器功能受限，大家不認為這個程式語言有什麼發展性。

然而，隨著瀏覽器越做越強大，2004 年 Google 透過 AJAX (非同步的 JavaScript 與 XML) 催生了 Gmail 這款跨時代產品，也正式開啟網頁應用程式 (web app) 的時代。2006 年亞馬遜推出 AWS，開起了雲端時帶。隨著瀏覽器與雲端逐漸發達，到了 2010 年，多數原本只是桌上型的軟體產品，開始移往瀏覽器。

而要寫出能在瀏覽器運作的程式，JavaScript 是當時的首選 (今天雖然有其他選擇，但 JavaScript 仍是首選)。只是，要把本來用 C++ 寫的那些軟體產品搬移成 JavaScript，對微軟的開發者們是個惡夢。原因很簡單，JavaScript 是個弱型別的語言，沒有型別檢查，很容易在寫程式時，有錯但難以發現。

也因為如此，在大型的程式碼庫的開發過程，會讓開發者不敢重構程式碼，因為不知道會不會改了 A 導致 B 壞掉。沒有型別檢查，在改的時候出問題不會報錯，只能等程式進到執行環境才知道有錯。但進到執行環境才發現錯誤通常太晚了。

當時在微軟內部出現許多花式的解決方法，舉例來說他們寫了一個 Script# 轉譯套件，先用 C# 寫，寫完後轉譯成 JavaScript。又或者有其他團隊先用 Java 寫，再把程式轉成 JavaScript。這類奇耙做法，不是因為做法本身好，只是因為大家不敢用 JavaScript。顯然這並非長久之計，於是當時微軟內部形成了一個由 Steve Lucco 帶領的團隊，決定要解決這問題。

TypeScript 的設計哲學

Steve Lucco 當時去找了微軟的程式語言設計大神 Anders Hejlsberg 幫忙 (基本上 Turbo、C# 與 .Net 都是他主持設計的)。一開始 Anders Hejlsberg 對於開發一個新語言這個決定感到遲疑；但在深入了解，得知原來開發者需要用各種繞彎的方式寫 JavaScript，他意識到確實需要一個全新的型別系統 (type system) 來解決 JavaScript 的問題，於是加入幫忙設計 TypeScript 這個語言。

關於解決 JavaScript 的問題，一個做法是開發一個全新的語言，例如 Google 開發的 Dart 語言。另個做法是針對 JavaScript 的問題打造一個補足的系統。TypeScript 團隊認為，JavaScript 是個有許多問題，但也不是那麼糟糕的語言。基於這點， TypeScript 團隊不是從打造全新語言，而是從如何補足 JavaScript 不足的角度出發。

TypeScript 本身是 JavaScript 的超集 (superset)。意即你可以在 TypeScript 裏面寫 JavaScript，這讓原本寫 JavaScript 的人可以一步步把程式碼轉成 TypeScript，不用一次遷移。而在有了型別的助力，從此開發者不用擔心型別問題在執行環境才被發現，要重構程式碼也變得更安心。

除此之外，因為有型別，讓 IDE 的自動補全程式碼功能變得更好。假如沒有型別，變得只能用猜的，就會讓跳出的補全選項品質參差不齊。但是如果有型別，就能很確定可以補全的選項，也讓補全的品質變得很好。TypeScript 當時跟微軟的 IDE 產品 VS Code 團隊合作共同開發，兩者在當時都是新的團隊，但彼此相扶相承，在將近十年後的今天，TypeScript 與 VS Code 幾乎是最多開發者使用的微軟產品。

開創微軟開源之路

TypeScript 最開始出現是為了解決微軟內部開發時遇到的問題。但他的創作者希望這個程式語言能夠不只停在微軟。而 TypeScript 能如此普及的一個關鍵點，是從最開始就開源。這是 Steve Lucco 跟 Anders Hejlsberg 在最開始就堅信的，他們認為想要讓開發者群採用，就必須開源。然而，光是要說服微軟開源這件事，TypeScript 團隊就花了半年。你沒看錯，要不要開源這件事，竟然要花半年來說服管理層！

在 2023 年的今天看會覺得怎麼需要想，肯定是要開源的，怎麼需要花那麼多時間與力氣來說服? 原因是開源這件事在當時的微軟並不容易，這是根基於微軟最開始的商業模式就是賣專有軟體 (proprietary software)，意思是微軟賺錢的命根，就是那賣出去一套又一套的 Windows、Words、Excels 等產品。要說服高層做一款開源、讓大家免費用，而不是賣錢的軟體，這與微軟的商業模式有極大的衝突。

能說服讓 TypeScript 開源，以及讓微軟這幾年在開源社群能夠發展如此蓬勃，蓬勃到甚至後來買下 GitHub 這間以開源程式碼聞名的公司，這之中的核心轉變，是因為微軟的商業模式在那時逐漸轉變。過去微軟是賣專有軟體，但現在的微軟金雞母之一 Azure 則是反過來賣幫你管軟硬體的雲端服務。

以雲端伺服器來說，你大可自己買機器，在自己的公司架伺服器，但那很麻煩，要確保不會突然天災或停電導致你的伺服器停止運轉；而 Azure 做的事，就是讓你付錢由他幫你打理好一切 (對這塊不熟的人，可以參考《從蛋糕店的例子，搞懂 IaaS、PaaS、SaaS、FaaS》 一文)

因為這轉變，微軟不再是看每個微軟做的軟體能賺多少；而是反過來，把好的軟體產品開源，讓使用者大幅增加，這時微軟再賣說「你可以自己託管，但比較麻煩，而且你託管也是有成本；不如用我幫你都託管好的，每個月付點訂閱費，或是按需求付費就好，輕鬆又划算」。

在微軟商業模式轉變的歷史脈絡，以及 TypeScript 團隊努力說服之下，TypeScript 得以開源。然而開源不是容易的事，在《React 紀錄片心得 1 — 重新思考最佳實踐》一文中，我們有摘要過 React 這個現在最火紅的開源專案，當時受到多大的挫折。而在 TypeScript 開山之下，微軟後續的其他開源項目，有了良好的基礎，進而打造今天龐大的開源帝國。

傾聽使用者的聲音

除了 TypeScript 本身解決 JavaScript 存在的問題外，TypeScript 能夠在眾多解決方案中，逐漸成為社群中的熱門選項，一個關鍵在於 TypeScript 團隊很願意傾聽使用者的聲音。舉例來說，網頁應用程式主流框架之一的 Angular 團隊，原本打算自己寫一個 AtScript，而 TypeScript 得知後，去跟 Angular 團隊說，你們要做的這個就是我們在做的是，不如我們來合作吧，這也促成 Angular 成為首個預設使用 TypeScript 的前端框架。

除了最開始合作的 Angular，針對其他熱門前端框架，TypeScript 團隊也很積極去了解如何可以跟他們更好的合作，包含 Knockout、React，以及 Vue 等主流前端框架，都有與 TypeScript 團隊的密切合作。而在伺服器端，目前新興的 JavaScript 執行環境 Deno 與 Bun 都原生支援 TypeScript，這也是因為 TypeScript 團隊花很多精力與這些執行環境的團隊合作。

這些合作過程中，TypeScript 積極傾聽不同團隊的聲音，確保 TypeScript 的設計與功能符合這些不同框架的需求。這也讓現在不管是網頁前端與後端，不管用什麼框架，TypeScript 都是多數開發團隊的首選。

小結

總的來說，TypeScript 是一個從需求而生的程式語言 (為了解決微軟當時開發上遇到的問題)，加上擁抱開源，以及積極傾聽使用者的聲音，讓它得以成為現今網頁應用開發的首選。以上摘要了這個精彩的紀錄片，再次推薦大家可以自己看一遍，看完後也歡迎分享你的心得！