Auswirkungen des Denkens in Blöcken statt Blobs

Gutenberg ist ein JavaScript-basierter Editor (genauer gesagt ein React-basierter Editor), der bald die Erfahrung beim Erstellen von Inhalten für WordPress und (in einer bevorstehenden Phase, wenn Gutenberg in einen Site Builder umgewandelt wird) die Erfahrung beim Erstellen verändern wird WordPress-Seiten.

Gutenberg, der Site-Builder, wird eine andere Denkweise verlangen, wie man die Grundlagen einer Website legt. In dem, was wir bereits als „altes“ Modell bezeichnen können, werden WordPress-Sites erstellt, indem durch Vorlagen ( header.php , index.php , sidebar.php , footer.php ) eine Struktur gegeben wird und der Inhalt der Seite aus einem einzigen Blob abgerufen wird von HTML-Code. Im neuen Modell verfügt die Seite über (React)-Komponenten, die über die ganze Seite verteilt sind, von denen jede ihre eigene Logik steuert, ihre eigenen Daten lädt und sich selbst rendert.

Um die bevorstehende Änderung visuell zu würdigen, bewegt sich WordPress hiervon ab:

… dazu:

Ich glaube, dass der Wechsel von HTML-Code-Blobs zu Komponenten für Baustellen nichts weniger als ein Paradigmenwechsel ist. Gutenbergs Wirkung ist viel mehr als ein Wechsel von PHP zu JavaScript: Es gibt Dinge, die in der Vergangenheit getan werden konnten, die möglicherweise keinen Sinn mehr machen. Ebenso eröffnet sich eine neue Welt voller Möglichkeiten, wie z. B. reichhaltige und leistungsstarke Benutzerinteraktionen. Webentwickler werden nicht von der Erstellung ihrer Sites in einer Sprache zur Erstellung ihrer Sites in einer anderen Sprache übergehen, da die Site nicht mehr dieselbe sein wird; es wird eine völlig andere Website sein, die gebaut wird.

Empfohlene Lektüre : Die vollständige Anatomie des Gutenberg-WordPress-Editors

Gutenberg wurde aus vielen Gründen noch nicht vollständig von der WordPress-Community angenommen. Zum einen basiert die neue Architektur auf einer Fülle von Tools und Technologien (React, NPM, Webpack, Redux usw.), die viel schwieriger zu erlernen und zu beherrschen sind als die alte PHP-basierte. Und obwohl es sich lohnen kann, einen neuen Stack zu lernen, der neue Funktionalitäten bietet, benötigt nicht jede Tante-Emma-Site diese neuen, glänzenden Funktionen.

Schließlich ist es kein Zufall, dass 30 % aller Sites weltweit WordPress-Sites sind: Die meisten davon sind wirklich einfache Sites wie Blogs, keine dynamischen sozialen Netzwerke wie Facebook. Zum anderen bedeutet WordPress-Inklusivität, dass jeder eine einfache Website erstellen kann – sogar Menschen ohne Programmiererfahrung, wie Designer, Content-Vermarkter und Blogger.

Aber die Komplexität der neuen Architektur wird viele Leute außen vor lassen (ich möchte gar nicht daran denken, meine Seite in verkleinertem JavaScript-Code zu debuggen). Und zum anderen, sobald Gutenberg live geht, wird Facebook-unterstütztes React zu bis zu 30 % aller Websites der Welt hinzugefügt – über Nacht. Vielen Leuten ist es unangenehm, irgendeiner Art von JavaScript-Bibliothek so viel Macht zu geben, während viele andere Facebook gegenüber misstrauisch sind. Um diese Bedenken auszuräumen, hat Gutenberg React abstrahiert, um auch die Codierung in anderen Frameworks oder Bibliotheken zu ermöglichen; In der Praxis wird React jedoch zweifellos die vorherrschende JavaScript-Bibliothek sein.

Und doch ist die Aussicht, eine neue Welt voller Möglichkeiten geboten zu bekommen, in der Tat süß. In meinem Fall bin ich begeistert. Meine Begeisterung gilt jedoch nicht der Technologie (React) oder der Umsetzung (Gutenberg), sondern dem Konzept, Websites aus Komponenten als Baueinheit zu erstellen. In Zukunft wird die Umsetzung möglicherweise auf eine andere Plattform wie Vue wechseln, das Konzept bleibt jedoch bestehen.

