Dieser Inhalt wurde automatisch aus dem Englischen übersetzt, und kann Fehler enthalten. Erfahre mehr über dieses Experiment.

View in English Always switch to English

Einführung in clientseitige Frameworks

Wir beginnen unsere Betrachtung von Frameworks mit einem allgemeinen Überblick: einer kurzen Geschichte von JavaScript und Frameworks, den Gründen für die Entstehung von Frameworks und ihrem Nutzen, Überlegungen zur Auswahl eines Frameworks zum Lernen sowie Alternativen zu clientseitigen Frameworks.

Voraussetzungen: Vertrautheit mit den Grundlagen von HTML, CSS und JavaScript.
Lernziele:
  • Was Code von Drittanbietern ist und wie clientseitige JavaScript-Frameworks entstanden sind.
  • Welche Probleme Frameworks lösen, welche Alternativen es gibt und wie Sie ein Framework auswählen können.
  • Der Unterschied zwischen Bibliotheken und Frameworks.
  • Wann Frameworks eingesetzt werden sollten und wann nicht.

Die Entstehung von Bibliotheken und Frameworks

Als JavaScript 1996 aufkam, brachte es gelegentliche Interaktivität und Abwechslung in ein Web, das bis dahin aus statischen Dokumenten bestand. Das Web wurde nicht nur zu einem Ort, an dem man Dinge lesen, sondern auch Dinge tun konnte. Die Beliebtheit von JavaScript nahm stetig zu. Entwickler, die mit JavaScript arbeiteten, schrieben Werkzeuge zur Lösung ihrer Probleme und bündelten sie zu wiederverwendbaren Paketen, sogenannten Bibliotheken, um ihre Lösungen mit anderen zu teilen. Dieses gemeinsame Ökosystem aus Bibliotheken prägte die Entwicklung des Webs und führte schließlich zu Frameworks.

Ein Framework ist eine Bibliothek, die Vorgaben dazu macht, wie Software entwickelt wird. Diese Vorgaben sorgen innerhalb einer Anwendung für Vorhersehbarkeit und Einheitlichkeit. Vorhersehbarkeit ermöglicht es, Software auf einen enormen Umfang zu skalieren und dennoch wartbar zu halten. Vorhersehbarkeit und Wartbarkeit sind entscheidend für den langfristigen Zustand und die Lebensdauer von Software. Mit modernen JavaScript-Frameworks ist es wesentlich einfacher geworden, hochdynamische, interaktive Anwendungen zu entwickeln.

JavaScript-Frameworks bilden die Grundlage für viele der beeindruckenden Anwendungen im heutigen Web – darunter zahlreiche Websites, die Sie vermutlich täglich nutzen.

Welche Frameworks gibt es?

Es gibt viele Frameworks. Derzeit gelten jedoch die folgenden vier als die „großen Vier“.

Ember

Ember wurde erstmals im Dezember 2011 veröffentlicht und führte Arbeiten aus dem Projekt SproutCore fort. Es ist ein älteres Framework mit weniger Nutzern als modernere Alternativen wie React und Vue. Dank seiner Stabilität, der Unterstützung durch die Community und einiger durchdachter Programmierprinzipien ist es dennoch recht beliebt.

Angular

Angular ist ein Open-Source-Framework für Webanwendungen, das vom Angular-Team bei Google sowie von einer Community aus Einzelpersonen und Unternehmen entwickelt wird. Es ist eine vollständige Neufassung von AngularJS durch dasselbe Team. Angular wurde offiziell am 14. September 2016 veröffentlicht.

Angular ist ein komponentenbasiertes Framework, das deklarative HTML-Templates verwendet. Beim Build übersetzt der Compiler des Frameworks die Templates für Entwickler transparent in optimierte JavaScript-Anweisungen. Angular verwendet TypeScript, eine Obermenge von JavaScript, die wir im nächsten Kapitel etwas genauer betrachten.

Vue

Nachdem Evan You am ursprünglichen Projekt AngularJS gearbeitet und daraus gelernt hatte, veröffentlichte er 2014 Vue. Vue ist das jüngste der großen Vier, hat aber in jüngerer Zeit deutlich an Beliebtheit gewonnen.

Wie Angular erweitert Vue HTML um eigenen Code. Darüber hinaus stützt es sich hauptsächlich auf modernes Standard-JavaScript.

