🏴‍☠️ 😦 🐘 最初のTypeScriptデモ 🏔️ 🏿 👩‍🏫

最近では、 TypeScriptの5周年記念が行われ、週1回の技術会議でAndersと開発チームと会う機会がありました。 TypeScriptの人生における重要なマイルストーンを祝福し、プロジェクトを去ってから4年間でどれだけの成果を上げたかを伝えたかったのです。

さらに、プロジェクトの作業の最初にTypeScriptで作成された古いデモ（Stradaと呼ばれていました）を見つけて、現在TypeScriptで作業している人と一緒に視聴しました。

今日は、TypeScriptの始まりについてお話したいと思います。

開始する

2010年の秋に、Steve Luccoと私は新しいプロジェクトに取り組み始めました。彼の目標は、アプリケーション開発チームが大量のJavaScriptコードを管理できるようにすることでした。スティーブは本社の複数のテクニカルディレクターと話をしました。彼らは、部門のC ++ / C＃からJavaScriptへの急速な移行について話し、現在、プログラムと対話するためのWebアプリケーションおよび対応するスクリプトの開発に真剣な努力が注がれています。開発チームには、Visual Studioなどの品質の高いツールや、C ++およびC＃型システムが提供する機能がありませんでした。彼らは、JavaScriptへの移行を促進するために私たちができることを知りたいと思っています。その後、同様の方向に向かう強力なITトレンドに注目しました。

高速なJavaScriptエンジンが登場し、HTML5が開発され、印象的なWebアプリケーションのサイズと機能がいくつか登場しました。これらはすべて、WebでのJavaScriptの使用方法の急速な変化を示しており、過去数年はそうではありませんでした。

その時までには、前述の問題を解決するための多くのオプションがすでにありましたが、それらのどれも私たちに適さず、かなり広い市場ニッチの期待に応えませんでした。マイクロソフト内では、いくつかの大規模なチームがスクリプト＃を使用しました。これにより、JavaScriptの代わりにC＃を使用できるようになりました。ただし、結果として、実際にプログラムした環境からは遠すぎました。これはいくつかの不便を引き起こしました。また、 Google Closure Compilerがあり、JSコード内のコメントに埋め込まれた豊富なタイプのシステムを提供しました。これにより、高度なミニファイプロセスを制御できます（同時に、タイプに関連するエラーを追跡して報告できます）。そして最後に、 CoffeeScriptの全盛期がありました。 CoffeeScriptは、JS開発におけるトランスパイラーへの道を開いた、広く使用された最初のJavaScript言語でした。ちなみに、私は最初に次の類推を使用してTypeScriptの機能についてよく話しました：「 CoffeeScript：TypeScript :: Ruby：C＃/ Java / C ++ 」、しばしば次のように追加します。 Rubyで書く人:) 」。

私たちはすぐに、上記の3つのテクノロジーの交差点に位置するもの、あらゆる点で既存のものよりも優れたものを作成したいと考えました。私たちの見解では、これはセマンティクスと構文が可能な限りJavaScriptに近い言語であると想定されていました。そのようなプロパティは、それぞれCoffeeScriptとClosure Compilerが所有していました。さらに、この言語が型チェックと便利なツールをサポートすること、つまりスクリプト＃を最大限に活用することを望んでいました。

2010年の秋と冬に、マイナープロジェクトとしてTypeScriptの作業を開始しました。リラックスしないために、私たちの仕事の結果が他の人に示されるように、やる気を起こさせるために、私たちがやったことのデモンストレーションを伴う内部プレゼンテーションを計画しました。これは、Microsoftの研究およびソフトウェア開発チームのプログラミング言語スタッフが招待されるミニ会議であることになっています。しかし、イベントの1か月前に、スティーブ（当時チームで唯一のエンジニア）が手首を負傷したため、正常にプログラミングできませんでした。その結果、計画されたパフォーマンスを回避したくないので、実際に動作するコンパイラがなくても、私たちが目指していることを実証できるすべてのものを収集することにしました。（すぐに、スティーブは最初の真のTypeScriptコンパイラーを作成しました。これにより、最初の内部ユーザー（後にVSコードになったものを作成したチーム）がTypeScriptを使用して実際の問題を解決できるようになりました）。

