Statisch vs. Dynamisch vs. Jamstack: Wo ist die Grenze?

Sie werden oft hören, wie Entwickler über „statische“ und „dynamische“ Websites sprechen, oder Sie haben vielleicht jemanden den Begriff Jamstack verwenden hören. Was bedeuten diese Begriffe und wann wird eine „statische“ Website zu einer Jamstack- oder dynamischen Website? Diese Fragen klingen einfach, sind aber vielschichtiger, als sie scheinen. Lassen Sie uns diese Begriffe untersuchen, um ein tieferes Verständnis von Jamstack zu gewinnen.

Die Grenze finden

Was ist der Unterschied zwischen einem Stuhl und einem Hocker? Die meisten Leute werden antworten, dass ein Stuhl vier Beine und eine Rückenlehne hat, während ein Hocker drei Beine ohne Rückenlehne hat.

OK, das ist ein guter Ausgangspunkt, aber was ist mit diesen hier?

Je mehr ein Stuhl einem Hocker ähnelt, desto weniger Leute werden eindeutig zustimmen, dass es sich um einen Stuhl handelt. Irgendwann erreichen wir einen Punkt, an dem die meisten Leute zustimmen, dass es sich um einen Hocker und nicht um einen Stuhl handelt. Das mag wie eine alberne Übung klingen, aber wenn wir Stühle wirklich schätzen wollen, ist sie wertvoll. Wir finden heraus, wo die Grenzen eines Stuhls für die meisten Leute liegen. Wir bauen auch ein Verständnis für den Graubereich darüber hinaus auf. Schließlich gelangen wir zu dem Punkt, an dem selbst die größten Hardcore-Stuhl-Fans zugeben, dass ein Hocker vor ihnen steht.

So interessant Stühle auch sind, dies ist ein Artikel über Webseiten-Auslieferungstechnologien. Führen wir dieselbe Übung für statische, dynamische und Jamstack-Websites durch.

Auf hoher Ebene

Wenn Sie eine Website in Ihrem Browser aufrufen, passiert im Hintergrund vieles

1. Ihr Browser führt eine DNS-Auflösung durch, um den Domainnamen in eine IP-Adresse umzuwandeln.
2. Er fordert eine HTML-Datei von dieser IP-Adresse an.
3. Der Webserver sendet die angeforderte Datei zurück.
4. Während der Browser die Webseite rendert, kann er auf einen Verweis auf eine Ressource stoßen, z. B. eine CSS-, JavaScript- oder Bilddatei. Der Browser führt dann eine Anfrage für diese Ressource durch.
5. Dieser Zyklus setzt sich fort, bis der Browser alle Dateien für die Webseite hat. Es ist nicht ungewöhnlich, dass eine einzelne Webseite über 50 Anfragen stellt.

Bei jeder Anfrage ist die Antwort des Webservers immer eine statische Datei, selbst bei einer dynamischen Website. Sie könnten diese Dateien auf einen USB-Stick speichern, per E-Mail an einen Freund senden, genau wie jede andere Datei auf Ihrem Computer.

Beim Vergleich von statisch und dynamisch sprechen wir darüber, was der Webserver tut. Auf einer statischen Website existieren die vom Browser angeforderten Dateien bereits auf dem Webserver. Der Webserver sendet sie exakt so zurück, wie sie sind. Auf einer dynamischen Website wird die Antwort von Software generiert. Diese Software könnte sich mit einer Datenbank verbinden, um Daten abzurufen, ein Layout aus Vorlagendateien zu erstellen und das heutige Datum in die Fußzeile einzufügen. Sie tut all dies für jede Anfrage.

Das ist der grundlegende Unterschied zwischen statischen und dynamischen Websites.

Wo passt Jamstack hinein?

Statische Websites sind restriktiv. Sie eignen sich hervorragend für Informationswebsites. Per Definition können Sie jedoch keinen dynamischen Inhalt oder kein dynamisches Verhalten haben. Jamstack verwischt die Grenze zwischen statisch und dynamisch. Die Idee ist, all die Dinge zu nutzen, die statische Websites großartig machen, und gleichzeitig dynamische Funktionalität dort zu ermöglichen, wo sie benötigt wird.