React

Facebook veröffentlichte React im Jahr 2013. Zu diesem Zeitpunkt hatte das Unternehmen React bereits intern eingesetzt, um viele seiner Probleme zu lösen. Genau genommen ist React selbst kein Framework, sondern eine Bibliothek zum Rendern von UI-Komponenten. React wird zusammen mit anderen Bibliotheken verwendet, um Anwendungen zu erstellen: Mit React und React Native können Entwickler mobile Anwendungen erstellen, mit React und ReactDOM Webanwendungen und so weiter.

Da React und ReactDOM so häufig gemeinsam verwendet werden, gilt React umgangssprachlich als JavaScript-Framework. In diesem Modul verwenden wir den Begriff ebenfalls in diesem Sinn.

React erweitert JavaScript um eine HTML-ähnliche Syntax namens JSX.

Warum gibt es Frameworks?

Wir haben das Umfeld besprochen, das zur Entstehung von Frameworks geführt hat, aber noch nicht wirklich, warum Entwickler sie für nötig hielten. Um das zu verstehen, müssen wir zunächst die Herausforderungen der Softwareentwicklung betrachten.

Nehmen wir eine häufige Art von Anwendung: eine To-do-Liste. In späteren Kapiteln werden wir ihre Umsetzung mit verschiedenen Frameworks betrachten. Die Anwendung soll es Nutzern ermöglichen, eine Aufgabenliste anzuzeigen, neue Aufgaben hinzuzufügen und Aufgaben zu löschen. Gleichzeitig muss sie die zugrunde liegenden Daten zuverlässig verwalten und aktualisieren. In der Softwareentwicklung werden diese zugrunde liegenden Daten als Zustand bezeichnet.

Jedes dieser Ziele ist für sich genommen theoretisch einfach. Wir können die Daten durchlaufen, um sie darzustellen; wir können einem Objekt etwas hinzufügen, um eine neue Aufgabe anzulegen; und wir können eine Kennung verwenden, um eine Aufgabe zu finden, zu bearbeiten oder zu löschen. Wenn wir jedoch bedenken, dass die Anwendung Nutzern all dies über den Browser ermöglichen muss, werden erste Schwierigkeiten sichtbar. Das eigentliche Problem ist: Jedes Mal, wenn wir den Zustand unserer Anwendung ändern, müssen wir die Benutzeroberfläche entsprechend aktualisieren.

Wie schwierig das ist, können wir anhand von nur einer Funktion unserer To-do-Listen-App untersuchen: dem Anzeigen einer Aufgabenliste.

Der Umfang von DOM-Änderungen

HTML-Elemente zu erstellen und sie zum richtigen Zeitpunkt im Browser darzustellen, erfordert überraschend viel Code. Nehmen wir an, unser Zustand besteht aus einem Schlüssel-Wert-Speicher mit taskName (gesteuert durch das Texteingabefeld) und der Liste tasks:

js
const state = {
  taskName: "",
  tasks: [
    {
      id: "todo-0",
      name: "Learn some frameworks!",
    },
  ],
};

Wie zeigen wir unseren Nutzern eine dieser Aufgaben? Jede Aufgabe soll als Listeneintrag dargestellt werden – als HTML-Element <li> innerhalb einer ungeordneten Liste (einem <ul>-Element). Wie erstellen wir ihn? Das könnte etwa so aussehen:

js
function buildTodoItemEl(id, name) {
  const item = document.createElement("li");
  const span = document.createElement("span");

  span.textContent = name;

  item.id = id;
  item.appendChild(span);
  item.appendChild(buildDeleteButtonEl(id));

  return item;
}

Hier verwenden wir die Methode document.createElement(), um unser <li> zu erstellen. Für seine benötigten Eigenschaften und Kindelemente sind mehrere weitere Codezeilen nötig.

Der vorherige Codeausschnitt verweist auf eine weitere Funktion zum Erstellen eines Elements: buildDeleteButtonEl(). Sie folgt einem ähnlichen Muster wie die Funktion, mit der wir den Listeneintrag erstellt haben:

