Web開発用のフレームワークがこれほど多くあるのはなぜですか？
私は現在ジュニアバックエンド開発者です。JavaとScalaと書いて、大好きです。
私は本当にウェブ開発に乗りたいと思っていますが、ガイドを探すたびに、それは特定のフレームワークのガイドに過ぎないようです。何年にもわたってWebが進化してきたおかげで、開発者はWebアプリケーションを構築するためのより効率的で動的な方法をとらざるを得なくなったと私は完全に理解しています。
Flaskガイドに従っている場合、Web開発ではなく、Flaskを学習しているように感じます。また、Angularたぶん、私が獲得したFlaskスキルの1％を使用します。
Bootstrap、VueまたはDjangoを学びたくありません。Web開発を学びたいです。
そんなことありますか？そして、なぜ代わりにフレームワークにそのような焦点があるのですか？
注：これ以降、元の質問のタイトルの編集が行われたようです答えが書かれ、おそらくその意味が多少変更されました。元の質問のタイトルはあまり明確ではありませんでしたが、Web開発に複数のフレームワークが必要な理由を尋ねているようです
Webのしくみ
一言で言えば、Webは、インバウンドHTTPリクエストに応答してデータとコンテンツを提供するWebサーバー、およびHTTPリクエストからデータとコンテンツを取得するためにHTTPリクエストをWebサーバーに送信するWebブラウザーの概念を中心に構築されています。
さらに、HTTPはConnectionlessです。つまり、WebブラウザーはWebサーバーとの接続やソケットを一切保持しません。ブラウザはWebサーバーについて何も知りません。 Webサーバーはブラウザについて何も知りません。 2つは互いに完全に独立して動作します。
ブラウザは通常、リクエストを送信するときにレスポンスを期待しますが、リクエストを送信したURLで何をリッスンしているかはわかりません。
リクエストを受け取ったサーバーは、何がそのリクエストを送信したのかわかりません。そのリクエストを受け取って応答を返し、リクエストを完全に忘れてしまいます。
これは当然、常に2つの問題を解決する必要があることを意味します。Webブラウザーで発生する問題とWebサーバーで発生する問題です。
ウェブサーバーテクノロジー
Webの初期の頃は、ほとんどすべてのWebコンテンツが単純な静的HTMLでした-通常、テキストと画像の混合で、それ以外はほとんどありませんでした。 Web開発は、単純なHTTPサーバーでホストされているフォルダー構造に格納された静的なHTMLドキュメントの負荷をかき回すことを意味する傾向がありました。
ほとんどの最新の洗練されたWebアプリはこれを行いません。サーバーがプレーンスタティックHTMLページを保存することはほとんどありません。コンテンツはオンザフライで生成される傾向があります。そのコンテンツをサーバーで生成する場合は、WordPressなどのコンテンツ管理システムを使用するか、DjangoまたはFlaskなどのフレームワークを使用してWebサービスを記述します。
Webサーバーを作成している場合、そのサーバーで実行されるコードは、サーバー自体に権限（データベースとの通信など）がある限り、通常、Pythonなどの言語のすべての機能を自由に使用できます。サーバーのファイルシステムへのアクセス、ネットワークリソースへのアクセスなど）
クライアント側のテクノロジー
サーバー上でHTMLを生成する必要はありません。代わりにブラウザ内で生成できます。ほとんどの洗練されたWebアプリには、ブラウザー自体の中で直接実行される高度で動的なプログラム的な動作があります。
ただし、ブラウザはランタイム環境ではありません。したがって、Webブラウザーは、Python、Java、C＃などの言語を使用して動的UI動作を構築することはできません。
ブラウザは、たまたまスクリプトエンジンが組み込まれているアプリケーションです。 Webブラウザースクリプトの機能は、ブラウザーに表示されたWebコンテンツの操作（HTML要素のリアルタイム作成/操作）、イベントとユーザー入力のリアルタイム操作、およびHTTPリクエスト/レスポンスを操作します。
そのため、ブラウザー内で実行される動的な動作を構築するには、ECMAScript（旧称JavaScript）が必要です。ただし、C＃/ Javaの最新のデスクトップ/モバイルGUIフレームワークが（MVCやMVVMなどのパターンとともに）開発者がGUIアプリを作成するのに役立つのと同じように、AngularやVueなどのクライアント側フレームワークにも同じことが存在します。 。
これらのフレームワークは、15〜20年前にGUIフレームワークがWindows/* Nixデスクトップ開発者のために解決したのと同じ問題をWeb開発者にとって解決します。 Web開発者が実際にユーザーのブラウザー内で実行されるリッチでインタラクティブな動的動作を構築するための高レベルの抽象化を提供します。それ以外の場合は、代わりにECMAScriptを使用して生のHTML要素を直接「低レベル」で操作する必要があります（非常に単純なものを実行する場合は問題ありませんが、高度なWebアプリの場合は非常に困難です）。
美学
ほとんどのウェブサイト/アプリのコンテンツは、多くの場合、非常に洗練されたスタイリッシュな美学を持っています。 Webサイトを1995年に属しているように見せたくない場合を除き、デフォルトのスタイルは使用しないでください。
ただし、生のCSSを使用して独自のルック/フィールの美学を設計し、多くの異なるブラウザー/デバイスで一貫して機能させるために多くの時間を費やしたくない場合は、Bootstrapを使用すると、最小限の労力で、その方法を習得するために多くの時間を費やすことなく、すっきりとした、すっきりとした、モダンな、洗練されたルックアンドフィールを実現できます。
フレームワークを使用する理由
さまざまなフレームワークが存在して、さまざまな問題を解決し、Webのさまざまな側面を処理します。フレームワークを使用する必要はありませんが、最近のWeb開発は、Times New Romanフォントを使用した従来のJavaScriptや静的HTMLページをはるかに超えています。
最終的に存在するのは、20年以上前に比べてはるかに洗練された見栄えがユーザーに期待され、人々の期待に応えるWebアプリを構築しようとすると、WordPress（最小限の技術的な専門知識が必要）、またはそれらのフレームワークの使用が必要です。
Web開発is異なるフレームワークの使用。
必要に応じて、フレームワークなしでWebアプリケーションを作成できます。たとえば、サーバー側でCommon Gateway Interface（CGI）を使用し、クライアント側でプレーンJavaScriptを使用すると、2つの利点があります。
- 依存関係はありません。
- HTTPプロトコルをよく理解している必要があります。
一方、これには大きな欠点があります。
- 大規模なアプリケーションをすぐに開発することはできません。
フレームワークは、基盤となるテクノロジーの複雑さを抽象化するのに優れています。 HTTPは非常に複雑です。 JavaScriptは、すべての言語の癖とIEの異常な振る舞いで10年前に使用されていたほど複雑ではありませんが、DOMの操作やデータバインディングの[欠如]を含むがこれらに限定されない、一連の困難が依然としてあります。フレームワークを使用すると、すべての低レベルのものについて考える必要はありませんほとんどの場合なので、プロジェクト自体に集中できます。
たとえば、PDF）のような静的ファイルをユーザーがダウンロードできるように送信し、クライアント側でファイルを2時間キャッシュする必要があるとします。 -sideフレームワークでは、数行でそれを実行します。フレームワークがないと、使用するHTTPヘッダーを理解するために、多くの時間をかけてHTTP仕様を読む必要があります（これは読むのに最適な方法ではありません）。 、値のエンコード方法など。通常は、時間をかけたくないあの（まあ、たぶんそうするかもしれませんが、ほとんどの開発者はそうではなく、そのためにお金を払っていません）。
これは、何十ものフレームワークを知っている必要があるという意味ではありません。サーバー側（Flaskを選択しました。それは素晴らしいです！）とクライアント側（AngularとReactは問題ありませんが、低レベルにしたい場合でも、jQueryはまだです）それ自体はフレームワークではありませんが、実行可能な代替手段です。1年間選択を続け、それらのフレームワークを十分に学習します。それらを理解すると、他のフレームワークが最も効果的な方法を見つけることができます。
さらに重要なことは、ファッショナブルなので、多くのプログラマーが月に2回新しいフレームワークにジャンプするという過ちを犯さないことです。履歴書には多くの凝った名前を付けることができますが、Web開発の実際のスキルや理解は得られません。
あなたは十分な努力でほとんど何でもできる汎用言語を使用することに慣れています。
あなたはいくつかのことをうまく行うドメイン固有の言語/フレームワークについて読んでいます。 HTML、JSON、CSS、Railsなど、すべてがイーサーとまったく同じように機能します。しかし、それは1つだけで十分なので、そのうちの1つだけを使用するのは困難です。
多くのことを実行するものを使用すると、1つのことだけを実行する場合よりも、それらの実行が難しくなることが期待できます。汎用言語の唯一の利点は、一度習わなければならないことです。それは最良の選択ではありません。そのため、ホッジポッジには非常に多くの言語があります。
加えて、Webには破壊された長い歴史があり、標準が覆されており、それらすべてを統制する統一されたプラットフォームを構築することは非常に困難です。
申し訳ありませんが、必要な作業を適切に行うツールを少なくとも1つ学習する必要があります。それらの仕事のそれぞれが何であるかを学ぶことから始めます。多くの場合、それらを行う方法は複数あります。何かを選んで学びましょう。
ここでの他の回答は、優れた歴史とWebデザインの説明を提供しますが、正確な質問には直接回答しないでください：なぜso many異なる、競合するフレームワークがあるのですか？
答えは、私たちが知っているwebアプリケーション開発は、基本的にちょうど10年ほど古いだからです。 Web開発業界は、他のほとんどすべての業界と比較した場合、それ自体が幼児である、より大きなソフトウェア業界の内部で初期段階にあります。
IPhoneが爆発する前に、HTML/CSS/JSを使用するかどうか、またはクライアント側のようなものかどうかについて、Web開発コミュニティで正当な議論がありましたJava =または、Flashはリッチインターネットアプリケーションのデフォルト環境になる（つまり、ブログよりも奇妙なものになる）ため、Web開発者は、Internet ExplorerでHTML/CSS/JSをラングリングする時間と、可能な場合はFlashを学習する時間とを分けていました。 Java=アプレットはまだ本当に消え去っていた。それは混乱であり、サーバー側の世界はクライアント側からしっかりと切り離されていた。
現代のJavaScriptベースの世界では、Googleマップが登場する前から、JavaScriptを使用して大規模なインタラクティブアプリケーションを開発することは良いアイデアだと誰も考えていなかったので、今は忘れがちです。そのため、JavaScriptを堅牢な言語として評価することさえ、2005年頃から行われてきました。
IPhoneが本当に爆発的に普及し始めたのは2008年ごろで、iOSでFlashをサポートしないというAppleの決定は、私の意見では、Flashの死の恐怖でした。そしてそれでも、この事実を真に消化するのに数年かかりました。
したがって、業界として、私たちがHTML/CSS/JSをWeb開発のデフォルトスタックにすることを決定してから10〜11年しか経過していないことを考えると、したがって、そのような若い時代を考えると、世の中に出回っているさまざまなフレームワークはすべて、サーバーが生成した結果をHTMLテンプレートにバインドする最も効率的な方法をその場で理解しようとしている両方の業界を表しています。最初は、「サーバーでテンプレートチャンクを生成し、それらをHTTP応答に結合する」という考えがありました。このモデルはうまく機能しましたが、質問の核心に戻ると、Java/Spring、ASP.NET、RoR、Djangoなどがある理由は、サーバーの種類によって、実行できるソフトウェアのレベルが異なるためです。さまざまな料金体系でそれらについては、サーバー言語レベルでの単一サイズのフィットオールアプローチはありませんでした。 Javaと.NETは実行に費用がかかりましたが、非常に広範な開発が可能でした。さらに、それらでデスクトップアプリも実行できます。PHPは事実上無料ですが、それらにまとめるとわずかに制限されます。
毎年、言語レベルで、開発者は「この古い言語をWebに合うように曲げることができるか、それともWeb専用に設計されたまったく新しい言語を選ぶべきか」と尋ねていました。 2010年までに、99％以上のWebアプリケーションがJS/HTMLで記述されるようになり、Flash/Silverlight /アプレットを実行していたすべての人々はHTMLミックスにジャンプする必要があり、データバインディングなどの好ましい方法は純粋なJavascriptでネイティブに利用できるため、Web開発業界に、Webを完全な状態にさせるWebフレームワークを作成するよう圧力がかかりました。
このように機能した最初のフレームワークには、Knockout JSのようなものが含まれていましたが、最終的にはAngularに置き換わりました。クライアントですべてを実行することに深く入り込んで、ジュースがちょうど良いとは思わない人々のために、多くの選択肢が生まれました。 Angularの複雑さを十分に理解する価値があります。さらに、クライアントだけではできないこと（適切なセキュリティ、暗号化など）が多すぎるため、クライアントとサーバーの間で負荷を分散する必要があり、これによりクライアントに配置する機能とサーバーに配置する機能そして、ここには異なる意見があるため、問題を異なる方法で解決するために異なるフレームワークが登場しました。
最後に、さらに別の変数が、おそらく過去7〜8年間でスローされました。JavaScriptはクライアント側専用であるという確固たる原則は、サーバー側JavaScriptの導入によって捨てられました。これは、適切なWeb開発を行うために最低2言語（JSとサーバー言語）を学習する必要があることに不満を抱いた人々からのものです。これは、Node.jsの現代的な爆発につながり、開発者は再びパラダイスな選択を迫られました。
つまり、要約すると、Web開発には3つの異なる基盤があります。
- 主にサーバー側の非JavaScriptコード（PHP、ASP.NET、Javaなど）
- 非常に重いクライアント側フレームワーク（Angular、React、Emberなど）Pure
- JavaScriptハイブリッド（Node.jsなど）
上記の各基盤の内部には、価格、言語、サーバー要件などによって区別される数十以上のさまざまなフレームワーク/戦略があります。そのため、1つのフレームワークですべてを統括することはできません最新のWeb開発用。