AngularJS は本当に完璧ですか? angularjs に関するいくつかの問題の詳細な分析

AngularJS の利点については話さないようにしましょう。少なくともほとんどのフロントエンド ワーカーは今でも AngularJS を熱狂的に尊敬しています。開発が容易になるからです。そこで疑問は、なぜ多くの有名な Web サイトが Angular を使用しないのかということです。 この記事を一緒に見てみましょう

いくつかのポイントから始めましょう:

1. 最悪の SEO フレンドリー

これは間違いなく非常に致命的であり、これは多くの若いスタートアップが簡単に挑戦する勇気を持たない原因となっています。検索エンジン クローラーとソーシャル プレビューのスクリーンショットは、JavaScript でレンダリングされたページを認識できず、既存のソリューションは複雑で非常に時間がかかります。

実際、通常、ページの読み込みは 5 つの部分で構成されます (Java を例にします):

1. ブラウザは HTTP リクエストをサーバーに送信します

2. サーバーはこのリクエストを処理して結果を取得しますデータを取得し、Jsp Template を取得し、このデータをテンプレートを通じてブラウザーが認識する HTML テキストに構築し、ブラウザーに送信します

3. ブラウザーは HTML テキストを解析し、ページのコンテンツを表示します

最後のステップは、ブラウザーが HTML テキストを取得するときです。つまり、このプロセスの最後に、必要なデータが表示されます。 Angular を使用するプロセスは次のとおりです: ブラウザーは HTTP リクエストをフロントエンド サーバーに送信します

1. サーバーはこのリクエストを処理して結果データを取得し、結果データを Json 形式にカプセル化して送信します。ブラウザー

2. ブラウザーは Json を解析し、ページ上にデータを表示します

3. これら 2 つのプロセス、1 つはページ構築操作をサーバー上に置くことであり、もう 1 つはそれをブラウザ上に置くことです。これが最も明らかな違いであり、余分なインタラクションは言うまでもなく、検索エンジンの観点から見ると、ブラウザによって取得された静的コンテンツのみが表示され、JS コードは実行されません。
   前者の検索エンジンでは記事が表示されますが、後者の検索エンジンでは中括弧が次々と表示されます。これは、Angular によってレンダリングされたページが Baidu の「ブラックリスト」に含まれる理由でもあります。では、どうすれば解決できるでしょうか？
4. 引用:

クローラーに Web サイトにアクセスさせる方法は 2 つあります。サーバー上でブラウザー インスタンスを実行し、JavaScript の実行後に DOM に基づいて HTML ページを生成できます。または、検索クローラー用に別の HTML 静的ページのセットを構築することもできます。
5. 前者の解決策では、WebKit (および場合によっては Xvfb) をインストールし、ロード後にページを生成する必要があります (キャッシュを使用することもできますが、より複雑になります)。これにより、ページのロード時間が増加し、検索エンジンのランキングに影響します。 。

   後者の解決策 (別のサーバーサイド Web サイトを作成する) は、単純な Web サイトであれば満足できますが、ページが非常に多様である場合は悪夢になります。また、バックアップ Web サイトがメイン Web サイトと完全に一致しない場合、Google は厳しく罰し、トラフィックは激減します。

2. 最悪のユーザーエクスペリエンス

AngularJS を使用した後、ページのレンダリング方法が複数のプロセスに分割されるため、ページにアクセスし、このページのコンテンツが比較的大きい場合、明らかにブラウザーのレンダリング プロセス、ロードするコンテンツが多すぎるため、このプロセスは非常に悪く、特にロード プロセスがクライアントに配置される場合、遅延が非常に大きくなります。

リッチ JavaScript アプリケーションでは、通常、ページの遷移は瞬時に行われ、その後、さまざまな要素がサーバーから読み込まれます。サーバー側アプリケーションでは、クライアントがすべてのデータをダウンロードするのを待たずに、ページはデータのレンダリングを開始します。

クライアント アプリケーションの方が優れているように聞こえますが、実際にはこれは幻想です。

ユーザーがリンクをクリックすると、クライアントの JS アプリケーションに読み込みアニメーションがすぐに表示されますが、データの読み込みには 5 秒かかると想像してください。アプリケーションは一見すると高速に見えますが、

