私がこの回答を書いたのは、まだTypescriptが登場したばかりの頃でした。 の時に書いたものです。5年経った今、この回答は概要としては問題ありませんが、より深く知りたい方は Lodewijkの答え]11を見てください。

1000ft view...

私の言っていることを理解するには、この言語に関するMicrosoftの紹介ビデオをご覧ください。

大規模なJavaScriptプロジェクトでは、TypeScriptを採用することで、より堅牢なソフトウェアを実現できるかもしれませんが、その一方で、通常のJavaScriptアプリケーションを実行する場所に配置することも可能です。

TypeScriptはオープンソースですが、サポートされているIDEを使用している場合にのみ、入力時に賢いIntellisenseを得ることができます。当初はMicrosoftのVisual Studioだけだった（Miguel de Icazaのブログ記事にもある）。最近では、他のIDEもTypeScriptをサポートしています。

他にも似たような技術はありますか

サンプル

例として、ここにいくつかのTypeScriptがあります（TypeScript Playgroundでこれで遊ぶことができます）。

class Greeter {
    greeting: string;
    constructor (message: string) {
        this.greeting = message;
    }
    greet() {
        return "Hello, " + this.greeting;
    }
}  

そして、これが生成するJavaScriptは次のとおりです。

var Greeter = (function () {
    function Greeter(message) {
        this.greeting = message;
    }
    Greeter.prototype.greet = function () {
        return "Hello, " + this.greeting;
    };
    return Greeter;
})();

TypeScriptがメンバー変数やクラスメソッドのパラメータの型を定義していることに注目してください。これは JavaScript に変換する際には削除されますが、IDE やコンパイラはコンストラクタに数値型を渡すなどのエラーを発見するために使用します。

また、明示的に宣言されていない型を推論することもできます。例えば、greet()メソッドが文字列を返すと判断することができます。

Typescriptをデバッグする

もっと知りたいですか

TypeScriptのJavaScriptとの関係

TypeScriptはJavaScriptの型付けされたスーパーセットで、プレーンなJavaScriptにコンパイルされます。 JavaScript - typescriptlang.org. JavaScriptはEMCAの技術委員会39で開発されているプログラミング言語で、さまざまな関係者から構成されているグループです。TC39は、【ECMA】3：内部標準化団体が主催する委員会です。JavaScriptには、さまざまなベンダー（Google、Microsoft、Oracleなど）によるさまざまな実装があります。JavaScriptの目標は、ウェブの共通語になることです。 TypeScriptは、単一のオープンソースのコンパイラを持ち、単一のベンダーによって主に開発されているJavaScript言語のスーパーセットです。Microsoft社です。TypeScriptの目的は、型システムによってミスを早期に発見し、JavaScriptの開発をより効率的にすることです。 基本的にTypeScriptは3つの方法でその目標を達成します。 1.1. 最新のJavaScript機能のサポート - JavaScript言語（ランタイムではない）は、ECMAScript規格によって標準化されています。すべてのブラウザやJavaScriptランタイムが、すべてのECMAScript規格のすべての機能をサポートしているわけではありません（こちらの概要を参照）。TypeScriptでは、最新のECMAScriptの機能の多くを使用することができ、それらを選択した古いECMAScriptターゲットに翻訳することができます（--targetコンパイラオプションの下にあるcompile targetsのリストを参照）。つまり、古いブラウザやJavaScriptランタイムとの後方互換性を保ちつつ、モジュール、ラムダ関数、クラス、スプレッド演算子、デストラクションなどの新機能を安全に使用することができるのです。 2.2. 高度な型システム - 型のサポートはECMAScript標準の一部ではありませんし、JavaScriptがコンパイル型ではなくインタプリタ型であることから、今後もそうなる可能性はありません。TypeScriptの型システムは非常に豊富で、インターフェース、列挙型、ハイブリッド型、ジェネリックス、ユニオン/インターセクション型、アクセス修飾子などが含まれます。TypeScriptの公式サイトには、これらの機能の概要が記載されています。TypeScriptの型システムは、他のほとんどの型付き言語と同等であり、場合によっては間違いなくより強力です。 3.3. 開発者ツールのサポート - TypeScript のコンパイラはバックグラウンドプロセスとして動作し、インクリメンタルなコンパイルと IDE の統合の両方をサポートします。