js
function buildDeleteButtonEl(id) {
  const button = document.createElement("button");
  button.setAttribute("type", "button");
  button.addEventListener("click", () => {
    state.tasks = state.tasks.filter((t) => t.id !== id);
    renderTodoList();
  });
  button.textContent = "Delete";

  return button;
}

Bemerkenswert ist, dass wir bei jeder Aktualisierung des Zustands renderTodoList manuell aufrufen müssen, damit die Anzeige mit dem Zustand synchronisiert wird. Der Code, der unsere Einträge auf der Seite darstellt, könnte etwa so aussehen:

js
function renderTodoList() {
  const frag = document.createDocumentFragment();
  state.tasks.forEach((task) => {
    const item = buildTodoItemEl(task.id, task.name);
    frag.appendChild(item);
  });

  while (todoListEl.lastChild) {
    todoListEl.removeChild(todoListEl.lastChild);
  }
  todoListEl.appendChild(frag);
}

Damit haben wir fast dreißig Codezeilen, die nur der Benutzeroberfläche dienen – nur dazu, etwas im DOM darzustellen. Und dabei haben wir noch nicht einmal Klassen hinzugefügt, mit denen wir unsere Listeneinträge später gestalten könnten!

Falls Sie neugierig sind: Unten finden Sie eine vollständig lauffähige Demo. Klicken Sie auf „Play“, um den Quellcode im Playground anzusehen.

Die direkte Arbeit mit dem DOM wie in diesem Beispiel setzt voraus, dass Sie vieles über seine Funktionsweise wissen: wie Elemente erstellt werden, wie ihre Eigenschaften geändert werden, wie Elemente ineinander eingefügt werden und wie sie auf die Seite gelangen. Nichts von diesem Code verarbeitet bereits Nutzerinteraktionen oder kümmert sich darum, Aufgaben hinzuzufügen oder zu löschen. Wenn wir diese Funktionen ergänzen, müssen wir daran denken, die Benutzeroberfläche zum richtigen Zeitpunkt und auf die richtige Weise zu aktualisieren.

JavaScript-Frameworks wurden entwickelt, um solche Arbeiten erheblich zu erleichtern – sie sollen eine bessere Entwicklungserfahrung bieten. Sie verleihen JavaScript keine völlig neuen Fähigkeiten, sondern machen seine vorhandenen Fähigkeiten leichter zugänglich, damit Sie Anwendungen für das heutige Web entwickeln können.

Weitere Informationen zu den in diesem Abschnitt verwendeten JavaScript-Funktionen:

Eine andere Art, Benutzeroberflächen zu erstellen

Jedes JavaScript-Framework bietet eine Möglichkeit, Benutzeroberflächen deklarativer zu beschreiben. Das bedeutet, Sie schreiben Code, der festlegt, wie Ihre Benutzeroberfläche aussehen soll, und das Framework setzt dies im Hintergrund im DOM um.

Der Ansatz, neue DOM-Elemente wiederholt mit reinem JavaScript zu erstellen, war auf den ersten Blick schwer zu verstehen. Im Gegensatz dazu zeigt der folgende Codeblock, wie Sie unsere Aufgabenliste mit Vue beschreiben könnten:

html
<ul>
  <li v-for="task in tasks" v-bind:key="task.id">
    <span>{{task.name}}</span>
    <button type="button">Delete</button>
  </li>
</ul>

Das ist alles. Dieser Codeausschnitt reduziert fast dreißig Codezeilen auf sechs. Falls Ihnen die geschweiften Klammern und die v--Attribute hier nicht vertraut sind, ist das kein Problem: Die Vue-spezifische Syntax lernen Sie später in diesem Modul kennen. Entscheidend ist hier, dass dieser Code der Benutzeroberfläche ähnelt, die er darstellt – anders als der Code in reinem JavaScript.

Dank Vue mussten wir keine eigenen Funktionen zum Aufbau der Benutzeroberfläche schreiben. Das Framework übernimmt dies auf optimierte, effiziente Weise. Unsere einzige Aufgabe bestand darin, Vue zu beschreiben, wie jeder Eintrag aussehen soll. Entwickler, die mit Vue vertraut sind, können sich beim Einstieg in unser Projekt schnell zurechtfinden. Das gilt nicht nur für Vue: Ein Framework kann die Effizienz sowohl einzelner Entwickler als auch ganzer Teams steigern.

