Komponenten: Serverseitig vs. Clientseitig

Bauen Sie 2021 eine Website? Ich vermute, Sie werden einen komponentengetriebenen Ansatz verfolgen. Das ist das Thema schlechthin heutzutage. React und Vue sind überall (ist Angular noch relevant?), während andere aufkommende Frameworks weiterhin versuchen, ins Rampenlicht zu rücken.

Im Laufe des letzten Jahrzehnts haben wir eine Explosion von Frameworks und Tools erlebt, die uns helfen, Websites systematisch mit Komponenten aufzubauen. Frühe Frameworks wie AngularJS halfen, das generische Konzept von Webkomponenten zu prägen. Webkomponenten sind auch wiederverwendbare HTML-Code-Schnipsel, die in JavaScript geschrieben und vom Browser funktionsfähig gemacht werden. Es sind clientseitige Komponenten.

Aber Komponenten im allgemeineren Sinne gibt es schon viel länger. Tatsächlich reichen sie bis in die frühen Tage des Webs zurück. Sie wurden nur nicht typischerweise als Komponenten bezeichnet, obwohl sie immer noch so funktionieren. Serverkomponenten sind ebenfalls wiederverwendbare Code-Schnipsel, werden aber in HTML kompiliert, bevor der Browser sie sieht. Es sind serverseitige Komponenten, und sie sind heute noch sehr relevant.

Selbst in einer Welt, in der man scheinbar nur "React, React, React" hört, sind beide Arten von Komponenten immer noch relevant und können uns helfen, super tolle Websites zu bauen. Lassen Sie uns untersuchen, wie sich Client- und Serverkomponenten voneinander unterscheiden. Das gibt uns ein klareres Bild davon, woher wir kommen. Und dann haben wir die Informationen, die wir brauchen, um über die Zukunft nachzudenken.

Rendering

Vielleicht ist der größte Unterschied zwischen clientseitigen und serverseitigen Komponenten das, was sie ausmacht. Das ist das Ding, das für ihr Rendering verantwortlich ist.

Serverkomponenten werden gerendert von – Sie haben es erraten! – dem Server. Sie werden typischerweise nicht als Komponenten bezeichnet. Sie werden oft als Partials, Includes, Snippets oder Templates bezeichnet, je nach Framework, in dem sie verwendet werden.

Serverkomponenten können zwei Formen annehmen. Die erste ist der klassische Ansatz, bei dem Komponenten in Echtzeit basierend auf einer Anfrage vom Client gerendert werden. Sehen Sie hier

Die zweite Form ist der Jamstack-Ansatz. In diesem Fall wird die gesamte Website während eines Build-Prozesses kompiliert, und statisches HTML ist verfügbar, wenn es vom Client angefordert wird. Sehen Sie hier

In beiden Fällen sieht der Client (d. h. Ihr Browser) nie einen Unterschied zwischen Ihren Komponenten. Er empfängt einfach HTML vom Server.

Clientkomponenten hingegen werden gerendert von – Sie liegen zwei von zwei und sind auf einer ROLLE! – dem Client. Sie sind in JavaScript geschrieben und werden vom Client (Ihrem Browser) gerendert. Da der Server der Server ist und alles weiß, kann er Ihre Clientkomponenten kennen, aber ob er sich darum kümmert, etwas damit zu tun, hängt vom verwendeten Framework ab.

Ähnlich wie bei Serverkomponenten gibt es auch bei Clientkomponenten zwei Formen. Die erste sind die offizielleren Webkomponenten, die Shadow DOM verwenden. Shadow DOM hilft bei der Kapselung von Stilen und anderer Funktionalität (darauf werden wir später noch eingehen). Frameworks wie Polymer und Stencil nutzen Shadow DOM.

Die beliebteren Frameworks, wie React und Vue, repräsentieren die zweite Form der Komponente, die DOM-Manipulation und Scoping selbst handhabt.

Interaktivität

Da Serverkomponenten beim Senden an den Client nur HTML sind, muss die Anwendung, wenn sie auf dem Frontend interaktiv sein soll, separat JavaScript-Code laden.

Betrachten Sie einen Countdown-Timer. Seine Präsentation wird durch HTML und CSS bestimmt (wir kommen später noch zum CSS-Teil). Aber damit er seine Funktion erfüllen kann (zählen), benötigt er auch etwas JavaScript. Das bedeutet nicht nur, dieses JavaScript einzubinden, sondern auch eine Möglichkeit zu haben, mit der das JavaScript an die HTML-Elemente des Countdowns angehängt werden kann, was entweder manuell oder mit (noch) einem anderen Framework erfolgen muss.

Auch wenn dies unnötig mühsam erscheinen mag (besonders wenn Sie lange genug dabei sind, um diesen Ansatz zu erzwingen), gibt es Vorteile. Es ist eine klare Trennung der Verantwortlichkeiten, bei der der serverseitige Code an einem Ort lebt, während die Funktionalität an einem anderen Ort angesiedelt ist. Und es bringt nur den Code mit, den es für die Interaktivität benötigt (theoretisch), was die Belastung für den Browser verringern kann.