Es ist nicht immer einfach vorherzusehen, welche neuen Funktionen wir implementieren können. Es braucht Zeit, sich an ein neues Paradigma anzupassen, und wir neigen dazu, neue Werkzeuge auf die alte Weise zu verwenden, bis uns klar wird, wie wir die neuen Werkzeuge verwenden können, um neue Ziele zu erreichen. Sogar PDF-Dateien (die eine Repräsentation von Print darstellen, der vorherrschenden Technologie vor der Geburt des Internets) sind immer noch ein alltäglicher Anblick im Web, wobei die Vorteile vernachlässigt werden, die das Web gegenüber dem Druck hat.

„Papier auf einem Computerbildschirm nachzuahmen ist, als würde man einer 747 die Flügel abreißen und sie als Bus auf der Autobahn benutzen.“

– Ted Nelson

In diesem Artikel werde ich verschiedene Implikationen von Baustellen durch eine komponentenbasierte Architektur (als Konzept) und durch Gutenberg (als Implementierung) analysieren, einschließlich, welche neuen Funktionalitäten sie liefern kann und wie viel besser sie sich in die aktuelle Website-Entwicklung integrieren lässt Trends und was sie für die Zukunft von WordPress bedeuten.

Erweiterte Vielseitigkeit und Verfügbarkeit von Inhalten

Ein sehr wichtiger Nebeneffekt der Behandlung aller Inhalte als Blöcke besteht darin, dass HTML-Blöcke einzeln anvisiert und für verschiedene Ausgaben verwendet werden können. Während in das HTML-Blob eingefügte Inhalte nur über die Webseite zugänglich sind, kann auf sie als Chunks über eine API zugegriffen werden, und ihre Metadaten sind leicht verfügbar. Nehmen Sie Medienelemente – wie Videos, Audio oder Bilder. Als eigenständiger Block kann das Video in einer App abgespielt werden, das Audio kann als Podcast abgespielt werden und die Bilder können beim Senden eines Digests an die E-Mail angehängt werden – all dies, ohne den HTML-Code parsen zu müssen.

Ebenso können Inhalte aus Blöcken für verschiedene Medien angepasst werden: vom kleinsten bis zum größten Bildschirm, Touchscreen oder Desktop, per Sprache oder per Berührung, 2D/AR/VR oder wer weiß, was die Zukunft bringen könnte. Ein Audioblock ermöglicht beispielsweise die Wiedergabe des Audios auf einer Apple Watch, die per Sprache über das In-Car-System oder ein AWS Echo gesteuert wird, oder als schwebendes Element in unserer virtuellen Welt, wenn ein VR-Headset verwendet wird. Blocks können es auch einfacher machen, eine einzige Quelle der Wahrheit für Inhalte einzurichten, die in verschiedenen Ausgaben veröffentlicht werden sollen, wie z. B. einer reaktionsschnellen Website, AMP, mobilen App, E-Mail oder anderen, wie es NPR durch ihr „Create Once“ getan hat , Publish Everywhere (COPE)-Ansatz.

Hinweis : Für weitere Informationen zu diesen Themen empfehle ich, Karen McGranes Content in a Zombie Apocalypse Talk anzuschauen.

Blöcke können auch die Benutzererfahrung verbessern. Wenn Sie die Website über 3G durchsuchen, können Blöcke in einem langsamen Verbindungsmodus selbst rendern, um Bilder mit geringer Qualität anzuzeigen und das Laden von Videos zu überspringen. Oder es kann das Layout verbessern, indem beispielsweise angeboten wird, eine Bildergalerie mit einem Klick an jeder Stelle der Webseite anzuzeigen, und nicht nur an der Stelle, an der sie in den Artikel eingebettet wurde.

Diese Erfahrungen können durch die Trennung von Inhalt und Form erreicht werden, was bedeutet, dass die Präsentation und die Bedeutung des Inhalts entkoppelt werden und nur die Bedeutung in der Datenbank gespeichert wird, Präsentationsdaten zweitrangig werden und an einem anderen Ort gespeichert werden. Semantisches HTML ist ein Ausdruck dieses Konzepts: Wir sollten immer <em> verwenden, was eine Bedeutung impliziert, anstelle von <i> , das eine Form der Darstellung ist (um das Zeichen kursiv anzuzeigen), weil dann dieser Inhalt für verfügbar ist andere Medien, wie z. B. Sprache (Alexa kann nicht kursiv lesen, aber sie kann den Satz betonen).

