Die Webentwicklung (eher die JavaScript-Welt) entwickelt sich schnell. Die Tools, die gestern noch cool waren, benutzt heute niemand mehr (/s). Dieser Abschnitt soll diese Entwicklung mit ihren vielen Begriffen und Abkürzungen kurz und sehr vereinfacht darstellen und in Kontext setzen.

Es kann sein, dass ihr beim Recherchieren und Googlen für eure eigenen Web-Projekte auf einige dieser Begriffe stoßt oder Konzepte erklärt werden, die eng mit einer dieser Arten der Webentwicklung zusammenhängen. Dieser kleine Exkurs soll beim Verstehen helfen.

Jedes hier genannte Tool ist immer noch mehr als brauchbar, egal wie “alt” es ist. Wir wollen lediglich die Trends in der Webentwicklung zeigen.

Gerade die bewährten Frameworks wie Django (Python) eignen sich für Anfänger*innen (und im Rahmen der einwöchigen Programmier-Werkstatt) besser für ein Web-Projekt.

Um 2010: Full-Stack MVC Frameworks

Die Trennung zwischen Backend und Frontend ist nicht immer zu 100% klar. Full-Stack, MVC (Model-View-Controller) Web-Frameworks wie Ruby on Rails (Ruby), Django (Python) und Spring MVC (Java)1 waren um 2010 an der Spitze ihrer Beliebtheit. Das Frontend liegt “nah” am Backend. Bei jedem HTTP-Request wird eine Funktion ausgeführt, die ein paar Daten sammelt oder modifiziert, womit dann ein gerendertes HTML-Dokument zurückgegeben wird. Das HTML-Dokument wird durch HTML-Templates auf dem Server generiert. Diese HTML-Templates (Beispiel anhand von Django) sind spezifisch für das jeweilige Framework. Es sind normale HTML-Dateien mit ein paar extra Funktionen, um Daten aus dem Backend darstellen zu können.

Mit der Zeit wurden Front- und Backend strenger voneinander getrennt. Das Internet wandelte sich von einfachen Webseiten zu komplexen Webanwendungen. Webseiten wurden dynamischer und interaktiver. Der Client (also das Gerät, mit welchem eine Website besucht wird) wurde auch wichtiger.

Ab Anfang 2010er: Client-Side Rendering & Single-Page Applications

Bisher hat der Client nur das HTML und CSS, was vom Server kam, gerendert. Mit der Einführung von Client-side JavaScript Frameworks änderte sich das. Der Server schickt beim ersten Besuch einer Website nicht nur HTML und CSS, sondern ein ganzes JavaScript Programm, was dann vom Browser ausgeführt wird. Dieses kleine JavaScript Programm in deinem Browser spielt dann eine Art “Zwischen-Server”. Wenn du auf einen Button oder Link innerhalb einer Website klickst, die ein solches Client-side JavaScript Framework benutzt, wird nicht zwingend ein HTTP-Request an den Server geschickt, sondern es wird erstmal nur weiterer JavaScript Code (der schon in deinem Browser lebt) ausgeführt. Dieser Code entscheidet dann, ob ein HTTP-Request an den Server gebraucht wird. Falls ja, schickt der Server als Antwort dann meist kein komplettes HTML-Dokument zurück, sondern nur ein Schnipsel von Daten, welches das kleine JavaScript Programm in deinem Browser dann irgendwie anzeigt oder modifiziert.

Dieser Umbruch von Server-side Rendering zu Client-side Rendering kam Anfang der 2010er Jahre. Mit dem Client-Side Rendering spart man sich beim Hin- und Herklicken auf einer Website viele HTTP-Requests (weil das kleine JavaScript Programm bereits die ganze Webanwendung enthält) und damit Wartezeit. Außerdem wurde der Ort, wo die Webseite gerendert wurde, vom Rechenzentrum auf das einzelne Endgerät geschoben, was den Betreiber*innen von Webseiten etwas Rechenleistung spart.

Auf Server-Seite wurden APIs, insbesondere REST-APIs, beliebter. Anstelle von einer großen Full-Stack Anwendung (Ruby on Rails, Djano, Spring), wurden kleine REST-API Microservices (z.B. FastAPI & Flask für Python, ExpressJS für NodeJS) cooler. Der Server musste nur noch Daten (meist in Form von JSON) schicken und nicht mehr auch noch das ganze HTML-Dokument drumherum.

