単一ページのWebアプリケーションを構築することの利点と欠点
現在取り組んでいるサイドプロジェクトのプロトタイピング/概念実証フェーズの終わりに近づいており、より大規模なアプリケーション設計の決定を決定しようとしています。アプリは、アジャイル開発プロセスに合わせて調整されたプロジェクト管理システムです。私が行う必要がある決定の1つは、従来のマルチページアプリケーションとシングルページアプリケーションのどちらを使用するかです。
現在、私のプロトタイプは従来のマルチページセットアップですが、私はbackbone.jsを調べてクリーンアップし、Javascript（jQuery）コードに構造を適用しています。 backbone.jsは複数ページのアプリケーションで使用できますが、単一ページのアプリケーションではより効果的です。単一ページのアプリケーション設計アプローチを使用することの利点と欠点のリストを考え出そうとしています。これまでのところ：
利点
すべてのデータは、ある種のAPIを介して利用できる必要があります。とにかくアプリケーションにAPIを使用したいので、これは私のユースケースにとって大きな利点です。現在、データを取得/更新するための私の呼び出しの約60〜70％はREST APIを介して行われます。単一ページのアプリケーションを実行することで、私のREST APIは、アプリケーション自体がそれを使用するためです。また、アプリケーションが成長するにつれて、API自体もアプリケーションが使用するものになるため、APIをアプリケーションのアドオンとして維持する必要がないことも意味します。
より応答性の高いアプリケーション-最初のページの後に読み込まれるすべてのデータが最小限に抑えられ、コンパクトな形式（JSONなど）で送信されるため、データリクエストは一般的に高速になり、サーバーの処理はわずかに少なくなります。
短所
- コードの複製-たとえば、モデルコード。サーバーサイド（この場合はPHP）とクライアントサイドの両方でJavaScriptでモデルを作成する必要があります。
- Javascriptのビジネスロジック-なぜこれが悪いのかについて具体的な例を示すことはできませんが、Javascriptでビジネスロジックを誰でも読み取れるようにするのは適切ではありません。
- JavaScriptのメモリリーク-ページが再読み込みされないため、JavaScriptのメモリリークが発生する可能性があり、デバッグをどこから始めればよいかさえわかりません。
両刃の剣のようなものもあります。たとえば、シングルページアプリケーションでは、アプリケーションが特定のリクエストに必要な最小限のデータを要求するため、各リクエストで処理されるデータははるかに少なくなる可能性がありますが、サーバー。それが良いことか悪いことかはわかりません。
プロジェクトにどの方向に進むべきかを決定するときに留意する必要がある単一ページWebアプリケーションの利点と欠点のいくつかは何ですか？
最大の欠点は、クライアントがJavaScriptを有効にし、かなりの量を実行できるほど強力である必要があることです。アクセシビリティの懸念や、静的HTMLの解析に依存するその他の要件を満たすことも困難です（ただし、特定のAPIを知っているものは、おそらくHTMLスクレイピングよりも優れています）。最後に、重大なメモリリークが発生しやすくなります。
コードを複製したり、クライアントにビジネスロジックを配置したりすることに関しては、どれだけの作業を行う必要があるかはわかりません。クライアントのモデルがView-Model（UIが表示する世界と一致するモデルであり、ビジネスモデルではない）である場合、ViewModelとビジネスモデルまでの一致するロジックをクライアントに置くことができます。サーバー、または両方のビット。これは、APIにクライアント固有のファサードを含めるか、クライアントにUI入力をAPI呼び出しに変換させるかについての感覚に依存します。
また、knockout.jsを確認することもできます。バックボーンよりも優れているかどうかはわかりませんが、プロジェクトに適している可能性があります。
単一ページWebアプリケーションでよく見られる欠点：
- サイトの特定の部分にリンクできないため、エントリポイントが1つしかないことがよくあります。
- 機能しない戻るボタンと進むボタン。
- タブの使用は制限されているか、存在しません。
（特にモバイル:)
- 読み込みに非常に時間がかかります。
- まったく機能しない。
- ページを再読み込みできません。ネットワークが突然失われると、サイトの最初に戻ります。
これらはすべて回避できますが、私が見た限りでは、ほとんどのサイトビルダーは回避できません。
Javascriptを実行しない非常に重要なクライアントが1つあります。Googleクローラー（現在2012）です。 （おそらく、BingはJSを実行していません。）
インデックスを作成する必要があるすべてのページの適切な非AJAXバージョン、またはインデックスを作成する必要があるページへのリンクを提供する必要があります。
サイトが小さい場合は、ボットのインデックス作成のみを目的として、いくつかのページの非常に基本的なバージョンを提供できます。
サイトのコンテンツのほとんどが登録ユーザーのみを対象としている場合、または他の理由でインデックスを作成する必要がない場合は、インデックスなしのスペース全体を、独自の検索、ブラックジャックなどを使用して、1ページのアプリとして作成できます。
これらのどちらでもない場合は、最初からマルチページサイトを開発し、AJAX更新のみを提供して、ページの「一般的な目的」を変更しない場所に置くことをお勧めします。
-コードの複製-たとえば、モデルコード。サーバー側（この場合はPHP）とサーバー側の両方でJavaScriptでモデルを作成する必要があります。
PHP=の世界にいますが、.NETの世界には、JavaScript WCFプロキシを自動的に作成するためのコード生成戦略があります。詳細は こちら をご覧ください。
PHPアプリケーションでJavaScriptを使用してリモートオブジェクトを自分で作成する必要がない場合に使用できるオプションはわかりませんが、これは.NETで単一ページアプリケーションを作成する場合のオプションです。
選択はどちらかである必要はありません。 JWt は、たとえば、複数ページのWebページの完璧な錯覚を実装するWebツールキットですが、単一のページです。さらに、JavaScriptを持たないGoogleボットとブラウザーを認識し（試してみて）、検出すると従来のマルチページモデルに切り替えます。
要するに：
- aPIを作成する必要はありません（ただし、必要に応じて作成できます）
- 応答性の高いアプリケーション：ユーザーがクリックするたびに、最大で1つのサーバーラウンドトリップ（および画像のフェッチ）が必要
- コードの重複なし
- クライアント側のビジネスロジックなし
- 最小限の複雑さのクライアント側
- 検索ボットはそれをインデックス化できます