最初のデモンストレーション

以下は、2011年2月1日に小規模チーム以外のStradaデモで使用した主要なコードです。

<!DOCTYPE html> <html> <meta http-equiv="X-UA-Compatible" content="IE=9"> <head>    <title>JavascriptWebClient</title>    <script src="http://ajax.aspnetcdn.com/ajax/jquery/jquery-1.5.1.js" type="text/javascript"></script> </head> <body>    <h1>Employee Pay</h1>       <h3><font color="#3AC1EF">▍SalesEmployee's are paid: <span id='salesEmployeePay'></span></font></h3>    <div id='results'></div>    <script type='text/strada'>        extern var $;        class Employee(string name, double basepay) {          public double calculatePay() {            return basepay;          }        }        class SalesEmployee(string name, double basepay, double salesbonus) : Employee(name, basepay) {          public string getName() { return name; }          public double calculatePay() {            return base.calculatePay() + salesbonus;          }        }        var employee = new Employee('Bob', 1000);        var salesEmployee = new SalesEmployee('Jim', 800, 400);        $('#salesEmployeePay').html(salesEmployee.calculatePay());    </script>    <!-- Load the Strada compiler to processs text/strada tags -->    <script src='StradaCompiler.js' type="text/javascript"></script> </body> </html>

最終的にTypeScriptと呼ばれる言語になった要素が多数あります。

注釈を必要とせずに行28〜30で型を適用する暗黙的なプロセス。
クラス-アプリケーションメカニズムと変数のタイプの実装を記述する方法として。クラスは単純なJavaScriptでは便利ですが、TypeScriptではより重要な役割を果たし、実装と型の両方を一度に記述でき、二重の作業を行う必要がありません。
extern

キーワード。タイプ情報が提供されていない（またはまだ提供されていない）場合でも、通常のJSコードおよびライブラリと透過的に対話できます。

ただし、ここでは、最終的にTypeScriptから削除したものを見ることができます。

クラス構文ここに示されている、より「機能的な」クラス構文を使用したかったのです。私は、少し前に、クラスに同様の簡潔な構文を使用するF＃に取り組みました。さらに、C＃の同様の構文についても説明しました。この構文は、ECMAScriptで標準化されたクラスのプロトタイプに基づくアプローチで見られるように、オブジェクトプロパティの代わりに、当時人気があったJavaScriptの「クラス」で状態を表すためにクロージャーを使用するスタイルに適していることに注意してください。このトピックは、TypeScriptのリリースまでほとんど議論の余地がありました。

ECMAScriptのクラスで発生したことは別の方向に進み、TypeScriptを将来の標準に近づけたいと考えましたが、標準の構成体の上にTypeScriptクラスを記述しなければならないという事実は嫌いでした（通常の状況では、名前の4倍の繰り返しになります変数）。その結果、標準への準拠を強調しました。それは危険でした。事実は、ES6がどのような運命を待っているのかが完全には明らかではなかったということです。 ES4のように、彼は出てこなかっただろう。しかし、私たちにとって最も重要なことは、JavaScriptの中で最も軽量な抽象化であると想定されていたTypeScriptの主要な目標に従うことでした。。
プレフィックスとしてタイプを指定します。上記のコードでは、 string name

代わりにstring name

ようなものを見ることができますname: string

string-現代のTypeScriptで使用されるレコード。現在any

と呼ばれている型にvar

キーワードを使用したため、最初はこの構文に傾倒していました。これにより、 var x = …

ような式で明示的にany

型に暗黙的にキャストできます。さらに、これは、暗黙的なvar

型がそこに現れたときにC＃で最近行われたものに似ていました。しかし、この位置に型情報を配置するための言語の文法は、解析に多くの問題をもたらします。さらに、この分野では、JavaScriptなどの言語でフォーマットname: string

を使用した貴重な先例がありましたname: string

（まず、ActionScriptであり、ECMAScript4で出てきませんでした）。その結果、ここで使用されているアプローチを非常に早く変更しました。最初のプレゼンテーションから2か月後に行ったコードサンプルでは、コロン構文が既に使用されています。
スーパークラス。 class Foo : Bar

デザインのclass Foo : Bar

