タイトルを見たとき、あなたも思わず悪態をつき、編集者を厳しく批判したくなったと思います… 焦っているのはわかりますが、まだ焦らないでください。
https://www.zhihu.com/question/621997070経由
これは実は最近 Zhihu で非常に人気のある質問で、サイトの一貫した伝統「まず真実かどうかを尋ね、次にその理由を尋ねる」によれば、この質問はセンセーショナルであり、意図的に注目を集めようとしているようです。
2012 年にリリースされたTypeScript は、現在、多くのプログラミング言語ランキング、インデックス、開発者調査でトップにランクされており、最も人気があり一般的に使用されているプログラミング言語でもあり、世界中の何百万人もの開発者によって使用されています。
TypeScript に関するいくつかのニュース記事を見つけて、雰囲気をつかんでください。
- 2022 年の JavaScript 調査: TypeScript が引き続き優勢、Vite と Tauri が人気
- 2021 年の JavaScript 調査: Vite の年に、Esbuild とTypeScript の採用率が大幅に増加
- 2020 年開発者アンケート: TypeScript が Python を上回り、Scala が最も収益性が高い
- RedMonk ランキング: TypeScript と C++ は同点、Kotlin は Go を超えるでしょうか?
いわゆる「TypeScript が大手企業によって放棄された」に関して、今年は確かに 2 つの有名な出来事がありました。
- Ruby on Rails の作者 DHH が、TypeScript コードが Turbo 8 から削除されることを発表
- Svelte は TypeScript から JavaScript に切り替えています
あなたが優れた専門家であるかどうかについては、フロントエンドの第一人者である Winter 氏の「コノテーション」評価を見てみるのもよいでしょう 。
そろそろ本題に戻りましょう。Open Source China は最近、次の 3 人の上級フロントエンド エンジニアにインタビューしました。
Liu Yong は、コミュニティでは Tianzhu という愛称で呼ばれており、大企業の Node.js インフラ部門の責任者であり 、EggJS / CNPM のコア開発者です。
コミュニティのニックネームが xcatliu (野良子猫) である Liu Yicheng は、 「TypeScriptチュートリアル入門」 の著者であり、Tencent ドキュメント チームの出身です。
Li Zhen はコミュニティ内でダニというあだ名で呼ばれており、Tencent ドキュメント チームの出身です。
議論の方向性は「TypeScript を捨てて JavaScript に戻る」というテーマから始まったばかりですが、それぞれの意見を見てみましょう。
Q: TypeScriptはJavaScript を ベースにした新しい言語です 。理論的には JavaScript よりも完成度が高いはずですが、なぜ人々は依然として古い JavaScript に戻るのでしょうか? これは歴史を逆転させるものとしてカウントされますか?
Liu Yong:それは逆転ではなく、単なる選択です。シナリオによっては、TypeScript の作成に追加コストがかかることもあります。たとえば、いくつかのオープン ソース ライブラリのソース コードを見てきましたが、コア ロジックはわずか数十行ですが、正確な型プロンプトを実現するために、コア ソース コードよりもはるかに多くの型体操が記述されています。正しいか間違っているかは開発者によって異なるため、基準はバランス ポイントを見つける必要があります。もちろん、現状に関する限り、個人的にはできれば TypeScript を使用することをお勧めしますが、型体操をしたいかどうかは開発者自身の状況によって異なります。
Liu Yicheng:既に TypeScript を使用しているプロジェクトが JavaScript の使用に戻ることはまれですが、JavaScript から TypeScript にアップグレードするプロジェクトが増えています。TypeScript は JavaScript の型システムを改善し、コードの保守性を高めますが、コンパイル手順と一部の開発コストも増加します。一部のプロジェクトでは、JavaScript がすでにニーズを満たしているため、TypeScript 型システムの複雑さを増す必要はありませんが、他の複雑なプロジェクトでは、コードの保守性を向上させるために型システムが必要であるため、これは始まりではありません。歴史を逆転させるのではなく、実際の状況に基づいて技術的な選択を行ってください。
Q: TypeScriptからJavaScript に戻る上記のプロジェクトは すべて開発フレームワークですが、これはプロジェクトの種類に関連していますか? JavaScriptプロジェクトはフレームワーク プロジェクトに選ばれる可能性が高いですか?
Li Zhen:はい、プロジェクトの種類は、JavaScript か TypeScript の選択に影響を与える要因になる可能性があります。フレームワークまたはライブラリ、特にフロントエンド フレームワークまたはライブラリを開発する場合、JavaScript の使用を選択するのが一般的です。
一方で、開発フレームワークは、開発者がさまざまなプロジェクトで使用できるように、幅広い互換性を備えている必要があります。JavaScript は Web 開発の基本言語であるため、ほとんどすべてのブラウザと環境が JavaScript をサポートしています。これにより、JavaScript で記述されたフレームワークが広く採用され、統合されやすくなります。
一方、開発フレームワークは通常、さまざまなプロジェクトのニーズを満たすために、使いやすい API と柔軟な拡張メカニズムを提供する必要があります。JavaScript を使用すると、型の注釈やコンパイル手順をあまり必要とせずに、これらの概念をより直接的に表現できます。これにより、開発者はフレームワークをより早く理解して使用できるようになり、カスタマイズと拡張が容易になります。
Liu Yong:フレームワークやクラス ライブラリの開発者は、多くのエッジ ケースを考慮する必要があることがよくありますが、この場合、完全な型を作成するのは非常に労力がかかる作業であり、コードの量もはるかに多くなり、メンテナンスコストの増加につながります。 。実際、コミュニティはまだ模索段階にあり、どの部分を改善する必要があり、どの部分を選択できるかというバランス ポイントを見つける必要があります。
Q: TypeScriptを使い始めたのは、TypeScript が型チェックを提供しているためで、 JavaScriptにはロジックだけがあって型がないという問題 が補われています。では、JavaScript + JSDoc を使用して型宣言を解決すれば、TypeScript を使用する必要はなくなりますか?
Liu Yong:まず第一に、JSDoc は型宣言の問題を完全に解決することはできませんし、開発者が開発期間中に問題を発見するのにも役立ちません。
TypeScript 型にはそれ以上のコメントや説明を含めることができないため、私は個人的に TypeScript を作成するときに対応する JSDoc も作成します。また、将来的には TypeScript チームがこのエクスペリエンスを最適化してくれることを期待しています。
Liu Yicheng: JSDoc は型の問題の一部しか解決できませんが、TypeScript は完全な型システムです。TypeScript エコシステムはより繁栄していますが、一般の開発者やプロジェクトの場合、JSDoc を使用する開発コストと保守コストは TypeScript よりも高くなる可能性があります。
Li Zhen:理論的には可能ですが、TypeScript と比較すると、まだいくつかの制限があります。
-
静的型チェックの完全性: JSDoc アノテーションは言語に直接埋め込まれているのではなく、アノテーション ベースであるため、その型チェックは TypeScript の型システムほど完全で正確ではない可能性があります。
-
ツールサポートの違い: 一部のツールやエディターは型チェックに JSDoc アノテーションを利用できますが、その機能とインテリセンスは TypeScript に比べて制限される場合があります。
-
エコシステムの違い: TypeScript には独立した型システムと型宣言ファイルのエコシステムがあり、既存の JavaScript ライブラリやツールとよりシームレスに統合できます。JavaScript + JSDoc を使用すると、型アノテーションを記述して維持するために、より多くの手動作業が必要になる場合があります。
Q: TypeScriptの登場は、一般人がJavaScriptを制御できないからだと考える人もいますが、「悪い人ほど自由を好む」と考える人もいますが、どう思いますか? この 2 つの言語の選択はプログラマーのレベルに関係しますか?
リー・ジェン：趣味で個人のレベルを判断するのは非常に退屈です。JavaScriptと TypeScript を書く専門家がいます。
Liu Yong:笑~ 優れた TypeScript プロジェクトが多くの Any に提出されていると学生が不満を言うのは珍しいことではありません。また、TypeScript リポジトリを引き継ぎ、これらの奇妙な型がどのように機能するかを理解するために多くの型定義を読まなければならないという苦情も多く見てきました。言語の選択は主にチームのエンジニアリングと標準化の程度に依存し、多すぎると十分ではないと思います。TypeScript クラス ライブラリが多数の型を記述しているにもかかわらず、テストが 1 つも含まれていない場合、それは不適格だと思います。
Liu Yicheng: TypeScript が登場した理由の 1 つは、JavaScript の「制御」が難しいということです。JavaScript は 柔軟性が高すぎて型の制約がないため、バグのあるコードを書きやすくなります。TypeScript はこの問題をある程度解決し、コードの保守性が向上し、コードの高さが向上しました。
JavaScript や TypeScript ではプログラマのレベルを測ることはできません。単純なプロジェクトや個人プロジェクトの場合は、JavaScript の方が 軽量で柔軟性が高い場合がありますが、大規模なチームのコラボレーションが必要な複雑なプロジェクトの場合は、TypeScript の型システムの方がコードの保守性と信頼性が向上します。
Q: TypeScriptの将来の発展をどのように見ていますか? それは流行になると思いますか、それとも最終的にはJavaScriptに置き換わると思いますか? 誰のテクノロジー エコシステムが優れていると思いますか?
Liu Yong: TypeScript は JavaScript のスーパーセットとして位置付けられており 、その機能は TC39 によって策定された ECMAScript 仕様 (つまり JavaScript ) に基づいています。それが JavaScript に取って代わるとは思えませんが 、結局のところ、これは正式な仕様ではなく、 JavaScript の既存のエコシステムは巨大すぎます。
もちろん、TypeScript は現在、ある程度事実上の標準になっています。特に Node.js 関係者が ESM と CJS の行き先について躊躇しているためです。そのことがコミュニティ開発者間の長期的な分離につながり、ますます多くの人々がコミュニティ開発者間の分離につながっています。 TypeScript を使用することを選択せざるを得なくなり、クラス ライブラリを作成し、同時に ESM と CJS にコンパイルします。現在、TypeScript エコシステムは大規模な規模に達しているため、CoffeeScript ほど短命ではありません。
Liu Yicheng:個人的には、TypeScript は今後も人気があり、より広く使用されるようになると思います。ただし、JavaScript を「置き換える」わけではありません 。TypeScript の目標は、JavaScript を「置き換える」ことではなく 、JavaScript の補足として JavaScript に基づく型システムを 提供し、さまざまなプロジェクトやシナリオでそれぞれの利点を発揮することです。
JavaScript と TypeScript の技術的なエコロジーは長い間統合されており、ほとんどすべてのライブラリに TypeScript タイプのファイルが含まれています。
Li Zhen: TypeScript が JavaScript を完全に置き換える可能性は低く、むしろ JavaScript の補足および拡張として機能すると思います。当分の間、両者の間にゼロサムゲームは存在しないでしょうし、私は両方の言語がより良く発展することを願っています。現在、JavaScript エコシステムの方が大きくなっていますが、TypeScript の地位と影響力は増大し続けています。一般の開発者としては、両者の間に矛盾がないときに開発に注意を払うのが最善です。
インタビューの全文を見る: 「TypeScript はまったく必要ありません。JS + JSDoc で十分です」、上司はもっと欲しいと言った