Ähnliches lässt sich auch mit reinem JavaScript erreichen. Template-Literale erleichtern es, HTML-Zeichenfolgen zu schreiben, die das fertige Element darstellen. Für eine so einfache Anwendung wie unsere To-do-Liste kann das sinnvoll sein. Bei großen Anwendungen, die Tausende von Datensätzen verwalten und möglicherweise ebenso viele unterschiedliche Elemente in einer Benutzeroberfläche darstellen, ist dieser Ansatz jedoch nicht wartbar.

Weitere Vorteile von Frameworks

Sehen wir uns einige weitere Vorteile von Frameworks an. Wie bereits angedeutet, lassen sich diese Vorteile auch mit reinem JavaScript erzielen. Ein Framework nimmt Ihnen jedoch die Denkarbeit ab, die nötig wäre, um diese Probleme selbst zu lösen.

Werkzeuge

Da jedes der Frameworks in diesem Modul eine große, aktive Community hat, bietet das jeweilige Ökosystem Werkzeuge, die die Entwicklung erleichtern. Mit diesen Werkzeugen lassen sich beispielsweise Tests hinzufügen (um sicherzustellen, dass sich Ihre Anwendung wie erwartet verhält) oder Linting einsetzen (um Fehlerfreiheit und einen einheitlichen Codestil zu fördern).

Hinweis: Wenn Sie mehr über Werkzeuge für die Webentwicklung erfahren möchten, lesen Sie unseren Überblick über clientseitige Werkzeuge.

Aufteilung in Komponenten

Die meisten großen Frameworks ermutigen Entwickler, die verschiedenen Teile ihrer Benutzeroberflächen in Komponenten aufzuteilen – wartbare, wiederverwendbare Codeeinheiten, die miteinander kommunizieren können. Der gesamte Code für eine bestimmte Komponente kann in einer Datei (oder einigen wenigen festgelegten Dateien) liegen. So wissen Sie als Entwickler genau, wo Sie Änderungen an dieser Komponente vornehmen müssen. In einer Anwendung mit reinem JavaScript müssten Sie selbst Regeln festlegen, um das effizient und skalierbar zu erreichen. Ohne solche Regeln könnte es vielen JavaScript-Entwicklern passieren, dass der Code für einen Teil der Benutzeroberfläche über eine ganze Datei verstreut ist – oder sich sogar in einer ganz anderen Datei befindet.

Routing

Die wichtigste Eigenschaft des Webs ist, dass Nutzer von einer Seite zur nächsten navigieren können – schließlich ist es ein Netz miteinander verknüpfter Dokumente. Wenn Sie auf dieser Website einem Link folgen, kommuniziert Ihr Browser mit einem Server und lädt neue Inhalte zur Anzeige. Dabei ändert sich die URL in Ihrer Adressleiste. Sie können die neue URL speichern und später zur Seite zurückkehren oder sie mit anderen teilen, damit diese dieselbe Seite leicht finden. Ihr Browser merkt sich außerdem Ihren Navigationsverlauf, sodass Sie vor- und zurücknavigieren können. Dies wird als serverseitiges Routing bezeichnet.

Moderne Webanwendungen laden und rendern üblicherweise keine neuen HTML-Dateien. Stattdessen laden sie ein einzelnes HTML-Grundgerüst und aktualisieren fortlaufend das darin enthaltene DOM, ohne Nutzer zu neuen Webadressen zu führen. Solche Anwendungen heißen Single-Page-Apps oder SPAs. Jede neue, einer Webseite ähnliche Ansicht wird gewöhnlich als View bezeichnet. Standardmäßig findet dabei kein Routing statt.

Wenn eine SPA komplex genug ist und genügend unterschiedliche Views darstellt, ist eine Routing-Funktion wichtig. Nutzer sind daran gewöhnt, auf bestimmte Seiten einer Anwendung verlinken und in ihrem Navigationsverlauf vor- und zurückgehen zu können. Wenn diese üblichen Webfunktionen nicht funktionieren, leidet die Nutzererfahrung. Wird das Routing auf diese Weise von einer clientseitigen Anwendung übernommen, heißt es clientseitiges Routing.

