TSKaigi 2026で見た、TypeScriptエコシステムの変化── Go移植・Deno 2.8・AI生成スライドのトップ画像

TSKaigi 2026で見た、TypeScriptエコシステムの変化── Go移植・Deno 2.8・AI生成スライド

投稿日時:
maguroのアイコン

Deno Land Inc. / ソフトウェアエンジニア

maguro

Xアカウントリンク

みなさんこんにちは。

「あの人も読んでる」、第19回目の投稿です。maguro(X @yusuktan)がお届けします。

先日、TSKaigi 2026に参加してきました。TSKaigiはTypeScriptを中心としたカンファレンスで、今年は2026年5月22日(金)〜23日(土)に開催されました。僕自身も登壇し、DenoのTypeScript基盤が tsc から tsgoへどのように移行しつつあるのか、という話をしてきました。

そこで今回は、TSKaigi関連で気になった話題を取り上げるとともに、便乗してDeno 2.8のリリースノートと、そこから見えるDenoの今後の方針についてもざっくり見ていけたらなと思います。

TS 7: How We Got There

まず取り上げたいのは、TypeScriptチームのJake Baileyさんによる基調講演「TS 7: How We Got There」です(TSKaigi公式ページ)。

TypeScript 7については、Microsoftが2025年3月に公開したA 10x Faster TypeScriptの記事が大きな話題になりました。TypeScriptのコンパイラとTypeScriptのlanguage serviceをGoによるネイティブ実装へ移植することで、ビルド時間・エディタ起動・メモリ使用量を大きく改善する、というものです。

基調講演では、この「速くなります」という結果だけでなく、そこに至るまでの背景と移植プロセスが丁寧に説明されていました。

TypeScriptは単なるコンパイラではありません。tsc の型チェックに加えて、エディタのhover、補完、diagnostics、go-to-definitionといった体験も支えています。

従来のTypeScriptはTypeScript自身で書かれており、セルフホストには「チーム自身が毎日ドッグフーディングできる」「コミュニティがコンパイラにコントリビュートできる」という大きな利点がありました。

一方で、JavaScript/TypeScriptであることによる限界も見えていました。

  • JavaScriptではオブジェクトをスレッド間で共有できないため、マルチスレッド化しようとするとシリアライズのコストが大きい
  • async/await はfunction coloringを生み[1]、Promiseにもコストがある
  • VS Codeに同梱されるNode.jsを含め、多くのNode.jsビルドには4GBのメモリ制限がある[2]
  • tsserver は基本的に単一プロセスでリクエストを順番に処理するため、重い処理が詰まると後続のhoverや補完も待たされる

セルフホストすることのメリットと、TypeScript(JavaScript)が本質的に抱える限界。これらを天秤にかけた結果、別言語への移植という大きな決断を下すことになりました。

ただ、移植するにあたって難しいのが、TypeScriptにはコンパイラの挙動を完全に規定する独立した仕様書がないということです。「現在のコンパイラがどう振る舞うか」そのものが事実上の仕様になっています。だからこそ、構造を大きく変える“rewrite”(書き換え)ではなく、既存のコード構造・振る舞いをできるだけ保った“port”(移植)が必要になります。

その前提で言語選定を考えると、RustやZig、C#、OCamlなどが候補に挙がる中でGoになったことが納得できます。TypeScriptの旧コードベースがもともとクラス継承を使わずデータ・関数・インターフェース中心で書かれていたため、Goの構造にほぼそのまま移せます。加えて、goroutineによる並行性、GCがあることによる移植のしやすさ、そしてチームが数日で書けるようになる学習コストの低さが理由として挙げられていました。

この記事のつづきを読もう
新規登録/ログインしたらできること
  • すべての記事を制限なく閲覧可能
  • 限定イベントに参加できます
  • GitHub連携でスキルを可視化
ログイン
アカウントをお持ちでない方はこちらから新規登録