Webframeworks – eine Kategorisierung

Welches Webframework soll im nächsten Projekt eingesetzt werden?

Kai Wähner

Webanwendungen verdrängen immer mehr die klassischen Desktopanwendungen und sind aus dem Alltag nicht mehr wegzudenken – sei es als E-Mail-Client oder für die einfache Verwaltung der Bankkonten über das Web. Zur Realisierung dieser Anwendungen werden Webframeworks eingesetzt, von denen es mittlerweile alleine schon im Java-Umfeld eine fast unüberschaubar große Anzahl gibt [1]. In Foren, Blogs und Fachzeitschriften liest man regelmäßig über neu erschienene Frameworks oder zusätzliche Features. In diesem Zusammenhang fallen häufig Begriffe wie Ajax, Rich Internet Application oder Portal. Doch was bedeuten diese Begriffe eigentlich? Und welches Webframework ist für welches Projekt relevant? Der Artikel gibt einen Überblick über die verschiedenen Frameworktypen und nimmt eine Kategorisierung anhand grundlegender Design- und Entwicklungskriterien vor.

Der Artikel beschreibt wichtige Designentscheidungen im Umfeld der Entwicklung von Webanwendungen. Darüber hinaus werden die verschiedenen Framework- und Technologietypen näher erläutert. Anschließend wird eine Übersicht der im Markt existierenden Webframeworks gegeben und anhand von Kriterien kategorisiert.

Was ist ein Webframework?

„Webframework“ wird als Oberbegriff für die Kombination mehrerer Technologien zur Entwicklung von Webanwendungen verwendet. Das Ziel ist dabei, sich wiederholende Tätigkeiten zu vereinfachen, rein technische Aufgabenstellungen (z. B. Kommunikation über Servlets) abzunehmen und die Wiederverwendung von Code zu fördern. Die Fähigkeiten eines Webframeworks sind darauf ausgelegt, schnell Ergebnisse zu erzielen und lauffähige Webanwendungen zu erstellen. Der Artikel betrachtet Webframeworks, die ohne Zusatzaufwand auf einer JVM lauffähig sind. Ajax (Kasten: „Ajax (Asynchronous JavaScript and XML)“) und entsprechend das Web 2.0 haben sich mittlerweile etabliert und werden durch nahezu alle aktuellen Webframeworks unterstützt – meist durch eigene Ajax-Komponenten, die keine JavaScript-Kenntnisse erfordern. Zumindest aber die Integration von Ajax-Bibliotheken ist immer verfügbar.

Abb.1: Vergleich der Kommunikation ohne und mit Ajax
Ajax (Asynchronous JavaScript and XML)

Ajax bezeichnet ein Konzept der asynchronen Datenübertragung zwischen Webbrowser und Server (Abb. 1). Dabei wird ermöglicht, im Hintergrund weitere Daten vom Server zu laden, während eine Seite im Browser angezeigt wird. Diese Daten werden verwendet, um mittels JavaScript die aktuelle Seite zu aktualisieren. Da die Seite nicht jedes Mal vollständig neu geladen werden muss, kann der Benutzer flüssiger mit der Anwendung arbeiten. Technisch betrachtet bezeichnet Ajax eine Menge von Technologien, die zur Webentwicklung eingesetzt werden. HTML wird für die Darstellung verwendet. Der Browser wandelt es in einen Document-Object-Model-(DOM-)Baum um, der mittels JavaScript modifiziert werden kann, um die dynamische Darstellung von Inhalten zu ermöglichen. Zur asynchronen Kommunikation mit dem Server wird das XMLHttpRequest-Objekt eingesetzt und in der Regel entweder XML, JSON oder reiner Text als Datenformat verwendet.

