TypeScriptを選んだ理由：Redditの開発者の歴史

約半年前、Steve RedditのCEO は 、サイトを再設計すると発表しました。 ここでの主な質問は、どのようにそれを行うかです。 現在、フロントエンド開発は、Redditが生まれた当時の開発とは大きく異なります。 これで、Webアプリケーションの各サブシステムにオプションの膨大な選択があります。 ページをレンダリングする方法は？ コンテンツのスタイル設定方法 写真とビデオファイルを保存および管理する方法 コードの書き方 現代の状況では、これらの質問にはどれもすぐに答えられるものはありません。



答えを見つけるために必要な最初のそのような質問の1つは、「選択する言語はどれですか？」です。

豊富な選択肢と言語要件について

奇妙なことに、フロントエンドの言語はJavaScriptである必要はありませんでした。 最終的に、この目的のためにどの言語が選択されても、それに記述されたコードはJavaScriptでコンパイルされます。 ただし、コードが正確にコンパイルされるものは、開発者が作成するものよりもおそらく重要ではありません。 言語の選択は容易ではありませんでした。 考慮しなければならないことは次のとおりです。

1. BuckleScript
   
   
2. ClojureScript
   
   
3. CoffeeScript
   
   
4. ニレ
   
   
5. ElixirScript
   
   
6. JavaScript 2016および将来の言語バージョン
   
   
7. JavaScript +アノテーション
   
   
8. ニム
   
   
9. ピュアスクリプト
   
   
10. 理由
    
    
11. TypeScript
    
    

ところで、これは完全なリストからはほど遠い。 各言語には長所と短所があります。そのため、言語の1つを選択できるように、次の要件を策定しました。

1. それは強く型付けされた言語でなければなりません 。 タイプは、ミクロレベルで、ドキュメントの役割を果たします。 これらは、ある程度、コードの正確性を確保するのに役立ち、さらに重要なことには、リファクタリングを簡素化します。 強く型付けされた言語を探していたもう1つの考慮事項は、開発速度です。 作業を高速化するために、強く型付けされた言語を見つけようとしました。 このようなアイデアは、多くのプログラマーが開発した典型的なビジョンに反するものです。 つまり、これは開発者にとって追加の負担であり、作業の速度を低下させると一般に受け入れられています。 ただし、開発速度を上げることは、エラーの可能性を高めることも意味します。 コードは、たとえ迅速に記述されたとしても、できるだけ少ないエラーを含むように入力する必要がありました。 強力なタイピングは、急成長中のプロジェクトでも役立ちます。 弊社のエンジニアチームは常に規模を拡大しており、コードに携わる人の数は着実に増加しています。
   
   
   
   
2. 優れたサポートツールが必要です。 私たちがやろうとしていることを考慮して（サイトの大幅な再設計）、かなりの数の補助ツールを独自に作成する時間はありませんでした。 既製のオープンソースソリューションを使用して迅速に開始できることが非常に重要でした。 より具体的には、これらは問題の特定のツールです。 これは、一般的なビルドシステム（Webpackなど）との統合、リンターのサポート、テストフレームワークとの簡単な統合です。 一部の言語の補助システムの統合が明らかでない場合、この言語は考慮されなくなりました。
   
   
   
   
3. この言語は深刻なプロジェクトで使用されることになっていました 。 言語は良さそうに見えたが、実際には個々の愛好家の小さなプロジェクトでのみ使用されていた場合、それは私たちの仕事には不適切かもしれません。 さらに、言語が深刻なプロジェクトで使用されていない場合、そのような言語がどのくらい続くか、および言語開発者がその言語で見つかったエラーに関するメッセージにどれだけ迅速に応答するかについて疑問が生じます。
   
   
   
   
4. 開発者は、言語を十分に早く習得する必要があります 。 上記のリストには素晴らしい言語がありますが、唯一のマイナスは、開発者がそれらを習得するのに時間がかかりすぎることです。 その中でも、私はElmとPureScriptについて言及したいと思います。 それらの使用の問題について真剣に議論しました。 しかし、最終的には、それらの実装は、それらに精通していない開発者がプロ​​ジェクトで生産的に作業できるレベルに達するには、それらに慣れていない開発者による新しいプログラミング概念の開発に必要な作業が多すぎることを意味することが判明しました。
   
   
   
   
5. 言語は、クライアントとサーバーの両方で動作するはずです。 Redditでは、SEOは非常に重要であるため、ブラウザで表示できるページを配信するためのユニバーサルシステムの欠如は大きな問題です。
   
   
   
   
6. 優れたライブラリサポート 。 すべてをゼロから書くつもりはありませんでした。 信頼できる、実績のあるライブラリを必要とするタスクがいくつかあります。 私たちは、既存のライブラリから必要なものを選択する機会を得たいと考えました。

これらの要件を検討した後、2つのオプションを決定しました。 1つ目はTypeScriptです。 2番目はJavaScript + Flowです。 しかし、最終的な選択を行う前に、TypeScriptとFlowの機能、およびそれらの違いをできるだけよく理解する必要がありました。

編集または注釈？

TypeScriptとFlowの重要な違いの1つは、TypeScriptはJavaScriptにコンパイルされる言語であり、FlowはJavaScriptコードに追加できる型注釈のコレクションであることです。 注釈付きコードの正確性は、静的アナライザーによってチェックされます。