Mit den nativen Fähigkeiten von JavaScript und des Browsers lässt sich durchaus ein Router erstellen. Beliebte, aktiv weiterentwickelte Frameworks bieten jedoch ergänzende Bibliotheken, die Routing zu einem intuitiveren Teil des Entwicklungsprozesses machen.

Was Sie beim Einsatz von Frameworks bedenken sollten

Effektive Webentwicklung bedeutet, die am besten geeigneten Werkzeuge für die jeweilige Aufgabe einzusetzen. JavaScript-Frameworks erleichtern die Entwicklung von Frontend-Anwendungen, sind aber kein Allheilmittel. In diesem Abschnitt behandeln wir einige Punkte, die Sie bei ihrer Verwendung bedenken sollten. Möglicherweise benötigen Sie überhaupt kein Framework – setzen Sie keines nur um seiner selbst willen ein.

Vertrautheit mit dem Werkzeug

Wie reines JavaScript erfordern auch Frameworks Einarbeitungszeit und haben ihre Eigenheiten. Bevor Sie sich für ein Framework in einem Projekt entscheiden, sollten Sie sicherstellen, dass Sie genügend Zeit haben, seine Funktionen so weit kennenzulernen, dass es Ihnen nützt, statt Sie zu behindern. Auch Ihre Teammitglieder sollten sich mit dem Framework wohlfühlen.

Überdimensionierte Lösungen

Wenn Ihr Webentwicklungsprojekt ein persönliches Portfolio mit wenigen Seiten ist und diese Seiten kaum oder gar nicht interaktiv sind, benötigen Sie möglicherweise weder ein Framework noch das damit verbundene JavaScript. Frameworks sind allerdings nicht alle gleich umfangreich; manche eignen sich besser für kleine Projekte als andere. In einem Artikel für das Smashing Magazine beschreibt Sarah Drasner, wie Vue jQuery ersetzen kann, wenn nur kleine Teile einer Webseite interaktiv werden sollen.

Größere Codebasis und Abstraktion

Frameworks ermöglichen es Ihnen, deklarativeren Code zu schreiben – und mitunter insgesamt weniger Code –, indem sie die Interaktionen mit dem DOM im Hintergrund übernehmen. Diese Abstraktion verbessert die Entwicklungserfahrung, hat aber ihren Preis. Um Ihren Code in DOM-Änderungen umzusetzen, müssen Frameworks eigenen Code ausführen. Dadurch wird die fertige Anwendung größer und ihre Ausführung rechenintensiver.

Ein gewisser zusätzlicher Code ist unvermeidlich. Ein Framework, das Tree-Shaking unterstützt – also beim Build ungenutzten Code entfernt –, hilft Ihnen, Ihre Anwendungen klein zu halten. Dennoch müssen Sie diesen Faktor berücksichtigen, wenn Sie die Leistung Ihrer Anwendung beurteilen, insbesondere auf Geräten mit begrenzter Netzwerkbandbreite oder Speicherkapazität, etwa Mobiltelefonen.

Die Abstraktion durch Frameworks beeinflusst nicht nur Ihr JavaScript, sondern auch Ihren Umgang mit den Grundlagen des Webs. Unabhängig davon, wie Sie für das Web entwickeln: Das Endergebnis, mit dem Ihre Nutzer letztlich interagieren, ist HTML. Wenn Sie Ihre gesamte Anwendung in JavaScript schreiben, können Sie HTML und den Zweck seiner verschiedenen Tags aus den Augen verlieren. Das kann zu einem HTML-Dokument führen, dem Semantik und Barrierefreiheit fehlen. Es ist sogar möglich, eine anfällige Anwendung zu schreiben, die vollständig von JavaScript abhängt und ohne JavaScript nicht funktioniert.

Frameworks sind nicht die Ursache dieser Probleme. Mit falschen Prioritäten kann jede Anwendung anfällig, aufgebläht und unzugänglich werden. Frameworks verstärken allerdings unsere Prioritäten als Entwickler. Wenn Ihre Priorität darin besteht, eine komplexe Webanwendung zu erstellen, geht das damit leicht. Wenn Sie jedoch nicht ebenso sorgfältig auf Leistung und Barrierefreiheit achten, verstärken Frameworks auch die Anfälligkeit, den Umfang und die mangelnde Zugänglichkeit Ihrer Anwendung. Moderne Entwicklungsprioritäten, durch Frameworks verstärkt, haben die Struktur des Webs an vielen Stellen auf den Kopf gestellt. Statt eines robusten Netzwerks von Dokumenten, bei dem Inhalte im Vordergrund stehen, stellt das Web heute oft JavaScript an die erste und die Nutzererfahrung an die letzte Stelle.

