Ruby、Python、PHP などのサーバー側 MVC を使用して非常に複雑な Web サイトを構築する代わりに、Web サイトを複数のモジュールに分割し、それぞれを backboneJS、EmberJS などのクライアント側 MVC で構築しないでください。この場合、PHP / Ruby を使用して、データのみを提供する Web サービスのみを作成します。
各モジュールは小さな Web アプリとして機能するようになりました。相互にリンクすると、完全に複雑な Web アプリのように見えます。
私は多くの Web サイト (github、groupon、stackoverflow など) にアクセスし、このアプローチを構築または採用することができます。しかし、私はこの種のアプローチを見ていません。このアプローチは、この種の Web サイトで問題がありますか?
そうそう。私は答えを得ました。
Google グループから: 理由の 1 つは JavaScript を使用しないユーザー エージェント、つまり検索エンジンのクローラーと NoScript がオンになっているユーザーにあると思います。
これらが本当の問題であり、ウェブサイトがまだサーバー側 MVC を使用している理由であることを願っています。
Web サイトがターゲット ユーザーを認識していない場合、クライアント側でどれだけうまく動作するかを予測できません。そのため、コンテンツの多くを構築するためにサーバーに依存する必要があります。
また、stackoverflow がクライアント側の MVC を使用してより多くのコンテンツを構築するように設計されている場合、誰も Google 検索を使用して stackoverflow の投稿にアクセスできないと考えてください。
ウィキペディアの「検索エンジンの最適化」セクションから:一般
的なすべての Web 検索エンジンのクローラーで JavaScript が実行されないため、SEO はこれまで、SPA モデルの採用を希望する公開 Web サイトに問題をもたらしてきました。
コメントが待ち遠しかった
トリッキーな部分は確かにあなたが言及したポイントだと思います
相互にリンクすると、完全に複雑な Web アプリのように見えます。
各 MVC フレームワークは、ルーティング、データ バインディング、アプリケーションの状態、 DOM 要素のレンダリングなど、最新の Web アプリで発生する通常の問題に対処するために異なるアプローチを使用するため、実質的に重複するタスクを実行する複数のフレームワークを持つことになると思います。いずれかのフレームワークの組み込み機能の一部を非アクティブ化または無効化する必要があり、frankenstein -app :) の維持が非常に困難になります。
良い例は jQuery-mobile と ember.js で、どちらもルーティングシステムを備えています。jQuery は DOM を使用して状態を保持します。ember.js は状態を完全にJavaScriptで保持するため、はるかに高速です。jQuery-mobile と ember.js を使用するプロジェクトで同様の問題が発生したため、ルーティング システムの 1 つを決定する必要がありました。 jQuery-mobile 側。最後に、ember.js のみを使用して jQuery-mobile を削除し、モバイルに見えるアプリ用の CSS を削除しました。
具体的な要件によるものではない場合、IMHO の最善の策は、非常に優れた柔軟で独断的なフレームワーク (個人的にはember.jsを好みます) を1 つだけ用意し、言及したモジュールを唯一の選択肢で作成することです。
それが役に立てば幸い。
それが私たちが今向かっている変化だと思います。あなたのことはよくわかりませんが、はるかに多くのクライアント側 MVC Web サイトがあることに気付きました。とにかく、あなたもこれを見ることができます....
http://backbonejs.org/#examples
私の見解では、学習曲線を除けば、JSON/REST を使用してクライアント MVC と Web API を使用して開発するのはかなり適切です。