タイプスクリプト、本当に退場されるのか？

少し前の話ですが、開発者コミュニティで熱い議論が繰り広げられています。TypeScriptを「本当に必要か？」という根源的な質問を投げかけるきっかけとなったのが、David Heinemeier Hansson（DHH／Ruby on Railsの創始者）が、Hotwire TurboプロジェクトからTypeScriptを除外したことです。

TypeScriptは2012年にMicrosoftからリリースされて以来、JavaScriptに静的型を導入して大規模プロジェクトの保守性を向上させるツールとして定着してきました。しかしDHHの決断以降、Svelteなど他のプロジェクトでもTypeScriptの削除が検討され、開発者たちは混乱に陥っています。

本稿ではTypeScriptをめぐる賛否の議論をバランスよく見つつ、皆さんのプロジェクトにTypeScriptが本当に必要かを判断するための基準を提示します。

DHHによるブログ投稿

TypeScriptに反対する声

DHHがTurbo 8でTypeScriptを除外した理由

DHHは自身のブログ記事「Turbo 8 is dropping TypeScript」で、除外決定の背景を率直に明かしています。彼の主張を要約すると以下の通りです。

「TypeScriptは私の開発体験に喜びを加えるどころか、妨げになります。明示的なコンパイル段階が必要なだけでなく、型体操（type gymnastics）でコードを汚染する。簡単であるべきものが難しくなり、難しいものは結局 any になってしまうのです。」

DHHは、ES6以降JavaScript自体が十分に成熟した言語になったと主張しています。特にクラス構文や各種改善が追加されたことで、JavaScriptだけでも十分に楽しい開発体験が提供できるというわけです。

コードの汚染と複雑性の問題

TypeScript反対論者が最も頻繁に指摘するのが「コードの汚染」です。単純なJavaScriptコードがTypeScriptで書かれると、型定義のためのコードが増え、可読性が落ちることが多いです。

// TypeScript
function processUser(user: User & { permissions: Permission[] }): Promise<ProcessedUser | null> {
  // 구현
}

// JavaScript
function processUser(user) {
  // 구현
}

上記の例のように、TypeScriptでは型定義のために追加コードが必要です。小規模なプロジェクトやプロトタイプ段階では、こうした型定義がかえって開発スピードを落とすことがあります。

コンパイル時間とビルドプロセス

TypeScriptはブラウザで直接実行できないため、JavaScriptに変換するコンパイル過程が必須です。プロジェクト規模が大きくなるほどこのコンパイル時間は増大し、開発ワークフローに負荷をかけることになります。

DHHは「JavaScriptはブラウザで実行される言語である」という点を強調し、ツールなしに自由にコードを書けるというのが大きな祝福だと言います。

TypeScriptを支持する理由

保守性と拡張性

TypeScriptの最大の利点は大規模プロジェクトにおける保守性です。型システムはコードの意図を明確に表現し、リファクタリング時に発生しうるエラーを事前に防いでくれます。

interface UserProfile {
  id: string;
  name: string;
  email: string;
  createdAt: Date;
}

function updateUserEmail(profile: UserProfile, newEmail: string): UserProfile {
  return {...profile,email: newEmail
  };
}

上記のコードで、もし UserProfile インターフェースが変更されたら、TypeScriptは影響を受けるすべてのコードを即座に通知します。何百ものファイルを一つひとつ確認する必要がありません。

エラー削減と信頼性

JavaScriptはランタイムで型エラーが発生します。つまり、プロダクション環境でユーザーがエラーに遭遇する可能性があるということです。一方でTypeScriptはコンパイル段階でこうしたエラーを捕捉します。

function calculateTotal(price: number, quantity: number): number {
  return price * quantity;
}

calculateTotal("100", 5); // コンパイルエラー：stringはnumberに代入できません