Barrierefreiheit in einem von Frameworks geprägten Web

Knüpfen wir an den vorherigen Abschnitt an und betrachten wir die Barrierefreiheit etwas genauer. Barrierefreie Benutzeroberflächen erfordern immer Überlegung und Aufwand, und Frameworks können diesen Prozess erschweren. Häufig müssen Sie fortgeschrittene Framework-APIs verwenden, um auf native Browserfunktionen wie ARIA-Live-Regionen oder die Fokusverwaltung zuzugreifen.

In manchen Fällen schaffen Framework-Anwendungen Barrieren, die bei herkömmlichen Websites nicht bestehen. Das deutlichste Beispiel dafür ist das bereits erwähnte clientseitige Routing.

Bei herkömmlichem (serverseitigem) Routing hat die Navigation im Web vorhersehbare Ergebnisse. Der Browser setzt den Fokus an den Anfang der Seite, und assistive Technologien geben den Seitentitel bekannt. Das geschieht jedes Mal, wenn Sie zu einer neuen Seite navigieren.

Beim clientseitigen Routing lädt Ihr Browser keine neuen Webseiten. Deshalb weiß er nicht, dass er den Fokus automatisch anpassen oder einen neuen Seitentitel bekannt geben sollte. Die Entwickler von Frameworks haben sehr viel Zeit und Arbeit in JavaScript investiert, das diese Funktionen nachbildet. Dennoch gelingt dies keinem Framework vollständig.

Daraus folgt, dass Sie die Barrierefreiheit von Anfang an bei jedem Webprojekt berücksichtigen sollten. Bedenken Sie aber auch, dass abstrahierte Codebasen mit Frameworks eher schwerwiegende Probleme mit der Barrierefreiheit entwickeln können, wenn Sie nicht darauf achten.

So wählen Sie ein Framework aus

Jedes der in diesem Modul behandelten Frameworks verfolgt bei der Entwicklung von Webanwendungen einen anderen Ansatz. Jedes wird regelmäßig verbessert oder verändert und hat eigene Vor- und Nachteile. Welches Framework das richtige ist, hängt vom Team und vom Projekt ab. Sie sollten selbst recherchieren, was Ihren Anforderungen entspricht. Die folgenden Fragen können Ihnen dabei helfen, Ihre Möglichkeiten gezielter zu untersuchen:

  1. Welche Browser unterstützt das Framework?
  2. Welche domänenspezifischen Sprachen verwendet das Framework?
  3. Gibt es eine aktive Community, gute Dokumentation und weitere Unterstützung für das Framework?

Die Tabelle in diesem Abschnitt gibt einen schnellen Überblick über die aktuelle Browser-Unterstützung der einzelnen Frameworks und die domänenspezifischen Sprachen, mit denen sie verwendet werden können.

Im Allgemeinen sind domänenspezifische Sprachen (DSLs) Programmiersprachen, die für bestimmte Bereiche der Softwareentwicklung relevant sind. Im Zusammenhang mit Frameworks handelt es sich bei DSLs um Varianten von JavaScript oder HTML, die die Entwicklung mit dem jeweiligen Framework erleichtern. Wichtig ist: Keines der Frameworks verlangt von Entwicklern, eine bestimmte DSL zu verwenden. Fast alle wurden jedoch mit Blick auf eine bestimmte DSL entwickelt. Wenn Sie auf die bevorzugte DSL eines Frameworks verzichten, entgehen Ihnen Funktionen, die Ihre Entwicklung sonst erleichtern würden.

Wenn Sie ein Framework für ein neues Projekt auswählen, sollten Sie dessen Browser-Unterstützung und DSLs sorgfältig prüfen. Eine unpassende Browser-Unterstützung kann für Ihre Nutzer zum Hindernis werden; eine unpassende DSL-Unterstützung für Sie und Ihr Team.