Das „Stack“ in Jamstack ist irreführend. Die Wahrheit ist, dass Jamstack überhaupt kein Stack ist. Es ist eine Philosophie, die eine bemerkenswerte Ähnlichkeit mit den 5 Säulen des AWS Well-Architected Frameworks aufweist. Die Mehrdeutigkeit des Begriffs hat zu umfangreichen Diskussionen in der Community darüber geführt, was es bedeutet, Jamstack zu sein.

Was ist Jamstack?

Jamstack ist eine Obermenge von statisch. Aber um Jamstack wirklich zu verstehen, beginnen wir mit den Samen, die zur Prägung des Begriffs geführt haben.

Im Jahr 2002 veröffentlichte der verstorbene Aaron Swartz einen Blogbeitrag mit dem Titel „Bake, Don’t Fry.“ Obwohl Aaron „Bake, Don’t Fry“ nicht geprägt hat, ist dies das erste Mal, dass ich jemanden erkenne, der die Vorteile statischer Websites anerkennt und gleichzeitig die wahrgenommenen Einschränkungen des Wortes bricht.

Ich kümmere mich nicht darum, umständliche AOLserver-, Postgres- und Oracle-Installationen warten zu müssen. Ich kümmere mich darum, meine Backups mit scp durchführen zu können. Ich kümmere mich darum, keine Installation oder Konfiguration durchführen zu müssen, um meine Website auf einen neuen Server zu verschieben. Ich kümmere mich darum, plattform- und serverunabhängig zu sein.

Wenn wir durch die Geschichte stöbern, können wir ähnliche Frustrationen finden, die zu den Jamstack-Samen geführt haben

• Ben und Mena Trott schufen MovableType aufgrund Unzufriedenheit mit bestehenden Blog-CMS – Leistung, Stabilität.

• Tom Preston-Werner schuf Jekyll, um sich von Komplexität zu lösen

  Ich wusste bereits viel über das, was ich nicht wollte. Ich hatte die Nase voll von komplizierten Blogging-Engines wie WordPress und Mephisto. Ich wollte großartige Beiträge schreiben, nicht tausende von Seitenvorlagen gestalten, den ganzen Tag Kommentare moderieren und ständig hinter der neuesten Softwareversion hinterherhinken.

• Steve Francia schuf Hugo für die Leistung

  In den letzten Jahren wurde dieser Blog von WordPress und davor von Drupal betrieben. Beide sind gute Software, aber im Laufe der Zeit wurde ich immer enttäuschter darüber, wie beide für das Schreiben von Inhalten optimiert sind, obwohl die mit Abstand häufigste Nutzung das Lesen von Inhalten ist. Aufgrund der Notwendigkeit, den PHP-Interpreter bei jeder Anfrage zu laden, konnte er nie als schnell bezeichnet werden und verbrauchte viel Speicher auf meinem VPS.

Die gleichen Themen tauchen auf, wenn Sie sich die Ursprünge vieler früher Jamstack-Tools ansehen

• Komplexität reduzieren
• Leistung verbessern
• Anbieterabhängigkeit reduzieren
• Bessere Arbeitsabläufe für Entwickler

In den letzten 20 Jahren hat sich JavaScript von einer Sprache zur Ergänzung kleiner Interaktionen auf einer Website zu einer Plattform für den Aufbau umfangreicher Webanwendungen im Browser entwickelt. Parallel dazu haben wir eine Bewegung gesehen, große Anwendungen in kleinere Microservices aufzuteilen. Diese beiden Entwicklungen führten zu einer neuen Art des Website-Aufbaus, bei der Sie ein statisches Frontend haben konnten, das von einem dynamischen Backend entkoppelt war.

Im Jahr 2015 wollte Mathias Biilmann über diese moderne Art des Website-Aufbaus sprechen, kämpfte aber mit der einschränkenden Definition von statisch

Wir waren in diesem Bereich der modernen statischen Websites. Das ist eine wirklich schlechte Beschreibung dessen, was wir tun, oder? Und wir hatten immer wieder dieses Problem, dass, wenn wir mit Leuten über statische Websites sprachen, sie an etwas sehr Statisches dachten. Sie dachten an eine Broschüre oder etwas ohne bewegliche Teile. Eine kleine Einzelseite oder so etwas.

Um diese Einschränkungen zu überwinden, prägte er den Begriff „Jamstack“, um diesen neuen Ansatz zu beschreiben, und er verbreitete sich wie ein Lauffeuer. Was alte statische Technologie aus den 90er Jahren war, wurde wieder neu und bis an neue Grenzen gebracht. Viele Entwickler erkannten die Vorteile des Jamstack-Ansatzes, was dazu beitrug, dass Jamstack zu dem blühenden Ökosystem heranwuchs, das es heute ist.