C＃スタイルのスーパークラスのclass Foo : Bar

ました。その後、 extends

使用に切り替えました。
スクリプトをコンパイルするアプローチ。ここにもう1つ小さなものがあります。コードは<script type="text/strada">

ブロックにあり、コメントにはStradaCompiler.js

が "on the fly"と呼ばれるtext/strada

ブロックのコンパイルを担当していることにStradaCompiler.js

てStradaCompiler.js

。次に、プロジェクトのアセンブリの独立したステージを使用する代わりに、 <script>

タグを使用してTypeScriptをHTMLに直接配置し、この組み込みコードがページの読み込み時に転置（および、できればキャッシュ）されることを想像しました。当時、このアプローチはCoffeeScriptの小規模プロジェクトで一般的でしたが、かなり大きな開発チームと議論した結果、ほとんどの場合ではなくとも、多くの実際の状況でこれが非実用的であることがわかりました。実際には、このような問題は、WebPackなどのツールを使用して最終的に解決されました。WebPackは、コードを動的に再コンパイルしましたが、コンパイルされた形式でブラウザに表示しました。

私はこれがすべて花であると言わなければなりません。さらに興味深いのは、このコードをどのように機能させるかです。

どのように機能しましたか

その後、F＃でJavaScriptインタープリターを作成するための小さな2次プロジェクトがありました（F＃での作業からJavaScriptでの作業に切り替える手段のようなものです）。このプロジェクトの一部は、かなり安定したJavaScript（ES5）パーサーでした。 Stradaに追加した新しいコンストラクトをサポートするために、いくつかの文法を変更しました（驚くほど少数が必要でした）。基本的には次のようになりました。

 @@ -459,8 +466,12 @@ StatementList:    | Statement                              { [$1]} // See 12.2 VariableStatement:                          -    | VAR VariableDeclarationList SEMICOLON  { VariableStatement(List.rev($2)) } -    | VAR VariableDeclarationList            { VariableStatement(List.rev($2)) } +    | Type VariableDeclarationList SEMICOLON  { VariableStatement([], false, $1,List.rev($2)) } +    | Type VariableDeclarationList            { VariableStatement([], false, $1, List.rev($2)) } +    | READONLY Type VariableDeclarationList SEMICOLON  { VariableStatement([], true, $2,List.rev($3)) } +    | READONLY Type VariableDeclarationList            { VariableStatement([], true, $2, List.rev($3)) } // See 12.2 VariableDeclarationList:    | VariableDeclaration                                  { [$1]}

ちなみに、この初期バージョンではreadonly

だったようです。

結果のASTを通常のJavaScriptとして出力する方法を見つけましたが、型を破棄する代わりに、クロージャーコンパイラによってそれらをコメントに変換しました。その結果、デザインは特に安定していないことが判明しましたが、デモを開始するにはこれで十分でした！

その後、これは非常に論理的であり、型チェックツールの形式で結果のコードをクロージャコンパイラと呼びました。 Closure CompilerはAppEngineに便利なサービスがあり（まだあります）、その結果、コードをPOSTリクエストとしてこのサービスに送信し、エラーに関する情報を受け取りました。

当時、Silverlight（およびFlash）は、クライアントアプリケーションの開発において依然として重要な役割を果たしていました。そのため、パーサー（F＃で記述）を開始するために、 text/strada