Framework Browser-Unterstützung Bevorzugte DSL Unterstützte DSLs Quelle
Angular Moderne Browser TypeScript HTML-basiert; TypeScript offizielle Dokumentation
React Moderne Browser JSX JSX; TypeScript offizielle Dokumentation
Vue Moderne Browser (IE9+ in Vue 2) HTML-basiert HTML-basiert, JSX, Pug offizielle Dokumentation
Ember Moderne Browser (IE9+ in Ember 2.18) Handlebars Handlebars, TypeScript offizielle Dokumentation

Hinweis: Die DSLs, die wir als „HTML-basiert“ bezeichnen, haben keine offiziellen Namen. Streng genommen sind sie keine echten DSLs. Da es sich jedoch um nicht standardisiertes HTML handelt, halten wir es für sinnvoll, sie hervorzuheben.

Hat das Framework eine starke Community?

Das ist möglicherweise am schwierigsten zu beurteilen, da sich die Stärke einer Community nicht unmittelbar an leicht verfügbaren Zahlen ablesen lässt. Die Anzahl der GitHub-Sterne oder die wöchentlichen npm-Downloads eines Projekts können einen Eindruck von seiner Beliebtheit vermitteln. Manchmal hilft es aber am meisten, in einigen Foren zu suchen oder mit anderen Entwicklern zu sprechen. Entscheidend ist nicht nur die Größe der Community, sondern auch, wie offen und einladend sie ist und wie gut die verfügbare Dokumentation ist.

Meinungen aus dem Web

Verlassen Sie sich dabei nicht allein auf unsere Einschätzung – im Web gibt es zahlreiche Diskussionen. Die Wikimedia Foundation hat sich kürzlich entschieden, Vue für ihr Frontend zu verwenden, und dazu eine Bitte um Stellungnahmen (RFC) zur Einführung eines Frameworks veröffentlicht. Eric Gardner, der Autor des RFC, erläutert darin die Anforderungen des Wikimedia-Projekts und warum bestimmte Frameworks für das Team geeignet waren. Dieser RFC ist ein gutes Beispiel dafür, welche Recherchen Sie selbst anstellen sollten, wenn Sie den Einsatz eines Frontend-Frameworks planen.

Die State-of-JavaScript-Umfrage ist eine hilfreiche Sammlung von Rückmeldungen von JavaScript-Entwicklern. Sie behandelt viele Themen rund um JavaScript, darunter die Nutzung von Frameworks und die Einstellung der Entwickler zu ihnen. Mittlerweile liegen Daten aus mehreren Jahren vor, anhand derer Sie die Beliebtheit eines Frameworks einschätzen können.

Das Vue-Team hat Vue ausführlich mit anderen beliebten Frameworks verglichen. Dieser Vergleich ist möglicherweise nicht ganz unvoreingenommen – worauf das Team selbst hinweist –, aber dennoch eine wertvolle Informationsquelle.

Alternativen zu clientseitigen Frameworks

Wenn Sie nach Werkzeugen suchen, die die Webentwicklung beschleunigen, und wissen, dass Ihr Projekt kein umfangreiches clientseitiges JavaScript benötigt, kommen einige andere Lösungen infrage:

  • Ein Content-Management-System
  • Serverseitiges Rendering
  • Ein Generator für statische Websites

Content-Management-Systeme

Content-Management-Systeme (CMS) sind Werkzeuge, mit denen Nutzer Inhalte für das Web erstellen können, ohne selbst unmittelbar Code zu schreiben. Sie eignen sich gut für große Projekte, insbesondere wenn Autoren mit begrenzten Programmierkenntnissen Inhalte beitragen sollen oder Programmierer Zeit sparen möchten. Die Einrichtung kann allerdings erheblichen Zeitaufwand erfordern. Außerdem geben Sie bei der Verwendung eines CMS zumindest einen Teil der Kontrolle über die endgültige Ausgabe Ihrer Website ab. Wenn das gewählte CMS beispielsweise standardmäßig keine barrierefreien Inhalte erzeugt, lässt sich das oft nur schwer verbessern.

Zu den beliebten CMS gehören WordPress, Joomla und Drupal.

Serverseitiges Rendering

