Einführung in client-seitige Frameworks
Wir beginnen unseren Blick auf Frameworks mit einem allgemeinen Überblick über den Bereich, werfen einen kurzen Blick auf die Geschichte von JavaScript und Frameworks, warum Frameworks existieren und was sie uns bieten, wie Sie beginnen können, über die Auswahl eines Frameworks zum Lernen nachzudenken, und welche Alternativen es zu client-seitigen Frameworks gibt.
Voraussetzungen: | Vertrautheit mit den grundlegenden HTML, CSS und JavaScript Sprachen. |
---|---|
Ziel: | Zu verstehen, wie client-seitige JavaScript-Frameworks entstanden sind, welche Probleme sie lösen, welche Alternativen es gibt und wie man ein geeignetes auswählt. |
Eine kurze Geschichte
Als JavaScript 1996 debütierte, fügte es gelegentliche Interaktivität und Spannung zu einem Web hinzu, das bis dahin aus statischen Dokumenten bestand. Das Web wurde nicht nur ein Ort, um Dinge zu lesen, sondern um Dinge zu tun. Die Beliebtheit von JavaScript stieg stetig. Entwickler, die mit JavaScript arbeiteten, entwickelten Werkzeuge, um die Probleme zu lösen, denen sie begegneten, und fassten sie in wiederverwendbare Pakete namens Bibliotheken zusammen, um ihre Lösungen mit anderen zu teilen. Dieses gemeinsame Ökosystem von Bibliotheken half, das Wachstum des Webs zu gestalten.
JavaScript ist jetzt ein wesentlicher Bestandteil des Webs, auf 98 % aller Websites verwendet, und das Web ist ein wesentlicher Bestandteil des modernen Lebens. Nutzer verfassen Dokumente, verwalten ihre Budgets, streamen Musik, schauen Filme und kommunizieren sofort über große Distanzen, mit Text, Audio oder Video. Das Web ermöglicht uns Dinge, die früher nur in nativen Anwendungen möglich waren, die auf unseren Computern installiert waren. Diese modernen, komplexen und interaktiven Websites werden oft als Webanwendungen bezeichnet.
Die Einführung moderner JavaScript-Frameworks hat es viel einfacher gemacht, hochdynamische und interaktive Anwendungen zu erstellen. Ein Framework ist eine Bibliothek, die Meinungen darüber bietet, wie Software erstellt wird. Diese Meinungen ermöglichen Vorhersagbarkeit und Homogenität in einer Anwendung; Vorhersagbarkeit ermöglicht es, dass die Software zu einer enormen Größe skaliert werden kann und dennoch wartbar bleibt; Vorhersagbarkeit und Wartbarkeit sind entscheidend für die Gesundheit und Langlebigkeit von Software.
JavaScript-Frameworks treiben einen Großteil der beeindruckenden Software auf dem modernen Web an – einschließlich vieler der Websites, die Sie wahrscheinlich täglich nutzen. MDN Web Docs, auf denen Sie dies gerade lesen, verwendet das React/ReactDOM-Framework für die Benutzeroberfläche.
Welche Frameworks gibt es?
Es gibt viele Frameworks, aber derzeit werden die "großen vier" als die folgenden angesehen.
Ember
Ember wurde im Dezember 2011 als Fortsetzung der Arbeit am SproutCore-Projekt veröffentlicht. Es ist ein älteres Framework, das weniger Nutzer hat als modernere Alternativen wie React und Vue, aber es genießt immer noch eine beträchtliche Beliebtheit aufgrund seiner Stabilität, Community-Unterstützung und einiger cleverer Programmierungsprinzipien.
Angular
Angular ist ein Open-Source-Webanwendungs-Framework, das von Googles Angular Team und einer Gemeinschaft von Personen und Unternehmen geleitet wird. Es ist eine vollständige Neuentwicklung des gleichen Teams, das AngularJS erstellt hat. Angular wurde offiziell am 14. September 2016 veröffentlicht.
Angular ist ein komponentenbasiertes Framework, das deklarative HTML-Vorlagen verwendet. Zur Build-Zeit, transparent für Entwickler, übersetzt der Compiler des Frameworks die Vorlagen zu optimierten JavaScript-Instruktionen. Angular verwendet TypeScript, eine Obermenge von JavaScript, die wir im nächsten Kapitel etwas genauer anschauen werden.
Vue
Nachdem er am ursprünglichen AngularJS Projekt gearbeitet und von ihm gelernt hatte, veröffentlichte Evan You 2014 Vue. Vue ist das jüngste der großen vier, hat jedoch in letzter Zeit eine Beliebtheitsspitze erlebt.
Vue erweitert, wie AngularJS, HTML mit einem Teil seines eigenen Codes. Ansonsten stützt es sich hauptsächlich auf modernes, standardgerechtes JavaScript.
React
Facebook veröffentlichte React im Jahr 2013. Zu diesem Zeitpunkt hatte Facebook React bereits intern eingesetzt, um viele seiner Probleme zu lösen. Technisch gesehen ist React kein Framework; es ist eine Bibliothek zum Rendern von UI-Komponenten. React wird in Kombination mit anderen Bibliotheken verwendet, um Anwendungen zu erstellen — React und React Native ermöglichen es Entwicklern, mobile Anwendungen zu erstellen; React und ReactDOM ermöglichen es ihnen, Webanwendungen zu erstellen usw.
Da React und ReactDOM so oft zusammen verwendet werden, wird React umgangssprachlich als ein JavaScript-Framework verstanden. Wenn Sie dieses Modul lesen, arbeiten wir mit diesem umgangssprachlichen Verständnis.
React erweitert JavaScript mit HTML-ähnlicher Syntax, bekannt als JSX.
Warum existieren Frameworks?
Wir haben die Umgebung besprochen, die zur Schaffung von Frameworks führte, aber nicht wirklich warum Entwickler das Bedürfnis verspürten, sie zu schaffen. Das Erkunden des Warum erfordert zunächst die Untersuchung der Herausforderungen der Softwareentwicklung.
Betrachten Sie eine Art von Anwendung, die wir in zukünftigen Kapiteln mithilfe verschiedener Frameworks implementieren werden: einen To-do-Listen-Ersteller. Diese Anwendung sollte es den Nutzern ermöglichen, Dinge wie das Rendern einer Liste von Aufgaben, das Hinzufügen einer neuen Aufgabe und das Löschen einer Aufgabe zu tun; und sie muss dies tun, während sie zuverlässig die Daten verfolgt und aktualisiert, die der Anwendung zugrunde liegen. In der Softwareentwicklung sind diese zugrunde liegenden Daten als Zustand (engl. state) bekannt.
Jedes unserer Ziele scheint in Isolation theoretisch einfach. Wir können über die Daten iterieren, um sie zu rendern; wir können ein Objekt hinzufügen, um eine neue Aufgabe zu erstellen; wir können einen Bezeichner verwenden, um eine Aufgabe zu finden, zu bearbeiten oder zu löschen. Wenn wir daran denken, dass die Anwendung dem Nutzer ermöglichen muss, all diese Dinge über den Browser zu tun, beginnen einige Risse zu zeigen. Das eigentliche Problem ist: Jedes Mal, wenn wir den Zustand unserer Anwendung ändern, müssen wir die Benutzeroberfläche aktualisieren, um sie anzupassen.
Wir können die Schwierigkeit dieses Problems untersuchen, indem wir uns nur ein Merkmal unserer To-do-Listen-App ansehen: das Rendern einer Liste von Aufgaben.
Die Umständlichkeit von DOM-Änderungen
HTML-Elemente zu erstellen und sie zur richtigen Zeit im Browser darzustellen, erfordert überraschend viel Code. Angenommen, unser Zustand ist ein Array von Objekten, das so strukturiert ist:
const state = [
{
id: "todo-0",
name: "Learn some frameworks!",
},
];
Wie zeigen wir eine dieser Aufgaben unseren Nutzern? Wir möchten jede Aufgabe als Listenelement darstellen – ein HTML-<li>
-Element in einem ungeordneten Listen-Element (einem <ul>
). Wie erstellen wir es? Das könnte so aussehen:
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, und mehrere weitere Codezeilen, um die Eigenschaften und Kindelemente zu erstellen, die es benötigt.
Das vorherige Snippet verweist auf eine weitere Erstellungsmethode: buildDeleteButtonEl()
. Es folgt einem ähnlichen Muster, das wir zum Erstellen eines Listenelements verwendet haben:
function buildDeleteButtonEl(id) {
const button = document.createElement("button");
button.setAttribute("type", "button");
button.textContent = "Delete";
return button;
}
Dieser Button macht noch nichts, aber er wird später funktionieren, sobald wir unser Lösch-Feature implementieren. Der Code, der unsere Elemente auf der Seite rendern wird, könnte so aussehen:
function renderTodoList() {
const frag = document.createDocumentFragment();
state.tasks.forEach((task) => {
const item = buildTodoItemEl(task.id, task.name);
frag.appendChild(item);
});
while (todoListEl.firstChild) {
todoListEl.removeChild(todoListEl.firstChild);
}
todoListEl.appendChild(frag);
}
Wir haben jetzt fast dreißig Codezeilen, die sich nur der Benutzeroberfläche widmen – nur, um etwas im DOM zu rendern – und an keiner Stelle fügen wir Klassen hinzu, die wir später verwenden könnten, um unsere Listenelemente zu stylen!
Direkt mit dem DOM zu arbeiten, wie in diesem Beispiel, erfordert das Verständnis vieler Dinge darüber, wie das DOM funktioniert: wie man Elemente erstellt; wie man ihre Eigenschaften ändert; wie man Elemente ineinander hineinsetzt; wie man sie auf der Seite erscheinen lässt. Keiner dieses Codes behandelt Benutzerinteraktionen oder befasst sich mit dem Hinzufügen oder Löschen einer Aufgabe. Wenn wir diese Funktionen hinzufügen, müssen wir daran denken, unsere Benutzeroberfläche zum richtigen Zeitpunkt und auf die richtige Weise zu aktualisieren.
JavaScript-Frameworks wurden erstellt, um diese Art von Arbeit viel einfacher zu machen — sie existieren, um eine bessere Entwicklererfahrung zu bieten. Sie bringen keine brandneuen Fähigkeiten zu JavaScript; sie geben Ihnen jedoch einfacheren Zugang zu den Fähigkeiten von JavaScript, sodass Sie für das heutige Web entwickeln können.
Wenn Sie die Codebeispiele aus diesem Abschnitt in Aktion sehen möchten, können Sie sich eine funktionierende Version der App auf CodePen ansehen, die es den Nutzern auch erlaubt, neue Aufgaben hinzuzufügen und zu löschen.
Lesen Sie mehr über die in diesem Abschnitt verwendeten JavaScript-Funktionen:
Eine andere Möglichkeit, UIs zu erstellen
Jedes JavaScript-Framework bietet eine Möglichkeit, Benutzeroberflächen deklarativer zu schreiben. Das heißt, sie ermöglichen es Ihnen, Code zu schreiben, der beschreibt, wie Ihre Benutzeroberfläche aussehen soll, und das Framework übernimmt das Ändern des DOMs im Hintergrund.
Der native JavaScript-Ansatz, neue DOM-Elemente in Wiederholungen zu erstellen, war auf den ersten Blick schwer zu verstehen. Im Gegensatz dazu zeigt der folgende Codeblock, wie Sie mit Vue unsere Liste von Aufgaben beschreiben könnten:
<ul>
<li v-for="task in tasks" v-bind:key="task.id">
<span>{{task.name}}</span>
<button type="button">Delete</button>
</li>
</ul>
Das war's. Dieses Snippet reduziert fast dreißig Codezeilen auf sechs Zeilen. Wenn die geschweiften Klammern und v-
Attribute hier Ihnen unbekannt sind, ist das in Ordnung; Sie werden später im Modul über Vue-spezifische Syntax lernen. Das, was hier zu beachten ist, ist, dass dieser Code aussieht wie die Benutzeroberfläche, die er darstellt, während der native JavaScript-Code dies nicht tut.
Dank Vue mussten wir keine eigenen Funktionen zum Erstellen der Benutzeroberfläche schreiben; das Framework übernimmt das für uns auf eine optimierte, effiziente Weise. Unsere einzige Aufgabe war es, Vue zu beschreiben, wie jedes Element aussehen sollte. Entwickler, die mit Vue vertraut sind, können schnell verstehen, was vor sich geht, wenn sie unserem Projekt beitreten. Vue ist darin nicht allein: Ein Framework zu verwenden, verbessert die Effizienz des Teams sowie der einzelnen Entwickler.
Es ist möglich, Dinge ähnlich wie dies in nativem JavaScript zu tun. Template Literal Strings ermöglichen es Ihnen, HTML-Zeichenfolgen zu schreiben, die das Endelement darstellen würden. Das könnte eine nützliche Idee für etwas Einfaches wie unsere To-do-Listen-Anwendung sein, aber es ist nicht wartbar für große Anwendungen, die Tausende von Datenaufzeichnungen verwalten und ebenso viele einzigartige Elemente in einer Benutzeroberfläche rendern könnten.
Andere Dinge, die Frameworks bieten
Werfen wir einen Blick auf einige der anderen Vorteile, die Frameworks bieten. Wie bereits angedeutet, sind die Vorteile von Frameworks mit nativem JavaScript erreichbar, aber die Verwendung eines Frameworks nimmt die intellektuelle Belastung, diese Probleme selbst lösen zu müssen.
Werkzeuge
Da jedes der Frameworks in diesem Modul eine große, aktive Gemeinschaft hat, bietet das Ökosystem jedes Frameworks Werkzeuge, die die Entwicklererf experience verbessern. Diese Werkzeuge machen es einfach, Dinge wie Testing (um sicherzustellen, dass Ihre Anwendung so funktioniert, wie sie sollte) oder Linting (um sicherzustellen, dass Ihr Code fehlerfrei und stilistisch konsistent ist) hinzuzufügen.
Hinweis: Wenn Sie mehr Details zu Konzepten von Web-Tools erfahren möchten, werfen Sie einen Blick auf unser Client-seitige Tools-Übersicht.
Aufteilung
Die meisten großen Frameworks ermutigen Entwickler dazu, die verschiedenen Teile ihrer Benutzeroberflächen in Komponenten zu abstrahieren — wartbare, wiederverwendbare Codeblöcke, die miteinander kommunizieren können. Der gesamte Code, der mit einer bestimmten Komponente zusammenhängt, kann in einer Datei (oder ein paar spezifischen Dateien) leben, sodass Sie als Entwickler genau wissen, wo Sie zur Änderung dieser Komponente hinsehen müssen. In einer nativen JavaScript-App müssten Sie Ihr eigenes Set von Konventionen erstellen, um dies auf eine effiziente, skalierbare Weise zu erreichen. Viele JavaScript-Entwickler, wenn sie ihrem eigenen Gerät überlassen werden, könnten am Ende mit all dem Code, der mit einem Teil der Benutzeroberfläche verbunden ist, überall in einer Datei verteilt sein — oder sogar in einer anderen Datei.
Routing
Die grundlegendste Funktion des Webs ist, dass es den Nutzern ermöglicht, von einer Seite zur anderen zu navigieren – es ist schließlich ein Netz aus miteinander verbundenen Dokumenten. Wenn Sie einem Link auf dieser Website folgen, kommuniziert Ihr Browser mit einem Server und ruft neue Inhalte ab, die für Sie angezeigt werden. Dabei ändert sich die URL in Ihrer Adressleiste. Sie können diese neue URL speichern und später auf die Seite zurückkehren oder sie mit anderen teilen, damit sie leicht die gleiche Seite finden können. Ihr Browser merkt sich Ihren Navigationsverlauf und ermöglicht es Ihnen auch, vorwärts und rückwärts zu navigieren. Dies wird als Server-seitiges Routing bezeichnet.
Moderne Webanwendungen rufen typischerweise keine neuen HTML-Dateien ab und rendern sie nicht – sie laden eine einzelne HTML-Hülle und aktualisieren kontinuierlich das DOM darin (bekannt als Single-Page-Apps oder SPAs), ohne die Nutzer zu neuen Adressen im Web zu navigieren. Jede neue pseudo-Webseite wird normalerweise als Ansicht bezeichnet, und standardmäßig wird kein Routing durchgeführt.
Wenn eine SPA komplex genug ist und genügend einzigartige Ansichten rendert, ist es wichtig, Routing-Funktionalität in Ihre Anwendung zu integrieren. Menschen sind es gewohnt, auf spezifische Seiten in einer Anwendung verlinken zu können, in ihrem Navigationsverlauf vor- und zurückzureisen usw., und ihre Erfahrung leidet, wenn diese Standard-Web-Features gebrochen sind. Wenn das Routing von einer Client-Anwendung auf diese Weise behandelt wird, wird es treffend als Client-seitiges Routing bezeichnet.
Es ist möglich, einen Router mit den nativen Fähigkeiten von JavaScript und dem Browser zu erstellen, aber beliebte, aktiv entwickelte Frameworks haben begleitende Bibliotheken, die Routing zu einem intuitiveren Teil des Entwicklungsprozesses machen.
Dinge, die bei der Verwendung von Frameworks zu beachten sind
Ein effektiver Webentwickler zu sein bedeutet, die geeignetsten Werkzeuge für die Aufgabe zu verwenden. JavaScript-Frameworks erleichtern die Entwicklung von Front-End-Anwendungen, aber sie sind keine Wunderlösung, die alle Probleme löst. In diesem Abschnitt wird über einige der Dinge gesprochen, die Sie bei der Verwendung von Frameworks beachten sollten. Beachten Sie, dass Sie möglicherweise überhaupt kein Framework benötigen — achten Sie darauf, nicht nur aus Prinzip ein Framework zu verwenden.
Vertrautheit mit dem Werkzeug
Wie bei nativem JavaScript erfordern Frameworks Zeit zum Lernen und haben ihre Eigenheiten. Bevor Sie sich entscheiden, ein Framework für ein Projekt zu verwenden, stellen Sie sicher, dass Sie genug Zeit haben, um genug seiner Funktionen zu lernen, damit es Ihnen nützend ist, anstatt gegen Sie zu arbeiten, und stellen Sie sicher, dass Ihre Teamkollegen sich damit ebenfalls wohlfühlen.
Überengineering
Wenn Ihr Webentwicklungsprojekt ein persönliches Portfolio mit wenigen Seiten ist und diese Seiten wenig oder keine interaktive Funktionalität haben, ist ein Framework (und all sein JavaScript) möglicherweise überhaupt nicht notwendig. Das heißt, Frameworks sind nicht monolithisch, und einige von ihnen sind besser für kleine Projekte geeignet als andere. In einem Artikel für Smashing Magazine schreibt Sarah Drasner darüber, wie Vue jQuery ersetzen kann als Werkzeug, um kleine Teile einer Webseite interaktiv zu machen.
Größere Codebasis und Abstraktion
Frameworks ermöglichen es Ihnen, deklarativeren Code zu schreiben – und manchmal insgesamt weniger Code – indem sie die DOM-Interaktionen für Sie übernehmen, im Hintergrund. Diese Abstraktion ist großartig für Ihre Erfahrung als Entwickler, aber sie ist nicht kostenlos. Um das, was Sie schreiben, in DOM-Änderungen zu übersetzen, müssen Frameworks ihren eigenen Code ausführen, was wiederum bedeutet, dass Ihr endgültiges Softwarestück größer und rechenintensiver zu betreiben ist.
Einige zusätzlicher Code ist unvermeidlich, und ein Framework, das Baumschütteln unterstützt (Entfernung aller Codes, die während des Build-Prozesses in der App nicht tatsächlich verwendet werden), ermöglicht es Ihnen, Ihre Anwendungen klein zu halten, aber dies ist immer noch ein Faktor, den Sie im Auge behalten müssen, wenn Sie die Leistung Ihrer App in Betracht ziehen, insbesondere auf netzwerk-/speicherbeschränkten Geräten wie Mobiltelefonen.
Die Abstraktion von Frameworks betrifft nicht nur Ihr JavaScript, sondern auch Ihre Beziehung zur wahren Natur des Webs. Egal, wie Sie für das Web entwickeln, das Endergebnis, die Schicht, mit der Ihre Nutzer letztendlich interagieren, ist HTML. Wenn Sie Ihre gesamte Anwendung in JavaScript schreiben, kann es passieren, dass Sie die HTML-Struktur und den Zweck ihrer verschiedenen Tags aus den Augen verlieren und ein HTML-Dokument erstellen, das unsemantisch und unzugänglich ist. Tatsächlich ist es möglich, eine fragile Anwendung zu schreiben, die vollständig von JavaScript abhängt und ohne sie nicht funktioniert.
Frameworks sind nicht die Quelle unserer Probleme. Mit den falschen Prioritäten kann jede Anwendung fragil, überladen und unzugänglich sein. Frameworks verstärken jedoch unsere Prioritäten als Entwickler. Wenn Ihre Priorität darin besteht, eine komplexe Webanwendung zu erstellen, ist das einfach zu tun. Wenn Ihre Prioritäten jedoch nicht sorgfältig Performance und Barrierefreiheit wahren, verstärken Frameworks Ihre Fragilität, Ihre Überladung und Ihre Unzugänglichkeit. Moderne Entwicklerprioritäten, verstärkt durch Frameworks, haben die Struktur des Webs an vielen Stellen umgekehrt. Anstatt ein robustes, inhaltsorientiertes Netzwerk von Dokumenten zu sein, stellt das Web nun oft JavaScript an die erste Stelle und die Benutzererfahrung an die letzte.
Barrierefreiheit auf einem framework-gesteuerten Web
Lassen Sie uns auf dem aufbauen, was wir im vorherigen Abschnitt gesagt haben, und ein wenig mehr über Barrierefreiheit sprechen. Benutzeroberflächen zugänglich zu machen, erfordert immer einige Gedanken und Mühe, und Frameworks können diesen Prozess verkomplizieren. Sie müssen oft erweiterte Framework-APIs verwenden, um auf native Browserfunktionen wie ARIA Live-Regioinen oder Fokus-Verwaltung zuzugreifen.
In einigen Fällen schaffen Framework-Anwendungen Barrieren, die für traditionelle Websites nicht existieren. Das größte Beispiel dafür ist das client-seitige Routing, wie zuvor erwähnt.
Mit traditionellem (server-seitigem) Routing hat die Navigation im Web vorhersehbare Ergebnisse. Der Browser weiß, dass er den Fokus auf den Anfang der Seite setzen muss und unterstützende Technologien werden den Seitentitel ansagen. Diese Dinge passieren jedes Mal, wenn Sie zu einer neuen Seite navigieren.
Mit client-seitigem Routing lädt Ihr Browser keine neuen Webseiten, daher weiß er nicht, dass er den Fokus automatisch anpassen oder einen neuen Seitentitel ankündigen sollte. Framework-Autoren haben immense Zeit und Mühe investiert, JavaScript zu schreiben, das diese Funktionen nachbildet, und selbst dann hat kein Framework dies perfekt gemacht.
Das Ergebnis ist, dass Sie Barrierefreiheit von Anfang an in jedem Webprojekt berücksichtigen sollten, aber beachten Sie, dass abstrakte Codebasen, die Frameworks verwenden, eher unter größeren Barrierefreiheitsproblemen leiden, wenn Sie dies vernachlässigen.
Wie man ein Framework auswählt
Jedes der in diesem Modul besprochenen Frameworks verfolgt unterschiedliche Ansätze zur Webanwendungsentwicklung. Jedes wird regelmäßig verbessert oder verändert und jedes hat seine Vor- und Nachteile. Die Wahl des richtigen Frameworks ist ein team- und projektabhängiger Prozess, und Sie sollten Ihre eigene Recherche betreiben, um herauszufinden, was Ihren Bedürfnissen entspricht. Das Gesagte, wir haben einige Fragen identifiziert, die Sie stellen können, um Ihre Optionen effektiver zu recherchieren:
- Welche Browser unterstützt das Framework?
- Welche domänenspezifischen Sprachen verwendet das Framework?
- Hat das Framework eine starke Community und gute Dokumentation (und andere Unterstützung) verfügbar?
Die Tabelle in diesem Abschnitt bietet einen schnellen Überblick über die aktuelle Browserunterstützung, die von jedem Framework angeboten wird, sowie die domänenspezifischen Sprachen, mit denen es verwendet werden kann.
Im Allgemeinen sind domänenspezifische Sprachen (DSLs) Programmiersprachen, die in bestimmten Bereichen der Softwareentwicklung relevant sind. Im Kontext von Frameworks sind DSLs Variationen von JavaScript oder HTML, die es einfacher machen, mit diesem Framework zu entwickeln. Entscheidend ist, dass keines der Frameworks erfordert, dass ein Entwickler eine bestimmte DSL verwendet, aber sie wurden fast alle mit einer bestimmten DSL im Sinn entworfen. Wenn man sich entscheidet, nicht die bevorzugte DSL eines Frameworks zu verwenden, verpasst man Funktionen, die ansonsten die Entwicklererfahrung verbessern würden.
Sie sollten die Unterstützungsmatrix und DSLs eines Frameworks ernsthaft in Betracht ziehen, wenn Sie eine Wahl für ein neues Projekt treffen. Fehlende Browserunterstützung kann eine Barriere für Ihre Nutzer sein; eine nicht übereinstimmende DSL-Unterstützung kann eine Barriere für Sie und Ihre Teamkollegen sein.
Framework | Browserunterstützung | Bevorzugte DSL | Unterstützte DSLs | Quelle |
---|---|---|---|---|
Angular | Modern | TypeScript | HTML-basiert; TypeScript | offizielle Dokumentation |
React | Modern | JSX | JSX; TypeScript | offizielle Dokumentation |
Vue | Modern (IE9+ in Vue 2) | HTML-basiert | HTML-basiert, JSX, Pug | offizielle Dokumentation |
Ember | Modern (IE9+ in Ember Version 2.18) | Handlebars | Handlebars, TypeScript | offizielle Dokumentation |
Hinweis: DSLs, die wir als "HTML-basiert" beschrieben haben, haben keine offiziellen Namen. Sie sind nicht wirklich echte DSLs, aber es handelt sich um nicht-standardisierte HTML, deshalb glauben wir, dass sie es wert sind, hervorgehoben zu werden.
Hat das Framework eine starke Gemeinschaft?
Dies ist vielleicht die schwierigste Metrik zu messen, weil die Größe der Gemeinschaft nicht direkt mit leicht zugänglichen Zahlen korreliert. Sie können die Anzahl der GitHub-Sterne oder wöchentlichen npm-Downloads eines Projekts überprüfen, um eine Idee seiner Popularität zu bekommen, aber manchmal ist das Beste, was man tun kann, einige Foren zu durchsuchen oder mit anderen Entwicklern zu sprechen. Es geht nicht nur um die Größe der Gemeinschaft, sondern auch darum, wie einladend und inklusiv sie ist und wie gut die verfügbare Dokumentation ist.
Meinungen im Web
Glauben Sie nicht nur unserem Wort in dieser Angelegenheit — es gibt Diskussionen im gesamten Web. Die Wikimedia Foundation hat kürzlich beschlossen, Vue für ihr Front-End zu verwenden, und veröffentlichte eine Request for Comments (RFC) zur Einführung von Frameworks. Eric Gardner, der Autor der RFC, nahm sich die Zeit, die Bedürfnisse des Wikimedia-Projekts zu skizzieren und warum bestimmte Frameworks gute Entscheidungen für das Team waren. Diese RFC dient als ein großartiges Beispiel für die Art der Forschung, die Sie für sich selbst durchführen sollten, wenn Sie planen, ein Front-End-Framework zu verwenden.
Die State of JavaScript survey ist eine hilfreiche Sammlung von Rückmeldungen von JavaScript-Entwicklern. Sie behandelt viele Themen im Zusammenhang mit JavaScript, einschließlich Daten über die Nutzung von Frameworks und das Entwicklerempfinden ihnen gegenüber. Derzeit stehen mehrere Jahre an Daten zur Verfügung, die es ermöglichen, ein Gefühl für die Beliebtheit eines Frameworks zu bekommen.
Das Vue-Team hat Vue ausführlich mit anderen beliebten Frameworks verglichen. Es kann eine gewisse Voreingenommenheit in diesem Vergleich geben (die sie anmerken), aber es ist dennoch eine wertvolle Ressource.
Alternativen zu client-seitigen Frameworks
Wenn Sie nach Werkzeugen suchen, um den Webentwicklungsprozess zu beschleunigen, und Sie wissen, dass Ihr Projekt keine intensive client-seitige JavaScript-Funktionalität erfordern wird, könnten Sie auf einige andere Lösungen zum Erstellen des Webs zurückgreifen:
- Ein Content Management System
- Server-seitiges Rendering
- Ein statischer Site-Generator
Content Management Systeme
Content-Management-Systeme (CMSes) sind Werkzeuge, die es einem Benutzer ermöglichen, Webinhalte zu erstellen, ohne selbst direkt Code zu schreiben. Sie sind eine gute Lösung für große Projekte, insbesondere für Projekte, die Eingaben von Inhaltsautoren erfordern, die nur begrenzte Codierungsfähigkeiten haben, oder für Programmierer, die Zeit sparen wollen. Sie erfordern jedoch eine erhebliche Zeit für die Einrichtung, und die Nutzung eines CMS bedeutet, dass Sie zumindest einige Kontrolle über die endgültige Ausgabe Ihrer Website aufgeben. Zum Beispiel: Wenn Ihr ausgewähltes CMS nicht standardmäßig zugängliche Inhalte erstellt, ist es oft schwierig, dies zu verbessern.
Einige beliebte CMS-Systeme sind WordPress, Joomla und Drupal.
Server-seitiges Rendering
Server-seitiges Rendering (SSR) ist eine Anwendungsarchitektur, bei der es die Aufgabe des Servers ist, eine Single-Page-Anwendung zu rendern. Dies ist das Gegenteil von client-seitigem Rendering, das die häufigste und einfachste Möglichkeit ist, eine JavaScript-Anwendung zu erstellen. Server-seitiges Rendering ist einfacher auf dem Gerät des Clients, weil Sie ihnen nur eine gerenderte HTML-Datei senden, aber es kann schwierig einzurichten sein im Vergleich zu einer client-seitig gerenderten Anwendung.
Alle in diesem Modul behandelten Frameworks bieten sowohl server-seitiges Rendering als auch client-seitiges Rendering. Schauen Sie sich Next.js für React, Nuxt für Vue (ja, es ist verwirrend, und nein, diese Projekte sind nicht miteinander verbunden!), FastBoot für Ember und Angular Universal für Angular an.
Hinweis: Einige SSR-Lösungen werden von der Gemeinschaft geschrieben und gepflegt, während einige offizielle Lösungen vom Entwickler des Frameworks bereitgestellt werden.
Statische Site-Generatoren
Statische Site-Generatoren sind Programme, die alle Webseiten einer multiplen Website — einschließlich relevanter CSS oder JavaScript — dynamisch generieren, so dass sie an verschiedenen Orten veröffentlicht werden können. Der veröffentlichende Host könnte eine GitHub Pages-Branch, eine Netlify-Instanz oder ein beliebiger privater Server Ihrer Wahl sein, zum Beispiel. Es gibt eine Reihe von Vorteilen bei diesem Ansatz, hauptsächlich in Bezug auf Performance (das Gerät Ihres Benutzers erstellt die Seite nicht mit JavaScript; sie ist bereits vollständig) und Sicherheit (statische Seiten haben weniger Angriffspunkte). Diese Seiten können weiterhin JavaScript verwenden, wenn sie es benötigen, sind aber nicht abhängig davon. Statische Site-Generatoren erfordern, wie jedes andere Werkzeug, Zeit zu lernen, was eine Barriere für Ihren Entwicklungsprozess sein kann.
Statische Sites können so wenig oder so viele einzigartige Seiten haben, wie Sie wollen. So wie Frameworks Ihnen ermöglichen, schnell client-seitige JavaScript-Anwendungen zu schreiben, ermöglichen Ihnen statische Site-Generatoren, HTML-Dateien schnell zu erstellen, die Sie sonst einzeln hätten erstellen müssen. Wie Frameworks ermöglichen statische Site-Generatoren Entwicklern, Komponenten zu schreiben, die häufige Teile Ihrer Webseiten definieren, und diese Komponenten zusammenzustellen, um eine endgültige Seite zu erstellen. Im Kontext statischer Site-Generatoren werden diese Komponenten Vorlagen genannt. Webseiten, die von statischen Site-Generatoren erstellt wurden, können sogar home zu Framework-Anwendungen sein: Wenn Sie möchten, dass eine bestimmte Seite Ihrer statisch erzeugten Website eine React-Anwendung startet, sobald Ihre Nutzer sie besuchen, können Sie das tun.
Statische Site-Generatoren sind schon seit geraumer Zeit im Umlauf und werden ständig optimiert und weiterentwickelt. Eine Reihe von Optionen existiert, darunter Astro, Eleventy, Hugo, Jekyll und Gatsby, die auf verschiedenen Technologiestapeln aufbauen und unterschiedliche Funktionen bereitstellen. Andere Optionen, wie Docusaurus und VitePress, verwenden client-seitige Frameworks anstelle von Vorlagen, generieren jedoch ähnlich optimierte statische Dateien.
Wenn Sie mehr über statische Site-Generatoren im Allgemeinen lernen möchten, sehen Sie sich Tatiana Macs Anfängerleitfaden zu Eleventy an. Im ersten Artikel der Serie erklären sie, was ein statischer Site-Generator ist und wie er sich auf andere Mittel zur Veröffentlichung von Webinhalten bezieht.
Zusammenfassung
Und damit kommen wir zum Ende unserer Einführung in Frameworks — wir haben Ihnen noch keinen Code beigebracht, aber hoffentlich haben wir Ihnen einen nützlichen Hintergrund gegeben, warum Sie Frameworks überhaupt verwenden würden und wie Sie ein geeignetes auswählen können, und Sie dazu gebracht, noch mehr lernen zu wollen und sich auszutoben!
Unser nächster Artikel geht auf eine niedrigere Ebene und betrachtet die spezifischen Arten von Funktionen, die Frameworks in der Regel bieten und warum sie so funktionieren, wie sie es tun.