なぜ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後、これらの線はどこに描かれますか？MVCとMVVMは、クライアント側のJavaScriptコードにすべて揃っているようです。

私が知りたいのは、なぜそのような移行をしたのですか（サーバー側プログラミングの強調からクライアント側へ、コンパイル言語の優先からスクリプト言語へ、命令型プログラミングから関数型プログラミングへ、これらはすべて同時に発生したようです） ）そして、この移行/シフトはどのような問題を解決しましたか？

サーバーとクライアントの間でコンピューティングの負荷をシフトすることは周期的な現象であり、かなり以前からそうなっています。

私がコミュニティカレッジにいたとき、パーソナルコンピュータはただ頭を動かしていました。しかし、イーサネットはまだ広く使用されておらず、誰もローカルエリアネットワークを持っていませんでした。当時、大学には学生の記録を処理するメインフレームがあり、プログラミングクラスのプラットフォームとして機能していました。管理部門には、時分割ベースでメインフレームに接続された端末がありましたが、学生はプログラミングの割り当てを完了するためにカードをパンチする必要があり、骨の折れるプロセスでした。最終的に、彼らは学生が端末で時間をサインアップできる実験室に入れましたが、それでもあなたの半インチ厚のエラーのプリントアウトを得るのにまだ30分ほどかかりました。 処理作業はすべてメインフレーム（サーバー）で行われました。

しかし、メインフレームは高価だったため、企業はローカルエリアネットワークの設置を開始し、処理負荷はサーバーから個々のクライアントマシンにシフトしました。他のユーザーと処理能力を共有します。サーバーは、同様の機能（おそらくより多くのメモリとハードドライブ領域）を備えた同様のマシンでしたが、主にファイルの共有に使用されました。これはクライアント/サーバーと呼ばれていました。 ほとんどの処理はクライアントコンピューターに移行していました。

クライアントマシンですべての処理を行うことの欠点の1つは、ソフトウェアのインストールとアップグレードのこの絶え間ないサイクルと、それに伴うすべての頭痛の種に閉じ込められたことです。これらのマシンのプログラミングモデル（イベントベースの分離コードユーザーインターフェイス）は、面倒で保守が難しいプログラム（泥の大きな塊）の作成を促進しました。ほとんどのエンドユーザーは、ハードウェアとソフトウェアを適切に保守するスキルを持っていなかったため、IT保守担当者の軍隊が必要でした。

コンピューターがますます強力になるにつれて、分業が可能になりました。これで、ファイルサーバー、データベースサーバー、Webサーバー、プリントサーバーなどを使用できます。各マシンは、提供されたタスクに合わせていくらか最適化され、必要な専門知識を持つ誰かが保守できます。Webブラウザーで実行されるプログラムを作成できるため、クライアントのインストールは不要になりました。これは、マルチティアまたはnティアと呼ばれていました。メインフレーム時代のように、ブラウザは本質的にダム端末として使用されていましたが、サーバーとの通信方法はより洗練され、独自性が低く、タイムシェアリングとポーリングではなく割り込みメカニズムに基づいていました。 処理はサーバーに戻りました。

ただし、Web開発にはまったく新しい頭痛の種が伴いました。ブラウザ用に作成されたほとんどの基幹業務アプリケーションは、静的なフォームとレポートでした。UIで利用できるインタラクティブ機能はほとんどありませんでした。Javascriptはまだ2番目の風を見つけていませんでした。また、ブラウザの非互換性に大きな問題があり、普及が妨げられていました。しかし、事態はずっと良くなっています。HTML5とCSS3はブラウザプログラミングモデルにかなりの新機能を提供し、jQueryが登場し、Javascriptの有用性を全世代のプログラマーが発見するのを助けました。新しいフロントエンドUIフレームワークが登場しました。完全なゲームであっても、ブラウザで高度にインタラクティブなUIを作成することが可能になりました。 処理は再びクライアントに戻りました。

現在では、クラウド内で処理能力を好きなだけ購入したり、サーバー上でプログラムを実行したりできます。私たちは今、ソフトウェア開発者として、クライアントとサーバーの両方で処理能力を実行できる場所について多くの選択肢がある場所にいると思います。

あなたは2つの非常に異なる概念を混ぜているようです：

1. プレゼンテーションとビジネスロジック（MVC）の分離=>保守性の向上
2. 実行をノードに割り当てる=>効率を上げる

クライアント/サーバーコンピューティングは、クライアントとサーバーに比べて一般的に多くのコンピューティング能力を提供していなかったため、最初のクライアント/サーバーコンピューティングが最初のものを暗示していました。このため、「重い」ビジネスロジック計算（M）をサーバーに移動し、「軽い」ビュー処理（V）をクライアントに移動することは自然に思えました。次に、2つの間で変換するために、何らかの種類のアービトレーター（C）を実装する必要がありました。

かつては高価なサーバーハードウェアを暗示していたプロセス能力をクライアントが簡単に備えているため、ビジネスロジックを実行する場所（クライアント側またはサーバー側）の境界が曖昧になりました。実際、答えは特定のユースケースとトレードオフの選択に依存します。例えば：

• クライアントの待ち時間と複雑さ：コードをクライアントに展開/ダウンロードする必要がないため、サーバー側の処理によりシステムがシンプルになりますが、計算中にクライアント側の待ち時間が発生します。

• 複雑さ対サーバー負荷：クライアント側のコンピューティングはシステムの複雑さを増す可能性がありますが、サーバー負荷の軽減にも役立つ場合があります。

• 分散アプリケーションの復元力と中央実行：モバイルアプリの世界では、ネットワークが切断されてもクライアントが動作し続けることが重要です。ただし、これには、ビジネスロジックの複数の展開バージョンを管理するコストがかかります。