TypeScriptの他のJavaScriptターゲット言語との関係

TypeScriptは、JavaScriptにコンパイルする他の言語と比較して、独自の哲学を持っています。JavaScriptのコードは有効なTypeScriptのコードであり、TypeScriptはJavaScriptのスーパーセットなのです。ほとんどの場合、.jsファイルを.tsファイルにリネームして、TypeScriptを使い始めることができます（下記の「JavaScriptの相互運用性」を参照）。TypeScriptのファイルは読みやすいJavaScriptにコンパイルされているので、元に戻すことも可能ですし、コンパイルされたTypeScriptを理解することも難しいことではありません。TypeScriptは、JavaScriptの成功例をベースにしながら、その弱点を改善しています。 一方では、最新のECMAScript標準を古いJavaScriptバージョンにコンパイルする将来性のあるツールがあり、Babelが最も人気があります。一方で、CoffeeScript、Clojure、Dart、Elm、Haxe、Scala.jsなど、JavaScriptをターゲットにした、JavaScriptとは全く異なる言語もあります（こちらのリストを参照）。これらの言語は、JavaScriptの将来性よりも優れているかもしれませんが、将来性が保証されるほどの普及が見込めないリスクがあります。また、これらの言語では経験豊富な開発者を見つけるのに苦労するかもしれませんが、見つけた開発者はより熱心であることが多いでしょう。また、これらの言語はJavaScriptの本質から離れているため、JavaScriptとの相互運用にはやや手間がかかります。 TypeScriptはこの両極端の間に位置するため、リスクのバランスがとれています。TypeScriptはどんな基準でもリスクの高い選択ではありません。全く別の言語ではないので、JavaScriptに慣れていれば慣れるのにほとんど手間はかかりませんし、優れたJavaScriptの相互運用性をサポートしており、最近では多くの採用例があります。

任意の静的型付けと型推論

JavaScriptは動的に型付けされます。これは、実行時に変数が実際にインスタンス化されるまで、JavaScriptはその変数の型を知らないことを意味します。これは、手遅れになる可能性があることも意味します。TypeScriptは、JavaScriptに型のサポートを追加します。ある変数が特定の型であるという誤った仮定に起因するバグは、適切に対処すれば完全に根絶することができます（コードをどれだけ厳密にタイプするか、あるいはコードを全くタイプしないかはあなた次第です）。 TypeScriptでは、型推論を利用することで、型付けが少しだけ簡単になり、明示的でなくなります。例えば、TypeScriptのvar x = "hello"は、var x : string = "hello"と同じです。型は単純に使用方法から推論されます。たとえ明示的に型付けしなくても、型は、そうしないと実行時エラーになるようなことをしないようにするために存在しています。 TypeScriptはデフォルトではオプションで型付けされています。例えば、function divideByTwo(x) { return x / 2 }はTypeScriptの有効な関数で、文字列で呼び出すと明らかにランタイムエラーになりますが、あらゆる種類のパラメータで呼び出すことができます。JavaScriptで慣れ親しんだように。これは、divideByTwoの例のように、型が明示的に割り当てられておらず、型が推測できない場合、TypeScriptは暗黙のうちに型anyを割り当てるからです。つまり、divideByTwo関数の型シグネチャは自動的に「function divideByTwo(x : any) : any」となります。 この動作を無効にするコンパイラフラグとして，--noImplicitAny があります．このフラグを有効にすると、より高い安全性が得られますが、より多くの型付けをしなければならないことになります。 型付けにはコストがかかります。まず第一に、学習曲線があります。そして第二に、もちろん、適切な厳密な型付けを使用してコードベースをセットアップするには、もう少し時間がかかります。私の経験では、他の人と共有している深刻なコードベースでは、これらのコストは完全に価値があります。A Large Scale Study of Programming Languages and Code Quality in Githubによると、「静的型付けされた言語は、一般的に動的型付けよりも欠陥が少なく、同じ点では強い型付けの方が弱い型付けよりも優れている」とのことです。 興味深いのは、この全く同じ論文で、TypeScriptはJavaScriptよりも欠陥が少ないとしていることです。 正の係数を持つものについては、その言語が以下のように関連していると予想できます。 正の係数を持つ言語は、欠陥修正の数が多いことが予想されます。 これらの言語には、C、C++、JavaScript、Objective-C、Php、Pythonなどがあります。 Pythonがあります。Clojure，Haskell，Ruby，Scala，TypeScriptの各言語は，いずれも負の係数を持つ。 Clojure，Haskell，Ruby，Scala，TypeScriptなどの言語は，すべて負の係数を持ち，これらの言語が平均よりも低いことを示唆している． これは、これらの言語が欠陥修正のコミットにつながる可能性が平均よりも低いことを意味する。