この 1 ページに機能を追加したいプログラマーが何人いるかについては議論しないでください。コンテンツを非同期で迅速に表示することをユーザーに要求するのは困難です。実際、ユーザーはページの下にあるものが後で読み込まれるかどうかを気にしません。

サーバーサイドアプリケーションでは、API 呼び出しが遅い場合、ページ全体の読み込みが遅くなります。サーバー側の遅さは全員に影響を及ぼすため、無視することはできません。しかし、クライアントの遅さは見落とされがちです。

サーバーは制御可能であり、設定したマシン上で実行されるため、このマシンで何が起こっているかを明確に知ることができるため、サーバーの遅さを簡単に解決できます。さらに、ほとんどのサーバーは内部クラスター ネットワーク内にあるため、サーバー間の情報転送が非常に高速になり、アクションに複数の情報転送が必要な場合でも、瞬時に完了できます。しかし、これらの転送をクライアントに置くと、多くの要因により速度が低下します。
私たちはユーザーが使用するブラウザーを厳密に制御したり、ユーザーのマシンの構成を制御したりすることはできませんが、私たち自身のサーバーに関するすべてを制御することはできます。

3. 一番大事なものが無味すぎる

無味？ AngularJS には「メンテナンスが簡単」「コーディングが便利」など、さまざまな利点があると言う人もいるでしょう。しかし、これはパフォーマンスとユーザーエクスペリエンスを犠牲にすることに基づいています。そして、いわゆる「依存性注入」やその他のバックエンドのアイデアがフロントエンドに強制的に導入されます。これは高尚に思えますが、何が間違っているのでしょうか?バックエンドは構造、サービスに分かれており、よりシンプルな開発のためにさまざまなフレームワークが使用されます。Web フロントエンド自体は静的であり、ビジネスには関与しないと思います。彼にとって本当の助けは何もない。

これらの利便性から、それが役に立たないとは言えないかもしれませんが、どのようなシナリオでも、AngularJS を完全に置き換え、それよりも優れたソリューションを実行できるソリューションはほぼ存在します 。これ。 。 。これは恥ずかしいです！たとえばfreemaker。

Freemaker は誰にとっても馴染みのあるもので、ajax を介して http リクエストを実行する代わりに、Java が提供する freemakerApi 関数を直接呼び出してデータを非同期に取得できます。同様に、そのパフォーマンスも AngularJS を上回っています パフォーマンスと比較すると少しいじめかもしれませんが、テンプレート エンジン として、freemaker は確かにパフォーマンスの点で AngularJS を破る資格があります。

使いやすさの点では、freemaker は Java 関数を直接呼び出すだけでなく、http 経由でデータを取得することもできますが、取得したデータを HTML テキストに構築してからブラウザに渡して分析することが最も重要です。はい、依存関係の挿入やその他の関連機能もサポートしており、上記の点を組み合わせると、スケーラビリティ、保守性、全体的なパフォーマンス、ユーザー エクスペリエンスなどの点で AngularJS を圧倒します。 AngularJS ほど優れていない唯一の点は、開発段階です。 angular に比べて、freemaker の開発はより複雑です。つまり、angular の方が開発プロセスがはるかに単純で、多くのパフォーマンス要素が切り捨てられているからだとすると、これは非常に怖いと考える人もいます。パフォーマンスのメカニズムを追求して常に最適化を行っている人もいれば、よりシンプルな開発を目指して最適化を行っている人もいます。どちらが正しいか間違っているかは言えませんが、私は前者を好みます。

Freemaker はさておき、nodejs には置き換え可能なソリューションや MVC フレームワークが多数あるので、ここでは詳しく説明しません。

ブラウザにおける js の役割は、コンテンツのプレゼンテーションではなく、対話にあるべきだと思います。それは正しい解決策ではありません。

4. アプリケーションシナリオの問題

フロントエンドとバックエンドが分離されているシナリオでは AngularJS が良い選択のように見えますが、前述したように、フロントエンドとバックエンドが分離されている場合、AngularJS の考慮事項は狭すぎます。開発上の変更に加えて、分離しました。便利ではありますが、本来のパフォーマンスとエクスペリエンスが失われ、間違いなく失敗です。これらの理由と組み合わせると、AngularJS を使用できるシナリオは非常に少ないかもしれません。バックグラウンド (バックエンド管理コントロール パネル) と WEBApp いくつかのシナリオで使用できます。