ある開発者は「大規模プロジェクトでTypeScriptは安定的な開発環境構築に必要不可欠」と強調しています。サービスの安定性が重要なエンタープライズ環境では、このような事前エラー防止は極めて重要です。

チーム協業と開発者体験

TypeScriptはIDEの自動補完、リファクタリングツール、リアルタイムエラーチェックなど優れた開発ツールサポートを提供します。特にチームプロジェクトで他の開発者のコードを理解し利用する際、型定義は「生きたドキュメント」としての役割を果たします。

/**
 * 사용자 데이터를 검증하고 처리합니다
 */
function validateUser(user: User): ValidationResult {
  // IDE가 User 타입의 모든 속성을 자동완성해줍니다
  if (!user.email.includes('@')) {return { valid: false, error: 'Invalid email' };
  }
  return { valid: true };
}

新しいチームメンバーが加入した時、型定義を見るだけで関数がどのような引数を受け取り、何を返すかを明確に理解できます。

エンタープライズ環境での価値

大企業や複雑なビジネスロジックを扱うプロジェクトでは、TypeScriptの価値は一層際立ちます。数百人規模の開発者が協業し、数年にわたり保守しなければならないコードベースでは、型の安定性が不可欠です。

実際に Microsoft、Google、Airbnb といった大手企業がTypeScriptを積極導入してきた理由もまさにここにあります。

開発者コミュニティの反応

分かれた意見

DHHのTypeScript除外の決定は開発者コミュニティで大きな議論を呼び起こしました。韓国の開発者コミュニティでも意見ははっきりと分かれています。

賛成の立場:

• 「小規模プロジェクトではTypeScriptはオーバーエンジニアリングだ」
• 「JavaScriptの柔軟性がTypeScriptの厳格さより勝る」
• 「コンパイル段階がないことが開発スピードを上げる」

反対の立場:

• 「大規模プロジェクトではTypeScriptなしでは保守が不可能だ」
• 「型の安定性は選択ではなく必須だ」
• 「初期の学習曲線はあるが、長期的には利益になる」

TurboでTypeScript削除作業がマージされた時、反応は概ね否定的でした。多くの開発者がこの決定に懸念を表明しています。

YouTuber 조코딩 氏の意見

有名ユーチューバーの조코딩氏は「SvelteでもTypeScriptが退場された」と述べ、生産性に支障をきたすという理由で行われた決定だと言及しています。このように、一部のフレームワークやライブラリではTypeScriptを選択しない、あるいは除外する動きも見られます。

JSDocという代替案

TypeScriptの代替としてよく取り上げられるのが JSDoc です。JSDocはコメントを通じて型情報を提供する方式です。

/**
 * @param {string} name - 사용자 이름
 * @param {number} age - 사용자 나이
 * @returns {Object} 사용자 객체
 */
function createUser(name, age) {
  return { name, age };
}

JSDocはコンパイル段階なしで型ヒントを提供できるという利点があります。しかし、TypeScriptほど強力な型チェックやIDEサポートを提供するわけではありません。多くの開発者が「JSDocを使うならむしろTypeScriptを使ったほうがマシだ」という意見を出しています。

JavaScriptとTypeScriptの未来

ECMAScriptのType Annotations提案

興味深いことに、TC39（ECMAScript仕様を策定する委員会）は、JavaScriptに直接“型注釈（Type Annotations）”を追加する提案を検討しています。現在Stage 1の段階にあるこの提案が通れば、JavaScript自身で型を表現できるようになります。

// 未来のJavaScript?
function add(a: number, b: number): number {
  return a + b;
}

重要なのは、これらの型注釈がランタイムでは無視されるという点です。つまり、ブラウザが直接実行可能な形になるのです。こうなれば、TypeScriptのコンパイル段階なしに型の安定性を確保できる可能性があります。

共存の可能性

Type Annotationsの提案が実現したとしても、TypeScriptが完全に消えるとは考えづらいです。TypeScriptは単に型注釈を提供する以上の機能を備えています：