充実したIDEサポート

TypeScriptでの開発体験は、JavaScriptに比べて格段に向上しています。IDEはTypeScriptコンパイラーから豊富な型情報をリアルタイムで知らされます。これにより、いくつかの大きな利点があります。例えば、TypeScriptでは、コードベース全体で名前の変更などのリファクタリングを安全に行うことができます。また、コード補完機能により、ライブラリが提供するあらゆる機能についてインラインヘルプを得ることができます。もう覚えたり、オンラインリファレンスで調べたりする必要はありません。コーディング中にコンパイルエラーが発生した場合は、赤い線で表示され、IDEに直接報告されます。このようにして、JavaScriptを使った作業に比べて、生産性を大幅に向上させることができます。より多くの時間をコーディングに、より少ない時間をデバッグに費やすことができます。 TypeScriptをサポートするIDEには、Visual Studio Code、WebStorm、Atom、Sublimeなど、さまざまなものがあります。

厳密なヌルチェック

cannot read property 'x' of undefinedやundefined is not a functionといった形式のランタイムエラーは、JavaScriptコードのバグに起因するものが非常に多いです。TypeScriptでは、TypeScriptコンパイラが知らない変数を使用することができないため、すぐにこの種のエラーが発生する可能性は低くなります（ただし、any型付けされた変数のプロパティは例外です）。しかし、undefinedに設定された変数を誤って使用することはまだ可能です。しかし、バージョン2.0のTypeScriptでは、Non-nullable型を使用することで、この種のエラーを完全に排除することができます。これは次のように動作します。 厳密なヌルチェックを有効にすると（--strictNullChecksコンパイラーフラグ）、TypeScriptコンパイラーは、明示的にヌル化可能な型であると宣言しない限り、変数に undefined を代入することを許可しません。たとえば、let x : number = undefinedとすると、コンパイルエラーになります。undefinedは数字ではないので、これは型理論に完全に合致します。これを修正するために、xをnumberとundefinedの和の型として定義することができます。すなわち、「let x : number | undefined = undefined」です。 型がnullableであること、つまり値がnullまたはundefinedである可能性がある型であることがわかると、TypeScriptコンパイラは制御フローに基づいた型解析によって、コードがその変数を安全に使用できるかどうかを判断することができます。つまり、if文などで変数がundefined` であることを確認すると、TypeScriptコンパイラは、コードの制御フローのその分岐にある型がもはやnullableではなく、したがって安全に使用できることを推測します。以下に簡単な例を示します。

let x: number | undefined;
if (x !== undefined) x += 1; // this line will compile, because x is checked.
x += 1; // this line will fail compilation, because x might be undefined.

2016年のカンファレンス「build」では、TypeScriptの共同設計者であるAnders Hejlsberg氏が、この機能について詳細な説明とデモンストレーションを行いました。video（44:30から56:30まで）。

コンパイレーション

TypeScriptを使用するには、JavaScriptコードにコンパイルするためのビルドプロセスが必要です。もちろん、プロジェクトの規模にもよりますが、ビルドプロセスは通常、数秒で完了します。TypeScript コンパイラはインクリメンタルなコンパイル(--watch コンパイラフラグ)をサポートしており、後続のすべての変更をより高速にコンパイルすることができます。 TypeScript コンパイラは、生成される .js ファイルにソースマップ情報をインラインで記述したり、個別の .map ファイルを作成したりすることができます。ソースマップ情報は、Chrome DevToolsなどのデバッグユーティリティやその他のIDEで使用することができ、JavaScriptの行とTypeScriptで生成された行を関連付けることができます。これにより、ブレークポイントを設定したり、ランタイム中に変数を検査したりすることが、TypeScriptコード上で直接可能になります。ソースマップ情報は非常によく機能しており、TypeScriptよりもずっと前から存在していました。しかし、TypeScriptのデバッグは一般的に、JavaScriptを直接使用する場合ほど優れているわけではありません。例えば、thisキーワードを考えてみましょう。ES2015からクロージャに関するthisキーワードのセマンティクスが変更されたため、thisは実行時に_thisという変数として実際に存在することがあります（この回答参照）。これはデバッグ中に混乱するかもしれませんが、一般的にはそれを知っていたり、JavaScriptのコードを検査していれば問題はありません。なお、Babelも全く同じような問題を抱えています。 TypeScript コンパイラには、decoratorsに基づいたインターセプトコードの生成、異なるモジュールシステムのためのモジュールローディングコードの生成、JSXの解析など、他にもいくつかのトリックがあります。しかし、TypeScript コンパイラ以外のビルドツールが必要になることもあるでしょう。たとえば、コードを圧縮したい場合は、そのための他のツールをビルドプロセスに追加する必要があります。 Webpack]13、Gulp、Gruntなど、世の中にあるほとんどの JavaScript ビルドツールで利用できる TypeScript コンパイルプラグインがあります。TypeScriptのドキュメントには、integrating with build toolsというセクションがあり、これらすべてを網羅しています。ビルド時のチェックをさらに強化したい場合は、linterも利用できます。また、Angular 2、React、Ember、SystemJS、Webpack、Gulpなどの他の技術と組み合わせてTypeScriptを使い始めるためのシードプロジェクトも数多く存在しています。

JavaScriptの相互運用性

TypeScriptはJavaScriptと非常に密接に関連しているため、優れた相互運用性を備えていますが、TypeScriptでJavaScriptライブラリを扱うにはいくつかの追加作業が必要です。TypeScriptコンパイラが、_.groupByやangular.copy、$.fadeOutなどの関数呼び出しが実際には違法なステートメントではないことを理解するために、TypeScript定義が必要です。これらの関数の定義は .d.ts ファイルに記述されます。 定義の最も単純な形は、識別子をどのようにでも使用できるようにすることです。例えば、Lodashを使用する場合、1行の定義ファイル declare var _ : any を作成すると、_ に対して好きな関数を呼び出すことができますが、もちろん、間違いを犯すこともあります。_.foobar()`は、TypeScriptの呼び出しとしては合法ですが、実行時にはもちろん違法な呼び出しとなります。型サポートやコード補完を適切に行いたい場合は、定義ファイルをより正確にする必要があります（例としてlodash definitionsを参照）。 独自の型定義があらかじめパッケージされている Npm modules は、TypeScript コンパイラによって自動的に理解されます（documentation 参照）。独自の型定義を含んでいない他のほとんどの半人気のJavaScriptライブラリについては、誰かが別のnpmモジュールを通じて型定義をすでに利用可能にしています。これらのモジュールは「@types/」というプレフィックスを持ち、DefinitelyTypedというGithubリポジトリから提供されています。 注意点が1つあります。型定義は、実行時に使用しているライブラリのバージョンと一致している必要があります。型定義が一致していないと、コンパイル時に型がランタイムと一致していないという理由だけで、TypeScriptは存在する関数の呼び出しや変数の参照解除を許可しなかったり、存在しない関数の呼び出しや変数の参照解除を許可したりすることがあります。ですから、使用しているライブラリの正しいバージョンの型定義を読み込むようにしてください。 正直なところ、これには若干の手間があり、TypeScriptを選択せずに、型定義を取得する必要のないBabelのようなものを選択する理由の1つになるかもしれません。一方で、自分が何をしているのかを理解していれば、間違った定義ファイルや欠落した定義ファイルに起因するあらゆる問題を簡単に解決することができます。

