Webアプリケーションフレームワーク
高いトラフィックに対応したWebアプリケーションを実現するため、プログラマはWebサーバとの密な結合を望んだ。Apache HTTP Serverは、例えば、Webサーバが任意のコードを実行したり(mod pythonなど)、特定のリクエストを動的なコンテンツを扱えるWebサーバに転送するような(mod_jk(英語版)など)モジュールをサポートしている。Javaなどの言語で書かれた動的なコンテンツをWebサーバで扱うことができるよう設計されたものもある(Apache Tomcatなど) 。
自己記述的なコンテンツ管理システムが、高位のレイヤーのWebアプリケーションフレームワークに進出し始めている。 例えば、Drupalの構造は Webアプリケーションフレームワークに関連した機能を提供するモジュールにより機能を拡張できる最小限のコアを提供している。 WordPress、JoomlaとPloneも同様な機能を持っている。 Liferay(オープンソース)のような高度な汎用コンテンツ管理システムでは、更にコンテンツのバージョン管理、公開開始日/終了日、公開する前の承認ワークフロー、プレビュー機能、マルチメディアコンテンツの対応など従来ではWebSphereやMicrosoft SharePointなどでしか提供されていない機能にも対応している。 伝統的にこれらは コンテンツ管理システムとも呼ばれる。 しかし、コンテンツの管理がこれらのシステムの上で最重要の機能であるかについては議論の余地がある。Liferayのようなフレームワークは関数API、機能のフレームワークやコーディング標準、伝統的にWebアプリケーションフレームワークに関連する機能も提供している。
多数のフレームワークが、データモデル、ビジネスロジック、ユーザーインターフェイスを分割するためにMVCモデルに従っている。
膨大な数のJavaフレームワークが開発中、ないしは実際に使用されている。 これらのフレームワークの多くはJakarta EEプラットフォームの上に構築されているか、ないしは要素を借りてきている。
ごくわずかの例外はあるが、Webアプリケーションフレームワークは多数のプラットフォームで動作する、プラットフォーム非依存の言語の上に作られている。
特定の構成を推奨するフレームワークもあるが、大半のものは Windows、macOS、LinuxなどのUnix系のプラットフォーム上で動作する。 特筆すべき例外として、.NETのために書かれたDotNetNukeはMonoランタイムをサポートしていない。
ほとんどのMVCフレームワークは、プッシュ型のアーキテクチャにしたがっている。このようなフレームワークは、処理を要求するアクションを実行し、次に結果を出力するためにデータを表示のレイヤにプッシュする。 Struts、Django、Ruby on Rails、Spring Frameworkの一部であるSpring MVCなどがこのアーキテクチャの良い例である。
これに対するものとしてプル型のアーキテクチャがあり、「コンポーネント型」とも呼ばれている。こうしたフレームワークは表示レイヤから処理を開始し、必要に応じて複数のコントローラからの処理の結果を「プル」する。 このアーキテクチャでは、複数のコントローラーが一つのビューに関連付けられる。 Tapestry、Velocity などがプル型アーキテクチャの一例である。