このような大きな名前は、今日、クライアントのMVCコンセプト（Angular、Ember、Backbone、Marionette、Knockoutなど、数千個）とFull-Stackコンセプト（Derby、Meteor）を比較することを示唆しています。 長所、短所、神話、エラーを分析します。
背景
むかしむかし、MVCがWeb開発者の頭の中で普及し始めた頃、それはサーバー上にありました。 Django、Ruby on Rails、Asp Net MVC、Yiiは、サーバー上の優れたMVCの例です。 誰もが好みに合わせて独自の言語を選択し、静的ページがネットワーク上を飛びました、jQuery-ああ、素晴らしい時間でした。 雷が突然襲った。 ユーザーは、クリックするたびにページ全体がリロードされるのを待つのではなく、Webを通常のプログラムで動作するように（インタラクティブに）したいことがわかりました。 一見、jQuery + Ajaxはこの問題を解決できますが、Web開発者がブラウザーの非構造化コードにinれ始めると、より根本的な変更が必要であることが明らかになりました。
アイデアは、MVCが既にサーバー上でコードを正常に構造化していた場合、クライアントでもこの問題を解決できるというものでした。 クライアントで最初に本当に人気のあったMVCはBackboneで、これは非常にエレガントでシンプルなソリューションです。 その後、誰もが自分の夢のフレームワークを作成しようとしましたが、世界では、Angular、Knockout、Batman、Ember、および他の多くの同様のフレームワークが見られました。 この豊富さで迷子にならないようにするプロジェクト全体が登場しました。 ルーター、テンプレート、バックエンド、REST-api、ワイヤ上のデータ-これらはすべてこの楽しい時代の象徴です。 幸せは永遠に続き、雲のない未来を覆すものはないように思えました。
問題
問題に最初に遭遇したのはTwitterでした。 一般的に、彼らはずっと行きました。 Ruby on Railsから始めて、サーバー上でhtmlを生成し、クライアント上のMVC上のすべてを書き換えて、ある時点で、ユーザーが140文字のテキストを読むのに4秒待つことに気付きました。 現在、Scalaを使用してサーバー上でhtmlの一部を生成し、JavaScriptを使用してクライアント上で一部を生成します。 Googleはこれを行い、C ++を使用してサーバーでhtmlを生成し、JavaScriptを使用してクライアントでhtmlを生成します。 このようなアーキテクチャは維持が難しく、中小企業や新興企業では利用できません。
検索エンジンは、Javascriptよりもサーバーからhtmlを取得する可能性が高くなります。 ユーザー用のクライアント上のMVCに加えて、検索エンジン専用のサーバー上でhtmlを生成することにより、問題を解決しようとする場合があります。 他のクライアントは、サーバー上のMVCを支持してクライアント上のMVCを放棄し、SEOの対話性を犠牲にします。
双方向性の時代では、ユーザーは他のユーザーが行ったデータの変更をブラウザーですぐに確認したいと考えています。 クライアント間のデータ同期は簡単な作業ではありません。サーバー部分が必要であり、クライアントのMVCカテゴリでは解決できません。
交換可能なバックエンド
クライアント上のMVCの主な議論の1つは、バックエンドを簡単に変更できることです。 クライアント上のMVCは、サーバーが少なくともREST-api、検証、データの操作、承認を持っていると想定しているため、バックエンドの変更は非常に簡単な手順ではありません。 実際には、バックエンドはほとんど変更されません。
バックエンドを変更する可能性は、サーバーとクライアントで事前に1つの言語を使用する利点を前もって無視するという意味でも制限されます。
-1つの言語、1つの環境、1つの用語
-同じモジュール（参照）
-コードの再現性
フレームワークは、Node.jsバックエンドがある場合にのみ、これらすべてを使用できます。
Node.js
Node.jsの主な神話は、Node.jsは安定しておらず、リクエストが失われることがあるということです。 クラスタとドメインの出現により、これはもはや関係ありません。
もう1つの神話は、Node.jsが遅いことです。 ここで、v8はCの3〜5倍しか遅い、またはNode.jsは接続を維持するために約8 kbのメモリしか消費しないと言うことができます。 しかし、おそらく単一のサーバー上で100万の同時接続で十分な議論になるでしょう。
三番目の神話は差し迫ったコールバック地獄です。 非同期Node.jsはそのイデオロギーであり、独自の利点を提供します。新しいリクエストは、それに対するすべてのリクエストが処理されるまで待つ必要がありません。 非同期環境でコードを書くことは、同期環境で書くこととまったく同じではなく、習慣が必要です。 Node.jsの有能な手では、コードは美しく透明です。
4番目の神話は、JavaScriptはあまり良い言語ではないということです。 ダグラス・クロックフォードは、この声明に反対することを認めました。
フルスタック
フルスタックフレームワークに関する主な神話は、それらがモノリシックなデザインであり、特定のコンポーネントを選択する際の柔軟性を奪うということです。 柔軟性と使いやすさの間には矛盾があります。 そして、正しい決定は、妥協点を見つけることです。 たとえば、Derbyは、 express.js 、 racer 、 share.js 、 live-db 、 tracksなどのコンポーネントで構成されています。それぞれが厳密に機能を実行し、一部は置き換え可能です。
2番目の神話は、フルスタックフレームワークは非常に複雑で、大規模なプロジェクトにのみ適しているというものです。 Derbyは、データベースのない静的サイトに使用でき、マルチプレイヤーゲームや大規模なインタラクティブアプリケーションと同じように成功します。
3番目の神話は、サーバーとクライアント間でコードを再利用したり、クライアント間でデータを同期したりすると、何らかのセキュリティ問題が発生する可能性があるというものです。 サーバーでのみすべてのシークレットコードを実行することは常に可能であるため、クライアントはそれについて何も知りません。 データ同期メカニズムは、データへのアクセスを制限する方法を提供します。
4番目の神話は、フルスタックフレームワークはまだ未加工で安定していないため、データを同期するときにパフォーマンスの問題が発生するというものです。 現在、負荷のかかっている本番のプロジェクトがいくつかあります。 問題ありません。
フルスタックフレームワークは、サーバー上のすべての最高のMVCとクライアント上のMVCを組み合わせて、これに1つの言語を使用する利点を掛け合わせ、組み込みのデータ同期などのユニークな機能と組み合わせて、Web開発者に彼のアイデアを実装するための強力なツールを提供します以前はGoogleやTwitterなどのモンスターだけがアクセスでき、今日のWebの未来をより近づけます。
ダービーコンテンツ