Bei Clientkomponenten sind Markup und Interaktivität tendenziell eng gekoppelt, oft in derselben Datei oder im selben Verzeichnis. Während dies schnell unübersichtlich werden kann, wenn Sie nicht sorgfältig auf Organisation achten, ist ein großer Vorteil von Clientkomponenten, dass sie bereits Zugriff auf den Client haben. Und da sie in JavaScript geschrieben sind, kann ihre Funktionalität direkt neben ihrem Markup (und ihren Styles) ausgeliefert werden.

Performance

Im direkten Vergleich schneiden serverseitige Komponenten tendenziell besser ab. Wenn die Seite, die ein Browser erhält, alles enthält, was er für die Präsentation benötigt, wird er diese Präsentation dem Benutzer viel schneller liefern können.

Da clientseitige Komponenten JavaScript erfordern, muss der Browser zusätzliche Informationen (oft in separaten Dateien) herunterladen oder verarbeiten, um die Komponente rendern zu können.

Allerdings werden clientseitige Komponenten oft im Kontext eines größeren Frameworks verwendet. React hat Gatsby und Next, während Vue Nuxt hat. Diese Frameworks haben Mechanismen für die Schaffung einer überlegenen In-App-Erfahrung. Was ich damit meine ist, dass sie zwar langsamer sein mögen, um die erste Seite zu laden, die Sie auf einer Website besuchen, aber dann ihre Energie darauf konzentrieren können, nachfolgende Ansichten extrem schnell zu liefern – oft schneller, als eine serverseitig gerenderte Website ihren Inhalt liefern kann.

Wenn Sie denken: Ja, aber was ist mit Pre-Rendering und…

Ja, Sie haben Recht. Da kommen wir noch hin. Außerdem bitte keine Spoiler mehr. Der Rest von uns ist auf der Fahrt dabei.

Sprachen

Serverkomponenten können in (fast) jeder serverseitigen Sprache geschrieben werden. Dies ermöglicht es Ihnen, Ihre Templates in derselben Sprache wie die Anwendungslogik zu schreiben. Zum Beispiel verwenden Anwendungen, die mit Ruby on Rails geschrieben sind, standardmäßig ERB-Templating, eine Form von Ruby. Somit verwenden Rails-Apps dieselbe Sprache für die Anwendung selbst wie für ihre Komponenten.

Der Grund, warum Clientkomponenten in JavaScript geschrieben sind, ist, dass dies die Sprache ist, die Browser für die Interaktivität auf einer Website verarbeiten. JavaScript verfügt jedoch auch über serverbasierte Laufzeiten, von denen die beliebteste Node.js ist. Das bedeutet, dass Code für Clientkomponenten in derselben Sprache wie die Anwendung geschrieben werden könnte, solange die Anwendung mit Node (oder Ähnlichem) geschrieben ist.

Styling (CSS)

Beim Styling von Komponenten stoßen serverseitige Komponenten auf dieselben Schwierigkeiten wie bei JavaScript. Die Styles sind typischerweise von den Komponenten getrennt und erfordern etwas zusätzlichen Aufwand, um Styles an die Elemente auf der Seite zu binden.

Es gibt jedoch Frameworks wie Tailwind CSS, die daran arbeiten, diesen Prozess weniger schmerzhaft zu gestalten.

Viele clientseitige Komponentenbibliotheken bieten CSS-Unterstützung (oder zumindest ein Muster zum Styling) sofort. Das bedeutet oft, die Styles in derselben Datei wie Markup und Logik einzubinden, was unordentlich werden kann. Aber typischerweise können Sie diesen Ansatz mit etwas Aufwand an Ihre Bedürfnisse anpassen.

Willkommen in der (hybriden) Zukunft

Keine der beiden Komponentenarten ist allein die Antwort. Serverseitige Komponenten erfordern zusätzlichen Aufwand bei Styling und Interaktivität, der unnötig erscheint, wenn wir uns die Angebote von Clientkomponenten ansehen. Aber dann neigen Clientkomponenten dazu, die Performance auf dem Frontend zu beeinträchtigen. Und da der Erfolg einer Website oft von der Nutzerbindung abhängt, kann ein Mangel an Performance das Endergebnis beeinträchtigen und ausreichen, um Clientkomponenten nicht nutzen zu wollen.

Was bedeutet das für eine Zukunft, die sowohl Performance als auch ein gutes Entwicklererlebnis erfordert? Höchstwahrscheinlich ein hybrider Ansatz.

Komponenten werden serverseitig gerendert werden müssen. Das ist einfach so. So optimieren wir die Performance, und gute Performance wird weiterhin ein Merkmal erfolgreicher Websites sein. Aber da wir jetzt die Einfachheit von Frontend-Logik und Interaktivität mit Frameworks wie React und Vue gesehen haben, bleiben diese Frameworks (zumindest für eine Weile).

