#お勧めしたい理由
## 1 新しい文法を使っても古い環境で動作させることができる
私の場合、GoogleBotが認識できるJavaScriptが前提なので、おのずと使える機能はES5に制限される。その範囲ではclassすら使うことはできない。しかしTypeScriptを用いれば、classだろうが継承だろうがやりたい放題だ。事前にやるべきことは出力ターゲットの指定だけだ。
## 2 型チェックが強力で柔軟
変数に型を付けることができるので、ちょっとしたミスが起きにくくなる。TypeScriptの凄まじいところは、可能性のある型をすべて記述できることだ。送られてくるデータが「数値」、もしくは「文字列が入った配列」など、可能性を事細かに指定できる。さらにif文で型チェックを入れておくだけで、文法チェックの段階で型を確定してくれるのだ。わざわざキャストする必要もない。これはかなりヤバイ。
## 3 入力補完が利用できる
様々なAPIを利用していると、開発中に細かいメソッド名を失念することは多い。そのたびに正確な名前を調べに行くのは時間の浪費だ。VSCodeなどの対応環境とTypeScriptであればそんな無駄はおこらない。さらに引数についても教えてくれる。JSDocでコメントが入っていれば、ドキュメントを読みに行く必要もない。
## 4 DOMのイベントは最初から型定義されている
addEventListenerなどで追加するイベント処理、受け取ったハンドルの中身を完全に覚えている人は少ないと思う。TypeScriptの恐ろしいところは、イベントごとの定義があらかじめ用意されているところだ。「addEventListener('click',e=>{})」とやったら、eのメンバが入力補完の対象となる。
## 5 npmでType定義をインストールすれば、WebAPIも入力補完やエラーチェックの対象となる
例えばGoogleのAPIを使いたいと思ったとき、npmなどを使い追加で定義パッケージをインストールすれば、APIの命令や引数、その型に至るまで、全てが入力補完の対象だ。型チェックも効くので、変なデータを入れようと思ったら、文法チェックの段階で引っかかる。開発時の迷いは発生しない。有名どころのAPIは大抵用意されている。
## 6 jsに変換されてもtsでトレースできる
.ts(TypeScript)をトランスコンパイルして.js(JavaScript)を生成する。当然、それぞれは別のファイルだ。このときmapファイルというのを生成できる。tsとjsの対応関係が入ったデータだ。出力されたjsにはこのマップファイルとの関係がコメントの形で挿入されている。ブラウザで実行されるのはjsなのだが、ブラウザはこのマップファイルを読み込んでくれる。ブラウザの開発コンソールでデバッグを行うと、そこに表示されるのはtsのコードなのだ。この機能はIE11ですら対応している。デバッグをする部分に死角はない。
## 7 ソースコード中に型が書けるので、ドキュメントを作るのが簡単
JavaScriptでメソッドのコメントを作る際、引数の型などはコメント入力時に書くことになる。TypeScriptなら最初から型が入っているので、コメント生成用のプラグインを入れておけば、型が入力済みの状態でコメントを書くことができる。コーディングの際、コメントを書くというのは気の重い作業なのだが、書く分量が減るというのはとてもありがたい。気力を削がれずに済むのだ。
導入に当たっての壁
1 TypeScriptの環境構築のためNode.jsのインストールが必要
2 npmなどのパッケージマネージャで必要なモジュールをそろえる必要がある
3 tsconfig.jsonの設定方法の理解とディレクトリ構成を整える部分
4 既存のJavaScriptのコードで型がらみのエラーを吐きまくる可能性
5 WebAPIの型定義のモジュールを探す手間
6 特に使うことは必須では無いが、モジュールバンドラの知識(使わないという選択も含めて)
5番までの範囲でTypeScriptを使う限り、拡張JavaScriptのような感覚で便利に利用できる。ただし、そこから先に進むのは混沌とした世界が待ち受けていることを覚悟して欲しい。ちなみにモジュールバンドラに関して、私は使わないという選択をした。
まとめ
バックエンドには様々な言語の選択肢があるが、フロントエンドに関しては実質的に素のJavaScriptを使うか、TypeScriptを使うかという選択肢しかない。
TypeScriptを使用することによるメリットは非常に大きい。まだ導入していないというのなら、ぜひ使ってみて欲しい。