WordPress und Jamstack

Ich moderierte kürzlich ein Panel auf der virtuellen Jamstack Conf von Netlify, zu dem der CEO von Netlify, Matt Biilman, und der Gründer von Automattic, Matt Mullenweg, gehörten. Die ganze Sache wurde – zumindest für einige – als ein „Jamstack vs. WordPress“-Showdown aufgebaut.

Ich habe viele eigene Gedanken dazu und denke, dass ich als Experte nützlicher bin als als Moderator. Dies ist eines meiner Lieblingsgespräche im Tech-Bereich! Erlauben Sie mir also, zu bloggen.

Offenlegung: Sowohl Automattic als auch Netlify sind aktive Sponsoren dieser Website. Ich habe Produktionswebsites, die beide nutzen, und ehrlich gesagt, ich bin ein Fan von beiden, was ein übergreifender Punkt ist, den ich zu machen versuche. Ich schreibe und veröffentliche dies auch auf einer WordPress-Website.

Verlauf

1. Richard MacManus veröffentlichte „WordPress Mitbegründer Matt Mullenweg ist kein Fan von JAMstack“ mit Zitaten aus einer E-Mail-Unterhaltung zwischen ihnen, ein Satz von Matt, der lautete: „JAMstack ist eine Regression für die überwiegende Mehrheit der Leute, die es annehmen.“
2. Matt Biilmann veröffentlichte eine Antwort „Zu Mullenweg und dem Jamstack – Regression oder Zukunft?“ mit einem ganzen Abschnitt mit dem Titel „Das Ende der WordPress-Ära“.
3. Leute haben sich zwischendurch zu Wort gemeldet. Netlify Board Member Ohad Eder-Pressman schrieb einen offenen Brief. Sarah Gooding fasste einige der Aktivitäten auf WP Tavern (die Matt Mullenweg gehört) zusammen. Ich habe mich auch zu Wort gemeldet.
4. Matt Mullenweg stellte seine Bemerkungen mit neuen Spitzen klar.

Die Debatte fand am 6. Oktober auf der Jamstack Conf Virtual 2020 statt. Es gibt kein öffentliches Video davon (Entschuldigung).

Der Stack

Jamstack mit WordPress zu vergleichen ist etwas seltsam. Was vergleichbar ist, ist die Tatsache, dass sie beide Wege sind, die man beim Erstellen einer Website einschlagen kann. Vieles in diesem Beitrag wird dies berücksichtigen und die beiden auf diese Weise vergleichen. Warum sie nicht direkt vergleichbar sind, liegt daran, dass

• Jamstack ist eine lose Beschreibung einer architektonischen Philosophie, die statische Dateien auf CDNs und JavaScript-zugängliche Dienste für dynamische Bedürfnisse fördert.
• WordPress ist ein CMS auf dem LAMP-Stack.

Diese Dinge sind nicht Äpfel mit Äpfeln zu vergleichen.

Wenn wir uns nur einen Moment lang auf den Stack konzentrieren, wäre der Vergleich zwischen

• Statisches Hosting + Dienste
• LAMP

Ein Beispiel für Static + Services ist die Verwendung von Netlify für das Hosting (das statisch ist) und die Verwendung von Diensten, um alles Dynamische zu tun, was Sie benötigen. Vielleicht nutzen Sie die eigenen Formular- und Authentifizierungsfunktionen von Netlify und Hasura für die Datenspeicherung.

Auf einem LAMP-Stack haben Sie MySQL, um Daten zu speichern, sodass Sie sich hier nicht an einen externen Dienst wenden müssen. Sie haben auch PHP zur Verfügung. Mit diesen (zusätzlich zu Open-Source-Software) haben Sie alles, was Sie für die Authentifizierung benötigen. Das bedeutet nicht, dass Sie niemals auf Dienste zurückgreifen; Sie tun dies nur seltener, da Sie mehr Technologie zur Hand haben, als Sie von dem Server haben, den Sie bereits besitzen.

Matt B. bezeichnete den LAMP-Stack als „Monolith“. Matt M. widersprach diesem Begriff und nannte ihn einen „integrierten Ansatz“. Ich bin kein Informatiker, aber ich könnte mir vorstellen, dass dies in beide Richtungen gehen kann. Hier ist Wikipedia

[…] eine monolithische Anwendung beschreibt eine einstufige Softwareanwendung , bei der die Benutzeroberfläche und der Datenzugriffscode in einem einzigen Programm zusammengefasst sind.

So definiert, scheint WordPress tatsächlich ein Monolith zu sein, und doch fährt der Wikipedia-Artikel fort:

[…] eine monolithische Anwendung beschreibt eine Softwareanwendung, die ohne Modularität konzipiert ist.

So gesehen scheint dies WordPress als Monolith zu disqualifizieren. Die Hook- und Plugin-Architektur von WordPress ist modular. 🤷‍♂️

Es wäre interessant zu hören, wie diese beiden Herren sich mit den Nuancen dort auseinandersetzen, aber die Software ist, wie sie ist. Eine selbst gehostete WordPress-Website läuft auf einem Server mit einem vollständigen Technologie-Stack. Es ist sinnvoll, so viel wie möglich von diesem Server zu verlangen (d. h. integriert). Bei einem Jamstack-Ansatz ist der Server von Ihnen abstrahiert. Alles andere, was Sie tun müssen, ist in verschiedene Dienste aufgeteilt (d. h. nicht integriert).

Der WordPress-Ansatz bedeutet nicht, dass Sie niemals auf externe Dienste zurückgreifen. In beiden Stacks würden Sie wahrscheinlich etwas wie Stripe für E-Commerce-APIs verwenden. Sie könnten etwas wie Cloudinary für robuste Medien speicherung und -bereitstellung verwenden. Sogar der Jetpack-Dienst von WordPress (den ich benutze und mag) bringt viel Leistung auf eine selbst gehostete WordPress-Website, indem er sich wie ein Drittanbieterdienst verhält und Dinge wie Asset-Hosting und Suchtechnologie von Ihren eigenen Servern auf Cloud-Server verlagert. Beide Stacks sind Konglomerate von Technologien.

Keiner der Stacks ist mehr ein „Kartenhaus“ oder anfälliger als der andere. Auf alle Websites kann die Metapher „nur so stark wie das schwächste Glied“ angewendet werden. Wenn ein WordPress-Plugin eine fehlerhafte Version liefert oder irgendwie beim Upload beschädigt wird, kann es meine Website ruinieren, bis ich sie repariere. Wenn meine API-Schlüssel für meine serverlose Datenbank ungültig werden, kann meine Jamstack-Website ruiniert sein, bis ich sie repariere. Wenn Stripe ausfällt, verkaufe ich keine Produkte auf irgendeiner Art von Website, bis sie wieder online sind.

Preise

WordPress.com hat einen kostenlosen Plan, und das ist absolut ein Ort, an dem Sie eine Website erstellen können. (Ich habe mehrere.) Aber Sie erhalten keinen Entwickler-Zugriff darauf, bis Sie den Business-Plan für 25 US-Dollar pro Monat haben. Selbst gehostetes WordPress ist Open Source und kostenlos, aber Sie werden keinen kostenlosen Ort finden, um eine selbst gehostete WordPress-Website hochzufahren. Es beginnt günstig und skaliert nach oben. Sie benötigen LAMP-Hosting, um WordPress auszuführen. Hier ist ein Überblick über relativ günstige Hosting-Pläne

• Ein „Shared“-Plan von Bluehost beginnt bei 3,95 $/Monat.
• Der niedrigste Plan bei Flywheel kostet 14 $/Monat. (Diese Website befindet sich auf einem höherwertigen Flywheel-Plan.)
• Media Temple hat WordPress-spezifisches Hosting ab 20 $/Monat. (Diese Website war lange Zeit auf einem High-Tier-Plan von Media Temple.)
• Automattics Pressable Service hat einen Plan ab 25 $/Monat.

Es steckt von Anfang an Geld dahinter.

Der kostenlose Start ist bei Jamstack viel üblicher, dann entstehen Kosten an verschiedenen Punkten. Da Jamstack neuer ist, fühlt es sich wie ein Markt an, der sich noch sortiert.

• Vercel ist kostenlos, bis Sie Teammitglieder oder Funktionen wie passwortgeschützte Websites benötigen. Eine einzelne passwortgeschützte Website kostet 150 $/Monat. Sie können Basisauthentifizierung zu jedem Server mit Apache ohne zusätzliche Kosten hinzufügen.
• Netlify ist sehr ähnlich und schaltet Funktionen in höheren Plänen frei und bietet à la carte-Funktionen pro Website, wie z. B. Analysen (9 $/Monat) und Authentifizierung (5.000 aktive Benutzer kosten 99 $/Monat).
• AWS Amplify beginnt kostenlos, aber wie bei allem auf AWS wird Ihre Nutzung auf vielen Ebenen gemessen, wie Build-Minuten, Speicher und Bandbreite. Sie haben eine Beispielberechnung für eine Web-App mit 10.000 täglichen aktiven Benutzern, die zweimal im Monat aktualisiert wird, was 65,98 $/Monat kostet.
• Azure Static Web Apps hat noch keine Preise veröffentlicht, wird aber mit ziemlicher Sicherheit eine kostenlose Stufe oder kostenlose Nutzung oder eine Art davon haben.

All das ist eine gute Erinnerung daran, dass Netlify nicht der einzige Akteur im Jamstack-Spiel ist. Jamstack bedeutet nur statisches Hosting plus Dienste.

Sie können keine Pauschalaussagen treffen wie Jamstack ist billiger. Es hängt viel zu stark vom Nutzungsumfang und den Bedürfnissen der Website ab. Bei hoher Nutzung und vielen Premium-Diensten kann Jamstack (ähnlich wie Serverless im Allgemeinen) super teuer werden. Jamstack gibt an, dass ihre Enterprise-Preise ab 3.000 $/Monat beginnen, und obwohl Sie Dinge wie Authentifizierung, Formulare und Medienverarbeitung erhalten, erhalten Sie kein CMS oder irgendeine Art von Datenspeicherung, was Sie wahrscheinlich viel höher treiben wird.

Obwohl diese WordPress-Website nicht für Unternehmen gedacht ist, kann ich Ihnen sagen, dass sie einen Server in der Nähe von 1.000 $/Monat benötigt, und das unter der Annahme, dass Cloudflare davor geschaltet ist, um die Bandbreite direkt zum Host zu reduzieren und Jetpack Dinge wie Medien-Hosting und Suchfunktionen übernimmt. Mailchimp sendet unseren Newsletter. Wufoo betreibt unsere Formulare. Wir haben auch kostenpflichtige Plugins wie Advanced Custom Fields Pro und einige WooCommerce-Add-ons. Das ist noch nicht alles. Es sind wahrscheinlich ein paar Tausend pro Monat insgesamt. Dies ist nicht nur bei einem integrierten Ansatz der Fall, sondern verdeutlicht, dass die Kosten einer WordPress-Website ebenfalls sehr hoch sein können. Sie veröffentlichen keine Preise (eine gängige Taktik für Unternehmen), aber Automattics eigener WordPress VIP Hosting-Service beginnt sicherlich im mittleren vierstelligen Bereich, bevor Sie Drittanbieter-Dinge hinzufügen.

Fazit: Hier findet kein Paradigmenwechsel bei den Preisen statt.

Performance

80 % der Web-Performance sind ein Front-End-Thema.

Das ist eine wahre Geschichte, aber sie basiert auch auf dem Fundament des Servers (der die ersten 20 % ausmacht). Das schnellste Front-End der Welt fühlt sich nicht schnell an, wenn die erste Antwort vom Server mehrere Sekunden dauert. Sie müssen sicherstellen, dass die erste Anfrage blitzschnell ist, wenn Sie eine schnelle Website wünschen.

Wissen Sie, was super schnell ist? Globale CDNs, die statische Dateien ausliefern. Das ist es, was Sie auf jeder Website tun wollen, unabhängig vom Stack. Während dies das Fundament von Jamstack (statisches CDN-basiertes Hosting) ist, bedeutet das nicht, dass WordPress dies nicht kann.

Sie nehmen eine index.html-Datei mit statischem Inhalt, legen sie auf Netlify, und sie wird blitzschnell sein. Vielleicht erstellt Ihr statischer Site-Generator diese Datei (die, wie erwähnt, sehr wohl Inhalte aus WordPress beziehen kann). Es gibt etwas sehr Schönes an der Robustheit und dem stabilen Fundament davon.

Standardmäßig erstellt WordPress keine statischen Dateien, die auf einem globalen CDN gecacht werden können. WordPress reagiert auf Anfragen von einem einzigen Ursprung, führt PHP aus, das Dinge aus der Datenbank abfragt, bevor eine Antwort zusammengestellt wird, und dann wird schließlich die Seite zurückgegeben. Das kann ziemlich schnell sein, aber es ist weitaus weniger stabil als eine statische Datei auf einem globalen CDN und es ist weitaus einfacher, mit Anfragen zu überlasten.

WordPress-Hosts wissen das und versuchen, das Problem auf Hosting-Ebene zu lösen. Sehen Sie sich nur WP Engines Ansatz an. Ohne dass Sie etwas tun, verwenden sie einen Seitencache, damit die Website im Wesentlichen eine statische Ressource zurückgeben kann, anstatt PHP ausführen oder eine Datenbank abfragen zu müssen. Sie setzen auch alle Arten von Caching ein, einschließlich der Partnerschaft mit Cloudflare, um das bestmögliche Caching zu erreichen. Während ich das schreibe, ist meine shoptalkshow.com Website buchstäblich ausgefallen. Ich habe mich an den Host, Flywheel, gewandt, um zu sehen, was los war. Es stellte sich heraus, dass ich, als ich dort hineinging, um eine Staging-Umgebung einzuschalten, einen falschen Schalter umgelegt und deren Caching ausgeschaltet habe. Die Website konnte den Traffic nicht bewältigen und ging einfach kaputt. Das erneute Einschalten des Caching-Schalters hat es sofort behoben. Ich hatte Cloudflare nicht vor der Website, aber das hätte ich tun sollen.

Cloudflare ist Teil der magischen Sauce, um WordPress schnell zu machen. Allein das Voranstellen vor Ihre selbst gehostete WordPress-Website leistet Wunder, um sie schnell und zuverlässig zu machen. Eines der fehlenden Puzzleteile war großartiges Caching des HTML selbst, das sie diesen Monat buchstäblich behoben haben und jetzt kann auch das gecacht werden. Es gibt eine Art lustige Ironie darin, dass das Caching von WordPress das Caching von Anfragen als statisches HTML und statische Assets bedeutet und deren Auslieferung von einem globalen CDN, was im Grunde das ist, was Jamstack am Ende des Tages ist.

Matt M. erwähnte, dass WordPress.com globale CDNs nutzt, die bei bestimmten Traffic-Stufen greifen. Ich bin mir nicht sicher, ob das Cloudflare ist oder nicht, aber ich bezweifle es nicht.

Mit Cloudflare vor einer WordPress-Website sehe ich die gleichen ersten Antwortzeiten wie auf Netlify-Websites ohne Cloudflare (da sie nicht empfehlen, Cloudflare vor Netlify-gehosteten Websites zu verwenden). Das sind mittlere zweistellige Millisekunden-Zahlen, was sehr, sehr gut ist.

Von diesem Fundament aus wird jede Diskussion über Performance zu einem Front-End-spezifischen Thema. Front-End-Taktiken für Geschwindigkeit sind die gleichen, unabhängig von der Situation auf dem Server, dem Hosting oder dem CMS auf der Back-End-Seite.

Sicherheit

Es gibt weitaus mehr Geschichten über gehackte WordPress-Websites als über Jamstack-Websites. Aber ist es fair zu sagen, dass WordPress weniger sicher ist? WordPress hat fast zwei Jahrzehnte Geschichte und es gibt um ein Vielfaches mehr Websites, die darauf basieren, als bei Jamstack. Abgesehen von der Sicherheit werden Sie bei WordPress mit diesen Zahlen mehr Geschichten finden.

Matt M. brachte vor, dass whitehouse.gov auf WordPress läuft, was offensichtlich eine Website ist, die höchste Sicherheitsstufen benötigt. Es ist nicht so, dass WordPress selbst unsichere Software ist. Es ist das, was Sie damit tun. Haben Sie unsichere Passwörter? Das ist unsicher, egal welche Plattform Sie verwenden. Ist der Server selbst unsicher durch Dateiberechtigungen oder Zugriffsebenen? Das ist nicht unbedingt die Schuld der Software, aber Sie könnten sich wegen der Software in dieser Position befinden. Führen Sie die neueste Version von WordPress aus? Die Nutzung ist bestenfalls fragmentiert, und je älter die Version, desto unsicherer wird sie sein. Knifflig.

Es mag interessanter sein, über Sicherheitsvektoren nachzudenken. Das heißt, an welchen Punkten es möglich ist, gehackt zu werden. Wenn Sie eine statische Datei auf einem statischen Hosting-Dienst haben, würde ich sagen, dass es ziemlich wenige Angriffsvektoren gibt. Aber trotzdem gibt es einige

• Ihr Hosting-Konto könnte gehackt werden
• Ihr Git-Repository könnte gehackt werden
• Ihr Cloudflare-Konto könnte gehackt werden
• Ihre Domain kann gestohlen werden (es passiert)

Das gilt auch für eine WordPress-Website, nur dass es zusätzliche Angriffsvektoren gibt wie

• Serverseitiger Code: XSS, schlechte Plugins, Remote-Ausführung usw.
• Datenbank-Schwachstellen
• Ausführen einer älteren, veralteten Version von WordPress
• Das Anmeldesystem befindet sich direkt auf der Website selbst, z. B. können böse Jungs /wp-login.php bombardieren.

Ich denke, es ist fair zu sagen, dass es mehr Angriffsvektoren bei einer WordPress-Website gibt, aber es gibt bei jeder Website genügend Vektoren. Das Hosting-Konto jeder Website ist ein großer Vektor. Alles, was in der DNS-Kette sitzt. Alle Drittanbieter-Dienste mit Anmeldungen. Alles mit einem API-Schlüssel.

Persönliche Erfahrung: Diese Website läuft auf WordPress und wurde noch nie gehackt, aber nicht aus Mangel an Versuchen. Ich habe das Gefühl, dass ich mich bei meinen WordPress-Websites mehr um die Sicherheit kümmern muss als bei meinen Websites, die nur aus statischen Website-Generatoren erstellt sind.

Skalierung

Die Skalierung beider Ansätze kostet Geld. Diese WordPress-Website ist nicht massiv skaliert, erfordert aber einige deutliche Skalierungen gegenüber den Einstiegsanforderungen an den Server. Ich leite den gesamten Traffic über Cloudflare, sodass ein Spitzenwert in den letzten 30 Tagen mir sagt, dass ich 5 TB Bandbreite pro Monat bediene.

Auf einem Netlify Business-Plan (600 GB Traffic für 99 US-Dollar, dann 20 US-Dollar für zusätzliche 100 GB) ergibt diese Rechnung 979 US-Dollar. Erinnern Sie sich, als ich sagte, dass diese Website ungefähr einen Server benötigt, der etwa 1.000 $/Monat kostet? Ich habe das geschrieben, bevor ich diese Zahlen berechnet habe, also war ich super nah dran (ich habe es geschafft). Jamstack im Vergleich zu WordPress im Maßstab dieser Website ist ziemlich Kopf an Kopf. Alle Hosts werden Bandbreite berechnen und Obergrenzen mit Überziehungsgebühren haben. Amplify berechnet 0,15 $/GB über einer monatlichen Obergrenze von 15 GB. Flywheel (mein WordPress-Host) berechnet auf Basis einer monatlichen Besucherbegrenzung, und darüber hinaus sind es 1 $ pro 1000.

Die Geschichte mit der WordPress-Skalierung ist

• Verwenden Sie einen Host, der damit umgehen kann und der seine eigene bewährte Caching-Strategie hat.
• CDN-alles (was normalerweise bedeutet, Cloudflare davor zu schalten).
• Letztendlich werden Sie dafür bezahlen müssen.

Die Geschichte mit der Jamstack-Skalierung ist

• Der Host und die Dienste sind auf Skalierbarkeit ausgelegt.
• Sie müssen weniger über die Skalierung nachdenken in Bezug auf kann dieser Dienst damit umgehen, oder muss ich wechseln?
• Sie müssen mehr über die Skalierung nachdenken in Bezug auf die Tatsache, dass jeder Aspekt jedes Dienstes Preise hat, die Sie im Auge behalten müssen.
• Letztendlich werden Sie dafür bezahlen müssen.

Ich musste mit meinem WordPress-Hosting ein wenig umziehen, um Hosts zu finden, die den aktuellen Bedürfnissen der Website entsprechen. Ein WordPress-Site zu verschieben ist nicht trivial, aber es ist weitaus einfacher, als zu einem anderen CMS zu wechseln. Wenn Sie beispielsweise eine Jamstack-Website auf einem Headless-CMS aufbauen, das zu teuer wird, ist die Kosten für den Umzug eine größere Aufgabe als der Wechsel des Hosts.

Ich mag, was Dave Rupert neulich (in einer Slack-Unterhaltung) über den Vergleich der Leistung zwischen den beiden geschrieben hat.

Jamstack: Nutzen Sie, was immer Sie wollen, um Ihr Ding zu bauen, es gibt Add-ons, die Ihnen helfen, und nutzen Sie unser Ding, um es auf einem CDN bereitzustellen, damit es nicht abstürzt.

WordPress: Nutzen Sie unser Ding, um Ihr Ding zu bauen, es gibt Add-ons, die Ihnen helfen, und Sie müssen bestimmte Hosts verwenden, damit es nicht abstürzt.

Es gibt auch andere Arten von „Skalierung“. Ich denke an etwas wie die Anzahl der Benutzer. Das ist etwas, das alle Arten von Diensten für Preisstufen verwenden, was eine verständliche Metrik ist. Aber das ist bei WordPress kostenlos. Sie können beliebig viele Benutzer mit beliebig vielen nuancierten Berechtigungen haben. Das ist nur das CMS, also könnten zusätzliche Dienste Ihnen immer noch pro Kopf berechnen. Vercel oder Netlify berechnen Ihnen pro Kopf für Teamkonten. Contentful (ein beliebtes Headless-CMS) beginnt bei 489 $/Monat für Teams. Selbst die Team-Stufe von GitHub kostet 4 $ pro Benutzer, wenn Sie etwas benötigen, das das kostenlose Konto nicht leisten kann.

Trennung von Front- und Back-End

Das ist eine der großen Sachen, die die Leute bei Jamstack begeistert. Wenn alle Funktionen und Inhalte meiner Website über APIs laufen, kann das Front-End frei gestaltet werden, wie es möchte.

• Möchten Sie eine rein statische Website erstellen? OK, rufen Sie während des Build-Prozesses diese API auf und erledigen Sie das.
• Möchten Sie eine clientseitig gerenderte Website mit React oder Vue oder was auch immer erstellen? Gut, rufen Sie die API clientseitig auf.
• Möchten Sie den Mittelweg gehen, etwas vorrendern, etwas clientseitig rendern und etwas serverseitig rendern? Cool, es ist eine API, Sie können sie abrufen, wie Sie möchten.

Diese Flexibilität ist bei Neuentwicklungen gut, aber die Leute sind genauso begeistert von theoretischer zukünftiger Flexibilität. Wenn alle Funktionen und Inhalte API-gesteuert sind, haben Sie Front- und Back-End vollständig getrennt, was bedeutet, dass Sie zukünftig mehr Flexibilität haben, eines von beiden zu ändern.

• Solange Ihre APIs weiterhin das liefern, was das Front-End erwartet, können Sie das Back-End neu gestalten, ohne das Front-End zu beeinträchtigen.
• Solange Sie die benötigten Daten erhalten, können Sie das Front-End neu gestalten, ohne das Back-End zu beeinträchtigen.

Diese Art der Trennung fühlt sich für Websites bestimmter Größe und Skalierung „zukunftssicher“ an. Ich kann nicht genau bestimmen, welche Skalierungszahlen das sind, aber sie sind vorhanden.

Wenn Sie jemals eine größere Website-Neugestaltung durchgeführt haben, nur um eine Seite oder die andere zu berücksichtigen, dann fühlt sich der Umstieg auf ein System, bei dem Sie das Back-End und das Front-End getrennt haben, sicherlich wie ein kluger Schritt an.

Sie können eine WordPress-Website trennen (darauf werden wir im Abschnitt „Beides verwenden“ eingehen), aber standardmäßig ist WordPress ein sehr integrierter Ansatz, bei dem das Front-End aus Themes in PHP mit sehr WordPress-spezifischen APIs erstellt wird. Überhaupt nicht getrennt.

Entwicklererfahrung

Jamstack hat gute Arbeit geleistet, um die Entwicklererfahrung (DX) stark zu priorisieren. Ich habe jemanden gehört, der es als „lokales Optimum“ bezeichnete, was bedeutet, dass Jamstack um die lokale Entwicklung (und die Erfahrung des lokalen Entwicklers) herum konzipiert ist.

• Es wird erwartet, dass Sie lokal arbeiten. Sie arbeiten in Ihrer eigenen komfortablen (lokalen, schnellen, angepassten) Entwicklungsumgebung.
• Git ist ein First-Class-Citizen. Sie pushen zu Ihrem Produktions-Branch (z. B. master oder main), dann läuft Ihr Build-Prozess und Ihre Website wird bereitgestellt. Sie erhalten sogar eine Vorschau-URL der Produktionswebsite für jede Pull-Anfrage, was eine beeindruckend tolle Funktion ist.
• Nutzen Sie beliebige Tools. Sie möchten eine Website in Hugo vorbauen? Nur zu. Haben Sie create-react-app in der Schule gelernt? Benutzen Sie das. Möchten Sie mit dem coolen neuen Framework de jour experimentieren? Nur zu. Es gibt viel Freiheit, wie Sie wollen zu bauen, indem Sie die Tatsache nutzen, dass Sie einen Build ausführen und jeden Ordner in Ihrem Repository bereitstellen können, den Sie möchten.
• Was Sie nicht tun müssen, ist auch wichtig. Sie müssen sich nicht mit HTTPS befassen, Sie müssen sich nicht mit Caching befassen, Sie müssen sich nicht um Dateiberechtigungen kümmern, Sie müssen kein CDN konfigurieren. Selbst fortgeschrittene Entwickler schätzen es, weniger tun zu müssen.

Es ist nicht so, dass WordPress die Entwicklererfahrung nicht berücksichtigt (zum Beispiel haben sie eine CLI und sie kann hilfreiche Dinge tun, wie z. B. Blöcke schablonieren), aber die DX fühlt sich für mich nicht so grundlegend für das Projekt an.

• WordPress lokal auszuführen ist knifflig, da Sie irgendwie einen (X)AMP-Stack ausführen müssen, was bekanntermaßen launische Drittanbietersoftware beinhaltet. Gott sei Dank gibt es Local by Flywheel. Es gibt einige Anleitungen, aber es fühlt sich nicht wie eine Priorität an.
• Was gehört in Git? Bis heute weiß ich es nicht wirklich, aber ich habe mich weitgehend auf den gesamten /wp-content-Ordner geeinigt. Es fühlt sich seltsam an, dass es keine Anleitung oder offensichtlichen Best Practices gibt.
• Sie sind für die Bereitstellung völlig auf sich allein gestellt. Selbst WordPress-spezifische Hosts meistern das hier nicht wirklich. Es ist meistens nur: Hier sind Ihre SFTP-Anmeldeinformationen.
• Selbst wenn Sie eine gute lokale Entwicklungs- und Bereitstellungspipeline eingerichtet haben (ich bin mit meiner zufrieden), hilft das nicht wirklich beim Verschieben der Datenbank, also sind Sie auch hier auf sich allein gestellt.

Dies sind alles lösbare Dinge, und die WordPress-Community ist so groß, dass Sie jede Menge Informationen dazu finden werden, aber ich denke, es ist fair zu sagen, dass WordPress DX nicht im Kern beherrscht. Es ist ein wenig Wild-West-artig, selbst nach all diesen Jahren.

Tatsächlich habe ich festgestellt, dass, weil die Förderung einer gesunden lokalen Entwicklungsumgebung so nebensächlich ist, viele Leute überhaupt keine haben. Dies ist anekdotisch, aber in den letzten Jahren habe ich mich zweimal mit den Websites anderer Leute beschäftigt, die ausschließlich nur in der Produktion funktionieren. Das wäre eine Sache, wenn es sehr einfache Websites mit weitgehend Standardverhalten wären, aber diese waren alles andere als das. Sie sind sehr komplex (viel mehr als diese Website), einschließlich öffentlicher Benutzeranmeldungen, bezahlter Mitgliedschaften und Berechtigungen, Seitenersteller, benutzerdefinierter Shortcodes, benutzerdefinierter CSS und einer Menge beweglicher Teile. Es hat mir Todesangst eingejagt. Ich wollte nichts anfassen. Sie haben PHP live bearbeitet, um Dinge zum Laufen zu bringen – Cowboy-Coding, wie die Leute das scherzhaft nennen. Ein Syntaxfehler und die Website ist ruiniert, vielleicht sogar die Seite, die Sie gerade ansehen.

Die Tatsache, dass WordPress einen so großen Teil des Webs ohne besonders gute DX antreibt, ist sehr interessant. Es gibt kein Jamstack ohne DX. Es ist eine rein entwicklerzentrierte Sache. Bei WordPress gibt es wahrscheinlich gar keinen Entwickler auf den meisten Websites. Es wird installiert (oder einfach aktiviert, im Fall von WordPress.com) und der Websitebesitzer kümmert sich von dort aus. Der Websitebesitzer ist wie ein Entwickler, da er viel Macht hat, aber vielleicht gar keinen Code schreibt.

In diesem Sinne würde ich sagen, dass WordPress weitaus mehr Fokus auf UX als auf DX legt, was ein wichtiger Teil von all dem ist...

CMS und Endbenutzer-UX

WordPress ist ein verdammt gutes CMS. Selbst wenn Sie es nicht mögen, gibt es eine Menge Leute, die es mögen, und die Zahlen sprechen für sich. Was Sie bekommen, wenn Sie sich entscheiden, eine Website mit WordPress zu erstellen, ist eine riesige Menge an Möglichkeiten, um so ziemlich jede Art von Website zu erstellen, die Sie sich wünschen. Es ist unwahrscheinlich, dass Sie mit WordPress in die Situation geraten, Ups, ich habe mich hier selbst in die Ecke manövriert.

Das ist eine große Sache. Jenn hat das auf den Punkt gebracht und bemerkt, dass die Leute, die WordPress nutzen, eine größere Geschichte sind als die Bedürfnisse eines Entwicklers.

WordPress kann eine absolut riesige Menge an Dingen tun

• Bloggen (oder sein jeder Typ von inhaltsgesteuertem CMS-ähnlichem Standort)...
  • Mit Inhaltsvorschauen, was auf Jamstack möglich, aber schwierig ist
• Umgang mit Benutzern/Berechtigungen...
  • auf Admin/CMS-Ebene und
  • auf der nach außen gerichteten Ebene (z. B. Foren, Abonnements, soziale Netzwerke usw.)
• E-Commerce
• Formulare verarbeiten
• Plugins bis zum Abwinken

Jamstack kann all diese Dinge auch absolut tun, aber jetzt ist Jamstack im Wild-West-Gebiet. Wenn man sich Tutorials zum Speichern von Daten ansieht, werden oft die Erstellung einzelner CRUD-Funktionen für eine Cloud-Datenbank erklärt. Das sind Tiefgang-Sachen, die sehr mächtig sein können, aber weit davon entfernt sind, ein paar Knöpfe zu drücken, was bei WordPress oft der Fall ist.

Ich wette, ich könnte wahrscheinlich ein einfaches Jamstack-E-Commerce-Setup mit Stripe-APIs zusammenbasteln, was sehr cool ist. Aber dann würde ich nervös werden, wenn ich über Bestandsverwaltung, Versandzonen, Produktvarianten und was weiß ich noch alles nachdenken müsste, was im E-Commerce-Land kompliziert wird, und ich wünschte mir etwas super Robustes, das alles für mich erledigt.

Manchmal bauen wir Entwickler Websites nur für uns (ich mache mehr als meinen fairen Anteil daran), aber ich würde sagen, dass Entwickler hauptsächlich Websites für andere Leute bauen. Die wichtigste Frage ist also: Baue ich etwas, das für die Leute, für die ich es baue, ermächtigend ist?

Sie können eine gute Website-Manager-Erfahrung erzielen, egal was passiert, aber WordPress hat sicherlich bewiesen, dass es in diesem Bereich liefert, ohne außergewöhnlich viel benutzerdefinierte Entwicklung zu verlangen.

Jamstack hat einige Tricks, die ich mir wünschen würde, dass sie auf WordPress umgesetzt werden könnten, aber. Hier ist ein großer Punkt für mich: benutzergenerierte Inhalte und Updates. Ich habe buchstäblich drei Websites, die davon profitieren. Eine Website über Konferenzen, eine Website über Serverless und eine kommende Website über Coding-Fonts. WordPress hätte alle drei dieser Websites absolut gut bewältigen können. Aber was ich wirklich will, ist, dass die Leute Inhalte so aktualisieren und einreichen können, dass ich sagen kann: Yep, sieht gut aus, zusammenführen. Durch die Wahl eines Jamstack-Ansatzes befinden sich die Inhalte in öffentlichen GitHub-Repos, und jeder kann teilnehmen.

Ich denke, das ist super. Es erfordert nicht einmal unbedingt, dass jemand aus der Öffentlichkeit Git oder GitHub kennt oder versteht, da Netlify CMS dieses Konzept von Open Authoring hat, das die gesamte Beitrags-Erfahrung im Browser mit einer Benutzeroberfläche für die Bearbeitung beibehält.

Beide nutzen

Dies ist ein wichtiger Punkt, der meiner Meinung nach oft zur Sprache kommt. Selbst Netlify selbst sagt „Es gibt kein Gegeneinander.“

Hier ist die Sache:

• Das „A“ in „Jam“ steht für APIs. Nutzen Sie APIs, um Ihre Website entweder zur Build-Zeit oder auf Client-Seite zu erstellen.
• WordPress-Websites haben standardmäßig eine REST-API (und können auch eine GraphQL-API haben).
• Greifen Sie also auf diese API zu, um CMS-Daten auf Ihrer Jamstack-Website abzurufen.

Ja, absolut. Das funktioniert und Leute tun es. Ich finde es ziemlich cool.

Aber...

• Eine WordPress-Website zusätzlich zu Ihrer Jamstack-Website zu betreiben, bedeutet… Sie betreiben eine WordPress-Website zusätzlich zu Ihrer Jamstack-Website. Das verursacht Kosten und technische Schulden.
• Sie erhalten oft nicht den vollen Nutzen von WordPress. Der Abruf von Daten über eine API *könnte* alles sein, was Sie brauchen, aber dies ist ein ganz anderer Ansatz zum Erstellen einer Website als das Erstellen eines WordPress-Themes. Sie erhalten keinen der anderen Vorteile von WordPress. Ich denke da an Situationen wie diese: Sie finden ein schickes Plugin, das einen schönen Gutenberg-Block zu Ihrer Website hinzufügt. Das „funktioniert einfach“ auf einer WordPress-Website, aber es hat wahrscheinlich ein spezielles Frontend-Verhalten, das nicht funktioniert, wenn Sie nur den HTML-Code über eine API abrufen. Es lädt wahrscheinlich zusätzliche Skripte und Stile, deren Einbindung an Ihrem Hosting-Standort Sie selbst herausfinden und deren Updates Sie selbst pflegen müssen.

Hier sind einige Akteure, die alle einen einzigartigen Ansatz für das „Beide Nutzen“ verfolgen:

• Frontity: Ein React-Framework für WordPress. Sie betreiben es mit einem Node-Server dahinter, zusätzlich zu Ihrer WordPress-Website. Der Node-Server rendert React zu HTML, sodass Sie Server-Side-Rendering für alle Seiten erhalten, aber Sie erstellen auch immer noch eine SPA.
• WP2Static: Ein WordPress-Plugin, das eine statische Version Ihrer Website erstellt und diese bei Änderungen automatisch bereitstellen kann.
• Strattic: Sie hosten die dynamische WordPress-Website für Sie (was sie als „Staging“ bezeichnen) und Sie arbeiten dort normal mit WordPress. Dann wählen Sie die Bereitstellung aus, und sie hosten auch eine statische Version Ihrer Website für Sie.
• Shifter: Shifter hostet die WordPress-Website für Sie. Sie haben zwei Optionen: 1) Betreiben Sie sie Headless (also greifen Sie nur auf die API, REST oder GraphQL, für Daten zu) oder 2) Betreiben Sie sie statisch (also wenn Sie alles in WordPress so haben, wie Sie es möchten, stellen Sie es bereit, was eine statische Version Ihrer Website erstellt, die sie ebenfalls hosten, oder Sie können sie woanders hochladen, z. B. Netlify).

Es gibt unzählige andere Möglichkeiten, beide zu integrieren. Hier sprechen unsere eigenen Geoff und Sarah über die gemeinsame Nutzung von WordPress und Jamstack durch die Verwendung von Vue/Nuxt mit der REST-API und das Hosting auf Netlify.

Keine Nutzung

Nur für den Fall, dass dies unklar ist: Es gibt absolut unzählige Möglichkeiten, Websites zu erstellen. Wenn Sie eine Ruby on Rails-Website erstellen, ist das weder Jamstack *noch* WordPress. Man könnte argumentieren, dass es eher einer WordPress-Website ähnelt, da es einen Server benötigt und Sie diesen Server nutzen, um so viel wie möglich zu tun. Man könnte auch argumentieren, dass es eher Jamstack ähnelt, da es zwar kein statisches Hosting ist, aber die Verwendung von APIs und das Zusammenfügen von Diensten fördert.

Das Web ist ein großer Ort, Leute, und dies ist kein Nullsummenspiel. Ich gehe fest davon aus, dass WordPress weiter wachsen wird *und* Jamstack weiter wachsen wird, weil *das Web selbst wächst*. Selbst wenn wir nur den Marktanteil betrachten, würde ich *immer noch* darauf wetten, dass beide wachsen und alles andere in kleinere Scheiben drängen.

Auswahl

Ich werde hier gar nicht erst darauf eingehen. Nicht, weil ich versuche, Favoriten zu vermeiden, sondern weil es nicht notwendig ist. Ich sehe keine Entwickler, die Nägel kauen, um sich zwischen einem WordPress- oder einem Jamstack-Ansatz für die Erstellung einer Website zu entscheiden. Wir sind an dem Punkt angelangt, an dem die Technologien gut genug verstanden sind, dass der Prozess so abläuft:

1. Zieh dir die Hosen an
2. Bewerte Bedürfnisse und Ergebnisse
3. Wähle Technologien