1-1、基本：TypeScriptの概要(1)

1.1 TypeScriptとは

プログラミングコミュニティへの導入から20年以上が経ち、JavaScriptは今や史上最も広く利用されているクロスプラットフォーム言語の1つとなっています。JavaScriptは当初、Webページにわずかなインタラクティブ性を加えるための小さなスクリプト言語でしたが、現在ではあらゆる規模のフロントエンドおよびバックエンドのアプリケーションに最適な言語に成長しています。JavaScriptで書かれたプログラムのサイズ、範囲、複雑さは指数関数的に増加していますが、JavaScript言語は異なるコード単位間の関係を表現する能力がありません。JavaScriptの非常に特異なランタイムセマンティクスと組み合わせると、言語とプログラムの複雑さの間のこのミスマッチは、JavaScript開発を大規模な管理が困難なタスクにしてしまいます。

プログラマが書く最も一般的なエラータイプは、タイプエラーとして記述できます。タイプが異なる値が予想される場所で、あるタイプの値が使用されています。これは、単純なスペルミス、ライブラリのAPI表面を理解できない、ランタイム動作の誤った仮定、その他のエラーが原因である可能性があります。TypeScriptの目標は、JavaScriptプログラムの静的型チェッカー、つまり、コードが実行される前に実行されるツール(静的)であり、プログラムの型が正しいことを確認する(型チェック)ことです。

TypeScriptはマイクロソフトによって開発された自由でオープンソースのプログラミング言語です。これはJavaScriptのスーパーセットであり、基本的にはオプションの静的型とクラスベースのオブジェクト指向プログラミングがこの言語に追加されています。

TypeScriptはJavaScriptの言語拡張として非常に人気があります。既存のJavaScript構文の上に型レイヤーを追加します。このレイヤーは削除されても、実行時のパフォーマンスにはまったく影響しません。多くの人はTypeScriptを「単なるコンパイラ」と考えていますが、TypeScriptを2つの独立したシステムと考える方が良いでしょう。コンパイラ(構文を処理する部分)と言語ツール(エディタとの統合を処理する部分)です。この2つのシステムを独立して見ることで、私たちがこれまで行ってきた意思決定を説明できる2つの重要な視点を得ることができます。

npm[3]では、TypeScriptのダウンロード数は毎年倍増しています。2021年12月1日現在、週間ダウンロード数は2200万件を超えている。昨年12月には約1200万件だった。なお高成長傾向を維持しており、減速の兆しは見られない。

バージョン2.0以降、TypeScriptでは2か月ごとに定期的にreleaseがリリースされるようになりました。しかし現在はリリースのペースを落とし、3カ月ごとのリリースに変更している。そのうち1か月かけて新しいfeaturesを書いてベータ版をリリースし、残り2か月でベータ版のテストとバグ修正を行い、その後のリリースをより安定させることができます。

1.2 `JS`, `ES`, `TS` の関係

1995年：JavaScript

当時のネットスケープは、そのNavigatorブラウザによって、Web時代が始まった当時、最も有名な第1世代のインターネット企業になりつつありました。

ネットスケープは、静的なHTMLページに動的な効果を追加したいと考えていたため、 Brendan Eich は2週間以内にJavaScript言語を設計しました。

なぜJavaScriptと名付けられたのか。理由は当時Java言語が非常に人気だったので、ネットスケープ社はJavaの名を借りて普及させたいと考えていたのですが、実はJavaScriptは文法的にJavaに似ている部分以外はほとんど関係がありませんでした。

1997年：ECMAScript

ネットスケープがJavaScriptを開発し、その1年後にマイクロソフトがJavaScriptをまねてJScriptを開発したことで、JavaScriptをグローバル標準にするために、いくつかの企業がECMA（European Computer Manufacturers Association）（欧州コンピュータ製造業者協会）組織と連携してECMAScript標準と呼ばれるJavaScript言語の標準を制定したからだ。

版本	发布时间	一般的な呼び方	简称
第1版	1997年6月	ECMAScript 1	ES1
第2版	1998年4月	ECMAScript 2	ES2
第3版	1999年12月	ECMAScript 3	ES3
第4版	2007年10月草案	ECMAScript 4	ES4
第5版	2009年12月	ECMAScript 5	ES5
第6版	2015年6月	ECMAScript 2015	ES6
第7版	2016年6月	ECMAScript 2016	ES7
第8版	2017年6月	ECMAScript 2017	ES8
第9版	2018年6月	ECMAScript 2018	ES9
第10版	2019年6月	ECMAScript 2019	ES10
第11版	2020年6月	ECMAScript 2020	ES11
第12版	2021年6月	ECMAScript 2021	ES12

