- Entgegen der Ansicht, dass die Unterscheidung zwischen statischen und dynamischen Websites verschwommen sei, haben auf statischen Dateien basierende Websites über lange Betriebszeiträume hinweg weiterhin andere Eigenschaften
- Die seit den Anfängen des Webs fortbestehende Methode der Dateibereitstellung und die Effizienz des Servierens statischer Dateien sind Gründe dafür, dass statische Websites leicht langfristig erhalten bleiben
- Statische Websites haben eine klare Verantwortungsgrenze wie ein Dateisystem zwischen Webserver und Inhalten, sodass beide Seiten nur begrenzt voneinander wissen müssen
- Bei dynamischen Websites ist die Grenze zwischen Webserver und Nutzer-Code klein und nur schwer einfach zu halten, und es ist auch schwierig, diese Grenze und API zu standardisieren
- Das Unterscheidungskriterium ist nicht der Arbeitsaufwand oder die Änderungsfrequenz, sondern wo die Grenze liegt und worauf jede Seite achten muss
Ausgangspunkt der Debatte über statische Websites
- Wesley Aptekar-Cassels’ Artikel There is no such thing as a static website vertritt die Ansicht, dass der Unterschied zwischen statischen und dynamischen Websites kleiner ist als gedacht
- Statische Websites sind dynamischer und komplexer als es auf den ersten Blick scheint
- Dynamische Websites zu erstellen und zu betreiben ist einfacher geworden als früher
- Die einzelnen Punkte sind überzeugend ausgeführt, führen aber nicht zwingend zu dem Schluss, dass der Unterschied zwischen statischen und dynamischen Websites kleiner geworden ist
Unterschiede durch Dauerhaftigkeit und Verantwortungsgrenzen
- Über lange Zeiträume hinweg haben auf statischen Dateien basierende Webinhalte eine hohe Dauerhaftigkeit gezeigt
- Konkrete Webserver und Hosts mögen sich ändern, aber statische Dateien und die Art, Dateien in einem Verzeichnisbaum abzulegen, bestehen seit den Anfängen des Webs fort
- Das Servieren statischer Dateien ist auch bei dynamischen Websites häufig nötig und effizient, daher nutzen Websites, die nur aus statischen Dateien bestehen, dieselben Vorteile
- Wer nur statische Inhalte bereitstellt, erhält eine stabile Website, die sich leicht weiter betreiben lässt; historisch galt das für dynamische Websites nicht
- Der Kern statischer Websites ist eine Verantwortungsgrenze mit einfacher und starker Isolierung
- Auf der einen Seite steht die Komplexität des statischen Webservers, einschließlich dynamischer Updates wie der Erneuerung von HTTPS-Zertifikaten
- Auf der anderen Seite stehen die statischen Dateien, dazwischen liegt ein Dateisystem oder etwas Dateisystemähnliches
- Was beide Seiten voneinander verlangen, ist sehr begrenzt
- Dynamische Websites haben es schwer, zwischen Webserver und Nutzer-Code eine solche kleine und klare Grenze zu schaffen
- Auch die Wahrscheinlichkeit einer Standardisierung über eine einzelne Grenze und API hinweg ist gering
- Das Web ist in gewisser Weise darauf ausgelegt, statische Dateien bereitzustellen
- Dieser Unterschied macht statische Dateiserver beim Betrieb und bei der Migration vorteilhafter als dynamische Webserver und Laufzeitumgebungen
- Statische Dateiserver sind leicht zu finden
- Selbst wenn der aktuelle Betreiber aufhört, lässt sich die Website leicht an einen anderen Ort umziehen
- Diese Dauerhaftigkeit gilt zumindest für kleine bis mittlere statische Websites, die auf einen einzelnen Server passen
- Die Unterscheidung zwischen statischen und dynamischen Websites ist nicht verschwommen
- Maßgeblich sind nicht der Arbeitsaufwand für Erstellung und Betrieb einer Website oder die Menge regelmäßig wechselnder Elemente wie die Erneuerung von HTTPS-Zertifikaten
- Maßgeblich ist, wo die Grenze liegt und worauf jede Seite achten muss
- Statische Websites haben eine scharfe Grenze, die es erlaubt, beide Seiten unabhängig voneinander zu behandeln; dynamische Websites haben eine solche Grenze von Natur aus nicht und müssen sie bei Bedarf künstlich ziehen
1 Kommentare
Hacker-News-Kommentare
Ich verdiene meinen Lebensunterhalt mit einer Content-Website und bin dieses Jahr von Craft CMS auf einen selbst entwickelten Generator für statische Websites umgestiegen
Jetzt muss ich mich weder um den Server noch um ein CMS kümmern, es gibt keine Updates mehr und auch keine schwere Datenbank oder komplexe Caching-Konfiguration. Es ist jetzt einfach nur noch ein Server für statische Dateien, also stabiler und fast wartungsfrei
Das Beste daran ist, dass ich offline arbeiten kann. Ein Texteditor reicht völlig aus, deshalb fühlt sich selbst ein kleines MacBook 12" sehr schnell an
Versionsverwaltung ist ebenfalls sehr nützlich, weil ich Änderungen prüfen oder rückgängig machen kann und über alle Inhalte hinweg per Regex Suchen/Ersetzen ausführen kann. Mit Textdateien lässt sich einfach arbeiten
Hier habe ich aufgeschrieben, wie sich dieser Wechsel angefühlt hat und warum er gut funktioniert: https://nicolasbouliane.com/projects/ursus
Ich fände es allerdings gut, wenn diese Technik auch für Menschen zugänglicher würde, die nicht selbst neu kompilieren und deployen können. Es ist eine schnelle und günstige Art, Websites zu bauen, aber bestehende Tools wie Hugo setzen beim Nutzer ziemlich viel voraus und schaffen dadurch eine Einstiegshürde
Der Artikel war auch unterhaltsam zu lesen. Ich habe die ursprüngliche Version von html-to-markdown erstellt, die bei der Migration verwendet wurde, und freue mich, dass sie noch nützlich ist
Schnell, mit genau den richtigen Inhalten und ohne unnötigen Ballast
Ich persönlich hätte gern einen Bereich für Fernsehserien und Filme, die im Berlin der Vergangenheit und Gegenwart spielen, plus eine kurze Bewertung dazu, wie realistisch sie das echte Berlin darstellen
Für über 95 % aller Websites hätte es wahrscheinlich gereicht, 70 % der beliebten Inhalte im RAM zu cachen und die restlichen 30 % von SSDs mit 10.000 IOPS bei zufälligen Lesezugriffen auszuliefern
Wenn man nicht ständig am Site-Design herumbastelt, sollten Website und HTML lokal erzeugt werden, und eine vollständige Generierung sollte weniger als 1 Sekunde dauern
Aber ein GitHub-, Versionsverwaltungs- und Texteditor-zentrierter Ansatz ist immer noch stark auf Techniker und Programmierer ausgerichtet. Man braucht so etwas wie gehostetes WordPress oder etwas, das eher an die Zeiten von Dreamweaver/Frontpage erinnert
Mir gefällt, dass man bis in die Details eintauchen kann, wenn man etwas Besonderes umsetzen will. Wenn ich zum Beispiel den Artikel über Favorite Git Aliases bearbeite, kann er in eine
.bash_aliases-Datei umgewandelt, zu GitLab gepusht und zusätzlich auf GitHub gespiegelt werdenFür Interessierte: https://jdsalaro.com. Den Stack oder die Gründe habe ich dort noch nicht ausführlich beschrieben, aber ich werde das nach und nach dokumentieren
Zunächst habe ich einen Markdown- und Myst-Spickzettel für Sphinx (https://jdsalaro.com/cheatsheet/sphinx-myst-cheat-sheet/) und eine Anleitung zum Laden von
environment.pickle(https://jdsalaro.com/howto/sphinx-load-environment-pickle/) veröffentlichtDas bedeutet auch, dass weniger Ressourcen wie Strom verbraucht werden, kleinere Hardware ausreicht und vor allem die Sicherheit steigt. Statische Websites sind schwerer anzugreifen, und mögliche Schwachstellen beschränken sich eher auf den Webserver als auf den Website-Code
Normalerweise nutze ich Hugo, das sehr funktionsreich und ausgereift ist. Ich habe damit auch mehrsprachige Websites gebaut
Man könnte auch darüber nachdenken, Turbo Hotwired in statische Websites zu integrieren. Das kann die Reaktionsfähigkeit bei der Navigation verbessern und die Last sowohl auf Server- als auch auf Client-Seite senken
Falls nötig, lässt sich Turbo auch mit Mercure integrieren, um Seiten in Echtzeit zu streamen
Der größte Unterschied zwischen statischen und dynamischen Websites ist die Angriffsfläche für Sicherheit
Im schlimmsten Fall kann ein Webserver für statische Sites nur dazu gebracht werden, die falsche Datei auszuliefern, und selbst das lässt sich abmildern, indem man nur Dateien auf den Server legt, die überhaupt ausgeliefert werden dürfen
Eine dynamische Website kann dazu gebracht werden, Code auszuführen, falsche Daten aus einer zugänglichen Datenbank zurückzugeben oder sogar Daten zu verändern
WordPress-Kompromittierungen passieren ständig, Nginx-Kompromittierungen dagegen nicht
Technisch gesehen gibt es keine Website, die keinen Code ausführt. Vom Webserver über den Dateisystemtreiber bis hin zum Betriebssystem ist alles Code
Es stimmt zwar, dass statische Dateien die Angriffsfläche verkleinern, aber man sollte gründlich darüber nachdenken, warum das so ist, und intelligente dynamische Systeme entwerfen, die die Sicherheitsmerkmale statischer Sites übernehmen
Am Ende geht es um Eingaben und darum, wie man mit ihnen umgeht. Selbst wenn man sehr komplexen Code ausführt, ist kein Angriff möglich, wenn überhaupt keine Eingaben entgegengenommen werden. Natürlich gibt es auch bei statischen Sites Eingaben, sonst wüsste man ja nicht, welche Seite ausgeliefert werden soll. Genau hier liegt der entscheidende Unterschied
Ich stimme zu, dass die Angriffsfläche statischer Sites kleiner ist, aber ich denke, der wichtigere Grund ist, dass nginx viel stärker geprüft wird und sich langsamer entwickelt als eine durchschnittliche Kombination aus WordPress-Plugins
Wenn man seinen eigenen statischen Webserver baut, ist die erste Version wahrscheinlich anfälliger für Angriffe als eine Standardinstallation von WordPress
Eine statische Website könnte theoretisch überhaupt keine Updates brauchen. Solange sich das Ziel nicht ändert, etwa die HTML-Version, gibt es den Begriff eines Updates fast gar nicht
location-Blocks mit der DirektivealiasAus Entwicklersicht ist die Unterscheidung anhand der vom Web bereitgestellten Abstraktion — also Hypermedia über HTTP/S — ziemlich sauber.
Die Semantik dieser Abstraktion besteht darin, dass auf einem bestimmten Pfad eine Anfrage mit Headern und Body eingeht und eine Antwort mit Headern und Body zurückgegeben wird. Zwischengeschaltete Netzwerkdetails wie TLS werden verborgen.
Moderne Frameworks verbergen in der Praxis noch mehr vor Entwicklern, indem sie sogar Authentifizierungs-Sessions und Request-Header automatisch verwalten. Innerhalb dieser Abstraktion ist die Standardunterscheidung „statisch hängt nicht von Request/State ab, dynamisch schon“ sauber, aber diese Unterscheidung stützt sich auf die Semantik, die die Abstraktion bereitstellt.
Das ist ähnlich dazu, dass TCP als verbindungsorientiertes Protokoll auf einer zugrunde liegenden paketbasierten Struktur arbeitet. Man kann TCP für Anwendungen verwenden, die Stream- oder paketförmige Datenübertragung benötigen.
Man kann zwar behaupten: „In Wirklichkeit liegt alles auf IP auf, also gibt es diese Unterscheidung nicht“, aber dann betrachtet man es auf der falschen Abstraktionsebene.
Das heißt jedoch nicht, dass die Kernaussage des Artikels falsch ist. Entwickler sollten sich der Zustandsbehaftetheit unter einer „zustandslosen Website“ immer bewusst sein, und es ist gut, Abstraktionen ein paar Ebenen tiefer zu verstehen, als man zunächst für nötig hält.
Persönliche Websites sind eine eigentümliche Mischung aus statisch und dynamisch. Der Großteil ist statisch, aber der Blogteil wird dynamisch gerendert.
Wenn man eine Blog-URL aufruft, wird eine Markdown-Datei von der Festplatte geladen, in HTML umgewandelt, und dieses HTML wird in ein Template eingesetzt, das den Rest der Seite samt CSS usw. zusammensetzt.
Trotzdem ist das schnell und effizient. Als einer meiner Blogposts letzte Woche auf Platz 1 bei HN landete, schrieb mir ein Freund per SMS, er hoffe, ich hätte Cloudflare eingerichtet. Hatte ich nicht, aber die Last meines VPS mit 2 Kernen und 1 GB RAM lag im Durchschnitt nie über 0,15.
Nach dem Muster: „Das meiste ist HTML, aber wenn man in dieser Datei zu dieser Zeile kommt, führt man Code aus, um eine Datei in einem anderen Format zu parsen und das Ergebnis in die Ausgabe einzufügen.“
2001 war das ein völlig sinnvoller Weg, eine statische Website mit etwas wie einem Kommentarbereich unter jedem Blogpost zu bauen. Solches PHP war günstig genug, dass selbst normale ISPs oft erlaubten, es unter
/~userdir/hochzuladen und dem öffentlichen Internet auszusetzen.Bei einer vernünftigen Struktur, die sich nicht zu schwer auf eine Datenbank stützt, kann selbst ein kleiner VPS problemlos Hacker-News-Traffic verkraften.
Wenn man Threads herausbringen will, braucht man vielleicht die Skalierungsmethoden von Facebook, aber für eine gewöhnliche read-only Website muss man wirklich nicht viel Geld ausgeben.
Mir fallen Gründe ein wie das Einfügen dynamischer Inhalte in Templates oder das Reduzieren von Build-Zeit und Komplexität, aber vielleicht gibt es noch andere Gründe, an die ich nicht gedacht habe.
Als Außenstehender, der ein wenig mit wasm arbeitet, habe ich nie verstanden, warum es besser sein soll, auf dem Server Benutzercode auszuführen, um „dynamische“ Webseiten zu erzeugen, statt einfach einen simplen Dateiserver zu nutzen.
Die dynamischen Teile könnten doch im Browser laufen, und der Server würde einfach nur Dateien ausliefern. Eine Ausnahme sind natürlich Browser der 90er, die für solche Aufgaben völlig ungeeignet waren.
Was Einfachheit und Skalierbarkeit angeht, gibt es nichts, das einen einfachen Dateiserver vor einem CDN schlägt.
Wichtig ist auch, wie viele Technologien es gibt, die dabei nicht die Grundfunktionen des Browsers kaputtmachen.
GitHub schafft es beim Durchsuchen von Quellcode in meiner Umgebung übrigens immer noch in etwa 40 % der Fälle, den Zurück-Button kaputtzumachen. Ich nutze Chrome auf OSX und habe keine Ahnung, wie das überhaupt möglich ist.
Meiner Erfahrung nach wirken Websites, die HTML serverseitig erzeugen, schneller und stabiler als solche, die auf Client-Rendering setzen. Wenn der Browser-Cache leer ist, fühlt sich das Öffnen eines booru mit mehr als 50 Bildern pro Seite immer schneller und angenehmer an als das Öffnen einer GitHub-Seite, die nur aus Text besteht, der seit Tagen nicht geändert wurde und ohnehin bereits überall gecacht ist.
Zum Beispiel möchte man vielleicht von Nutzern eingereichte Inhalte in einer Datenbank speichern, Authentifizierung brauchen oder Volltextsuche über Datensätze von mehreren GB anbieten. Möglicherweise muss man eine Schnittstelle zu etwas bereitstellen, auf das der Browser keinen Zugriff hat, oder Benutzereingaben validieren.
All das erfordert Benutzercode, der auf dem Server läuft. Dann müssen die Daten auf dem Server in ein wohldefiniertes Übertragungsprotokoll umgewandelt, an den Client geschickt, dort wieder umgewandelt und schließlich zu HTML verarbeitet werden.
In die andere Richtung gilt dasselbe: Wenn man bösartige angepasste Clients verhindern will, muss man Eingaben sowohl auf Client- als auch auf Serverseite validieren.
Oder man rendert auf dem Server direkt HTML und ist damit fertig. Das ist deutlich weniger Aufwand und liefert bei den meisten Anwendungen praktisch dieselbe Erfahrung.
Wenn es Geheimnisse gibt, die verborgen bleiben müssen, etwa Datenbankpasswörter, API-Schlüssel oder kryptografische Schlüssel, dann muss das Code auf dem Server handhaben. Wenn der gesamte Code auf dem Client läuft, besteht immer die Möglichkeit, dass ein Angreifer diese Geheimnisse entdeckt.
Es ist oft auch einfacher, die Angriffsfläche zu verkleinern, indem man dem Client eine kleinere, eingeschränktere API anbietet. Wenn der Client direkt mit der Datenbank verbunden wird, müssen Berechtigungen und Sicherheitseinstellungen exakt stimmen und lückenlos sein. Wenn die App dagegen nur eine Liste von Büchern oder Filmen bereitstellt, ist es schwerer, die Verteidigung zu durchbrechen.
Wenn man den initialen Ladevorgang direkt als ein sofort nutzbares Datenpaket ausliefert, wirkt eine Website oft reaktionsschneller. Selbst wenn die tatsächliche Zeit gleich ist wie beim Herunterladen der Anwendung, Anzeigen eines Ladeindikators und anschließenden Laden und Darstellen der Daten, wirkt Ersteres für Nutzer schneller.
Der Server steht normalerweise neben der Datenbank und anderen benötigten Servern, daher kann es schneller sein, das Nötige vorneweg zu laden. Netzwerkanfragen in einer solchen Umgebung sind stabiler. Wenn man alle Verarbeitung auf die Nutzerseite verlagert, muss man langsamere und instabilere Aufrufe bewältigen.
Der Server ist außerdem wahrscheinlich eine viel konsistentere Plattform als der Browser des Nutzers. Browser sind zwar besser geworden, haben aber immer noch viele subtile Unterschiede. Auf dem Server kann man die benötigten Werkzeuge und Runtime-Versionen genau festlegen und Updates deterministischer ausrollen.
Natürlich stimmt das nicht immer vollständig, und es gibt Ausnahmen. Ich arbeite überwiegend mit Frontend-Anwendungen, und es gibt auch gut entworfene Anwendungen, bei denen es sehr wertvoll ist, den Großteil oder sogar alles im Browser auszuführen. Das sind dann aber meist recht komplexe Web-Apps oder Fälle, in denen Rendering im Browser ohnehin in gewissem Maß erforderlich ist.
Die Generierung passiert nur einmal und ist sehr schnell abgeschlossen. Danach gelten aus Nutzersicht weiterhin die vielen Vorteile statischer Seiten.
Der Ressourcenverbrauch ist um mehrere Größenordnungen geringer, und die Seiten reagieren viel schneller. Auch die User Experience ist deutlich besser, aber in den letzten zehn Jahren haben wir dem kaum Aufmerksamkeit geschenkt.
rsyncauf den Webserver hochlud. Alle Seiten wurden dynamisch gerendert.Der Vorteil war, dass ich nach der einmaligen Einrichtung buchstäblich nie wieder an die Website denken musste und einfach nur mein bevorzugtes Markdown schreiben konnte.
Das war großartig. Zumindest bis der Webhoster PHP abgeschafft hat.
Aus diesen Gründen mag ich NextJS static export sehr.
Man baut die Seite und deployt nur statische
.html-,.js- und.css-Dateien auf ein beliebiges CDN oder einen statischen Webserver. Einzelne Seiten und Routen werden beim Build vorgerendert, deshalb ist der erste Ladevorgang sehr schnell und Suchmaschinen können die Seiten indexieren.Auch die Art, wie NextJS
.js-Code in Chunks aufteilt und vorlädt, trägt zu einem schnellen Ladeerlebnis bei. Wenn man reichhaltige Funktionen braucht, kann man sie beliebig dynamisch machen, indem man sie mit einer REST API nach Wahl verbindet.Mit einem MDX-Plugin lassen sich im selben Projekt auch vollständig statische Bereiche oder contentlastige Websites leicht erstellen.
Seit dem App Router in v13 habe ich allerdings das Gefühl, dass static export nicht mehr ausreichend gepflegt wird. Funktionen aus dem Pages Router wie shallow routing sowie statische Rewrites/Redirects fehlen beim static export.
Wenn man static export verwendet, braucht man die kommerziellen Vercel-Produkte überhaupt nicht, daher sorge ich mich, dass diese Funktion langfristig ganz verschwinden könnte.
Meist braucht man nicht einmal JavaScript, geschweige denn React, JSX, Middleware oder Server-Side Rendering.
Sich vorzustellen, so etwas mit so vielen beweglichen Teilen und npm-Abhängigkeiten langfristig zu warten, ist schwierig. Das heißt nicht, dass es dafür keinen Einsatzzweck gibt, aber bevor man für eine einzelne Landingpage zu einem Projekt mit einem 1.8-GiB-Git-Checkout und 828.128 Zeilen Code greift, sollte man es lieber einfach halten.
Siehe das Beispiel von Dan Abramov: https://gist.github.com/gaearon/9d6b8eddc7f5e647a054d7b33343...
Das liegt nicht am Geschäftsmodell von Vercel, sondern daran, dass dieser Anwendungsfall gemessen an der Nutzung von Next.js seltener ist.
Ich bin mir nicht sicher, was mit „static rewrites“ gemeint ist. Wird das nicht von Middleware erledigt?
Irgendwann in den 90ern habe ich meine Website mit m4 erzeugt, noch bevor ich den Begriff „Static Site Generator“ gehört hatte.
Danach bin ich zu PHP und Python gewechselt und nutze heute Jekyll, womit ich wieder bei statisch gelandet bin.
Wenn es irgendwie möglich ist, ist ein statischer Ansatz deutlich besser. Abgesehen von SSL-Zertifikaten kann ich alles nach meinem eigenen Zeitplan reparieren.
Wenn durch ein PHP-Upgrade etwas kaputtgeht, muss man es sofort beheben, und bis dahin ist die Website offline.
Bei einer statischen Website bleibt selbst dann, wenn der Generator kaputtgeht, das fehlgeschlagene Ergebnis einfach als statischer Zustand bestehen. Wenn ich keine neuen Beiträge veröffentlichen muss, ist das kein Problem.
Selbst wenn der Server ausfällt, muss ich nur einen Freund bitten, ein paar Dateien zu hosten. Ich muss nicht fragen: „Läuft das mit PHP-Version X und Konfiguration Y? Gibt es auch postgres?“
Manche Freunde sagen vielleicht auch: „Ich will auf meinem Rechner kein PHP installieren.“
Von der Komplexität her fühlt es sich ungefähr wie eine Stufe über
sed "s/VERSION/1.2.3/g"an. Wenn sich alles mit externen Shell-Befehlen erledigen lässt, muss man nichts wie Python installieren.Seit einigen Jahren erkunde ich ein Architekturpattern, das die Vorteile von statisch und dynamisch zugleich bietet.
Es erlaubt die Ausführung dynamischen serverseitigen Codes, hat aber sehr niedrige Skalierungskosten und erholt sich selbst, wenn etwas kaputtgeht.
Ich nenne das das Baked-Data-Pattern: https://simonwillison.net/2021/Jul/28/baked-data/
Die Kernidee ist, eine vollständige schreibgeschützte Kopie der Website-Daten als mit der Anwendung gebündeltes Asset auszuliefern.
Wie bei einer vollständig statischen Website muss bei jeder Änderung die gesamte Website neu ausgerollt werden, daher eignet sich das nicht für Websites mit laufenden Updates.
Der Vorteil ist, dass man es auf günstigem dynamischem Scale-to-zero-Hosting wie Vercel deployen kann, mehrere App-Kopien starten kann, um beliebigen Traffic zu verarbeiten, und der Host die App bei einem Absturz automatisch neu starten kann.
Ich habe statische Websites mit serverseitiger Suche oder Kommentarsystemen gesehen, bei denen jeder Beitrag oder Kommentar als eigene Flat File eingereicht wird und daraus statische Seiten automatisch neu erzeugt werden.
Ist der Unterschied vielleicht nur, dass statt Markdown-Dateien in sqlite gespeichert und von dort gebaut wird? Im Vergleich zu einer gewöhnlichen statischen Website mit allgemeiner Backend-/Server-seitiger Funktionalität scheint das der einzige auffällige, bedeutende Unterschied zu sein.
In kompilierten Binärdateien war es nie ungewöhnlich, kodierte binäre Ressourcen wie Dateien oder Bilder einzubetten. Man hat davon nur nicht zu viele verwendet, weil dadurch die ausführbare Datei größer wurde.
Ein Beispiel in C oder C++: https://github.com/graphitemaster/incbin
Interessant daran ist, dass Programme so gebaut wurden, dass sich die Daten in der ausführbaren Datei nicht verändern. Der kompilierte Code läuft auf der Maschine, und auch sicherheitstechnisch ergibt das Sinn.
Wenn man aber an Container denkt, zum Beispiel Docker, dann ist ein laufender Container ähnlich wie eine paketierte ausführbare Datei, hat aber auch ein Dateisystem.
Wenn man Daten in einen Container legt, ist das konzeptionell ähnlich wie in eine ausführbare Datei eingebettete Ressourcen; der Unterschied ist, dass sich diese Daten ändern können.
Wenn sich Daten zur Laufzeit im Container ändern, bleiben sie allerdings nicht erhalten, sofern man keinen persistenten Speicher anbindet.
In letzter Zeit frage ich mich, warum man nicht so etwas wie eine einzelne Datei gebaut hat, in der sich „eine ausführbare Datei und ein flüchtiger Datenspeicher innerhalb der ausführbaren Datei“ befinden. Programme und Daten wie eine Datenbank könnten doch in einer einzigen Datei kombiniert werden.
Das ist ein Gedanke, der lose mit „Baked Data“ zusammenhängt. Ressourcen in eine ausführbare Datei einzubetten bedeutet letztlich, kodierte Daten in die ausführbare Datei zu legen.
In Skriptsprachen könnte man eine Skriptdatei erzeugen, die base64-kodierte Daten direkt in Variablen enthält.
Die letzten beiden Ansätze eignen sich zwar nur für relativ kleine statische Daten, aber es wäre interessant, eine Technik zu entwickeln, die diese Beschränkung ausführbarer Dateien irgendwie aufhebt.
Meine Projektseite hoste ich ebenfalls auf diese Weise: https://usmanity.com/projects
Weil ich nicht jedes Mal die HTML-Dateien direkt bearbeiten wollte, wenn ich ein neues Projekt zur Liste hinzufüge oder Details bestehender Einträge ändere, nutze ich Notion und backe die Daten ein, bevor ich nach GitHub committe.
Wenn es aktiviert war, hat es alle Seiten der Website als HTML in ein Verzeichnis gebacken und
.htaccessso geändert, dass der gesamte Traffic dorthin geleitet wurde. Wenn Inhalte aktualisiert wurden, wurde alles neu gebacken.https://www.drupal.org/project/boost
Was bei statischen Websites aus meiner Sicht noch stark fehlt, ist die Frage, wo man ein CMS zum Bearbeiten hostet
Korrigiert mich gern, wenn ich falschliege, aber Decap CMS (früher Netlify CMS) läuft im Browser und kann über GitHub lesen/schreiben und anschließend einen Rebuild sowie ein Deployment auslösen. Wegen CORS kann der Browser aber wohl nicht direkt mit der GitHub-API kommunizieren, sodass man weiterhin einen kleinen Server oder Proxy braucht
Netlify hostet ein GitHub-Backend, das die Anfragen proxyt, aber damit ist man an Netlify und mögliche Änderungen der Preispolitik gebunden
Bei GitLab und BitBucket dürfte es dasselbe Problem geben: https://github.com/isomorphic-git/isomorphic-git#cors-suppor...
Gibt es dafür eine einfache Lösung mit minimalem Setup? Man könnte CORS per Browser-Erweiterung selektiv lockern, aber ideal ist das nicht
Ein an Git basiertes Static-Site-Generator-Setup mit einem CMS für Markdown-Bearbeitung und Live-Vorschau, das im Browser läuft und nur geringe Hosting-/Server-Anforderungen hat, wäre vermutlich ideal für unzählige kleine Websites und Blogs
Der Static Generator könnte diese Daten dann z. B. über einen JSON-Feed einlesen und daraus Seiten erzeugen. So könnte etwa jeder Produktdatensatz eine Beschreibung im HTML-Format enthalten
Dann könnten andere Leute Produktinformationen aktualisieren, während die Website trotzdem statisch bleibt. Ich dachte, Airtable wäre dafür geeignet, aber überraschenderweise unterstützt es HTML-Felder nicht besonders gut
Man baut die Website so, wie man möchte, verbindet Surreal per FTP und lässt dann Nutzer oder Kunden nur die erlaubten Bereiche bearbeiten
12 Dollar im Monat sind sehr günstig für etwas, das einem diese Sorgen abnimmt, und man kann nichttechnischen Nutzern einen vollständigen WYSIWYG-Editor bieten
[1] https://www.surrealcms.com
Derzeit funktioniert diese Erweiterung in lokal auf dem Laptop installiertem VS Code, aber nicht in GitHub Codespaces
Wenn man das innerhalb des kostenlosen GitHub-Codespaces-Kontingents mit einer vernünftigen Nutzungsbegrenzung zum Laufen bringen könnte, wäre das vermutlich der Gewinner. Man hätte ein vollständig online verfügbares, versionsverwaltetes Setup, ohne eine Entwicklungsumgebung auf dem eigenen Rechner installieren zu müssen, könnte die statische Website irgendwo wie auf S3 ausliefern und hätte trotzdem ein vollständiges CMS-Erlebnis
Ein sehr wichtiger Punkt bei statischen Websites ist, dass man sie viel leichter hochladen und dann vergessen kann
Wenn man sie etwa auf einer S3-Bucket-Website hochlädt, muss man sich fast um nichts kümmern
Wenn man eine PHP-Seite oder, schlimmer noch, ein selbst gehostetes WordPress als „hochladen und vergessen“-Website betreibt, kann sie sich in wenigen Monaten unbemerkt mit russischer Pornowerbung füllen
Ich betreibe ein paar statische Websites, und es ist wirklich schön zu wissen, dass sie immer online sind und nie repariert werden müssen. Bei dynamischen Websites braucht man dagegen Benachrichtigungen, um zu prüfen, ob sie ausgefallen sind.