AngularJS kam 2010 auf den Markt und war eins der ersten dieser Client-side JavaScript Frameworks.

2013: React

React, das bisher populärste dieser Client-side JavaScript Frameworks, erschien 2013. React beschreibt sich als Bibliothek zum Erstellen von User-Interfaces. Es ist deklarativ (anstelle von imperativ). Man beschreibt wie ein User-Interface aussieht. Die Schritte und Übergänge, die geschehen müssen, um zwischen verschiedenen User-Interfaces oder Zustände eines User-Interfaces umzuschalten, denkt sich React für dich aus.2

Vue kam dann 2014, ähnlich zu React. 2016 wurde Svelte veröffentlicht. Irgendwann hat sich React dazu entschieden, nicht mehr Framework heißen zu wollen, sondern Bibliothek. Heißt, nur mit React lässt sich keine vollständige Webanwendung entwickeln. Man braucht weitere kleinere Tools, bspw. um das Hin- und Herklicken zwischen Links zu ermöglichen (react-router). Dadurch wurden große JavaScript Frameworks, die auf React (oder Vue/Svelte) basieren und diese ganzen Tools bereits enthalten, beliebter.

Heute: Fullstack mit JavaScript

Fullstack ist wieder cool, aber diesmal beide Seiten in JavaScript. Next.js (basiert auf React) ist eins dieser großen JavaScript Frameworks, die auch Fullstack können. Mit Next.js wird die Trennung zwischen Front- und Backend wieder schwammiger. Ein Teil von Next.js muss wieder auf einem Server laufen. Es wird zwar immer noch ein kleines JavaScript Programm beim ersten Besuch einer Website auf den Client heruntergeladen, einige Seiten werden aber wieder vom Server vor-gerendert. Meistens für Zwecke der Suchmaschinenoptimierung (SEO), also wie hoch man in der Google-Suche angezeigt wird. Server-Side Rendering ist zum Teil also auch wieder cool. Remix.run soll das coolere Next.js sein.

Vorsicht

Immer den neusten Sachen hinterherzurennen ist nicht Sinn der Sache. Alle genannten Tools haben sich selbstverständlich parallel zu den Trends weiterentwickelt.

Django hat beispielsweise ein beliebtes REST-Plugin (Django REST framework), womit man mithilfe der Vielzahl an beinhalteten Funktionen von Django eine “leichte” REST-API bauen kann, die dann von den coolen JavaScript Frameworks konsumiert werden kann. Auch für die starren HTML-Templates, die von den coolen, interaktiven und dynamischen JavaScript Client-Frameworks “abgelöst” wurden, hat man sich was ausgedacht. Mit dem gehypten htmx (django-htmx) lassen sich UIs so interaktiv wie mit React gestalten, und dass direkt im HTML und ganz ohne JavaScript, was man selber schreiben muss!

Auch Ruby on Rails hat es einfacher gemacht, React und Co. zu integrieren. Und eigene Alternativen, die die gleiche Geschwindigkeit und Interaktiviät von Single-Page Applications á la React haben sollen, werden mitgeliefert (Turbo).

Was sollte man also benutzen? Das ist natürlich ganz dir überlassen. Schau dir ein paar Sachen an und lerne das, worauf du Lust hast. In der Programmier-Werkstatt empfehlen wir, bei den Java & Python Frameworks zu bleiben. Gerade bei kleinen Projekten kann man aber die gleiche Idee mal in unterschiedlichen Frameworks implementieren, um die Unterschiede wirklich zu verstehen. Letzendlich sind die Werkzeuge weniger wichtig, als man im ersten Moment denkt.

Fußnoten

  1. Spring ist immer noch sehr verbreitet, vor allem im Enterprise Bereich. In dem Abschnitt geht es lediglich darum, welche Tools man als “cooler” (Solo-)Webentwickler, der mit der Zeit geht, verwendet. ↩

  2. Warum React’s Art, UIs zu bauen, Vorteile gegenüber Vanilla-JS (also nur HTML und JavaScript ohne jeglichen Frameworks) hat(te): Abschnitt ab “Why do frameworks exist?” ↩