Es ist sehr schwierig, eine gründliche Trennung von Inhalt und Form zu erreichen, da Präsentationscode oft innerhalb des Blocks durch HTML-Markup hinzugefügt wird (das Hinzufügen der Klasse „Pull-right“ impliziert bereits eine Präsentation). Die Architektur der Site mithilfe von Blöcken trägt jedoch bereits dazu bei, ein gewisses Maß an Trennung auf Layoutebene zu erreichen. Darüber hinaus können Blöcke, die nur für eine Sache erstellt wurden und dies sehr gut tun, geeignetes semantisches HTML verwenden, haben eine gute Trennung von Bedenken in ihrer eigenen Architektur in Bezug auf HTML, JS und CSS (so dass sie auf andere Plattformen portiert werden können möglicherweise nur einen minimalen Aufwand erfordern) und zumindest auf Komponentenebene zugänglich sind.

Hinweis : Als allgemeine Faustregel gilt: Je umfassender eine Komponente ist, desto besser ist sie auf noch zu erfindende Medien vorbereitet.

Leider wurde Gutenberg nicht für diesen Zweck entwickelt, daher enthalten Blöcke auch viel HTML-Markup für die Präsentation. Beispielsweise hat ein Bildblock aus einem externen Bild als Bedeutung nur die URL für das Bild, die Alt-Beschreibung und die Bildunterschrift (und möglicherweise auch die Breite und Höhe); Nach dem Erstellen eines Bildblocks wurde der folgende Codeabschnitt in der DB gespeichert (die Klasse aligncenter dient der Präsentation, und das Markup <div class="wp-block-image" /> wäre vollständig überflüssig, wenn nur die Bedeutung gespeichert würde):

 <!-- wp:image {"align":"center"} --> <div class="wp-block-image"> <figure class="aligncenter"> <img src="https://cldup.com/cXyG__fTLN.jpg" alt="Beautiful landscape"/> <figcaption>If your theme supports it, you'll see the "wide" button on the image toolbar. Give it a try.</figcaption> </figure> </div> <!-- /wp:image -->

Außerdem werden Blöcke innerhalb des Inhalts des Beitrags (der ein großer HTML-Blob ist) gespeichert, anstatt dass jeder einen eigenen Eintrag in der Datenbank hat. Wiederverwendbare Blöcke (auch globale Blöcke genannt) haben jedoch ihren eigenen Eintrag, was mich befürchten lässt, dass Entwickler Standardblöcke in wiederverwendbare Blöcke konvertieren könnten, nur um einen schnellen Hack zu machen, um direkt in der DB darauf zuzugreifen.

Ebenso mache ich mir Sorgen, dass Blöcke, wenn sie nicht richtig gestaltet sind, sogar Chaos auf unseren Websites anrichten können. Unbewusste Entwickler können beispielsweise die Regel der geringsten Leistung ignorieren und JavaScript nicht nur für die Funktionalität, sondern auch für CSS und Markup verwenden. Darüber hinaus ist die serverseitige Rendering-Funktionalität (SSR) von Gutenberg nicht isomorph (dh sie erlaubt nicht, dass eine einzige Codebasis die Ausgabe sowohl für den client- als auch für den serverseitigen Code erzeugt), daher müssen dynamische Blöcke die Funktion zum Generieren des HTML-Codes implementieren auch als PHP, um eine progressive Erweiterung anzubieten (ohne die die Site beim anfänglichen Laden nicht zugänglich ist).

Zusammenfassend sind Blöcke ein Schritt in die richtige Richtung, um WordPress-Inhalte in jedem Format und für jedes Medium verfügbar zu machen, aber sie sind keine endgültige Lösung, so dass noch viel Arbeit erforderlich ist.

Leistung

Leistung zählt. Schnellere Websites führen zu zufriedeneren Benutzern, was zu besseren Konversionsraten führt. Das Team von Etsy zum Beispiel stellt neue Funktionen, so cool sie auch sein mögen, ins Regal, wenn diese dazu führen, dass die Ladezeit der Website einen kritischen Schwellenwert überschreitet (ich empfehle, sich Allison McKnights Vortrag über „Building Performance for the Long Term“ und Folien anzusehen). Das Team von Twitter hat seine Website vor einigen Jahren neu gestaltet, um serverseitiges Rendering zu unterstützen, um Inhalte so schnell wie möglich anzuzeigen, und implementiert kontinuierlich viele kleine Änderungen, die sich summieren, um eine schnelle Benutzererfahrung zu liefern.

