10倍高速になったTypeScript
(devblogs.microsoft.com)- Microsoftが、コンパイラとツールのネイティブ移植によりTypeScriptの性能を10倍向上させると発表
- エディタの起動時間を大幅に改善し、ビルド時間を10分の1に短縮、メモリ使用量も大幅に削減
- 2025年半ばまでに
tscのプレビュー版を公開し、2025年末までに完全なプロジェクトビルドと言語サービスを提供する予定
TypeScript性能改善の背景
- TypeScriptの中核的な価値は優れた開発者体験にある
- コードベースが大きくなるほどTypeScriptの価値は高まるが、大規模プロジェクトでは性能上の問題が発生
- 読み込み時間やチェック時間が長くなる問題がある
- エディタの高速起動時間とコードベース全体の解析のバランスが必要
- AIベースの機能には、高速かつ正確な意味情報の提供が必要
- コマンドラインビルドによるコードベースの状態検証への要求が高まっている
ネイティブ移植の進行計画
- TypeScriptコンパイラとツールのネイティブ移植作業を開始
- 性能改善の目標:
- エディタ起動時間の大幅短縮
- ビルド時間を最大10倍短縮
- メモリ使用量の削減
- 2025年半ば: コマンドラインで型チェック可能な
tscプレビュー版を公開予定 - 2025年末: 完全なプロジェクトビルドと言語サービスを提供予定
コード実行とテスト
- TypeScript Goコードリポジトリでコードのビルドと実行が可能
- リポジトリで
tscおよび言語サーバーのビルド・実行手順を提供 - 新機能に関する定期的な更新を予定
どれだけ速くなったのか?
- 現在のTypeScriptプロジェクトのビルド時間を複数の人気コードベースでテストした結果、次のような性能向上が確認された:
- VS Codeプロジェクトは約150万行のコードで、従来の77.8秒から7.5秒へ、約10.4倍高速化
- Playwrightプロジェクトは約35万行のコードで、従来の11.1秒から1.1秒へ、約10.1倍改善
- TypeORMプロジェクトは約27万行のコードで、従来の17.5秒から1.3秒へ、約13.5倍改善
- date-fnsプロジェクトは約10万行のコードで、従来の6.5秒から0.7秒へ、約9.5倍改善
- tRPCプロジェクトは約1万8千行のコードで、従来の5.5秒から0.6秒へ、約9.1倍改善
- rxjsプロジェクトは約2千行のコードで、従来の1.1秒から0.1秒へ、約11倍改善
- まだ機能は完全ではないものの、ほとんどのコードベースで10倍以上の性能改善が見込まれる
- 高速な型チェックとコード探索が可能になる
- AIツール統合や高度なリファクタリング支援も可能になる
エディタ性能の改善
- エディタの読み込み速度と応答速度を改善
- Visual Studio Codeコードベース基準の読み込み時間:
- 現在: 9.6秒 → ネイティブ版: 1.2秒（約8倍改善）
- メモリ使用量も約50%削減
- 言語サービス機能（自動補完、クイックインフォ、定義へ移動など）の性能向上が見込まれる
- 言語サーバープロトコル（LSP）ベースで移行作業を進めている
バージョンロードマップ
- TypeScript 5.8はすでにリリース済みで、TypeScript 5.9もまもなくリリース予定
- JSベースのTypeScriptコードベースは6.x系として引き続き開発を継続
- ネイティブコードベースが安定すれば、TypeScript 7.0としてリリース予定
- TypeScript 6 → JSベース版
- TypeScript 7 → ネイティブベース版
- TypeScript 7のリリース後も、6.x系は一定期間維持される予定
次のステップ
- 性能、コンパイラAPI、LSPなどに関する追加情報を今後公開予定
- GitHub FAQでよくある質問を確認可能
- 2025年3月13日にTypeScriptコミュニティDiscordでAMAを実施予定（PDT午前10時 | UTC午後5時）
24件のコメント
みんな structural typing を深く考えずに話しているのではないかと思いました。
C# や Rust のような nominal typing の言語に書き直そうとすると、プロジェクトの根本的な構成をあまりにも大きく変えなければならないので、簡単ではなかったでしょう。
structural typing を採用した言語の中で、既存の JS ベースより性能を高められるのは C++ か Go のどちらかでしょうが、生産性まで考えると代案はありません
いつ頃からかTSに触ることが少なくなっていたけど、こういうニュースを見るとまた気になってきますね？
ts で本当に避けられない場合を除いて
anyを乱用してしまうと、vanilla を使うのと大差ないですよね..（笑）かなり議論が白熱しているようで、Anders Hejlsberg本人が直接コメントを残していますね
https://github.com/microsoft/typescript-go/…
TypeScriptにコンパイルして、成果物がそのままバイナリとして出てきてほしい派
フロントエンドは門外漢なので……
swcとは違うのでしょうか？SWCはBabelのように互換性のあるJavaScriptコードを生成し、バンドルするところまでに焦点がありますが、こちらはTypeScriptコードをJavaScriptに変換したり、エラーをチェックしたりすることに焦点があります。
いわゆる「ドッグフーディング」ですね。自分たちが作ったものを自分たちで使うことです。でも、言語の場合は少し悩ましいですね。
個人的な考えですが、ts の土台である js のランタイム（e.g. spidermonkey, v8）のほとんどは c++ で書かれていて、js で実装されたランタイムは存在せず、
js -> js コンパイルも pure js を使うとあまりに遅いので esbuild だの何だのにみんな移っていくのを見ると、
ts でもあえてドッグフーディングにこだわる必要があるのか、とは思います
後になると、既存のTypeScriptコードベースの管理がおろそかになってしまわないか心配ですね。
うれしいニュースです！ 不思議なことに、MSのTypeScript言語は予想に反して本当に意外な（？）選択をたくさんしているようです。MSにとってはほぼ最初のオープンソースプロジェクトでもあり、JSを置き換えようとしていたGoogleのDartと違ってJSを補完しようとした選択もとても賢明に感じられましたし、今回のネイティブ移植言語についても自社言語がいくつもあるはずなのにGoogleのGoを選んだ点も驚きです。
あれ、Deno 側ですでに Rust ベースのツールチェーンを作ったものがあったはずですが……いきなり Go なんですか？
それはNodeのようなランタイムのことを指しているようですが、ここで言っているのはTS言語自体のコンパイラです。
ああ、もう少し記事を読んでみると、エディタが速くなるといった話もあって混乱していたようですね。
tscが10倍速くなる。つまり、ts -> jsのトランスパイル時間が大幅に短縮される。tsで開発された大規模プロジェクトをロードするときの速度が非常に速くなる。つまり、tsの構文チェックなど、tscの機能を共有するロジックが高速化されたという意味。そういう内容だったんですね。
再帰で構成されたジェネリック型を使うとき、遅くなってしまって次善策を使った経験があります。10倍なら、こういう部分も改善できるのではと期待しています。
「なぜGoなのか」という議論スレッド、面白いですね。
https://github.com/microsoft/typescript-go/discussions/411
考えるべきことも多いですね…
そうですね、でも .NET 開発者の方々の気持ちも理解できます……
.NETとRustの開発者たちがかなり怒っていますね
.NETは理解できますが、RustはGoと同じ位置づけだと思います。やはり、既存のJS関連のGoプロジェクトやライブラリも判断に影響したように思います。C# 言語の開発が止まったわけではありませんが、C# を使ったフレームワークが放置されているように感じることがあまりにも多いです
Goで書こう〜
とても期待しています。
Hacker Newsの意見