Server-Side vs. Client-Side: Die beiden Scripting-Techniken im Vergleich

Das Web basiert seit jeher auf einem einfachen Prinzip: Inhalte verschiedenster Art werden von Webservern bereitgestellt und können via HTTP oder FTP von Clients abgerufen werden. Bei den Clients handelt es sich um die bestens bekannten Browser wie Mozilla Firefox oder Google Chrome, die auf dem System des Users installiert und ausgeführt werden. Webserver wie Apache oder NGINX hingegen sind Bestandteil von Webprojekten, werden in dieser Umgebung auch installiert und ausgeführt und ermöglichen dem jeweiligen Client den Zugriff auf die Inhalte.

Während statische Inhalte wie klassische HTML-Elemente oder Bilder einfach nur übertragen und dargestellt werden, funktionieren dynamische Inhalte wie ein Wiki, ein Drop-down-Menü oder sämtliche Webanwendungen nur mithilfe von Skripten. Diese müssen mit der entsprechenden Skriptsprache ausgeführt und interpretiert werden, was einerseits auf Seiten des Servers, andererseits auf Seiten des Clients geschehen kann. Aus diesem Grund unterscheidet man auch zwischen Server-Side-Scripting und Client-Side-Scripting.

Was ist Server-Side-Scripting?

Server-Side-Scripting ist eine Technik, die bei der Entwicklung von Websites mit dynamischen Elementen und Webanwendungen zum Einsatz kommt. Sie basiert auf der Verwendung von Skripten, die vom Webserver mithilfe der geeigneten Skriptsprachen ausgeführt werden, wenn ein Client die entsprechenden Inhalte anfordert. Aufgabe der Skripte ist es oft, die passenden Daten aus einer Datenbank abzuholen und in das Webprojekt einzubauen. Der Nutzer greift über HTML-Seiten darauf zu, wobei ihm der Quellcode der Skripte komplett verborgen bleibt.

Die Nutzung solcher Server-Side-Scripts setzt voraus, dass der Client fortführend weitere Anfragen an den Webserver sendet, um dem User neue, veränderte Informationen zukommen zu lassen. Das bedeutet einerseits eine starke Auslastung der Server-Kapazitäten, was Einfluss auf die Antwortzeit des Webservers hat, und andererseits, dass eine bestehende Verbindung zum Server für die Nutzung des Webangebots unabdingbar ist.

In den frühen Tagen des World Wide Webs wurde Server-Side-Scripting beinahe ausschließlich vollzogen, indem Entwickler Programme in C sowie Perl- und Kommandozeilen-Skripte schrieben. Diese Anwendungen wurden vom Server-Betriebssystem ausgeführt und interpretiert, woraufhin das Ergebnis vom Webserver über das Common Gateway Interface (CGI) an den zugreifenden Browser übermittelt werden konnte.

Viele moderne Webserver können Skripte mittlerweile auch direkt ausführen, z. B. mithilfe entsprechender Module. Die heute am häufigsten eingesetzte serverseitige Skriptsprache ist die 1995 veröffentlichte und stark an C und Perl angelehnte Internet-ProgrammiersprachePHP. U. a. werden die folgenden Sprachen für Server-Side-Scripts verwendet:

 

ASP.NET

Java

Ruby

Entwickler

Microsoft

Sun Microsystems

Yukihiro Matsumoto u. a.

Lizenz

proprietär

GNU GPL

BSD

Erscheinungsjahr

2002

1995

1995

Plattform

Windows

unabhängig

unabhängig

Programmierparadigmen

objektorientiert

objektorientiert

multiparadigmatisch

 

Perl

PHP

Python

Entwickler

Larry Wall u. a.

Rasmus Lerdorf

Guido van Rossum, Python Software Foundation

Lizenz

GNU GPL und Artistic License

PHP-Lizenz u. a.

Python-Software-Foundation-Lizenz

Erscheinungsjahr

1987

1995

1991

Plattform

unabhängig

unabhängig

unabhängig

Programmierparadigmen

prozedural, modular, teilweise auch objektorientiert

imperativ, funktional, objektorientiert

multiparadigmatisch

Was ist Client-Side-Scripting?