JavaScript ist für Entwickler so attraktiv, dass sie keine Einschränkungen bei ihrer Verwendung erfahren, was ein echtes Problem darstellt: JavaScript ist sehr leistungsintensiv und sollte sehr vorsichtig verwendet werden.

So wie es jetzt aussieht, ist Gutenberg alles andere als optimal: Während das Erstellen eines Beitrags mit dem alten Editor (für den wir den Classic Editor installieren müssen) das Laden von etwa 1,4 MB JavaScript erfordert, lädt Gutenberg etwa 3,5 MB JavaScript, nur für seine Basis Erfahrung (d. h. ohne Installation eines zusätzlichen Blocks):

Das bedeutet, dass derzeit 3,5 MB die Grundlinie sind und die Ladegröße von dort aus nur zunimmt, wenn der Site-Administrator mehr Blöcke installiert. Wie in einem kürzlich erschienenen Artikel im Smashing Magazine zu sehen war, erforderte die Erstellung eines Testimonials-Blocks 150 KB minimiertes JavaScript. Wie viele Blöcke benötigt eine Standard-Site? Wie viele MB JavaScript muss die durchschnittliche Website herunterladen?

Die Auswirkungen sind vielfältig: Zum einen ist eine umfangreiche Website für die nächste Milliarde Benutzer unerreichbar, die hauptsächlich über langsame Verbindungen Zugriff haben und Datentarife kaufen, die einen erheblichen Teil ihres Gehalts ausmachen. Für sie macht jedes MB an Daten einen Unterschied: Das Versenden von Whatsapp-Nachrichten ist erschwinglich, das Herunterladen mehrerer MB an Skripten, nur um eine Seite zu laden, nicht.

Es ist wahr, dass der Benutzer der Website nicht mit Gutenberg interagieren muss, da Gutenberg lediglich zum Erstellen der Website dient, nicht zum Verwenden: Gutenberg ist ein Back-End-Editor, kein Front-End-Editor (und möglicherweise niemals sein – zumindest als Teil des WordPress-Kerns). Die Ersteller von Inhalten werden jedoch bestraft, und sie sind bereits ein beträchtliches Ziel. Darüber hinaus (wie ich bereits argumentiert habe) werden Benutzer möglicherweise auch durch dynamische Blöcke bestraft, die ihr Markup möglicherweise durch clientseitiges JavaScript anstelle von serverseitigem PHP erstellen.

Es gibt auch das Problem der Aufblähung durch doppelte Funktionalität, die durch Plugins von Drittanbietern hinzugefügt wird. Früher hat eine WordPress-Site möglicherweise mehrere Versionen von jQuery geladen, was relativ einfach zu beheben war. Heutzutage gibt es eine riesige Auswahl an Open-Source-Bibliotheken, aus denen Sie wählen können, um eine benötigte Funktionalität zu implementieren (Drag and Drop, Kalender, Mehrfachauswahlkomponenten, Karussells usw.), also höchstwahrscheinlich eine Website mit Dutzenden von Blöcken von Drittanbietern wird die gleiche Funktionalität haben, die von verschiedenen Bibliotheken implementiert wird, wodurch unnötige Aufblähung entsteht. Darüber hinaus wird Gutenberg selbst etwas aufgebläht: Da Blöcke im Frontend registriert werden, erfolgt die Aufhebung der Registrierung eines bereits registrierten Blocks durch Laden eines zusätzlichen Skripts. Meiner Meinung nach ist dies eine der größten Herausforderungen für die Gutenberg-Mitwirkenden: einen rationalisierten Prozess einzurichten, der es jedem (nicht nur Entwicklern mit Erfahrung mit Webpack) ermöglicht, unerwünschte Bibliotheken zu entfernen und nur die minimalen Ressourcen zu packen, die für die Anwendung benötigt werden .

Abschließend erwähne ich noch einmal, dass Gutenberg serverseitiges Rendering unterstützt, aber weil es möglicherweise nicht einfach zu warten ist, könnten Entwickler versucht sein, sich nicht darauf zu verlassen. In diesem Fall entstehen die Kosten für zusätzliche Roundtrips, die erforderlich sind, um die Daten von den REST-Endpunkten abzurufen, nur um das Layout zu rendern, während der Benutzer warten muss.