JavaScriptからTypeScriptへの変換

.jsファイルは、.tsファイルにリネームして、TypeScriptコンパイラに通すことで、構文的に同じJavaScriptコードを出力することができます（そもそも構文的に正しければの話ですが...）。TypeScriptコンパイラがコンパイルエラーを起こした場合でも、.jsファイルを生成します。また、--allowJsフラグを指定すれば、.jsファイルを入力として受け取ることもできます。これにより、TypeScriptをすぐに使い始めることができます。残念ながら、最初のうちはコンパイルエラーが発生することがあります。しかし、これは他のコンパイラでよくあるような、目に見えないエラーではないことを覚えておく必要があります。 JavaScriptのプロジェクトをTypeScriptのプロジェクトに変換するときに最初に発生するコンパイルエラーは、TypeScriptの性質上避けられません。TypeScriptはすべてのコードの有効性をチェックするため、使用されているすべての関数や変数について知る必要があります。そのため、すべての関数や変数に対して型定義を行う必要があり、そうしないとコンパイルエラーが発生してしまいます。上の章で述べたように、ほとんどのJavaScriptフレームワークには、[DefinitelyTyped package][23]をインストールすることで簡単に入手できる.d.tsファイルがあります。しかし、TypeScriptの定義が利用できない曖昧なライブラリを使用していたり、JavaScriptのプリミティブをポリフィルしていたりする場合もあるでしょう。そのような場合、コンパイルエラーをなくすためには、これらのビットの型定義を提供する必要があります。.d.tsファイルを作成して、tsconfig.jsonのfiles配列にインクルードすることで、TypeScriptコンパイラが常に考慮するようにします。このファイルでは、TypeScriptが知らないビットを any 型として宣言します。すべてのエラーを排除したら、必要に応じてそれらの部分に徐々に型付けを導入することができます。 TypeScriptをビルドパイプラインに組み込むためには、ビルドパイプラインを（再）設定する作業も必要です。コンパイルの章で述べたように、世の中には良いリソースがたくさんあるので、自分が使いたいツールの組み合わせを使ったシードプロジェクトを探すことをお勧めします。 最大のハードルは、学習曲線です。最初は小さなプロジェクトで遊んでみることをお勧めします。どのように動作するのか、どのようにビルドするのか、どのファイルを使うのか、どのように設定するのか、IDEでどのように機能するのか、どのように構成するのか、どのツールを使うのか、などを確認してください。大規模なJavaScriptのコードベースをTypeScriptに変換することは、自分が何をしているかを知っていれば可能です。72時間で600k行をTypeScriptに変換]24の例として、このブログを読んでみてください）。ただ、ジャンプする前に言語をよく理解しておく必要があります。