Aaron Swartz drückte es schön aus, 13 Jahre bevor Jamstack geprägt wurde: eine strikte Trennung zwischen Eingabe (die dynamischen Code zur Verarbeitung benötigt) und Ausgabe (die normalerweise gebacken werden kann) beibehalten. Mit anderen Worten, trennen Sie das Frontend vom Backend. Rendern Sie Inhalte vor, wann immer möglich. Schichten Sie dynamische Funktionalität hinzu, wo nötig. Das ist der Kern von Jamstack.

Der Grund, warum Sie eine Jamstack-Website gegenüber einer dynamischen Website erstellen möchten, liegt in den sechs Säulen von Jamstack

Chris geht in einem Deep-Dive-Vergleich zwischen Jamstack und WordPress auf einige dieser Punkte ein. Er vergleicht auch die Gründe für die Wahl einer Jamstack-Architektur im Vergleich zu einer serverseitigen in „Static or Not?“.

Nutzen wir diese Säulen, um Jamstack-Anwendungsfälle zu bewerten.

Wo ist die Grenze zwischen statisch und Jamstack?

Nachdem wir nun die Grundlagen von statisch und Jamstack kennen, tauchen wir ein und sehen, was an den Rändern jeder Definition liegt. Wir haben vier Kategorien, unter die jede Randfallgruppe fallen kann.

• Statisch – Dies hält sich strikt an die Definition von statisch.
• Im Grunde statisch – Obwohl nicht exakt statisch, würden die meisten Leute es als statische Website bezeichnen.
• Jamstack – Ein statisches Frontend, das von einem dynamischen Backend entkoppelt ist.
• Dynamisch – Rendert Webseiten bei Bedarf.

Viele dieser Anwendungsfälle können mehreren Kategorien zugeordnet werden. In dieser Übung ordnen wir sie der restriktivsten Kategorie zu, zu der sie passen.

Die Linien wurden gezogen

Die Untersuchung und Diskussion dieser Grenzfälle gibt uns ein besseres Verständnis der Grenzen all dieser Begriffe. Der Sinn dieser Übung ist nicht, dogmatisch über die Erstellung statischer oder Jamstack-Websites zu sein. Es geht darum, uns eine gemeinsame Sprache zu geben, um über die Kompromisse zu sprechen, die Sie eingehen, wenn Sie die Grenze von einem Konzept zum anderen überschreiten.

Es ist auch absolut nichts falsch an Kompromissen. Nicht alles kann eine rein statische Website sein. In vielen Fällen ergeben die Kompromisse Sinn. Sagen wir zum Beispiel, das Frontend muss das Land des Besuchers kennen. Dafür gibt es zwei Möglichkeiten

1. Beim Seitenaufruf eine Ajax-Anfrage ausführen, um das Land von einer API abzurufen. (Jamstack)
2. Verwenden Sie eine Edge-Funktion, um beim Antwort den Ländercode dynamisch in das HTML einzufügen. (Dynamisch)

Wenn der Ländercode ein "Nice-to-have" ist und die Webseite ihn nicht sofort benötigt, dann ist der erste Ansatz eine gute Option. Die Seite kann statisch sein und der API-Aufruf kann bei einem Fehler elegant fehlschlagen. Wenn jedoch der Ländercode für die Seite erforderlich ist, könnte es sinnvoller sein, ihn dynamisch mit einer Edge-Funktion hinzuzufügen. Es wird schneller sein, da Sie keinen zweiten Request/Response-Zyklus durchführen müssen.

Der Schlüssel ist, das Problem zu verstehen, das Sie lösen, und über die Kompromisse nachzudenken, die Sie mit verschiedenen Ansätzen eingehen. Möglicherweise haben Sie den Großteil Ihrer Website als Jamstack und einen Teil als dynamisch. Das ist völlig in Ordnung und kann für Ihren Anwendungsfall notwendig sein. Typischerweise gilt: Je näher Sie an statisch herankommen, desto schneller, sicherer und skalierbarer wird Ihre Website sein.

Dies ist erst der Anfang der Diskussion, und ich würde gerne Ihre Meinung hören. Wo würden Sie die Linien ziehen? Was bedeuten statisch und Jamstack für Sie? Sitzen Sie gerade auf einem Stuhl oder Hocker?