現在、n層開発のコードベースに、現在と同じかそれ以上ではない量のJavaScriptコードが含まれているのはなぜですか？
私は長い間Webプログラミングを行ってきましたが、どこかで、なぜ私たちが今日していることをしているのか（または、どうやってこのようにしていたのか）がわかりませんでしたか？
私は基本的なASP Web開発から始めました。そして、ごく初期の段階では、表示とビジネスロジックはページ上で混合されていました。クライアント側の開発は大幅に異なりました（VBScript、JavaScriptのさまざまなフレーバー））。サーバー側の検証について多くの警告がありました（そのため、クライアント側のロジックには近づきませんでした）。
その後しばらくColdFusionに移動しました。 ColdFusionはおそらく、タグを使用して表示ロジックとビジネスロジックを分離した最初のWeb開発フレームワークでした。それは私には非常にはっきりしているように見えましたが、非常に冗長であり、ColdFusionは高い市場需要がなかったので、次に進みました。
次に、ASP.NETバンドワゴンにジャンプして、MVCアプローチの使用を開始しました。また、Javaはエンタープライズシステムの象牙の塔型言語のように思われ、MVCアプローチも試しました。後で、ASP.NETがこのMVVM設計パターンを開発し、Java（正確には、J2EEまたはJEE）も苦労し、MVC2アプローチを採用しました。
しかし、今日、私が発見したのは、バックエンドプログラミングがもはや興奮と進歩の場ではないということです。また、サーバー側ベースのMVCプラクティスは時代遅れになっているようです（人々は本当にJSTLを使用していますか？）。今日、私が取り組んでいるほとんどのプロジェクトで、JavaScriptフレームワークとクライアント側の開発がすべてのエキサイティングで革新的な進歩を遂げているところだとわかりました。
サーバーからクライアント側の開発へのこの移行が行われたのはなぜですか？私はJEEプロジェクトの1つの単純な行カウントを行い、JavaScriptにはJava（サードパーティのライブラリを除く）よりも多くのコード行があります。プログラミング言語を使用するほとんどのバックエンド開発はJavaまたはC＃は、RESTのようなインターフェースを生成することであり、表示、視覚化、データの入出力、ユーザーの操作などのすべての困難な努力が対処されています... Angular、Backbone、Ember、Knockoutなどのクライアント側フレームワークを介して...
JQuery以前の時代には、n層開発でMVCのM、V、Cの間に明確な概念的な線があった図がたくさんありました。 jQuery後、これらの線はどこに描かれますか？クライアント側のJavaScriptコードでは、MVCとMVVMはすべて問題ないようです。
私が知りたいのは、なぜこのような移行を行ったのか（サーバー側プログラミングの重点からクライアント側へ、コンパイルされた言語の優先からスクリプト言語へ、命令型プログラミングから関数型プログラミングへ）、これらすべてが同時に発生したようです）そして、この移行/シフトはどのような問題を解決しましたか？
サーバーとクライアントの間で計算負荷をシフトすることは循環的な現象であり、かなり長い間そうでした。
私がコミュニティカレッジにいたとき、パーソナルコンピュータはSteamの責任者になりました。しかし、イーサネットはまだ広く使用されておらず、ローカルエリアネットワークは誰も持っていませんでした。当時、大学には学生の記録を処理し、プログラミングクラスのプラットフォームとして機能するメインフレームがありました。行政には時分割でメインフレームに接続された端末がありましたが、学生はプログラミングの割り当てを完了するためにカードをパンチする必要があり、骨の折れるプロセスでした。結局、彼らは学生が端末で時間にサインアップできるラボを設置しましたが、それでもまだ、30分の1インチほどの厚さのエラープリントアウトを取得するのに30分ほどかかりました。 すべての処理作業はメインフレーム（サーバー）で行われました。
しかし、メインフレームは高価だったため、企業はローカルエリアネットワークの設置を開始し、処理負荷はサーバーから個々のクライアントマシンにシフトしました。他の人と処理能力を共有します。サーバーは同様の機能を備えた同様のマシン（おそらくより多くのメモリとハードドライブ領域）でしたが、主にファイルの共有に使用されました。これはクライアント/サーバーと呼ばれていました。 ほとんどの処理はクライアントコンピューターに移行しました。
クライアントマシンですべての処理を実行することの欠点の1つは、ソフトウェアのインストールとアップグレードのこの永続的なサイクル、およびそれに伴うすべての頭痛の種に縛られてしまうことでした。これらのマシンのプログラミングモデル（イベントベースのコードビハインドユーザーインターフェイス）により、面倒でメンテナンスが難しいプログラム（大きな泥の塊）の作成が促進されました。ほとんどのエンドユーザーは、ハードウェアとソフトウェアを適切に保守するスキルを持っていなかったため、IT保守要員の軍隊を必要としました。
コンピュータがますます強力になるにつれて、分業が可能になりました。これで、ファイルサーバー、データベースサーバー、Webサーバー、プリントサーバーなどを使用できます。各マシンは、提供されたタスクに合わせていくらか最適化され、必要な専門知識を持つ誰かによって保守されます。 Webブラウザーで実行されるプログラムを作成できるため、クライアントのインストールは不要になりました。これは、Multi-Tierまたはn-Tierと呼ばれていました。ブラウザーは、メインフレーム時代と同様に、基本的にダム端末として使用されていましたが、サーバーとの通信方法はより高度で独自性がなく、タイムシェアリングやポーリングではなく割り込みメカニズムに基づいていました。 処理がサーバーに戻りました
しかし、Web開発にはまったく新しい頭痛の種が伴いました。ブラウザ用に作成されたほとんどの基幹業務アプリケーションは、静的なフォームとレポートでした。 UIで使用できる対話機能はほとんどありませんでした。 Javascriptはまだその第2の風を見つけておらず、ブラウザの非互換性に大きな問題があり、その広範な採用を妨げていました。しかし、状況は大幅に改善されました。 HTML5とCSS3は、ブラウザープログラミングモデルに実質的な新機能を提供します。jQueryが登場し、全世代のプログラマーがJavascriptの有用性を発見するのに役立ちました。新しいフロントエンドUIフレームワークが登場しました。完全なゲームでさえ、ブラウザで非常にインタラクティブなUIを書くことが可能になりました。 処理は再びクライアントに戻りました。
今日、クラウドで処理能力を好きなだけ、または少なく購入して、サーバー上でプログラムを実行できます。私たちは今、ソフトウェア開発者として、クライアントとサーバーの両方で処理能力を実行できる場所について多くの選択肢がある場所にいると思います。
あなたは2つの非常に異なる概念を混ぜているようです：
- プレゼンテーションとビジネスロジック（MVC）の分離=>保守性の向上
- ノードに実行を割り当てる=>効率を上げる
クライアント/サーバーコンピューティングは、サーバーに比べてクライアントは一般にあまりコンピューティング能力を提供していなかったため、最初のことを暗示するのにしばしば混乱していました。したがって、「重い」ビジネスロジック計算（M）をサーバーに移動し、「軽い」ビュー処理（V）をクライアントに移動するのは自然なことです。次に、2つの間を変換するために、ある種のアービトレーター（C）を実装する必要がありました。
かつては一部の高価なサーバーハードウェアを暗示していたプロセス能力をクライアントが簡単に利用できるようになったため、ビジネスロジックを実行する場所（クライアント側またはサーバー側）が曖昧になりました。実際、答えは特定のユースケースとトレードオフの選択に依存します。例：
クライアントレイテンシv.s.複雑さ：コードをクライアントにデプロイ/ダウンロードする必要がないため、サーバー側の処理によりシステムがシンプルになりますが、計算中にクライアント側のレイテンシが犠牲になります。
複雑さ対サーバーの負荷：クライアント側のコンピューティングはシステムの複雑さを増すかもしれませんが、サーバーの負荷を減らすのにも役立つかもしれません。
分散型アプリケーションの復元力との比較中央での実行：モバイルアプリの世界では、ネットワークが切断されていてもクライアントを動作させ続けることが重要な場合があります。ただし、これには、展開された複数のバージョンのビジネスロジックを管理するという代償が伴います。
これは、多くのトレードオフを網羅したものではありません。
ユーザーは、デスクトップアプリと同じ機能（ウェブサイトだけでなく）でも、いつも同じ機能を求めていました。これをすべてブラウザー（実際には複数のブラウザー）で実行することは、VBフォームを小さなコードでデータベースにリンクすることができた昔のこととは異なります。これは、サーバーに戻る必要はありません。
JavaまたはC＃などのプログラミング言語を使用するほとんどのバックエンド開発は、RESTのようなインターフェースを作成することであり、表示、視覚化、データ入出力、ユーザー操作などのすべての困難な作業です。 ... Angular、Backbone、Ember、Knockoutなどのクライアント側フレームワークを介して対処されています...
たぶん、バックエンドのプログラミング/サービスは同じように見えますが、それがアプリケーションの中心です。これらの領域では、コーディング方法がより効率的です。ツール、言語、ブラウザ、フレームワークはまだ進化しているため、UI/UXの開発は困難です。これらは、古いASPにはなかった新しいものです。単純なフォームとhtmlテーブルを備えたユーザーインターフェースで済むとしたら、それらの領域にはそれほど関心や誇大宣伝はありません。どちらでも、ユーザーはドラッグアンドドロップ、アニメーション、トランジション、ポップアップなどを望んでいます。
今日、私が取り組んでいるほとんどのプロジェクトで、JavaScriptフレームワークとクライアント側の開発がすべてのエキサイティングで革新的な進歩を遂げているところだとわかりました。
サーバーからクライアント側の開発へのこの移行が行われたのはなぜですか？
ここには実際には2つの質問があります。
- なぜクライアント側のプログラミングが進歩しているのですか？
- アプリケーションがサーバーではなくクライアントで実行されるように作成されているのはなぜですか？
2つは実際には異なります。
なぜクライアント側のプログラミングは進歩が起こっているのですか？
ランタイム、環境、エコシステムが過去3年間で大幅に成熟し、これによりイノベーターが活用するのを待っていた新しいニッチが開かれたためです。
フロントエンド開発はかつてhardでした。シッククライアントアプリケーションを構築するための従来技術やツールのないエコシステムで、ECMAScript 3の制約された機能を使用して、ブラウザー-常に敵対的な環境-をプログラミングする必要がありました。モジュールローダーはありませんでした。依存関係を適切に処理できませんでした。リンティングツールが不足していた。フレームワークは未成熟であり、フロントエンドの評判が低いため、これらの問題を解決できる革新者を遠ざけていました。
これらの要素は徐々に変化しているため、リッチクライアントアプリケーションを迅速に開発し、一貫して実行するための重要な要素を生み出しています。
質問への回答として、新しいフロントエンドテクノロジーがボトルネックを解放し、クライアントがユーザーの願望に追いつくことができるようになったのと同じくらい、進歩は前進しました。
サーバーではなくクライアントで実行するようにアプリケーションが作成されているのはなぜですか？
近い原因はたくさんありますが、近年最もはっきりしているのはスマートフォンの台頭です。
スマートフォンは、適度にパワフルなコンピューティングを安価でユビキタスで便利なものにします。それらは地球上の何十億もの人々に所有されており、本質的に新興経済の中産階級にコンピューティングをもたらしました。しかし、モバイルネットワークは停滞しており、不安定で、地理的、工学的、政治的なハード問題によって制約されています。この環境では、アプリケーションが状態をローカルに保存し、しぶしぶ上向きにステートレス操作でデータにパッチを適用することは避けられません。
どのように違うのでしょうか？スマートフォンがばかばかしい端末だと想像してみてください。すべての状態の変化は、非同期であり、誤りである必要があります。コンテンツの読み込みごとに貴重な費用がかかります。ファイブナインの稼働時間を持つ巨大なサーバーファームに投資する必要があります。コンピューティングコストは直接発生するため、急激な人気の急上昇により、実際にビジネスが混乱する可能性があります。
クライアント側のアプリケーションを使用すると、個々のユーザーに関係する状態を高速かつ同期的に処理できます。コンピューティングコストをユーザーにオフロードできます。ダウンタイムと貧弱なネットワーク接続を回避できます。それらはサーバーコードを非常にばかげているため、ネットワークインフラストラクチャー自体（静的HTMLおよびJSファイル、またはモバイルアプリの返信定型文）にキャッシュできます。
非常に大まかに言えば、クライアント側の開発では、中電力のパーソナルコンピューティングの低コストを活用し、高電力の集中コンピューティングの高コストを回避します。