(現在の唯一の代替手段: Vanilla JavaScript

私は、長い間 C を使って作業し、今でも MFC (Microsoft Foundation Classes) で開発している開発者を見てきました。理由は簡単です。C で UI を構築するための実質的な代替手段がないからです。 Qt は存在​​しますが、プロとして使用するには商用ライセンスが必要なため、MFC が唯一の選択肢となります。

MFC は基本的な UI コンポーネントを提供しますが、CAD ソフトウェアや病院用アプリケーションなどの実稼働レベルのプログラムを作成することもできます。

JavaScript エコシステムの現在の状態は非常によく似ています。

HPSE の目標に対処するために特別に構築されたフレームワークはありません。 Babylon.js のようなゲーム エンジンもありますが、これらは 3D グラフィックスの機能のみを提供し、React のような包括的な構造を提供しません。

結局のところ、すべては Vanilla JavaScript と TypeScript に戻ります。開発者はバニラ JavaScript が好きだからそれを使用しているわけではありません。他に選択肢がないので彼らはそれを使います。商用フレームワークがなかったため開発者が C ですべてを最初から構築しなければならなかった初期の頃と同様に、私たちは現在 JavaScript でも同じ状況に直面しています。 HPSE の要求を完全に満たす既存のフレームワークは存在しないため、Vanilla JavaScript を使用して手動で開発する必要があります。

そして率直に言って、これは JavaScript に限ったことではありません。これは他のほとんどの言語にも当てはまります。

「無料のランチなどというものはない」ということわざがあります。

新たな境界を打ち破るという壮大な野心を持って始まったプログラムの多くは、最終的にはプログラミング言語内に直接構築されたカスタム機能に大きく依存するようになりました。 HPSE も、いつかはブラウザーでネイティブ プログラムを実行するというビジョンを持って始まりましたが、今のところ、バニラ JavaScript で部分的に記述する必要があります。

「JavaScript を放棄して、C または Rust を使用して WebAssembly (WASM) モジュールを作成し、代わりにブラウザで実行したらどうだろうか?」と主張する人もいるかもしれません。

この質問に答える良い話があります。

Babylon.js と Three.js のリーダーは、かつてコメントで、WASM テクノロジーが彼らのエンジンの将来になるのかどうか尋ねられました。彼らの答えは「いいえ」

でした。

理由は簡単です。C /Rust コードは Web 環境で直接実行されないため、デバッグがより困難になります。また、V8 エンジンの進歩により、JavaScript は高いパフォーマンスを実現できるようになりました。 JavaScript はブラウザ内で直接実行され、高い生産性を提供するスクリプト言語です。これらの利点を放棄する必要はありません。

かつて、プログラマーは独自のオペレーティング システムを開発することで競争していました。しかし、Windows、Mac、Linux が標準になった後、焦点はこれらのシステム上で実行されるプログラムを構築する方法に移りました。同様に、今日のブラウザは、ブラウザ内で実行するプログラムを構築する方法を考えるのが妥当なところまで進化しています。

JavaScript を何に使用すべきか、使用すべきではないかについて明確な境界線があり、ハイエンドのタスクが JavaScript に本当に不向きであれば、Microsoft は Babylon.js プロジェクトを開始することはなかったでしょうし、Three.js も開始しなかっただろう。が作成されました。新しい Web 標準として確立されつつある WebGPU についても同様です。

最近、私は開発者としての自分のアイデンティティを振り返り、「フロントエンド」とは正確に何を意味するのか、そしてその用語が本当に Web クライアント開発の範囲を包括できるのかについて疑問を抱いています。

私の考えには誤った情報がたくさんあると思いますが、私が考えてきたことを整理するために、これを最初のブログエントリとして投稿します。

以上が(現在の唯一の代替手段: Vanilla JavaScriptの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。