2015年：TypeScript

TypeScriptは、JavaScriptのスーパーセットです。JavaScriptのすべての要素を含み、JavaScriptを実行するコードで、JavaScriptの構文を拡張します。JavaScriptよりも静的型、クラス、モジュール、インタフェース、型注釈の機能が追加され、大規模プロジェクトの開発が容易になりました。

TypeScriptは、2015年のECMAScriptや、非同期機能やDecoratorsなどの将来的な提案など、最新のJavaScript機能を提供し、堅牢なコンポーネントの構築を支援しています。次の図に、TypeScriptとES5、ES2015+の関係を示します：

1.3 TypeScriptとJavaScriptの違い

TypeScript	JavaScript
JavaScriptのスーパーセットは、大規模プロジェクトのコードの複雑さを解決するために使用されます	一种脚本语言，用于创建动态网页
コンパイル中にエラーを発見して修正できる	作为一种解释型语言，只能在运行时发现错误
静的タイプと動的タイプの両方をサポートする強力タイプ	弱类型，没有静态类型选项
最终被编译成 JavaScript 代码，使浏览器可以理解	ブラウザで直接使用可能
モジュール、汎用、インターフェイスのサポート	不支持模块、泛型或接口
ES3、ES4、ES5、およびES6+の機能をサポート	不支持编译其他 ES3，ES4，ES5 或 ES6+ 功能
地域社会の支援は増え続けており、まだそれほど大きくはない	大量的社区支持以及大量文档和解决问题的支持

1.4 TypeScriptの競合他社について教えてください。

TypeScriptの目標は、大規模なJavaScriptプロジェクトを作成し、ポストメンテナンスに自信のあるツールを人々に提供することです。JavaScript自体にはないシンタックスサポートは、JavaScriptを実行して実行時に検出しない限り、各識別子のタイプを表します。この問題を解決するために、TypeScriptにシンタックスが追加されました。

つまり、ツールとしてサポートすることを目標としているのであれば、TypeScriptではこの分野では競争できない競合他社が少数存在します：

ESLintとTSLint：TypeScriptと同じように、コード内で発生する可能性のあるエラーを強調するために使用されますが、チェックプロセスに新しい構文は追加されません。どちらもIDE統合のためのツールとして動作するつもりはなく、またTSやTS/ESLintは、プロジェクトにとって意味のない特性を「相手の領域だ」と言うことが多い。最新のコードでは、TS/ESLintの存在により、TypeScriptはすべてのコードベースに適用されるわけではないチェックを少なくすることができます。いくつかの機能が重なってしまいましたが、それらを良い補完ツールとして活用することができます。
CoffeeScript：おい、TypeScriptは2012年にリリースされたんだ！CoffeeScriptとTypeScriptの違いは、CoffeeScriptがJavaScriptにいくつかの機能を追加するなど、JavaScript言語を改善したいという点です。これは、CoffeeScriptと書き出されるJavaScriptの違いを理解することを意味します。時間の経過とともに、CoffeeScriptのベストコンセプトが逆に別のJavaScriptにしてしまい、ほとんどJavaScriptになってしまったCoffeeScriptに困ってしまう。
Flow：これは、FacebookのJavaScript型検査ツールおよびIDEツール言語です。TypeScriptと同じように、FlowはJavaScriptにいくつかのシンタックスサポートを追加して、より豊富なタイプのシステムを手に入れ、コンパイル時に削除します。JavaScriptを書き始めた頃、Flowは標準的なJavaScriptに近いツールだったので、最初に使ったツールです。Flowは素晴らしいタイプのシステムで、TypeScriptとは異なる目標を持っています。目に見えないタイプ層システムは「正しい」あるいは「十分に正しいと感じる」決定をし続けなければならず、Flowの目標は「正しい」（訳者注：Flowはsoundness[6]に偏っており、タイプ判断においてより悲観的である）であり、TypeScriptの目標は「感覚的にはほとんどの場合が正しい」（訳者注：TS公式はTSは完全なタイプではありません[7]と主張しており、unsound行動を許容し、completenessに偏っており、タイプ判断においてより楽観的である）である。魚と熊の掌は両方を得ることができなくて、完備な類型導出、良好な開発体験と完璧なJS協同（Perfect JavaScript Interop）はその2つしか取れない。