これは、多くのトレードオフを網羅したリストではありません。

ユーザーは、デスクトップアプリで使用していたのと同じ機能、Webアプリ（Webサイトだけでなく）の機能を常に望んでいたためです。これをすべてブラウザー（実際には複数のブラウザー）で実行することは、少しのコードでVBフォームをデータベースにリンクできる昔のようではありません。これは、サーバーに戻る必要がない場合に簡単に実行できます。

JavaやC＃などのプログラミング言語を使用したほとんどのバックエンド開発は、RESTのようなインターフェースを作成することであり、表示、視覚化、データ入力/出力、ユーザーインタラクションなどのすべての苦労はクライアント経由で対処されています。 Angular、Backbone、Ember、Knockoutなどのサイドフレームワーク

バックエンドのプログラミング/サービスは同じ古いもののように思えるかもしれませんが、それはアプリケーションの心臓部です。これらの領域では、コーディングの実践がより効率的です。ツール、言語、ブラウザ、フレームワークはまだ進化しているため、UI / UXの開発は困難です。これらは、古いASPにはなかった新しいものです。単純なフォームとhtmlテーブルを備えたユーザーインターフェイスを使用できれば、これらの領域にもあまり興味/誇大広告はありませんが、ユーザーはドラッグアンドドロップ、アニメーション、トランジション、ポップアップなどを望んでいます。

今日、私が取り組んでいるほとんどのプロジェクトで、JavaScriptフレームワークとクライアント側の開発は、すべてのエキサイティングで革新的な進歩が行われている場所であることがわかりました。

サーバーからクライアント側の開発へのこの移行が行われたのはなぜですか？

ここには実際に2つの質問があります。

1. 進歩が起こっているクライアント側のプログラミングはなぜですか？
2. アプリケーションがサーバーではなくクライアントで実行されるように書かれているのはなぜですか？

2つは実際には区別されます。

進歩が起こっているクライアント側のプログラミングはなぜですか？

過去3年間でランタイム、環境、エコシステムが大幅に成熟し、これが革新者が活用するのを待っている新しいニッチを開いたためです。

以前は、フロントエンド開発は困難でした。シッククライアントアプリケーションを構築するための先行技術やツールがなかったエコシステムで、ECMAScript 3の制約された機能を使用して、ブラウザー（常に敵対的な環境）向けにプログラミングする必要がありました。モジュールローダーはありませんでした。依存関係を適切に処理できませんでした。リンティングツールが不足していました。フレームワークは未熟であり、フロントエンドの評判の悪さは、これらの問題を解決できる革新者を遠ざけました。

これらの要素が徐々に変化するにつれて、リッチクライアントアプリケーションを迅速に開発し、それらを一貫して実行するためのクリティカルマスが生まれました。

質問に対する答えとして、新しいフロントエンドテクノロジーが進歩を押し進めたということではなく、ボトルネックを解放し、クライアントがユーザーの願望に追いつくことができたということです。

アプリケーションがサーバーではなくクライアントで実行されるように書かれているのはなぜですか？

多くの近接する原因がありますが、近年の最も顕著なのはスマートフォンの台頭です。

スマートフォンは、適度に強力なコンピューティングを安価で、ユビキタスで便利なものにします。彼らは世界中の何十億もの人々によって所有されており、本質的に新興経済の中流階級にコンピューティングをもたらしています。しかし、モバイルネットワークは低迷し、パッチが多く、地理的、工学的、政治的な困難な問題に制約されています。この環境では、アプリケーションが状態をローカルに保存し、データを不承不承かつステートレスな操作でパッチすることは避けられません。

どう違うのでしょうか？あなたのスマートフォンが単なるダム端末であると想像してください。すべての状態の変化は、非同期で誤りやすいものでなければなりません。すべてのコンテンツのロードには貴重な費用がかかります。稼働時間が5〜9の巨大なサーバーファームに投資する必要があります。コンピューティングコストはお客様が直接負担するため、急に人気が急上昇すると、実際にビジネスが停滞する可能性があります。

クライアント側のアプリケーションを使用すると、個々のユーザーに関連する状態を高速で同期的に処理できます。コンピューティングコストをユーザーにオフロードできます。ダウンタイムと劣悪なネットワーク接続を回避できます。サーバーコードを非常にバカにして、ネットワークインフラストラクチャ自体にキャッシュできるようにします。静的なHTMLファイルとJSファイル、またはモバイルアプリの定型応答です。

非常に広い意味で言うと、クライアント側の開発は、中規模のパーソナルコンピューティングの低コストを活用し、高電力の集中型コンピューティングの高コストを回避します。

あなたはいくつかの質問をしましたが、そのうちのいくつかはすでに良い答えを持っています。いくつかの回答がまだありません。

私が知りたいのは、なぜサーバー側プログラミングの強調からクライアント側への移行を行ったのか、...これらすべてが同時に発生したように見える）、そしてこの移行/シフトはどのような問題を解決したのですか？

ロバート・ハーヴェイはすばらしい答えをくれました。

...コンパイル言語の優先からスクリプト言語へ、

スクリプト言語には、コンパイルされた言語よりも多くの利点があります（たとえば）。

• 学びやすく使いやすい
• コンパイル時間を短縮します（開発期間の短縮）
• より多くの機能を提供します（ハイエンドのアプリケーション制御）
• 実行中のコードをすばやく変更できます
• 等

...命令型プログラミングから関数型プログラミングまで、

これは良い比較ですが、分散ソフトウェア（クラウドコンピューティングを考える）では、状態の変更（多くのノード間での同期）の管理が大きな問題になる可能性があると言って要約します。関数型プログラミングでは、状態の変化に対処する必要性ははるかに低くなります。