採用

TypeScriptはオープンソース（Apache 2ライセンス、[GitHub][25]参照）で、Microsoftが支援しています。2626がこのプロジェクトの指揮を執っています。非常に活発なプロジェクトです。TypeScriptチームはここ数年で多くの新機能をリリースしており、現在も多くの素晴らしい機能が計画されています（ロードマップ参照）。 採用と人気に関するいくつかの事実。

• 2017 StackOverflow developer surveyでは、TypeScriptは最も人気のあるJavaScriptトランスパイラであり（全体で9位）、最も愛されているプログラミング言語部門では3位を獲得しています。
• 【2018年のState of js調査】29では、TypeScriptはJavaScriptフレーバー部門の2大勝者の1つと宣言されました（もう1つはES6です）。
• 2019 StackOverlow deverloper survey]30では、TypeScriptはプロの開発者の間で最も人気のある言語として、CとC++の両方を抜いて9位にランクインした。また、最も愛されている言語の3位にも選ばれている。 [25]： https://github.com/Microsoft/TypeScript

"TypeScript Fundamentals" -- Pluralsightのビデオコースで、Dan WahlinとJohn Papaによるものですが、現在（2016年3月25日）はTypeScript 1.8を反映して更新されており、Typescriptの入門としてはとても良い内容です。

私にとって本当に良い機能は、インテリセンスの素晴らしい可能性の他に、classes、interfaces、modules、AMDの実装のしやすさ、そしてIEで起動したときにVisual StudioのTypescriptデバッガを使用できることです。

結論から言うと。意図した通りに使用すれば、Typescript は JavaScript プログラミングをより信頼性の高い、より簡単なものにすることができます。SDLC全体を通して、JavaScriptプログラマーの生産性を大幅に向上させることができます。