上記の違いは、プログラムの作成方法に直接影響します。 たとえば、TypeScriptおよびFlowの列挙での作業を見てください。



TypeScript

enum VoteDirection {  upvoted = 1,  notvoted = 0,  downvoted = -1, }; const voteState: VoteDirection = VoteDirection.upvoted;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

流れ

 const voteDirections = { upvoted: 1, notvoted: 0, downvoted: -1, }; type VoteDirection = $Keys<typeof voteDirections>; const voteState: VoteDirection = voteDirections.upvoted;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TypeScriptはコンパイルされた言語であるため、実行時に定義される型を作成するために使用できます。 フローでは、型は単なる注釈であるため、コード変換に依存して実行時に型表現を作成することはできません。



ただし、TypeScriptはコンパイルされた言語であるという事実により、いくつかの欠点があります。 TypeScriptを既存のコードベースに統合する場合、コンパイラがビルドプロセスを複雑にする可能性があります。 Babelとトランスパイレーションレイヤーを使用したビルドプロセスが確立されています。 TypeScriptに切り替えても維持したい最適化がいくつかあるため、既存の作業スキームを破壊しないTypeScriptを統合する方法が必要でした。 TypeScriptは、はるかに複雑なビルドプロセスをもたらします。



TypeScript処理とは対照的に、BabelはFlowタイプの注釈を自動的に削除します。 Flowを選択した場合、アプリケーションの構築プロセスは複雑ではありません。

コード検証

コード検証の分野では、通常、FlowはTypeScriptよりもパフォーマンスが高くなります。 Flowでは、デフォルトで、 NULL



型を使用することは禁止されています。 TypeScript 2.xでは、 NULL



許可されていない型のサポートが追加されましたが、この機能を自分で有効にする必要があります。 さらに、Flowは型をより適切に表示しますが、TypeScriptはしばしばany



参照しany



。



NULL



と型推論を許可する型に加えて、Flowは共分散と反分散の問題に適しています（このトピックに関する資料はこちらです ）。 ここでの典型的な問題状況の1つは、型付き配列の操作です。 デフォルトでは、Flowの配列は不変です。 これは、Flowの次の構成がエラーをスローすることを意味します。



流れ

 class Animal {} class Bird extends Animal {} const foo: Array<Bird> = []; foo.push(new Animal()); /* foo.push(new A);       ^ A. This type is incompatible with const foo: Array<B> = [];               ^ B */
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、TypeScriptで同じことをしようとすると、エラーメッセージなしで失敗します。



タイプスクリプト

 class Animal {} class Bird extends Animal {} const foo: Array<Bird> = []; foo.push(new Animal()); //  typescript  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに多くの類似した例を見つけることができますが、一般的な結論は、フローはTypeScriptよりも型チェックではるかに優れていることです。

生態系

これまで述べてきたことはすべて、Flowの利点について語っています。 プロジェクトに統合する方が簡単で、型チェックにうまく対応します。 なぜTypeScriptで停止したのですか？



TypeScriptの最も重要な利点の1つは、そのエコシステムです。 それは素晴らしいライブラリをサポートしています。 使用したほとんどすべてのライブラリーは、ライブラリー自体にタイプの説明があるか、 DefinitelyTypedで提示されています。 さらに、TypeScriptは、VSCodeおよび使用している他の一般的なエディターのプラグイン（AtomやSublimeTextなど）で優れたIntelliSenseをサポートしています。 さらに、TypeScriptがJSDocアノテーションを処理できることを発見しました。 JavaScriptを使用してTypeScriptに切り替えたため、これは特に有用であることが判明しました。



さらに、TypeScriptはより「社会的重要性」が高く、彼の人生は十分に長くなるという感覚があります。 TypeScriptを使用するいくつかの大規模なプロジェクト（VSCode、Rxjs、Angular、TypeScript自体）があるため、その機能セットがプロジェクトの目標を達成し、今後数年間でその言語を使用できると確信しています。どこにも行かない。 Flowについては、Facebook上の特定のタスクを解決するために作成されたものであり、その開発は同じ範囲のタスクによって決定されることを心配しています。 一方、TypeScriptは幅広い問題に焦点を当てており、Microsoftは現在取り組んでいます。 これにより、エラーが発生してそれらを報告した場合、彼らは私たちの声を聞いて行動を起こすと想定できます。



さらに、TypeScriptはJavaScriptのスーパーセットであるため、TypeScriptの開発、特に新しい型と言語構成体のサポートは、JSの開発に続くことが期待できます。 言語と型のシステムは並行して開発されます。それらの作業が進行中だからです。

まとめ

TypeScriptを選んだのは、新しい開発者が必要とするすべてのものをすばやく教えることができると確信しているからです（昨年、フロントエンドエンジニアの数は3倍になりました）。 この言語は、サイトの再設計におけるニーズを満たしていると確信しています。 さらに、すべてがTypeScriptが長期間存在することを示唆しており、私たちの調査では、TypeScriptがコードベースとうまく統合されることが示されています。 しかし、私たちにとって最も重要なことは、強く型付けされた言語への移行です。



型付き言語を使用すると、すでにいくつかの結果が得られています。 コードに含まれる型関連のエラーは少なく、大規模なリファクタリングをより自信を持って実行します。 埋め込みドキュメントは、オブジェクトと関数パラメーターの内部構造を記述するのではなく、概念に焦点を合わせています。 その結果、TypeScriptはまさに私たちが必要としていたものであると言えます。



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