ここで疑問が生じますが、管理コンソール ページを開発するときにパフォーマンスを過度に考慮する必要はなく、SEO 向けに最適化する必要もありません。ただし、このシナリオの中間点はコンテンツではなくインタラクションです。画面。 AngularJS はフロントエンドのテンプレート エンジンとしての地位を失いました。彼の役割は最小限で、それは恥ずかしかったです。

WebApp を開発する場合、パフォーマンスの点では、アプリ フレームワークはユーザーが使用するクライアントのバージョンを厳密に制御できるため、パフォーマンスを最適化することができます。 App フレームワークを選択することもできますが、App 開発フレームワークは自分で選択できるため、ほとんどすべての App フレームワークはパフォーマンスと使いやすさの両方の点で AngularJS を超えるソリューションを備えています。したがって、これは管理コンソール ページを開発するよりも悪いように思えます。

これらの点に基づいて、AngularJS の立場は非常に恥ずかしいと思います。

矛盾のない唯一のシナリオは、企業の内部アプリケーションを開発するシナリオである可能性があります。

これが、AngularJS が優れているように見える理由かもしれませんが、それを選択する企業はほとんどありません。パフォーマンスの追求は、すべてのプログラマー、特にバックエンド開発に携わるプログラマーにとって必要なことです。彼らは、一見便利な開発のために経験を放棄することはできません。本当に諦めたら、中学と高校の区別はどうなりますか？その建築家はどこの出身ですか?コードに関するコンサルテーションを数多く開始してください。

同様に、これは面接中に一部のフロントエンド エンジニアに当惑を引き起こしました:

Q: AngularJs の使用方法を知っていますか?
答え: はい！良い。 。しかし、あまり使われていません。 。でも本当にそうなんです。 。えー

AngularJS の利点については話さないようにしましょう。少なくともほとんどのフロントエンド ワーカーは依然として AngularJS を熱狂的に尊敬しています。開発が容易になるからです。そこで問題は、なぜ多くの有名な Web サイトが Angular を使用しないのかということです。
いくつかのポイントから始めましょう:

1. 最悪の SEO フレンドリー

この点は間違いなく非常に致命的であり、これが多くの若いスタートアップが試行しようとしない重要な理由です。検索エンジン クローラーとソーシャル プレビューのスクリーンショットは、JavaScript でレンダリングされたページを認識できず、既存のソリューションは複雑で非常に時間がかかります。

実際、通常、ページの読み込みは 5 つの部分で構成されます (Java を例にします):

1. ブラウザは HTTP リクエストをサーバーに送信します

2. サーバーはこのリクエストを処理して結果を取得しますデータを取得し、Jsp Template を取得し、このデータをテンプレートを通じてブラウザーが認識する HTML テキストに構築し、ブラウザーに送信します

3. ブラウザーは HTML テキストを解析し、ページのコンテンツを表示します

最後のステップは、ブラウザーが HTML テキストを取得するときです。つまり、このプロセスの最後に、必要なデータが表示されます。 Angular を使用するプロセスは次のとおりです: ブラウザーは HTTP リクエストをフロントエンド サーバーに送信します

1. サーバーはこのリクエストを処理して結果データを取得し、結果データを Json 形式にカプセル化して送信します。ブラウザー

2. ブラウザーは Json を解析し、ページ上にデータを表示します

3. これら 2 つのプロセス、1 つはページ構築操作をサーバー上に置くことであり、もう 1 つはそれをブラウザ上に置くことです。これが最も明らかな違いであり、余分なインタラクションは言うまでもなく、検索エンジンの観点から見ると、ブラウザによって取得された静的コンテンツのみが表示され、JS コードは実行されません。

前者の検索エンジンでは記事が表示されますが、後者の検索エンジンでは中括弧が次々と表示されます。これは、Angular によってレンダリングされたページが Baidu の「ブラックリスト」に含まれる理由でもあります。では、どうすれば解決できるでしょうか？

4. 引用:

5. クローラーに Web サイトにアクセスさせる方法は 2 つあります。サーバー上でブラウザー インスタンスを実行し、JavaScript の実行後に DOM に基づいて HTML ページを生成できます。または、検索クローラー用に別の HTML 静的ページのセットを構築することもできます。

   前者の解決策では、WebKit (および場合によっては Xvfb) をインストールし、ロード後にページを生成する必要があります (キャッシュを使用することもできますが、より複雑になります)。これにより、ページのロード時間が増加し、検索エンジンのランキングに影響します。 。

   後者の解決策 (別のサーバーサイド Web サイトを作成する) は、単純な Web サイトであれば満足できますが、ページが非常に多様である場合は悪夢になります。また、バックアップ Web サイトがメイン Web サイトと完全に一致しない場合、Google は厳しく罰し、トラフィックは激減します。

2. 最悪のユーザーエクスペリエンス

AngularJS を使用した後、ページのレンダリング方法が複数のプロセスに分割されるため、ページにアクセスし、そのページに大量のコンテンツが含まれていると、明らかにブラウザーのレンダリングで次のように感じます。ロードするコンテンツが多すぎるため、このプロセスは非常に悪く、特にロード プロセスがクライアントに配置される場合、遅延が非常に大きくなります。

リッチ JavaScript アプリケーションでは、通常、ページの遷移は瞬時に行われ、その後、さまざまな要素がサーバーから読み込まれます。サーバー側アプリケーションでは、クライアントがすべてのデータをダウンロードするのを待たずに、ページはデータのレンダリングを開始します。

クライアント アプリケーションの方が優れているように聞こえますが、実際にはこれは幻想です。

ユーザーがリンクをクリックすると、クライアントの JS アプリケーションに読み込みアニメーションがすぐに表示されますが、データの読み込みには 5 秒かかると想像してください。アプリケーションは一見すると高速に見えますが、
この 1 ページに機能を追加したいプログラマーが何人いるかについては議論しないでください。コンテンツを非同期で迅速に表示するようにユーザーに要求するのは困難です。実際、ユーザーはページの下にあるものが後で読み込まれるかどうかを気にしません。

サーバーサイドアプリケーションでは、API 呼び出しが遅い場合、ページ全体の読み込みが遅くなります。サーバー側の遅さは全員に影響を及ぼすため、無視することはできません。しかし、クライアントの遅さは見落とされがちです。

サーバーは制御可能であり、設定したマシン上で実行されるため、このマシンで何が起こっているかを明確に知ることができるため、サーバーの遅さを簡単に解決できます。さらに、ほとんどのサーバーは内部クラスター ネットワーク内にあるため、サーバー間の情報転送が非常に高速になり、アクションに複数の情報転送が必要な場合でも、瞬時に完了できます。しかし、これらの転送をクライアントに置くと、多くの要因により速度が低下します。
私たちはユーザーが使用するブラウザーを厳密に制御したり、ユーザーのマシンの構成を制御したりすることはできませんが、私たち自身のサーバーに関するすべてを制御することはできます。 (さらに詳しく知りたい場合は、PHP 中国語 Web サイトAngularJS 開発マニュアル にアクセスして学習してください)

3. 最も重要なことは無味すぎます

無味ですか? AngularJS には「メンテナンスが簡単」「コーディングが便利」など、さまざまな利点があると言う人もいるでしょう。しかし、これはパフォーマンスとユーザーエクスペリエンスを犠牲にすることに基づいています。そして、いわゆる「依存性注入」やその他のバックエンドのアイデアがフロントエンドに強制的に導入されます。これは高尚に思えますが、何が間違っているのでしょうか?バックエンドは構造、サービスに分かれており、よりシンプルな開発のためにさまざまなフレームワークが使用されます。Web フロントエンド自体は静的であり、ビジネスには関与しないと思います。彼にとって本当の助けは何もない。

これらの利便性から、それが役に立たないとは言えないかもしれませんが、どのようなシナリオでも、AngularJS を完全に置き換え、それよりも優れたソリューションを実行できるソリューションはほぼ存在します 。これ。 。 。これは恥ずかしいです！たとえばfreemaker。