Meiner Meinung nach wird die Leistung eine der größten Herausforderungen für Gutenberg sein, die im Hinblick auf eine weit verbreitete Akzeptanz über Erfolg oder Misserfolg entscheiden kann, und es gibt noch viel zu tun, vor allem in Bezug auf die nächste Stufe, wenn Gutenberg eine Website wird Baumeister.

Webstandards

Wie bereits erwähnt, abstrahiert Gutenberg React, um einen Framework-agnostischen Ansatz für Bausteine ​​bereitzustellen, der bei richtiger Implementierung verhindern kann, dass WordPress an React gebunden wird. Die WordPress-Community ist vorsichtig, wenn es darum geht, ein JavaScript-Framework in den WordPress-Kern zusammenzuführen, zum großen Teil, weil Backbone.js, nicht lange nachdem es dem WordPress-Kern hinzugefügt wurde, einen starken Rückgang der Popularität verzeichnete und abgesehen von der Stromversorgung des Media Managers nicht viele Funktionen erreicht wurden damit. Auch wenn React derzeit die beliebteste JavaScript-Bibliothek ist, gibt es keinen Grund zu der Annahme, dass dies immer der Fall sein wird (wie die Enträtselung von jQuery belegen kann), und WordPress muss darauf vorbereitet sein, wenn dieser Tag endlich kommt (was angesichts der schnellen Tempo der Technologie, kann früher als erwartet eintreten).

Der beste Weg, um zu vermeiden, an eine Bibliothek gebunden zu sein, sind Webstandards und in diesem Fall genauer gesagt die Implementierung von Blöcken durch Webkomponenten. Webkomponenten sind stark gekapselte Komponenten, die mit den Browser-APIs arbeiten, sodass für ihre Arbeit keine JavaScript-Bibliothek erforderlich ist. Sie können jedoch über jedes clientseitige JavaScript-Framework implementiert werden.

Auch wenn React noch keine nahtlose Integration mit Webkomponenten bietet, wird es dies irgendwann (oder besser gesagt hoffentlich) tun. Wie in der Dokumentation von React erklärt wird, können Webkomponenten und React-Komponenten zusammenarbeiten:

„React- und Web-Komponenten wurden entwickelt, um unterschiedliche Probleme zu lösen. Webkomponenten bieten eine starke Kapselung für wiederverwendbare Komponenten, während React eine deklarative Bibliothek bereitstellt, die das DOM mit Ihren Daten synchron hält. Die beiden Ziele ergänzen sich. Als Entwickler steht es Ihnen frei, React in Ihren Webkomponenten oder Webkomponenten in React oder beides zu verwenden.“

Stand heute sind die Aussichten für diese Situation nicht sehr vielversprechend: Ich habe keine Anleitung für Bausteine ​​mit Webkomponenten gefunden. Ich glaube, die Community sollte sich auf diese Sache konzentrieren und Entwickler ermutigen, mit dem Bau von Blöcken mit Webkomponenten zu beginnen, und zwar je früher, desto besser, da Gutenberg uns ohnehin dazu zwingt, neue Technologien zu lernen, und zwar jetzt. Es ist eine Gelegenheit, von Anfang an eine starke Grundlage mit Webstandards zu schaffen.

Interoperabilität zwischen Standorten, Homogenisierung von Standorten

Ein Block ist eine kleinere Einheit als ein Theme oder ein Plug-in, sodass Blöcke irgendwann für sich allein zugänglich sein und über neu geschaffene Blockmärkte erworben werden können. Höchstwahrscheinlich wird es zunächst zu einer kambrischen Explosion von Blöcken kommen, da sich viele Akteure im Ökosystem beeilen, ihre Lösungen als Erste zu vermarkten, was mittel- und langfristig zu einer Konsolidierung der erfolgreichsten führt.

Sobald sich der Staub gelegt hat, werden einige Blöcke hervorstechen und zu Gewinnern werden, die den größten Teil des Marktes in ihren spezifischen Kategorien einnehmen. Wenn/wann das passiert, wird dies sowohl Anlass zur Sorge als auch zum Jubel sein: Besorgnis über eine neue Welle der Homogenisierung des Webs (wie es bei Bootstrap geschah), da Websites, die dieselben Komponenten verwenden, möglicherweise dasselbe Erscheinungsbild haben , ein Jubel über eine erhöhte Interoperabilität zwischen Websites, die sich auf dieselben Komponenten und dieselben APIs verlassen, was die Tore zu neuen Möglichkeiten öffnen kann.