• 高度な型システム：ジェネリック、ユニオン型、インターセクション型など
• 型推論：明示的に型を書かなくても自動で型を把握
• デコレーター：メタプログラミング機能
• 厳格な型チェック：コンパイラオプションによる細かな制御

JavaScriptに型注釈が加われば、TypeScriptはより「高度な機能を必要とするプロジェクトのためのツール」としてポジショニングされる可能性が高いです。

フレームワークとライブラリの選択

React、Vue、Angular といった主要なフレームワークはいずれもTypeScriptを公式にサポートしています。Reactの公式ドキュメントでもTypeScript使用を推奨しています。

// React with TypeScript
interface ButtonProps {
  onClick: () => void;
  children: React.ReactNode;
  disabled?: boolean;
}

const Button: React.FC<ButtonProps> = ({ onClick, children, disabled = false }) => {
  return (<button onClick={onClick} disabled={disabled}>  {children}</button>
  );
};

Next.js、Remix といったメタフレームワークもTypeScriptを一級シチズン（first‑class citizen）として扱い、デフォルト設定として提供しています。

この流れを見ると、少なくとも当面はTypeScriptが主流の開発ツールとしての地位を維持するように思われます。

プロジェクトにTypeScriptが必要かどうかを判断する

TypeScriptを導入すべき場合

以下の条件のいずれかに該当するなら、TypeScript導入を真剣に検討してください：

プロジェクト規模が大きいか、長期保守が見込まれるとき

• 10以上のモジュールが相互作用している
• 開発が1年以上継続されるプロジェクト
• レガシーコードをリファクタリングすべき状況

チーム規模が大きいか、協業が重要な場合

• 3人以上の開発者が同時に作業
• フロントエンドとバックエンドで同じ型を共有する必要がある
• 新しいチームメンバーのオンボーディングが頻繁

信頼性・安定性が重要な場合

• 金融、医療など敏感データを扱うサービス
• B2Bエンタープライズソリューション
• 数百万人が使うプロダクションサービス

JavaScriptだけで十分な場合

逆に次のような状況なら、JavaScriptだけでも十分かもしれません：

プロトタイプや早期実験段階

• MVP（Minimum Viable Product）開発
• ハッカソンや短期プロジェクト
• アイデア検証フェーズ

小規模プロジェクトや個人プロジェクト

• 一人で開発・管理するプロジェクト
• 簡単なランディングページやブログ
• 学習用のトイプロジェクト

すでにJSDocで十分な型カバーがある場合

• 既存コードベースがよくドキュメント化されている
• チームがJSDoc使用に慣れている
• TypeScriptへの移行コストが負担になる

ハイブリッドアプローチ

0か100かで決める必要はありません。次のような戦略も検討できます：

段階的導入

• 新規モジュールからTypeScriptで記述
• 重要なコアロジックから型を追加
• allowJsオプションを使ってJavaScriptとTypeScriptを混合

選択的使用

• APIインターフェースとデータモデルだけTypeScriptで定義
• ユーティリティ関数はJavaScriptで維持
• フレームワークで求められる部分だけ型を追加

タイプスクリプトは道具に過ぎません

TypeScript論争の核心は「正しいか間違っているか」ではありません。DHHのようにJavaScriptのシンプルさと自由を好む人もいれば、大規模プロジェクトでTypeScriptの安定性を重視する人もいます。

重要なのは、皆さんのプロジェクト状況・チームの能力・ビジネス要件を総合的に考えて判断することです。TypeScriptは万能の解決策ではなく、JavaScriptも時代遅れなわけではありません。

ECMAScriptのType Annotations提案が進む中、今後JavaScriptとTypeScriptの境界はますます曖昧になるでしょう。その間にどこかで、皆さんのプロジェクトにとって最適な地点を見つけていただければと思います。

結局のところ、私たちの目標はより良いソフトウェアを作ることですからね :)