Freemaker は誰にとっても馴染みのあるもので、ajax を介して http リクエストを実行する代わりに、Java が提供する freemakerApi 関数を直接呼び出してデータを非同期に取得できます。同様に、そのパフォーマンスも AngularJS を上回っています パフォーマンスと比較すると少しいじめかもしれませんが、テンプレート エンジン として、freemaker は確かにパフォーマンスの点で AngularJS を破る資格があります。

使いやすさの点では、freemaker は Java 関数を直接呼び出すだけでなく、http 経由でデータを取得することもできますが、取得したデータを HTML テキストに構築してからブラウザに渡して分析することが最も重要です。はい、依存関係の挿入やその他の関連機能もサポートしており、上記の点を組み合わせると、スケーラビリティ、保守性、全体的なパフォーマンス、ユーザー エクスペリエンスなどの点で AngularJS を圧倒します。 AngularJS ほど優れていない唯一の点は、開発段階です。 angular に比べて、freemaker の開発はより複雑です。つまり、angular の方が開発プロセスがはるかに単純で、多くのパフォーマンス要素が切り捨てられているからだとすると、これは非常に怖いと考える人もいます。パフォーマンスのメカニズムを追求して常に最適化を行っている人もいれば、よりシンプルな開発を目指して最適化を行っている人もいます。どちらが正しいか間違っているかは言えませんが、私は前者を好みます。

Freemaker はさておき、nodejs には置き換え可能なソリューションや MVC フレームワークが多数あるので、ここでは詳しく説明しません。

ブラウザにおける js の役割は、コンテンツのプレゼンテーションではなく、対話にあるべきだと思います。それは正しい解決策ではありません。

4. アプリケーションシナリオの問題

フロントエンドとバックエンドが分離されているシナリオでは AngularJS が良い選択のように見えますが、前述したように、フロントエンドとバックエンドが分離されている場合、AngularJS の考慮事項は狭すぎます。開発上の変更に加えて、分離しました。便利ではありますが、本来のパフォーマンスとエクスペリエンスが失われ、間違いなく失敗です。これらの理由と組み合わせると、AngularJS を使用できるシナリオは非常に少ないかもしれません。バックグラウンド (バックエンド管理コントロール パネル) と WEBApp いくつかのシナリオで使用できます。

ここで疑問が生じますが、管理コンソール ページを開発するときにパフォーマンスを過度に考慮する必要はなく、SEO 向けに最適化する必要もありません。ただし、このシナリオの中間点はコンテンツではなくインタラクションです。画面。フロントエンドのテンプレート エンジンとしての AngularJS はその位置付けを失いました。彼の役割は最小限で、それは恥ずかしかったです。

WebApp を開発する場合、パフォーマンスの点では、アプリ フレームワークはユーザーが使用するクライアントのバージョンを厳密に制御できるため、パフォーマンスを最適化することができます。 App フレームワークを選択することもできますが、App 開発フレームワークは自分で選択できるため、ほとんどすべての App フレームワークはパフォーマンスと使いやすさの両方の点で AngularJS を超えるソリューションを備えています。したがって、これは管理コンソール ページを開発するよりも悪いように思えます。

これらの点に基づいて、AngularJS の立場は非常に恥ずかしいと思います。

矛盾のない唯一のシナリオは、企業の内部アプリケーションを開発するシナリオである可能性があります。

これが、AngularJS が優れているように見える理由かもしれませんが、それを選択する企業はほとんどありません。パフォーマンスの追求は、すべてのプログラマー、特にバックエンド開発に携わるプログラマーにとって必要なことです。彼らは、一見便利な開発のために経験を放棄することはできません。本当に諦めたら、中学と高校の区別はどうなりますか？その建築家はどこの出身ですか?コードに関するコンサルテーションを数多く開始してください。

同様に、これもフロントエンド エンジニアの面接中に当惑を引き起こしました。

Q: AngularJs の使用方法を知っていますか?

答え: はい!良い。 。しかし、あまり使われていません。 。でも本当にそうなんです。 。えー

この記事はここで終わります (さらに詳しく知りたい場合は、PHP 中国語 Web サイトAngularJS ユーザー マニュアル にアクセスして学習してください)。ご質問がある場合は、以下にメッセージを残してください。

以上がAngularJS は本当に完璧ですか? angularjs に関するいくつかの問題の詳細な分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。