Ich freue mich besonders über die Erweiterung der Interoperabilität zwischen den Standorten. Es ist ein Bereich, der langfristig Königreiche wie das von Facebook zunichte machen könnte: Anstatt sich auf ein monopolistisches Gateway für den Informationsaustausch zu verlassen, können Websites mit verschiedenen Communities Daten einfach und direkt untereinander austauschen. Dies ist kein neues Konzept: Die IndieWeb-Bewegung arbeitet seit langem daran, es jedem zu ermöglichen, seine eigenen Daten auf seinen eigenen Servern zu besitzen, indem Websites über Mikroformate miteinander kommunizieren. Zum Beispiel ermöglicht ihr Webstandard Webmention eine Unterhaltung zwischen zwei Sites, bei der jeder Kommentar und jede Antwort auf beiden gespeichert wird, und Micro.blog bietet eine Art Twitter, aber basierend auf dem offenen Web, in dem die Beiträge veröffentlicht werden auf der Chronik des Benutzers werden aus RSS- und JSON-Feeds von abonnierten Websites gesammelt. Diese Unternehmungen sind wunderbar, haben aber immer noch sehr geringe Auswirkungen, da ein gewisses Maß an technischem Verständnis erforderlich ist, um daran teilzunehmen. Die komponentenbasierte Architektur von Gutenberg kann möglicherweise eine viel breitere Wirkung erzielen: Beliebte Blöcke können es Dutzenden von WordPress-Sites ermöglichen, miteinander zu kommunizieren, wodurch schließlich bis zu 30 % aller Sites im Web Teil eines dezentralisierten, lose gekoppelten Netzwerks werden können .

Dieser Bereich wird jedoch viel Arbeit erfordern, bevor er rentabel ist. Ich denke nicht, dass die Standard-REST-Endpunkte die beste Kommunikationsschnittstelle sind, da sie nicht für diesen Zweck konzipiert wurden (die Leute von micro.blog haben eine bessere Lösung durch ihre JSON-Schnittstelle vorgeschlagen, die auf der RSS-Spezifikation basiert). Außerdem wird REST selbst durch GraphQL obsolet, sodass ich langfristig keine großen Hoffnungen darauf setzen würde. Ich bin auch daran beteiligt, einen besseren Weg zu finden, für den ich derzeit an einer anderen Art von API arbeite, die alle erforderlichen Daten in nur einer Anfrage abrufen kann und die Erweiterbarkeit durch eine komponentenbasierte Architektur unterstützt.

Ich gehe auch davon aus, dass die Integration mit Cloud-Diensten stärker in den Vordergrund rücken wird, da Anbieter ihre eigenen Blöcke freigeben können, um mit ihren eigenen Diensten zu interagieren. Da eine Komponente eine eigenständige Einheit ist, erledigt das einfache Ziehen und Ablegen des Blocks auf der Seite aus der Sicht des Benutzers bereits die gesamte Arbeit, wodurch es sehr einfach ist, leistungsstarke Websites mit wenig oder gar keinem Wissen zu erstellen. Beispielsweise könnte ein Bildspeicheranbieter wie Cloudinary einen Block freigeben, der das Bild automatisch entsprechend dem Anzeigebereich des Geräts zuschneidet, oder das Bild als WebP anfordern, falls unterstützt, oder andere Anwendungsfälle.

Zusammenfassend lässt sich sagen, dass die Konsolidierung des Blockmarktes zu einer Homogenisierung seines Aussehens und seiner Haptik führen kann, was ein bedauerliches Ereignis wäre und vermieden werden sollte, und zu leistungsstarken Funktionen in Bezug auf Interoperabilität und Datenaustausch zwischen Standorten und die Integration mit Cloud-Diensten.

Integration mit Musterbibliotheken

Eine Musterbibliothek ist eine Sammlung von Designelementen für Benutzeroberflächen, die häufig jeweils aus HTML-, JS- und CSS-Schnipseln bestehen. Ein Block ist eine autonome Komponente, die häufig aus HTML-, JS- und CSS-Elementen besteht. Blöcke sind also offensichtlich gut geeignet, um mit Musterbibliotheken dokumentiert/gebaut zu werden. Blöcke mit ihren Musterbibliotheken auszuliefern, wäre eine tolle Sache, da es Teams ermöglichen könnte, die Musterbibliothek der Site nicht nur auf Site-Ebene zu implementieren, sondern als Aggregation und Verfeinerung der Mini-Musterbibliotheken aus allen erforderlichen Blöcken.