Ein großer Vorteil von Ajax ist, dass kein Browser-Plug-in benötigt wird – lediglich JavaScript muss im Webbrowser aktiviert sein. Allerdings entstehen durch das neue Programmierparadigma auch einige Probleme, die von JavaScript-Bibliotheken oder Webframeworks „bereinigt“ werden müssen:

  • Die Funktionalität der „Zurück“-Schaltfläche des Browsers ist schwer zu gewährleisten, da Webbrowser normalerweise nur jeden neuen URL in ihrer Historie abspeichern.
  • Bei schlechter Programmierung besteht die Gefahr, dass ein Client öfters Anfragen an den Server senden muss, da es durch die Aufteilung auf mehrere Bereiche einer Seite oft auch mehrere unabhängige Events gibt. Dadurch wird die Auslastung des Webservers spürbar erhöht.
  • Das Setzen eines Lesezeichens auf einen ganz bestimmten Zustand einer Webanwendung muss nun explizit vom Entwickler realisiert werden.
  • Zusätzlicher Aufwand ist notwendig, um die Webanwendung einer Suchmaschine zugänglich zu machen.

JavaScript-Bibliotheken wie jQuery oder Prototype ermöglichen den Einsatz von Ajax durch bereits geschriebene JavaScript-Kontrollelemente, wodurch Ajax-basierte Webanwendungen mit deutlich weniger Entwicklungsaufwand realisiert werden können. Allerdings sind im Gegensatz zu Webframeworks im Java-Umfeld immer noch Low-Level-Programmierkenntnisse in JavaScript erforderlich. Die Frage, wann der Einsatz einer JavaScript-Bibliothek anstatt eines Webframeworks ausreichend sein kann, wurde unter [2] ausführlich beschrieben.

Das Motto „The right Tool for the right Job“ trifft auch auf Webframeworks zu, daher soll an dieser Stelle keine allgemeine Empfehlung ausgesprochen, sondern die Bewertung der einzelnen Frameworks durch den Leser ermöglicht werden. Kategorisiert werden Webframeworks, die eine große Community verfügen, viele Add-ons anbieten, Lernen und Nachschlagen durch Fachbücher, Blogs und Forenbeiträge ermöglichen und durch Fachzeitschriften sowie IT-Konferenzen in Medien vertreten sind.

Es wird nicht der Anspruch erhoben, alle verfügbaren Webframeworks komplett zu analysieren. Stattdessen erhält der Leser einen Überblick über die am Markt verfügbaren Frameworktypen und die Möglichkeit zu entscheiden, welcher Typ für die Anforderungen in einem konkreten Projekt am besten geeignet ist.

Multi-Page vs. Single-Page

Der Unterschied zwischen Multi-Page und Single-Page wird in Abbildung 2 dargestellt. Bei einer Multi-Page-Struktur besitzt die Webanwendung mehrere Seiten, durch die navigiert wird. Der Benutzer öffnet einen URL im Browser und eine konkrete Seite wird angezeigt. Während der Benutzung werden Hyperlinks verfolgt und Daten übertragen. Jede Seite besitzt daher einen eigenen URL. Durch diese Struktur sind typische „Browserfeatures“ wie Lesezeichen oder Vor- und Zurück-Navigation grundsätzlich verfügbar. Das klassische Beispiel ist Amazon, wo zuerst verschiedene Produkte, die jeweils eine eigene Seite besitzen, betrachtet und gegebenenfalls in den Warenkorb gelegt werden. Dann wird auf mehreren Seiten der Bestellvorgang (Auswahl von Adresse, Zahlungsart und Versandart) durchgeführt.

Bei der Single-Page-Struktur hingegen besitzt die Webanwendung nur eine Seite, in der alle Aktionen durchgeführt werden. Durch Panels und Reiter können mehrere Seiten simuliert werden. Oft gibt es aber nur genau eine Seite zur Darstellung der gesamten Anwendung. Der Benutzer öffnet einen URL im Browser, der dauerhaft unverändert bleibt. In der Anwendung öffnen sich oft neue Fenster bzw. Dialoge (z. B. für Warnhinweise). Typische Browserfeatures wie Lesezeichen oder Vor- und Zurück-Navigation sind daher meist nur durch Mehraufwand realisierbar. Auch die Durchsuchbarkeit, die insbesondere für Suchmaschinen notwendig ist, wird erschwert. Als klassisches Beispiel für die Single-Page-Struktur sei die Webanwendung Google Mail genannt, wo auf einer einzigen Seite alle Aufgaben zur E-Mail-Verwaltung durchgeführt werden.

Abb. 2: Vergleich der Multi-Page- und Single-Page-Struktur
Geschrieben von
Kai Wähner
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.