Webフレームワークがプログラミング言語のように単純でエレガントで楽しいものではないのはなぜですか？[閉まっている]

C、C ++、PHP、SQL、JavaScript、Python、ActionScript、Haskell、Lua、Lisp、Javaなど、ほとんどすべてのプログラミング言語について考えるとき、私は素晴らしいと思います。それらの言語の。

しかし、Webフレームワーク（私は主にPHPを使用しています）について考えるとき-Cake、CI、Symfony、Laravel、Zend、Drupal、Joomla、Wordpress、Rails、Djangoなど-私は神のようではありません。

プログラミング言語のようなシンプルで楽しく強力な構造を提供するWebフレームワークがないのはなぜですか？

私は、Pythonの側にいるにもかかわらず、何年もこの質問をしました。この現象の説明は1つではありませんが、この件についての私の考えは次のとおりです。

• WebフレームワークはXMLishマークアップ言語（HTML、現在のWebトライアドHTML-CSS-JavaScriptの一部）をクライアント/サーバーの方法で処理する必要があります。これは、相互に作用する3つの言語、つまりブラウザDOMと実行モデル（およびセキュリティモデル）を意味します。実際には、機能の各部分（「モジュール」）には、3つの言語すべてのコードが必要です。これに加えて、jQueryのセレクター言語は、もう1つの注意すべき言語になっています。

• HTML + CSSには、オブジェクトを配置するための直感的で数学的に適切なモデルがありません。Tcl / Tkでさえも、ジオメトリマネージャーの定義においてIMHOの方が優れています。これにより、プログラマーがHTMLレンダリングを厳密に定義するのを防ぎ、代わりに運に頼ることができます。「おそらく、このdivはほとんどのブラウザーでほとんどの場合機能します」。ただし、HTML5やTwitter Bootstrapなど、この面には前向きな進展がいくつかあります。

• Webテクノロジーは有機的に成長し、フレームワークもそれに伴って成長しているため、その形状は必ずしもエレガントである必要はありません。これは、プログラマーが次善のAPI、廃止予定のAPIなどを覚えておく必要があることを意味します。

• Webブラウザーにはまだわずかな非互換性があり、Webフレームワークに不必要な複雑さを追加します

• 全体的なアーキテクチャは混乱しています。これは、バックエンドとフロントエンドのスプリットシンキングであり、バックエンド側ではリクエスト/レスポンス、フロントエンド側ではデータ駆動型レンダリングと結び付いています。実行の順序はあまり明確ではなく（同期には労力が必要）、スタイルの配置、適切なスロットへのスクリプトが必要です（ほとんどすべてのjsスクリプトはbodyタグの終わりの前などに配置する必要があります）。キャッシングは、バックエンドからプロキシ、フロントエンドに及ぶさらに別の側面です。フォームの処理についても触れていません。

• Webフレームワークは、多くの概念を追加し、パイプを処理することで、これらの複雑さのほとんどに対処します。

• Web業界では、通常、最小限の役割のセットとして、グラフィックデザイナー、Webデザイナー/ Webプログラマー、バックエンドプログラマーに労働力が分配されます。前者2つは必ずしもプログラミングスキルを持っている必要はないため、異なる抽象化とツールが必要であり、フレームワークもそれらを容易にする必要があります。

要約すると、Webフレームワークは多くの複雑さを抽象化しようとしますが（それ自体が複雑さを増しています）、標準やその他の可動部分の急速な開発により、達成するのは非常に困難です。新しい機能を使用しないことは通常問題ではないため、プログラミング言語ははるかに成熟しています。

私は、便利なWebフレームワークを作成することは、GUI標準が導入され（モバイルデバイスなどのさまざまな操作モードをカバー）、基礎となるテクノロジが十分に安定した後にのみ可能になると思います。

Webテクノロジードメインにはそのようなものがないため、Webフレームワークには単純な構成要素がありません。低レベルの抽象化は必然的に高レベルにリークします。

私はそれの多くがWWWの制限に関係していると思います。具体的には、サーバーとクライアントの間で状態を保存する組み込みの方法はありません。クライアントがデータを要求し、サーバーがそれを提供し、接続が閉じられます。そのため、これらすべてのWebプラットフォームは、サーバー呼び出し間で状態を維持する独自の方法を組み合わせる必要があります。

小さなWebアプリを1度作成する必要があり、そのときにサーバー/クライアントのプログラミングを行ったことはありませんでした。すべてを把握するのに数週間かかりましたが、最も難しいのは、クライアントとサーバーがどこにあるのかを追跡することに頭を悩ませることでした。

これは変わるのでしょうか？疑わしい。それはウェブのアーキテクチャに根本的な変更を必要とするでしょう。

一般的に、原因は複数ある可能性があります。

1. フレームワークの場合、抽象化のギャップは大きくなります。最新の手続き型/ OOP言語は、マシンの抽象化を提供しますが、一部のマシン構造（変数へのデータの割り当て、メモリユニットへのデータの書き込み、またはプロシージャの呼び出しなど）を保持します。ギャップはそれほど大きくありませんが、フレームワークは、より多くの概念で動作するWebアプリケーションを開発するための抽象化を提供しようとします。
2. プログラマーの観点から見ると、フレームワークはより複雑になる可能性があります。これは最初のポイントの結果のようなものです。プログラミング言語はかなりシンプルで、シンプルな構成（if、for、変数、プロシージャなど）があります。また、標準ライブラリは、IOへの書き込みやコレクションの使用などの単純なものを抽象化します。標準ライブラリも非常にモジュール化されており、モジュール間の接続がほとんどまたはまったくありません。コレクションを使用するためにIOを知っている必要はありません。逆も同様です。標準ライブラリの一部がかなり複雑な場合、それらはミニフレームワーク（Java Collections FrameworkやExecutorsフレームワークなど）に配置されることに注意してください。フレームワークのケースでは、フレームワークを最大限に活用するために、フロー全体、すべての部分を知る必要があります。また、フレームワークはすでに構築されたアプリケーションです。
3. プログラミング言語ほど多くのリソースがフレームワークに配置されるわけではありません。これは説明の必要はないと思います。

ああ、でもあなたはそれがまさに問題だとわかります。フレームワークはチューリング完全であるとは想定されていません。それらは、特定の一連のタスクを簡潔な方法で実行するために一緒に構成できる、より制限された抽象化で構成されることになっています。したがって、あなたが言及したこれらのフレームワークは、制限された一連の抽象化を提供していないため、まったく面白くありません。それらは、それ自体ではなく、チューリング完全である可能性が高い抽象マシンを構成するよりも、リークの多い抽象化を提供します。「奇妙な機械」のコンセプトは、私が考えている最も近いものです。これらのフレームワークはすべて、Webアプリケーションの「奇妙なマシン」であり、「奇妙なマシン」は、フレームワークの本来あるべき姿の反対です。