PHP と Ajax のどちらを使用して Web ページをレンダリングする方が良いでしょうか?

現在、会社の管理バックエンド ページは基本的に Ajax を使用してページをレンダリングします。たとえば、ページング機能がすべて JS によってレンダリングされると、ページ全体が役に立たなくなります。 PHP と AJAX を使用するのが最善の方法です。皆さん、意見を聞かせてください。

返信内容:

1. 今でもjsを禁止する人はほとんどいません。
2. PHP はすべてのコードを生成します。これは、フレームワークを生成してから Ajax を生成するよりも確実に高速です。その理由は、どちらの場合も、ネットワーク ケーブルによって送信されるデータ K の数は基本的に同じであるためです。js が innerHTML を実行すると、dom が変更され、再描画と再配置が発生し、比較的コストがかかります。 PHP はフレームのみを担当しますが、一般的に PHP プロジェクトではフレームが提供されている場合でもテンプレート エンジンを使用する必要があるため、テンプレート エンジンがフレームを処理するのとコンテンツ全体を処理するのとの間にはほとんど時間差がありません。 。データ量が多い場合、ajax の利点は、データをセグメントに分割してダウンロードできるため、php よりも高速であることです。
3. php が ajax よりも速いという事実は無視してください。これらの違いは使用状況によって異なり、必要な規則はありません。
ajax は常に「安全」 「頻繁に更新される」 「フォーマットされたバッチデータ」と「データキャッシュ」に関連しており、ユーザーは古いデータを見たいとは思わないつまり、ユーザーは興味がないか、古いデータを見るために戻るボタンをクリックする必要がありません。 ajax はデフォルトでは back キーをサポートしていないため、back を実装したい場合は多くの作業を行う必要があります。
つまり、
A. キャプチャされたデータが機密である場合、ajax は必要ありません。機密でない場合は、ajax が必要です。キャプチャするものがフォーマットされたバッチ データではなく、ビデオ アドレスのキャプチャなど、他のものである場合は、1 つしかないため、ajax は必要ありません。ユーザーが大量のデータを参照することが予想される場合は、ajax を使用して最初にデータのバッチ (または php を使用して出力されるデータの最初のバッチ) をキャプチャし、その後バックグラウンドでゆっくりと他のデータのキャプチャを続けます。を選択し、この時点で ajax を使用します。
B. ページのレンダリング後にデータが静的な状態にある場合 (データが頻繁に更新されない場合)、PHP を使用する必要があります。 (ページに日付が表示され、昨日が 15 日、今日が 16 日である場合も、データは静的であるとみなされます。ユーザー名が特定の位置に表示されている場合も、データは静的であるとみなされます。静的。)
C. ページがレンダリングされた後、データは静的な状態ではありません。つまり、ページを見てから数十秒以内に、サーバー データベースには大量のデータが存在します。これらの更新をすぐに確認するには、 ajax を使用します。つまり、ページを開いてから 30 分から 1 時間はページを開いたままにしておく必要がある場合があり、いつでもデータの更新を確認したい場合は、ajax を使用する必要があります。
上記の私の理論に基づくと、一般的に言えば、会社の社内 Web サイトで大量の PHP と少しの Ajax が使用されていれば、それだけです。
ページングに関しては、ajax を使ってページング情報を取得すると美しいではないかという人もいます。ここでの原理は実際には同じであり、リストは形式のバッチ データとみなすことができ、キャッシュはページめくりに役立つため、ajax を使用できます。ただし、リスト ページの更新が非常に遅く、数日または数週間で新しい項目が 1 つしか追加されない可能性があります。その場合は、PHP を検討してください。ということで、今回は状況次第です。
Web ページに 30 個または 40 個の少数のバッチ データが表示されている場合、現時点では「フォーマットされたバッチ データ」に準拠していますが、今日もこれらのデータが表示され、明日もこれらのデータが変更されません。 ", PHP も推奨されます。Ajax は推奨されません。会社のイントラネットでは大量の php が使用できると述べたのはこのためです。

php が html を生成する場合、html ページ内のデータを常に更新する必要がある場合は、もちろん ajax です。 同社がこれを行うのには理由があります。将来的には、携帯電話、iOS、Android のバックエンドを変更する必要がなく、互換性を変更する必要もありません。 さて、これらの答えが何についてなのかわかりません...
質問者は、これは管理システムだと言いましたが、これは明らかに内部使用のためのものです。
この種のアプリケーションの特徴は、インタラクションが多く、アクセス速度は重要ではなく、開発リソースが比較的小さいことです。この場合、フロントエンド アーキテクチャ (angular、vue、react...) を使用します。このシナリオでは、これが最適なソリューションです。これにより、開発がより効率的になり、メンテナンスがより快適になります。

これであれば。アプリケーションは PHP を使用してページを直接表示し、対話用に jquery、jquerytable などを追加します。少なくとも、新しい管理パネルを追加するには、数百行、場合によっては数千行の js を記述する必要があります。 ajax を使用してページをレンダリングすることを、私はクラウド構造の Web アーキテクチャと呼んでいます。現在、モバイル開発プロジェクトが主要市場 (WeChat マイクロサイト開発など) を占めているため、SEO を考慮しないと、ハイブリッド レンダリングよりもクラウド構造の方が優れています。この利点は主に、ソフトウェア エンジニアリング開発の 3 つの重要な側面、柔軟性、拡張性、再利用性から生まれます。
1. 再利用性。ハイブリッド レンダリングを使用する場合、フロントエンドではフレームワークがほとんど使用されず、ブートストラップなどの CSS フレームワークのみが使用されるため、JS の基礎となるアーキテクチャを構築することが困難になります。これにより、フロントエンドの再利用性が大幅に制限されます。
2. 柔軟性。クラウド構造の開発において、フロントエンド技術者は完全に独立してページを構築でき、バックエンド技術者は必要に応じて必要なインターフェースを提供するだけで済みます。
3. 拡張性。優れたフロントエンドの最下層を構築し、新しい関数や新しいページを反復するのに非常に便利です。 単純なページがあるだけの場合は、PHP を直接使用する方が簡単です。しかし、状況が 1 つあります。それは、大量のページ コンテンツを含む長いページであり、同時実行の量が多いということです。
次に、PHP レンダリング構造と Ajax レンダリングの詳細がその能力を反映します。これにより、クライアントの応答性が向上し (サーバーが処理するロジックが少なくなり)、ユーザーはブラウザーがグルグル回転する代わりに、より速く物事を確認できるようになります。
Ajax 以降はデータ転送のみで、レンダリング構造は依然としてブラウザ内にあり、サーバーの文字列操作は大幅に少なくなり、サーバー側で一度にレンダリングするよりも明らかに優れています。
さらに、各リージョンからのリクエストを異なるビジネス システムに分散し、クロスドメインで実行することもできます。