Ich glaube, dass in diesem Fall etwas Ähnliches passiert wie der zuvor erwähnte Rationalisierungsprozess zum Erstellen von aufblähten JavaScript-Paketen, aber in Bezug auf UI/UX/Dokumentation. Es wäre sowohl eine Herausforderung als auch eine Gelegenheit für Gutenberg-Mitwirkende, einen Prozess einzurichten, der es Blockentwicklern erleichtert, Musterbibliotheken für ihre Blöcke zu erstellen, die, wenn sie alle zusammengeführt werden, zu einer kohärenten Musterbibliothek für die Website führen können. Gut implementiert, könnte eine solche Funktion die Kosten von Baustellen aus Sicht der Dokumentation/Wartung senken.

Was wird aus WordPress?

Sicherlich wird Gutenberg Websites attraktiver machen, allerdings auf Kosten eines erforderlichen Fachwissens, das nicht jeder beherrschen wird. Langfristig kann dies zu höherer Qualität und geringerer Quantität führen. Ausgehend von der WordPress-Maxime „Democratizing Publishing“ kann dies zum Problem werden.

Ich bin begeistert von Gutenberg, aber eher als Konzept einer komponentenbasierten Architektur, als als React-basierte Implementierung. Im Allgemeinen stimme ich dem zu, was Matt Mullenweg während des WordCamp Europe 2018 sagte, um Gutenberg zu rechtfertigen:

„Das Fundament von WordPress, das uns jetzt fünfzehn Jahre lang gute Dienste geleistet hat, wird nicht die nächsten fünfzehn Jahre überdauern.“

Ich glaube jedoch auch, dass das WordPress von fünfzehn Jahren in der Zukunft am Ende völlig anders sein wird als das, das wir heute kennen. Ich frage mich, ob WordPress am Ende in erster Linie der Client-basierte Editor sein wird und nicht viel mehr: Die Initiative, Gutenberg in Drupal zu integrieren, mit dem Ziel, Gutenberg zum Editor des offenen Webs zu machen, wird WordPress als Headless-CMS offiziell machen über REST-Endpunkte. Das ist an sich schon eine gute Entwicklung, macht aber WordPress als Backend entbehrlich: Wenn irgendeine andere Backend-Plattform bessere Features bietet, gibt es keinen Grund mehr, am WordPress-Backend festzuhalten. Schließlich wird Gutenberg auf der Client-Seite mit jedem von ihnen arbeiten können, während die Einfachheit der Erstellung einer Website mit WordPress verloren geht, wodurch das Spielfeld mit allen anderen Plattformen ausgeglichen wird.

Insbesondere würde es mich nicht überraschen, wenn Entwickler das Aufrechterhalten von zwei Codebasen (eine in JavaScript und eine in PHP) zum Rendern dynamischer Blöcke für zu anstrengend halten und sich entscheiden, auf Plattformen umzusteigen, die isomorphes serverseitiges Rendering unterstützen. Wenn dieses Szenario tatsächlich eintritt, würde Matt entscheiden, das WordPress-Backend auf Node.js umzustellen?

Vor allem wegen dieses Problems wage ich zu sagen, dass das WordPress von heute in 15 Jahren eine ganz andere Einheit sein könnte als das, was es heute ist. Wer weiß, was passieren wird?

Fazit

Indem Komponenten zur neuen Einheit für Baustellen gemacht werden, wird die Einführung von Gutenberg zu WordPress führen. Und wie bei jedem Paradigmenwechsel wird es Gewinner und Verlierer geben. Verschiedene Interessengruppen werden Gutenberg je nach ihrer eigenen Situation als positive oder negative Entwicklung betrachten: Während die Qualität einer Website steigt, wird der Preis für den Aufbau einer solchen Website durch die Einstellung von Entwicklern, die mit ihrer Komplexität umgehen können, ebenfalls steigen, wodurch sie weniger erschwinglich wird und weniger beliebt.

Dies sind aufregende Zeiten, aber auch entscheidende Zeiten. Von nun an könnte WordPress langsam anfangen, eine andere Entität zu sein, als wir es gewohnt sind, und wir müssen möglicherweise noch einmal darüber nachdenken, was WordPress ist und was es darstellt.