Wohin geht die Reise also?

Ich denke, wir werden in sehr naher Zukunft diese Komponenten auf drei Arten zusammenkommen sehen.

1. Fortschritt von JavaScript-Framework-Frameworks

Erinnern Sie sich, als Sie diesen Spoiler über Pre-Rendering ausbrüteten? Nun, sprechen wir jetzt darüber.

Frameworks wie Gatsby, Next und Nuxt fungieren als Frontend-Engines, die auf Komponenten-Frameworks wie React und Vue aufbauen. Sie bündeln Werkzeuge, um eine umfassende Frontend-Erfahrung mit ihrem bevorzugten Framework zu erstellen. Eine solche Funktion ist das Pre-Rendering, was bedeutet, dass diese Engines Komponenten introspektieren und dann statisches HTML auf der Seite schreiben, während die Website erstellt wird. Wenn Nutzer diese Seite dann aufrufen, ist sie tatsächlich schon da. Sie benötigen kein JavaScript, um sie anzuzeigen.

JavaScript kommt jedoch durch einen Prozess namens Hydration ins Spiel. Nachdem die Seite geladen ist und Ihr Nutzer alle (statischen) Inhalte sieht, beginnt die Arbeit des JavaScript. Es übernimmt die Komponenten, um sie interaktiv zu machen. Dies bietet die Möglichkeit, eine clientseitige, komponentenbasierte Website mit einigen der Vorteile des Servers zu erstellen, nämlich Performance und SEO.

Diese Tools sind wegen dieses Ansatzes sehr beliebt geworden, und ich vermute, dass wir ihre Weiterentwicklung sehen werden.

2. Integriertes clientseitiges Pre-Rendering

Das sind viele zusammengesetzte Wörter.

Worüber ich in den letzten Jahren viel nachgedacht habe, ist: Warum übernimmt React (oder Vue) nicht das serverseitige Rendering? Das tun sie, es ist nur nicht sehr einfach zu verstehen oder zu implementieren, ohne dass ein weiteres Framework hilft.

Einerseits verstehe ich das Single-Responsibility-Prinzip und dass diese Komponenten-Frameworks nur Mittel zum Aufbau clientseitiger Komponenten sind. Aber es fühlte sich wie ein großer Fehler an, das serverseitige Rendering an größere, komplexere Tools wie Gatsby und Next (neben anderen) zu delegieren.

Nun, React hat begonnen, sich in diese Richtung zu bewegen. Vue ist bereits dort. Und Svelte hat diesen Ansatz von Anfang an zur Priorität gemacht.

Ich denke, wir werden noch viel Entwicklung sehen, während diese traditionell auf Clientseite fokussierten Tools das serverseitige Rendering lösen. Ich vermute, das bedeutet auch, dass wir in Zukunft etwas mehr von Svelte hören werden, das in dieser Hinsicht an der Spitze zu sein scheint.

Das kann auch zur Entwicklung weiterer Wettbewerber zu sperrigeren Tools wie Gatsby und Next führen. Schauen Sie sich zum Beispiel an, was Netlify mit seiner Website macht. Es ist ein Eleventy-Projekt, das Vue-Komponenten einbindet und sie für die Verwendung auf dem Server rendert. Was ihm fehlt, ist das Hydration- und Interaktivitätsstück. Ich erwarte, dass sich das in sehr naher Zukunft zusammenfügen wird.

3. Serverseitige Komponenteninteraktivität

Und dennoch können wir die fortgesetzte Nutzung von serverseitigen Komponenten nicht außer Acht lassen. Der eine Nebeneffekt beider anderer Fortschritte ist, dass sie immer noch JavaScript-Frameworks verwenden, die unnötig erscheinen können, wenn man nur ein kleines bisschen Interaktivität benötigt.

Es muss einen einfacheren Weg geben, ein kleines bisschen JavaScript hinzuzufügen, um eine serverseitige Komponente, die in einer serverseitigen Sprache geschrieben ist, interaktiver zu machen.

Die Lösung dieses Problems scheint der Ansatz der Leute von Basecamp zu sein, die gerade Hotwire veröffentlicht haben, ein Mittel, um einige der Vorteile von Clientkomponenten auf den Server zu bringen, unter Verwendung von (fast) jeder serverseitigen Sprache.

Ich weiß nicht, ob das bedeutet, dass wir sofort Konkurrenz zu Hotwire sehen werden. Aber ich glaube, Hotwire wird viel Aufmerksamkeit bekommen. Und das könnte Leute dazu bringen, wieder mit Full-Stack-Monolithen-Frameworks wie Rails zu arbeiten. (Persönlich liebe ich es, dass Rails in dieser JavaScript-fokussierten Welt nicht obsolet geworden ist. Je mehr Wettbewerb wir haben, desto besser wird das Web.)

Wo denkst du, wird all das Komponenten-Geschäft hingehen? Lassen Sie uns darüber sprechen.