では、オープンソースのFlowコードベースのほとんどが最終的にTypeScriptに移行したのはなぜでしょうか。私の中では、2つのチームの異なるサイドポイントで決められている部分が大きいと思います。FlowはFacebookのコードベースを維持するために作られていますが、TypeScriptは独立した言語として作られています。ここには2つの証拠があります：

Facebookのコードベースは分割できない巨大なモノレポであるが、Flowチームはこのような大規模コードベース[8]の下で型を実行するために信じられないほど多くの仕事が[9]を作成した。一方、TypeScriptは「小さなコードベースサービスを構築するため（use projects to make sets of smaller codebases）」と言えるが、これは人々がオープンソースコミュニティでJavaScriptモジュールを書く方法に合致しているからだ。そう言うのは理にかなっていると思いますが、TypeScriptはFlowのようにFacebookのコードベースでは動作せず、Facebookのコードを大量に書き直してプロジェクトを構築するか、TypeScriptに大量の修正を加える必要があり、TypeScript全体の開発者の体験に影響を与える可能性があります。
タイプに対するDefinitelyTypedとFlowのアプローチを比較すると、TypeScriptチームはコンパイラエンジニアをローテーションで配置し、DefinitelyTypedのビルドツールをサポートし、コミュニティの管理を支援します。そしてFlowは、ほぼ完全にコミュニティによって維持されています。DTは現在、非Facebookコードの開発に注力してきたため、より規模が大きくなっており、Flowチームからの資金支援を得るのは困難になるだろう。

マイクロソフトがTypeScriptに社内で作成した独立した環境により、TypeScriptは、特別に難しい問題の解決だけに集中するのではなく、ツール開発やエコシステム全体のメンテナンスに自由に集中できるようになりました。これにより、TypeScriptチームは多くの人と協力し、コミュニティが望む機能を次々とリリースできるようになりました。時間の経過とともに、外部からの需要の伸びが鈍化しているため、Flowチームはコミュニティの仕事に時間を割くことがますます難しくなっているのではないかと推測しています。これが悪循環となっている。これにより、FlowはTypeScriptの直接的な「競合者」ではなく、さまざまな角度から、さまざまな制約を使って、類似の問題を解決する方法について興味深い視点を持つようになりました。

1.5 TypeScriptの今後

1.5.1TypeScriptの今後についてどう考えていますか。

現在、TypeScriptの使用を妨げている最大の障害は、ビルドツールが必要であることです。型文法がJavaScriptに組み込まれる可能性は低いと思いますが、JavaScriptでは「型をアノテーションで定義する」可能性は十分にあります。

このアイデアは、TypeScriptのようなタイプのシステムのシンタックスのセットを作成することですが、JSの実行時に何が起こるかは定義されていません。

const a: string = "1234";

// 将会变成这样
const a /*: string */ = "1234";

// 传入 JS 引擎

この例では、JSエンジンは、stringが=で終わる型注釈であることを認識します。この実際の働き方は複雑で、解明に時間がかかる。しかし、JavaScriptでTypeScriptを「ネイティブに」実行できるようにすることで、TypeScriptが使用される際の障壁が低くなります。BabelがTypeScriptサポートを追加したときと同じように、TypeScriptにいくつかの制約を適用します。でもそれだけの価値はあると思う。

Denoは、現在のJavaScriptエンジンによるネイティブTypeScriptのサポートをシミュレートしたRustで書かれたツールを実行することで、TSのJSへのコンパイルを非常に迅速に行うことができる、すべてのTSの障害を取り除く重要な例です。

1.5.2今日の競合他社

