Exploring the TypeScript Compiler Part 3: Why TypeScript?
本記事は tskaigi 2026 Day2の制約と時代から読み解くTypeScriptコンパイラ設計史の増補改訂版の Part 3です。
- Part 0: Overview
- Part 1: Why Go?
- Part 2: Inside the TypeScript Compiler
- Part 3: Why TypeScript?
- Part 4: Roslyn and the Red-Green Tree
- Part 5: JavaScript Madness🫠（Coming soon）
- Part 6: What Changes with Go（Coming soon）
今シリーズの Part1ではなぜ TypeScript コンパイラは Go で Port されたのか、Part2ではそもそもどんな動作原理なのかを追ってきました。Part3ではそもそもなぜ TypeScript が生まれたのか、周辺の出来事をたどっていきます。
TypeScript の1.0が公開されたのは2014年の4月であり、内部開発の開始はおおよそ2010年頃だと言われています。そこに至るまでにどんなことがあったのか追ってみましょう。
TSまでの道
2004 ~ 2006 Ajax革命
Google から2004年に Gmail、2005年に Google Maps など画期的な Web アプリケーションが公開されました。いわゆる Ajax 革命というやつです。
Web ページが単なる文書ビュアーからアプリケーションへ変貌していく起点となったと言われています。
2008 ~ 2010 JS高速化戦争
2008年9月には Google が V8を公開し、それを搭載したブラウザ Google Chrome もリリースします。公開直後のスナップショットではベンチマークの一つでIE7の15倍のパフォーマンスも記録しています。V8の登場により、JavaScriptCore や SpiderMonkey といった JS エンジン間の高速化競争がさらに激化します。
Node.js が登場したのも2009年ごろの話です。
2009 ~ 2010@Microsoft
ではこの頃 TypeScript の開発元である Microsoft は何をしていたのでしょうか。その内部事情が語られていたのが TypeScript Origins: The Documentary です。
ドキュメンタリーによると JS エンジンの高速化に伴ってもちろん IE の JS エンジン Chakra もどんどん改善が進んでいきました。その影響で JavaScript でより巨大なソフトウェアを作るという方向はもはや避けられなくなりました。 Microsoft も例外ではなく、主力製品であるデスクトップアプリケーションの Web 移植を迫られます。
しかしながら、2010年ごろの JavaScript は開発体験が他言語に比べて圧倒的に貧弱だったと語られています。C++ や C#で作られた数十万行の製品を移植するには、とても耐えられるものではありません。 そこで移植作業に使うエディタから JS で作り始めますが、あまりにデバッグがしにくく困り果ててしまいます1。
当時の選択肢
当時この問題に対するアプローチは大きく2つでした。
1. 別言語からJSへコンパイル
別言語から JS にコンパイルすることで JS を遠ざけるということでした。
- Script# (C# -> JS)
- CoffeeScript
といったツールを使って回避するという動きでした。
2. JS自体を置き換える
これに該当するのが Google の Dart です。現在は Flutter の台頭で知られていますが、元々は JavaScript の置き換えを目指していました。V8に関わった人物が Dart を作り、ブラウザに Dart VM を搭載する計画もありました。しかし、この計画は最終的に頓挫します。
Dart の野望
Dart が新言語として発表されること自体は、以前から外部に知られていたようです。発表直後に内部文書がリークし、その目的の1つが明らかになったという経緯を辿りました。
(このメモは実在自体はしたようですが、会社の決定ではなく単なる draft 文書です。JS を置き換える方針だけでなく、Harmony と呼ばれる後の ES6路線も含めた議論段階の資料である点には注意されたし)
グーグル、JavaScriptに代わるWeb言語「Dart」を開発中か
Dart VM を積んだ chromium である Dartium のプレビューが出るなどもしています。
Dart 1.0: A stable SDK for structured web apps
しかし、最終的にその計画は頓挫します。他のブラウザベンダーからの反発や、既存資産との相互運用性が理由です。ユーザー側にも、dart2js で JS にコンパイルする方がデバッグやクロスブラウザ対応を進めやすいという事情がありました。
第3の選択肢
社内では Script#を使いたいという要望もあったようです。一方、C#用の擬似的なランタイムやライブラリを使ってまで、実際のターゲットから離れることには疑問が残りました。
そこで、ターゲット言語から離れるよりも JS 自体を改善するという発想に至ります。JS を土台とし、機能を漸進的に追加できる言語として生まれたのが TypeScript です。
そして、開発中だったエディターはある人物に引き継がれます2。内部向けの Monaco Workbench3や Visual Studio Online 'Monaco'というサービスを経て現在の VSCode へと至ります。 また、エディターを引き渡す際には次の約束を取り付けたそうです。
I made them agree to one thing, which is: when we have enough TypeScript that you could actually use it, please try to use it in building VS Code and give us feedback because we desperately need feedback.
TypeScript が使えるようになったら、それでエディタを作りフィードバックしてほしいという約束です。この約束によって、
- TypeScript で VSCode を作る
- VSCode で VSCode と TypeScript を作る
というドックフーディング体制ができます。
Monaco からの手紙
なぜ引用符が付きの'Monaco'と表記されているのか気になった方はいるでしょうか？これにはある事件が関係しています。
2013年ごろにブラウザで使える軽量エディターのサービスとして Visual Studio Online Monaco が公開されます。
しかし、利用状況はかなり厳しく、全世界での MAU は3000人程度だったようです。
そこまで跳ねなかったにも関わらずヨーロッパにある某国から正式にその命名に関する手紙が届いたらしく、引用符をつけて'Monaco'としたことで対応したという嘘のような本当の話があります。
次回
TypeScript が生まれるに至った歴史的な背景を簡単に紹介しました。ここまでで TypeScript は既存のものを壊さないように、JavaScript のスーパーセットであること、型が実行時に消えることが要件として課せられています。
それに加えてドキュメンタリーではエディタをはじめとした周辺ツーリング体験の実現を非常に重視していたようにみて取れます。
ではそのようなツーリング体験を成立させるにはどのようなことをする必要があるのでしょうか。その解の1つはすでに同じく Microsoft が作っている C#のコンパイラ Roslyn にあります。次回はその Roslyn とそこから生まれた Red Green Tree（赤緑木）という実装パターンについて解説します。
Footnotes
-
個人的になぜエディタ自体も JS で作ろうとしたのかは疑問に感じました。Web アプリに JS が必要でも、エディタまで同じ言語にこだわる必要はなくない？と。ドキュメンタリーでは深く触れていないため推察になりますが、アプリだけでなく開発環境まで Web 化するという賭けだったのかもしれません ↩
-
その人物は、Gang of Four の一人としてや Eclipse で有名な Erich Gamma です。最近 Visual Studio Code: The First Decade というドキュメンタリーも公開されました ↩
-
TypeScript Origins: The Documentary で実際の画面を見ることができます。よく見ると TS にはない property という構文や、
.strという拡張子のファイルが現れています。.strは TypeScript のことで、プロジェクト名であった Strada の頭文字です。 ↩