Serverseitiges Rendering (SSR) ist eine Anwendungsarchitektur, bei der es Aufgabe des Servers ist, eine Single-Page-App zu rendern. Das Gegenteil ist das clientseitige Rendering, die häufigste und einfachste Art, eine JavaScript-Anwendung zu erstellen. Serverseitiges Rendering entlastet das Gerät des Nutzers, da ihm nur eine bereits gerenderte HTML-Datei gesendet wird. Im Vergleich zu einer clientseitig gerenderten Anwendung kann die Einrichtung jedoch schwieriger sein.

Alle in diesem Modul behandelten Frameworks unterstützen sowohl serverseitiges als auch clientseitiges Rendering. Sehen Sie sich Next.js für React, Nuxt für Vue (ja, die Namen sind verwirrend, und nein, die Projekte hängen nicht zusammen!), FastBoot für Ember und Angular Universal für Angular an.

Hinweis: Einige SSR-Lösungen werden von der Community entwickelt und gepflegt, während andere „offizielle“ Lösungen der Verantwortlichen für das jeweilige Framework sind.

Generatoren für statische Websites

Generatoren für statische Websites sind Programme, die alle Webseiten einer mehrseitigen Website dynamisch erzeugen – einschließlich des benötigten CSS und JavaScript –, damit sie an beliebig vielen Orten veröffentlicht werden können. Als Hosting-Plattform kommen beispielsweise ein GitHub-Pages-Branch, eine Netlify-Instanz oder ein privater Server Ihrer Wahl infrage. Dieser Ansatz hat mehrere Vorteile, vor allem bei Leistung (das Gerät des Nutzers muss die Seite nicht erst mit JavaScript aufbauen; sie ist bereits fertig) und Sicherheit (statische Seiten bieten weniger Angriffsflächen). Solche Websites können JavaScript weiterhin dort einsetzen, wo es nötig ist, sind aber nicht davon abhängig. Wie bei jedem anderen Werkzeug kostet es Zeit, den Umgang mit Generatoren für statische Websites zu erlernen, was Ihren Entwicklungsprozess zunächst bremsen kann.

Statische Websites können so wenige oder so viele unterschiedliche Seiten haben, wie Sie möchten. So wie Frameworks die schnelle Entwicklung clientseitiger JavaScript-Anwendungen ermöglichen, erlauben Generatoren für statische Websites die schnelle Erstellung von HTML-Dateien, die Sie sonst einzeln schreiben müssten. Ähnlich wie Frameworks ermöglichen sie Entwicklern, Komponenten für wiederkehrende Teile ihrer Webseiten zu schreiben und diese zu einer fertigen Seite zusammenzusetzen. Bei Generatoren für statische Websites heißen diese Komponenten Templates. Webseiten, die mit solchen Generatoren erstellt wurden, können sogar Framework-Anwendungen enthalten: Wenn beispielsweise beim Besuch einer bestimmten Seite Ihrer statisch generierten Website eine React-Anwendung gestartet werden soll, ist das möglich.

Generatoren für statische Websites gibt es schon seit Langem, und sie werden ständig optimiert und weiterentwickelt. Zur Auswahl stehen unter anderem Astro, Eleventy, Hugo, Jekyll und Gatsby. Sie bauen auf unterschiedlichen Technologie-Stacks auf und bieten jeweils eigene Funktionen. Andere Möglichkeiten wie Docusaurus und VitePress verwenden statt Templates clientseitige Frameworks, erzeugen aber ähnlich optimierte statische Dateien.

Wenn Sie mehr über Generatoren für statische Websites im Allgemeinen erfahren möchten, lesen Sie Tatiana Macs Leitfaden für Einsteiger zu Eleventy. Im ersten Artikel der Reihe erklärt die Autorin, was ein Generator für statische Websites ist und wie er sich zu anderen Möglichkeiten der Veröffentlichung von Webinhalten verhält.

Zusammenfassung

Damit sind wir am Ende unserer Einführung in Frameworks angelangt. Wir haben Ihnen noch keinen Code beigebracht, aber hoffentlich eine hilfreiche Grundlage dafür vermittelt, warum Sie Frameworks überhaupt einsetzen und wie Sie eines auswählen können – und Ihre Neugier geweckt, mehr zu lernen und selbst loszulegen!

Im nächsten Artikel gehen wir stärker ins Detail und betrachten, welche Arten von Funktionen Frameworks typischerweise bieten und warum sie so funktionieren, wie sie funktionieren.