スクリプトを検出し、それらを解析し、クロージャーを送信し、エラーを報告するSilverlightアプリケーションとしてページに配置しました。

 using System; using System.Collections.Generic; using System.Linq; using System.Runtime.Serialization; using System.ServiceModel; using System.Text; using System.ServiceModel.Activation; using System.Net; using System.IO; using System.Web; namespace JavascriptWebClient.Web {   // NOTE: You can use the "Rename" command on the "Refactor" menu to change the class name "ClosureCompile" in code, svc and config file together.   [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]   [ServiceBehavior(IncludeExceptionDetailInFaults=true)]   public class ClosureCompile : IClosureCompile   {       public string DoWork(string srcText)       {           System.Diagnostics.Debug.WriteLine("Hello!");           var request = WebRequest.Create("http://closure-compiler.appspot.com/compile");           request.Method = "POST";           request.ContentType = "application/x-www-form-urlencoded";           var stream = request.GetRequestStream();           // Send the post variables            StreamWriter writer = new StreamWriter(stream);           writer.Write("output_format=xml");           writer.Write("&output_info=compiled_code");           writer.Write("&output_info=warnings");           writer.Write("&output_info=errors");           writer.Write("&output_info=statistics");           writer.Write("&compilation_level=ADVANCED_OPTIMIZATIONS");           writer.Write("&warning_level=verbose");           writer.Write("&js_code=" + HttpUtility.UrlEncode(srcText));           writer.Flush();           writer.Close();           var response = request.GetResponse();           Stream responseStream = response.GetResponseStream();           StreamReader reader = new StreamReader(responseStream);           // get the result text            string result = reader.ReadToEnd();           return result;       }   } }

このコードはいくつの思い出を呼び起こしますか...

その結果、開発者ツールのツールを使用して<script>

内容を変更する際のエラーに関するインタラクティブな情報を受け取ることができ、バックグラウンドタイプチェックシステムがここで機能するという印象を与えました。これにより、達成したい主要な機能のいくつかを実証することができました。確かに、このすべてがどのように行われたかは、少なくとも1人の本物のプログラマがプロジェクトに取り組むのに適していませんでした。

次に、別のコードを示しました。ここでは、結果としてTypeScriptになったものとはさらに興味深い違いをいくつか見ることができます。たとえば、 number

代わりにdouble

型（ int

追加することを考えましたが、これによりJavaScriptのセマンティクスから遠ざかりました）、C＃で慣習的なインターフェイスのI

プレフィックス。インターフェイスや、型指定されていないオブジェクトと厳密に型指定されたクラスの要素の検索を自由に混在させる機能など、残っているものもいくつかあります。

 interface IHashtable {   double lookup(string i);   void set(string i, double d);       } class Hashtable() {   var o = {};   public double lookup(string i)   {       return this.o[i];   }   public void set(string i, double d)   {       this.o[i] = d;   } } interface IExpression {   double evaluate(IHashtable vars); } class Constant(double value) : IExpression {   public double evaluate(IHashtable vars) {       return value;   } } class VariableReference(string name) : IExpression {   public double evaluate(IHashtable vars) {       var value = vars.lookup(name);       return value;   } } class Operation(IExpression left, string op, IExpression right) : IExpression {   public double evaluate(IHashtable vars) {       double x = this.left.evaluate(vars);       double y = this.right.evaluate(vars);       switch (this.op) {           case '+': return x + y;           case '-': return x - y;           case '*': return x * y;           case '/': return x / y;       }   } } IExpression e = new Operation(new VariableReference("x"),'+',new Constant(3)); function f() {       IExpression e = new Operation( new VariableReference("x"),           '*', new Operation( new VariableReference("y"), '+', new Constant(2) ));       IHashtable vars = new Hashtable();       vars.set("x", 3);       vars.set("y", 5);       e.evaluate(vars); // Outputs "21"       vars.set("x", 1.5);       vars.set("y", 9);       return e.evaluate(vars); // Outputs "16.5"   } f();

まとめ

最初のデモから約1年半後、 TypeScriptをリリースしました。そして、5年後、TypeScriptはソフトウェア開発業界で最も急速に成長しているプログラミング言語の1つになりました。

さて、これを外部のオブザーバーとして見ると、TypeScriptチームが言語の最初のアイデアを固守する一貫性を賞賛せざるを得ません。重要なのは、TypeScriptはJavaScriptの単なる軽量な抽象化であるということです。また、元々指定されていた同じフレームワークを保持したまま、言語がどのように発展するかという楽しい印象を作り出します。つまり、その目的は、ほとんどすべてのJavaScriptプロジェクトで生産的に使用できる型システムを提供することです。 TypeScriptは、JSエコシステムにおける新しいフレームワークと開発スタイルの出現により、その理想に忠実であり続けています。

TypeScriptの記念日におめでとうございます。開発チームとTSコミュニティに感謝します。どのTypeScriptがすばらしい仕事をしているかに感謝します。

親愛なる読者！ TypeScriptを使用していますか？

最初のTypeScriptデモ

開始する

最初のデモンストレーション

どのように機能しましたか

まとめ

More articles: