TypeScript 纪录片心得 — 开创微软的开源之路

2023年9月22日

💎 加入 E+ 成長計畫 如果你喜歡我們的內容,歡迎加入 E+,獲得更多深入的軟體前後端內容

在社群引颈期盼下,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 是一个从需求而生的程式语言 (为了解决微软当时开发上遇到的问题),加上拥抱开源,以及积极倾听使用者的声音,让它得以成为现今网页应用开发的首选。以上摘要了这个精彩的纪录片,再次推荐大家可以自己看一遍,看完后也欢迎分享你的心得!

🧵 如果你想收到最即時的內容更新,可以在 FacebookInstagram 上追蹤我們