JetBrains WebStorm-高度なJavaScriptツールをサポートするIDEです。リファクタリング、コードフロー解析、JavaScript構文のチェックを行う独自のエンジンがあります。これはすばらしいことです。JetBrainsはすべてのIDEでしっかりとした仕事をしています。私は過去にAppCodeを使ってiOSの仕事をすることが多かった。TypeScriptのプロジェクトがある場合、WebStormはTypeScriptの言語ツールと独自のツールをミックスしてくれるので、Win-Winです。
JSにコンパイルされた言語-現在の例としてElm、ReScript、KotlinScriptがありますが、これらの言語はJavaScriptとの対話を中心にしています。これらはTypeScriptにとって興味深い言語であり、タイプシステムを実装するためのクリーンな環境を持っています。つまり、JSの負担がありません。競合他社としては、JavaScriptが中心ではないことや、CoffeeScriptからの移行にコミュニティが悩まされてきたことから、より細分化された市場を好む傾向があります。
WASM-TypeScriptの競合他社としてのWASMの見解は、WASMがJSコントロールブラウザDOMに代わる言語として機能するというものだと聞きました。これに反対する人々は、WASMにはDOMバインディングがなく、おそらく永遠に存在しないと考えている。TypeScriptにはJavaScriptの欠点が含まれていますが、JavaScriptランタイムにWASMを組み込んだことがあれば、ほぼ常にもっと好きになるでしょう。ということは、AssemblyScriptはこの点でかなり良い仕事をしているということになります。WASMはJSONと考えた方が良いかもしれません。WASMはプロジェクトを構成する別のツールであり、WASMとDOMの相互作用の仕方が変わっていない限り、JavaScriptの競合にはなりそうにありません。
WASMにコンパイルされた言語-たとえば、Rust、Go、Swiftなど、WASMにコンパイルできる他の言語。これらの言語はいずれもTypeScriptの現在のツールやwebのコア・ビルディング・モジュールとしての位置を占めている可能性がありますが、どうなるかわかりません。これらの言語は、さまざまな基本型を提供し、異なる目標に基づいてゼロから構築することができます。WASMやWASIが最終的に成功するのであれば、プラットフォームに関わることになると思いますが（appsなどの機能実装を考えてみてください）、その方向性を見てみると面白いと思います。本音を言えば、それらはTypeScriptの競合ではなく、JavaScriptのものです。

1.5.3 TypeScriptは生態系の中での位置をどう見ていますか？

TypeScriptは、タイプシステムやエディタツールの分野でイノベーションを起こしたいと考えています。私たちは、主流のプログラミング言語の中で最も表現力の高いタイプのシステムの1つを持っています。

TypeScriptが最初に作成されたときのJavaScriptの修正プロセスは現在とはかなり異なるため、TypeScriptには実際にはTC39の領域である機能がいくつかありますが、下位互換性が必要です。これらの機能はJavaScriptに何年も存在し、何度も繰り返されることがあります。つまり、TypeScriptは、特定の言語機能の2つのバージョンを維持する必要があります。

そこでTC39 JavaScript言語委員会の優秀なメンバーになり、エディタがサポートする言語特性についてフィードバックし、TypeScriptユーザーが見たい特性をサポートすることを目指しています。このコラボレーションによって、TC39はJavaScriptを制御し、TypeScriptもそれらをサポートします。

1.5.4 TypeScriptはそのオーディエンスをどのように見ていますか。

TypeScriptのオーディエンスは主に次のとおりです。

JavaScriptユーザー(言語ツールとして)
JS+JSDocユーザー(言語ツールとして)
TypeScriptユーザー(コンパイラ、言語ツールとして)
TypeScript strictモード(コンパイラ、言語ツールとして)

babel/swc/sucrase/esbuildなどのツールを使用してプロジェクトを構築する場合、tscはオプションですが、前述の参加者はTSリリースのたびに、または少なくとも2回ごとに新しい機能を利用できます（訳者注：babel、esbuildなどはTSの新機能をサポートするために更新されます。TSチームが直接プロジェクトに参加するか、vscodeなどの機能をtscなしで提供する場合があります。その他のリリース計画については、TS roadmap[10]を参照してください）。

1.5.5 TypeScriptはJSの生態をどのように追跡しているのか。

チームは、次のような方法でフィードバックを受けます：

GitHub Isuesには絶え間ないコメントの残響がある
Microsoftの社内チームが機能を提供するか、低速なコードベースのデバッグを私たちに依頼してきた
GitterまたはTypeScriptコミュニティのDiscordを介してコミュニティとつながる
マイクロクラスターの内部ツールを使用したアイデア/デザインのユーザーテスト
VS Codeと非常に密接な関係があり、多くの言語ツールからフィードバックが寄せられている
@TypeScriptチームのツイートを読むと
TypeScriptに移行されたブログ投稿とTypeScriptから移行されたブログ投稿を追跡します
業界調査とプログラミング言語の概要を追跡