JavaScript - 祝福か呪いか?

誰もが人生で少なくとも一度は JavaScript でコーディングしたことがあります。好きだという人もいれば、そうでないという人もいます。これは、JS エコシステムに対して良くも悪くも遠い感情を抱いている人々への小さな「手紙」になります。

始める前に、JavaScript の歴史を理解する必要があります。 JavaScript は言語ではなく、エコシステムです。 Java または C は言語 Javascript ではなく、ECMAScript が言語の実際の名前です。私たちが Javascript を非難するとき、実際にはエコシステムを非難することになります。

JavaScriptの歴史

プログラミングにはさまざまなものがありますが、プログラミングを大きな領域として想像すると、Web が最も大きな部分を占めます。

プログラミングについて話すとき、その 80% は Web 関連のテクノロジーです。そのため、JavaScript は 1995 年に、1997 年に IE4 でサポートされる純粋な Web 言語として開始されました。したがって、私たちが理解するためには、JavaScript はサーバー上での使用を意図したものではないことを知っておく必要があります。実際に Javascript をサポートした最初のブラウザである Netscape は Javascript エンジンとして Mocha を使用していましたが、V8 までのすべてが単に十分だったというわけではありません。

ニーズが大きくなるにつれ、JavaScript をより強力かつ高速にする最初の試みが始まりましたが、Google チームは奇跡を起こし、実際にクライアントだけでなく、Ryan Dahl による V8 と Node.js の導入により Javascript を十分に高速化しました。サーバーでも使用できるようになります。

C や Java などの他の言語は、マシン レベルで低レベルのプログラムを作成することを目的としています。サーバー上の奇跡の Javascript が何であるかを理解するには、クライアントに Java を配置しようとしているところを想像してください。この言語の目的は、DOM や Web API と対話するために使用されることではないため、多くのトリックを行う必要があります。

ECMAScript 1 は Web ブラウザー用の言語であり、Web ブラウザー内でのみ実行されることを目的としていました。その場合、そのパフォーマンスを言語のせいにする場合、それは言語ではなく、言語の背後にあるエンジンであることを知る必要があります

JavaScript が成長し始めた

約 10 年後の 2009 年、ECMAScript のニーズが高まり、ついに ES5 が登場しました。ここで一大ブームが起こりました。実際の言語 ECMAScript は、単純なフロントエンド アプリケーション以外にも実際に使用できました。わずか数年後、Express.js

の導入により、React やその他のフレームワークがフロントエンドだけでなくバックエンドにも登場し始めました。

JavaScript には自由が必要でした。フロントエンドはバックエンド開発のように厳格ではなく、React やそれ以前のクライアント側ブームの芸術的ニーズにより、多くのルールや制約のないかなり緩やかなエコシステムが形成されていたためです。

他の言語が 10 年以上サーバー上に存在していましたが、Javascript がその参入を目指しています。その単純な構文の性質によりこの言語は使いやすく、フロントエンドとバックエンドの開発に同じプログラミング言語を使用できるのも便利です.

1 つのコードベース

これについて話したいことがあります。 Shopify がプラットフォームを正式にリリースする 2009 年以前は、バックエンド サービスとの対話性はあまりありませんでした。 Javascript の悪い性質は当時の Web にとっては十分であり、当時存在していたいくつかの大きな Web プラットフォームでは PHP をバックエンドとして使用し、Facebook のようなフロントエンドを使用し、より多くのニーズがあれば Java をバックエンドとして使用していました。 API との対話性が悪く、何かを変更する必要がありました。

Node.js は、開発者が望むことを実現するのに役立ち、Web での開発エクスペリエンスをシームレスにし、同じ機能セットに対して異なる言語を使用する必要がなくなりました。当初、Nodejs のパフォーマンスは悪く、スケーリングが難しく、何かを行う必要がありました。

JavaScript には解決すべき問題がたくさんありました。最初に解決しなければならないのはパフォーマンスでしたが、nodejs のパフォーマンスも向上しました。

すべてに対応する 1 つのコードベースは可能でしたが、業界標準を満たす拡張性がありませんでした。タイプ セーフティは必須であり、Facebook が Hack を作成したように、Microsoft は Typescript を導入しました。

現代の問題

JavaScript はパフォーマンスの問題を解決しました。Go や Rust ほど高速ではないかもしれませんが、そうする必要はありません。 Web 標準に驚異的なパフォーマンスは必要ありません。必要な場合は、Go または Rust でサービスを 1 つ作成するだけです。私たちが知っているインターネットは、その中核で PHP と Ruby を使用していることをお伝えしておきます。これらは Javascript よりもはるかに遅く、リソースを大量に消費します。

JavaScript はタイプセーフティの問題を解決したため、大規模なプロジェクトで使用できるようになりましたが、数日前に大きなブレークスルーがあったまで、最後の問題が Javascript を追い詰めていました。

JavaScript は言語ではなくエコシステムであるため、新しい機能やツールは言語内ではなく言語を中心に構築されます。バックエンドで 3 つのエンドポイントを持つ小規模な SPA アプリケーションを実行するだけで、最終的に 20 個の構成ファイルが必要になります。私たちに必要な変更は、すべてを 1 つのものの中にまとめることです。

ECMAScript、タイプ、リンティング、セキュリティ、フォーマットを 1 つのバンドルにまとめます。なぜなら、現時点では依存関係地獄に陥っているだけでなく、物事を行う方法に関する単一の標準がないため、コーディングが困難だからです。 Java、Ruby、Go、Rust、Perl などの他の言語では、すべてが言語の壁の内側にあります。

JavaScript の未来

Ryan Dahl が Deno を紹介しました。Deno がやり始めていることは、すべてを束ねることです。とても期待できます。

Typescript は現在、そのパフォーマンス、ライブラリの量、言語とリソースの周りに存在する SDK を備えており、Deno が約束していることも含めて、Web 業界全体を引き継ぐことになります。

これらすべてのファイルとそのコマンドが単一の Javascript エンジン内にバンドルされている世界を想像してください。

• eslintrc.json

• tsconfig.json

• vite.config.js

• package.json

• postcss.config.js

• .prettierrc

• ecosystem.config.js

• .ハスキー

私の貧弱な理解からすると、JavaScript は、Web に関してはあと 3 ～ 4 年以内に、間違いなく選択できるようになるまでに非常に近づいています。マイクロサービス、マイクロフロントエンド、モノリスを構築したい場合、毎秒 5,000 リクエストまで拡張したい場合、または単純な SPA JavaScript を作成したい場合は、唯一のソリューションになります。

JavaScript に少し時間を与えれば、PHP、Ruby、Go などの Web の代替手段は後退するでしょう。なぜなら、現時点では誰もが Javascript に対して正当な反対意見を持っていますが、それでも将来は非常に有望だからです。

結論

結論として、JavaScript は Web ブラウザー用の単純なスクリプト言語としての地味な始まりから、クライアント側とサーバー側の両方のアプリケーションを処理できる堅牢なエコシステムへと大きく進化しました。その歩みは、パフォーマンス、スケーラビリティ、タイプ セーフの継続的な改善によって特徴付けられ、現代の Web 開発にとって多用途の選択肢となっています。

Node.js などのツールや React などのフレームワークの導入によりその機能が拡張される一方、Deno のようなイノベーションにより、さまざまなツールや構成を一貫した環境に統合することで開発プロセスがさらに合理化されることが約束されています。

継続的な進歩と強力なコミュニティにより、JavaScript の将来は有望に見え、開発者に明日の Web アプリケーションを構築するための統合された効率的なプラットフォームを提供します。

以上がJavaScript - 祝福か呪いか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。