Auch die Technik des Client-Side-Scriptings wird von Webentwicklern dazu verwendet, Projekte mit dynamischen Inhalten zu realisieren. Anders als bei der Server-Side-Variante werden die programmierten Skripte allerdings nicht vom Server, sondern vom zugreifenden Client ausgeführt und verarbeitet. Zu diesem Zweck bettet man die Skripte entweder in das HTML- bzw. XHTML-Dokument ein oder schreibt sie in eine separate Datei, die man mit dem Dokument verknüpft. Ruft der Nutzer nun eine Webseite oder Webanwendung mit einem solchen Client-Side-Script auf, sendet der Webserver das HTML-Dokument sowie das Skript an den Browser, der selbiges ausführt und das Endergebnis präsentiert. Clientseitige Skripte können darüber hinaus konkrete Instruktionen für den Webbrowser beinhalten, wie dieser auf bestimmte Aktionen des Nutzers wie z. B. auf einen Button-Klick reagieren soll. Oftmals muss der Client dazu keinen erneuten Kontakt zum Webserver aufbauen.

Da die Skripte im Browser des Nutzers ausgeführt werden, hat er – anders als bei Server-Side-Scripts – die Möglichkeit, ihren Quellcode einzusehen. Im Gegenzug setzt die Interpretation der Skripte voraus, dass die entsprechende Skriptsprache vom Webbrowser verstanden wird. Da z. B. auch Pop-ups und Webtracking-Tools auf Client-Side-Scripting basieren und die clientseitigen Skripte überdies die Ladezeit beeinflussen, existieren verschiedene Browser-Erweiterungen, die die Skripte blockieren.

Die bedeutendste Client-Side-Skriptsprache ist JavaScript. Sie wurde vom Mozilla-Vorgänger Netscape entwickelt und 1995 mit der Vorversion des Browsers Navigator 2.0 veröffentlicht – damals noch unter dem Namen LiveScript. Sie fand schnell Verbreitung und wurde somit zur universellen Skriptsprache aller relevanten Webbrowser. Mit deutlichen Abstrichen ist außerdem Shockwave Flash (SWF) zu nennen. Die objektorientierte Sprache ist ein wichtiger Bestandteil des Flash-Players von Adobe, der lange Zeit das Maß aller Dinge für Videos im World Wide Web war. Aufgrund diverser Sicherheitslücken und neuer Techniken wie HTML5 finden die ehemals weitverbreiteten Flash-Videos und -Animationen aber immer seltener Verwendung. In den früheren Zeiten des Webs erfreuten sich außerdem auch Microsoft Silverlight und Java-Applets großer Beliebtheit.

Theoretisch könnte auch jede andere Skriptsprache für Client-Side-Scripting genutzt werden, allerdings müssten sich die Entwickler aller relevanten Browser auch dazu entscheiden, diese zu unterstützen. Es gibt jedoch auch Alternativlösungen, die das clientseitige Skripten mit anderen Sprachen ermöglichen. Zu diesem Zweck wird der jeweilige Code mithilfe eines Transpilers wie CoffeeScript oder TypeScript interpretiert und als JavaScript ausgeführt.

Client-Side-Scripting vs. Server-Side-Scripting

Der Ausführungsort der Skripte hat einen erheblichen Einfluss auf die Struktur von Webprojekten. Je mehr Skripte in den Verantwortungsbereich des Browsers übertragen werden, desto „schlanker“ wird die Website bzw. Webanwendung für den Server. Die Serverressourcen werden so erheblich entlastet, es kann aber zu Performance-Einbußen beim zugreifenden Nutzer kommen. Überdies haben Sie als Entwickler mit einer erhöhten Komplexität zu kämpfen, wenn Sie einzig auf clientseitiges JavaScript setzen, da Sie viele Mechaniken leistungsstarker Frameworks wie ASP.NET MVC nachbilden müssen. Zusätzliche Probleme ergeben sich dadurch, dass Sie beim Client-Side-Scripting darauf angewiesen sind, dass der jeweilige Browser die verwendeten Skriptsprachen mit allen Features unterstützt und der User keine blockierenden Erweiterungen nutzt.

Um weder Client noch Server übermäßig zu belasten, sollten Sie auf eine gute Kombination aus Server-Side-Scripting und Client-Side-Scripting setzen und mit zusätzlichen Maßnahmen wie dem Caching statischer Inhalte und modernen Technologien wie AJAX für eine bestmögliche Ladezeit Ihres Webprojekts sorgen. Letztgenanntes Konzept steht für „Asynchronous JavaScript and XML“ und beschreibt die Möglichkeit der asynchronen Datenübertragung zwischen Client und Server. Ohne die Seite komplett neu laden zu müssen, kann der Webserver auf Anfragen und Nutzereingaben fast in Echtzeit reagieren und Daten mit dem Browser austauschen. Das klassische Beispiel für die Umsetzung der AJAX-Technik sind die Google Suggests, also die Suchvorschläge, die automatisch während der Eingabe eines Suchbegriffs in Google erscheinen.


Auf dem Laufenden bleiben?

Jetzt für unseren Newsletter anmelden und gratis Online-Marketing Whitepaper für lokale Anbieter sichern!