- Selbst bei einfachen Websites wie persönlichen Blogs oder Kontaktseiten bleiben normale Nutzer meist bei CMS wie WordPress, während statische HTML-Websites paradoxerweise eher für professionelle Engineers leicht zu betreiben sind
- Wer eine statische Website selbst erstellen will, muss mehrere Zwischenschritte eigenständig bewältigen: Domain kaufen, Hosting auswählen, DNS konfigurieren, SSG wählen und eine Deployment-Pipeline einrichten
- Engineers nutzen über GitHub Pages oder Cloudflare Pages kostenloses Hosting und Custom Domains, während normale Nutzer selbst dann, wenn statisch völlig ausreichen würde, auf teurere und schwergewichtigere Dienste angewiesen sind
- SuperHTML wurde als erster HTML Language Server vorgestellt, der Nutzern Diagnosen meldet; bestehende Diagnose-Tools sind meist an bestimmte Frontend-Frameworks gebunden und lassen sich nur schwer mit reinem Vanilla HTML verwenden
- Wenn es nicht gelingt, einfache Webentwicklung einfach zu machen, entfernt sich das Web von Nicht-Fachleuten, und normale Nutzer werden in geschlossene Räume wie soziale Netzwerke gedrängt
Das Paradox, dass statische Websites schwieriger werden
- Zwei Beispiele persönlicher Websites werden einander gegenübergestellt
- Die eine ist ein komplexes, in PHP geschriebenes CMS und benötigt einen Webserver, mehrere Worker, einen Redis-Cache und eine SQL-Datenbank
- Auch das Frontend wird als Single Page Application geladen, fordert Inhalte im JSON-Format an und setzt sie anschließend im Client wieder zusammen
- Die andere besteht aus statischen HTML-Dateien und ein oder zwei CSS-Dateien und verwendet kein JavaScript
- Oberflächlich betrachtet würde man erwarten, dass normale Nutzer eine einfache statische Website nutzen und professionelle Engineers eine komplexe Struktur verwenden; tatsächlich ist es eher umgekehrt
- Wenn normale Nutzer eine statische Website selbst betreiben wollen, müssen sie mehrere Schritte überwinden
- Domain kaufen
- Hosting-Plattform finden
- DNS konfigurieren
- SSG auswählen oder selbst erstellen
- Deployment-Pipeline einrichten
- Software Engineers hingegen können über GitHub Pages, Cloudflare Pages und ähnliche Dienste kostenloses Hosting sowie Unterstützung für Custom Domains nutzen
- In der Folge sind normale Nutzer selbst in den 99 % der Fälle, in denen eine statische Website ausreichen würde, an komplexe Lösungen gebunden, die mehr kosten und mehr Rechenressourcen verbrauchen
Der Bedarf an Tools, die das einfache Web einfach machen
- Ein Vortrag auf der SquiggleConf in Boston behandelte Erfahrungen bei der Implementierung eines HTML Language Servers; das Fazit führte zum Thema Web Accessibility
- SuperHTML wurde als erster HTML Language Server vorgestellt, der Nutzern Diagnosen meldet; der zugehörige Beitrag schaffte es auf die Hacker-News-Frontpage
- Linter existieren, und auch Editor-Diagnosen sind möglich, aber meist sind sie an bestimmte Frontend-Frameworks gebunden
- Dadurch entscheiden sich Nutzer für ein Framework, selbst wenn sie dessen Komplexität eigentlich nicht brauchen
- Das Web gehört nicht nur Software Engineers; je komplexer wir das Web machen, desto stärker werden normale Nutzer in den umzäunten Bereich sozialer Netzwerke gedrängt
- Startups und Big Tech haben aufgrund fehlender wirtschaftlicher Anreize kaum Grund, dieses Problem stellvertretend zu lösen; nötig ist, das einfache Web einfacher zu machen
1 Kommentare
Kommentare auf Hacker News
Ich habe viele bittere Erfahrungen damit gemacht, Marketing-Verantwortliche davon zu überzeugen, WordPress aufzugeben und statische Websites zu nutzen.
Am Ende geht es im Kern um die Einfachheit der Bearbeitung. WordPress-Sites sind nicht für Hosting, Technikverantwortliche, Buchhaltung oder Leser optimiert, sondern für Redakteure; und diejenigen, die die Site bearbeiten, bestimmen am Ende die Implementierung.
Wenn man ihnen die Wahl lässt zwischen einer Site, die in unter 100 ms rendert, vollständig sicher ist und 0 Euro Hostingkosten verursacht, aber Markdown-Dateien und ein wenig Deployment per Git erfordert, und WordPress, das langsam, teuer, anfällig ist und laufend Wartung braucht, aber eine gute Editing Experience bietet, wählen sie immer WordPress.
Ich war immer verwirrt, warum diese Leute die Entscheidungsgewalt haben, aber selbst wenn man dasselbe Experiment mehrfach wiederholt, ist das Ergebnis immer gleich.
Ich sehe nicht, was daran merkwürdig sein soll, WordPress zu wählen, statt einen Texteditor und Git zu lernen. Das Experiment müsste WordPress mit einem Tool vergleichen, das eine gute Editing Experience bietet, im Hintergrund aber eine statische Site und ein Git-Deployment erzeugt. Dann können die Nebenanforderungen Sicherheit und Geschwindigkeit relevant werden.
Es ist weniger ein Blog als vielmehr eine anpassbare Anwendung, die Laien mit Klicks und Drag-and-drop auf die gewünschten Funktionen zurechthämmern können. Kein Coding nötig, bis sie gehackt werden oder eine Custom-Funktion auftaucht, für die man einen echten Engineer braucht.
Wenn man Hugo, Ghost usw. nutzt, läuft es auf „Dafür brauchen Sie eine andere Plattform“ hinaus, und diese Plattform ist dann Shopify, ein Buchhaltungssystem, ein Social-Network-/Membership-Plugin, eine Jobbörse usw. WordPress ist zu einem Ding geworden, das man in alles Mögliche verwandeln kann.
Wenn jemand einem Consultant sagt, was er haben möchte, lautet die Antwort: „Ich richte Ihnen das in WordPress ein.“ Und weil alle WordPress nutzen, war es einfach, jemanden zu finden, der bei Problemen hilft, ein Plugin leicht anpasst oder einen Hook für den E-Mail-Versand einbaut. Die Ära der PHP-Consultants hat die Dominanz von WordPress geschaffen.
Das Problem ist, dass das meiste, selbst inklusive kostenpflichtiger Lösungen, keine vollständige Lösung ist. Sobald man anfängt, damit zu arbeiten, merkt man schnell, dass WordPress absurde Einschränkungen erzwingt. Man kann keinen Online-Shop außerhalb der Performance-Katastrophe eines Entity-/Metadata-Systems entwerfen, bei dem schon mittelgroße Queries 5 Sekunden dauern und 50 nicht optimierte Neben-Queries erzeugen. Manche Plugins umgehen WordPress sogar und legen eigene Datenbanktabellen an.
WordPress hat außerhalb von Blogs eine furchtbare Architektur, wird aber als Werkzeug für alles verwendet. Andere CMS tun das nicht, deshalb werden sie von den Leuten nicht genutzt.
Die Inhalte können weiterhin als generierte statische Dateien über ein CDN verteilt werden. Eine statische Site muss nicht Markdown und Git voraussetzen.
Ich habe lange nach einer Toolchain gesucht, mit der selbst ein Praktikant ohne jegliche technische Erfahrung Änderungen ausrollen kann, ohne sich in technischen Details zu verheddern, aber ich habe sie noch nicht gefunden.
Am nächsten kommt ein statischer Site-Generator auf einem Headless CMS, aber ehrlich gesagt sind sie alle ziemlich schlecht.
Als ich 2016 bei einer Agentur arbeitete, die Präsentations-Websites für lokale Unternehmen baute, bat ein Kunde darum, ein kleines iframe für ein Buchungssystem in die von ihnen erstellte Website einzubauen. Was sie schickten, war ein Word-Dokument; wie sich herausstellte, exportierten sie es als HTML und luden es auf günstiges Shared Hosting hoch.
Für sie passte das hervorragend. Sie konnten ihre Online-Speisekarte immer aktuell halten, weil sie sie direkt aus dem Word-Dokument exportierten, mit dem sie auch die gedruckte Karte erstellten. Damals haben wir intern ein bisschen darüber gespottet, aber heute tut mir das leid. Wenn man eine Million wichtigere Dinge zu tun hat, etwa ein Restaurant zu führen, ist das eigentlich eine geniale Methode.
Statische Sites zu erstellen ist nach wie vor einfacher. Nur sind die Authoring-Tools, die HTML erzeugen, heute nicht besonders gut, oder selbst wenn sie brauchbar sind, kommt ein Prozess hinzu, der auf einem Server laufen muss, um die Site auszuliefern.
Meine Aufgabe ist nicht, sie mit „das könnte man besser machen“ zu verspotten, sondern ihre Lösung zu verbessern und dafür zu sorgen, dass die Lösung, die ich liefere, mindestens so gut funktioniert wie der bisherige Ansatz, möglichst besser, ohne den bereits erzielten Erfolg zu stören.
Viele Entwickler geben es ungern zu, aber solche provisorischen Web-Lösungen funktionieren oft besser als viele Strategien, die ein erfahrener Webentwickler allein umsetzen würde.
Entscheidend ist, was das Unternehmen anbietet und wie es Beziehungen zu seinen Kunden aufbaut und mit ihnen interagiert. Manchmal reicht es, ein Word-Dokument nach HTML zu exportieren. Mit Technik kann man es verbessern, aber die eigentliche Magie liegt bei den Menschen, die das Geschäft betreiben.
Wege zu finden, solche Lösungen zu verbessern, kann tatsächlich ziemlich schwierig sein. Man kann eine bessere Website bauen und sie auf ausgefeilter Infrastruktur deployen, aber gefällt sie den Kunden am Ende besser? Wird das Geschäft dadurch besser? Dieser Teil kann alles andere als trivial sein.
Seit Jahren suche ich nach einer guten Alternative, die korrekteres HTML erzeugt als Words HTML-Export und mehr Optionen bietet.
Solche Dinge mag ich. Es gibt auch viele Sites als einzelne HTML-Datei, die mit Vue template gebaut werden, Sites, die als öffentliche Notion-Dokumente veröffentlicht sind, oder Inline-Fotobibliotheken in iCloud. Es ist erstaunlich, wie einfach und weit verbreitet es geworden ist, Dinge einfach miteinander zu verbinden, und man merkt, wie oft man die Sache verkompliziert, wenn man versucht, alles von Grund auf selbst zu bauen.
Wenn ich wenig Zeit habe, mag ich für kleine Microsites oder einmalige Sites, die man schnell zusammensteckt, auch Dinge wie mmm.page. Es macht Spaß, solche Tools zu erkunden.
Die „Dokumente“ einiger Seiten bestehen aber aus Bündeln von Tabellen mit Datum und Text, und der Kunde pflegt sie selbst. Am Ende sind wir bei einer ähnlichen Lösung gelandet: Sie legen Tabellen in ein Word-Dokument, geben es uns, und wir exportieren es nach HTML/CSS und setzen es an die passende Stelle.
Das ist weder elegant noch eine skalierbare Lösung, aber für den betreffenden Zweck ist es mit Abstand die einfachste Methode.
Damals war das erstaunlich, und heute ist es das immer noch. Still und leise haben wir den Traum verwirklicht, Computing zu allen zu bringen.
Genau dieses Problem erleben wir gerade massiv in Asheville. Selbst als der Mobilfunkdienst gerade erst wieder da war, nutzten alle ein ständig abbrechendes, miserables 3G, und keine der Websites, auf denen man grundlegende Überlebensinformationen bekommen sollte, lud überhaupt.
Gute Leute haben eine reine Text-News-Site gebaut, und heute habe ich gesehen, dass auch die Website von Buncombe County eine Low-Bandwidth-Site bekommen hat; als ich sie öffnete, blockierten aber immer noch 130 KB Bootstrap-CSS und 50 KB jQuery das Rendering.
Es ist großartig, dass Leute so etwas machen, aber die Bürger hätten es vor anderthalb Wochen gebraucht. Inzwischen haben wir schon herausgefunden, wo man Wasser, Lebensmittel, Brauchwasser und so weiter bekommt. Zu sehen, wie sehr Technik in dieser Situation versagt hat, war auf deprimierende Weise augenöffnend.
Die Stromausfallkarte des Versorgers liegt hinter einem Login und wird mit schickem Clustering und UI-Funktionen gerendert, sodass sie selbst bei guter Verbindung schon langsam ist. Deshalb dauert es ziemlich lange, den Status zu prüfen oder einen Ausfall zu melden.
Man kann den Stromversorger auch anrufen, aber das Menü ist nicht über Tastentöne, sondern über Sprach-Navigation gelöst, und es erkennt die durch schlechte 4G- oder 2G-Verbindungen verzerrte Stimme nicht gut.
Man braucht lange Wellenlängen und niedrige Leistung. Aber die Einstiegshürde ist sehr hoch, und ich bin mir nicht sicher, ob das aus guten Gründen so ist.
Von Black Mountain bis zu den Grenzen von Tennessee und Georgia war die Verbindung weg. Ich frage mich, ob viele Leute überhaupt wieder miserables 3G bekommen. Was ich weiß: Es war schwer, mit den Menschen, die dort leben, in Kontakt zu bleiben.
Einige meiner besten Arbeiten habe ich auf einem 12-Zoll-MacBook mit wackeligem Hotel-WLAN gemacht. Deshalb achte ich sehr auf Seitengeschwindigkeit.
Wenn man das Leid dieser Katastrophe in einem Satz zusammenfasst, dann war es ein Zusammenbruch der Kommunikation in allen möglichen Formen.
Ich stimme der Aussage sehr zu: „Das Web gehört nicht nur Software Engineers. Je komplexer wir das Web machen, desto stärker drängen wir normale Nutzer in die Umzäunungen, die wir soziale Netzwerke nennen.“
Zu der jüngsten Konferenz Squiggle Conf, von der dieses Zitat stammt, gibt es auch einen Podcast: https://changelog.com/jsparty/339
Mit der Zeit sind die Funktionen, die Menschen von einer „einfachen Website“ erwarten, deutlich anspruchsvoller geworden
Selbst ich als Programmierer bin ein paar Mal in die Falle von Static-Site-Generatoren getappt
Wenn man ein Side Project mit einem Static-Site-Generator beginnt und dann in dem Moment, in dem man eine kleine Funktion hinzufügen möchte, bereut, nicht einfach mit einer simplen Rails- oder PHP-App angefangen zu haben, ist das frustrierend
Wenn ich heute eine statische Website brauche, beginne ich einfach mit einem Ordner voller HTML-Dateien. Der Weg von der Idee zur Umsetzung ist viel weniger kompliziert und schneller, ohne theoretische Werkzeugdebatten oder Aufschieben
Ich bin ziemlich zufrieden damit, HTML und CSS direkt zu schreiben, würde es aber nicht allen empfehlen
Ein weiterer schöner Punkt: Wenn man sich später entscheidet, nach Rails zu „entkommen“, kann man den Ordner mit den HTML-Dateien einfach in den public/-Ordner von Rails kopieren. Der Upgrade-Pfad ist ziemlich einfach
In der Ruby-Welt ist Jekyll der bekannteste, aber er ist auf den speziellen Zweck zugeschnitten, Blogs in Markdown oder einer anderen leichtgewichtigen Markup-Sprache zu schreiben. Man kann ihn zwar für andere Zwecke zurechtbiegen, aber als allgemeiner Static-Site-Generator ist er nicht besonders bequem
Wenn du etwas willst, das sich leicht nach Rails kopieren/einfügen lässt, ist middleman gut, ein Rack-basierter Static-Site-Generator. Man kann von Anfang an mit erb/haml und ActiveSupport arbeiten
Wenn du die Einfachheit von handgeschriebenem HTML und CSS beibehalten willst, aber nur Komfortfunktionen wie Includes, Partial Templates und Link-Helper möchtest, ist nanoc als inkrementeller Static-Site-Generator ganz brauchbar. Man startet mit gewöhnlichem HTML/CSS und fügt Funktionen nur bei Bedarf hinzu
Gelegentlich schreibe ich Code, um Verhalten anzupassen, aber das passiert vielleicht alle paar Jahre. Es ist schlicht und funktioniert einfach gut
Es gibt Dinge, die ich von dynamischen Websites vermisse, aber ich bin mir nicht sicher, inwiefern ein einfacher Ordner mit HTML-Dateien besser sein soll als Pelican
Die Grundregel, die ich aufgestellt habe, um ein Aufblähen der Website-Funktionen zu verhindern, war, die gewünschte Identität festzulegen. Ich wollte sie als Archiv meiner Arbeiten haben, und ein Archiv muss über sehr lange Zeit Bestand haben. Deshalb passen statische Dateien, die sich leicht kopieren, spiegeln und auf jeder Hosting-Plattform betreiben lassen
Es hat etwas gedauert, die mehrsprachige Website richtig hinzubekommen, aber zumindest war das ein einmaliger Aufwand
Auch Style-Änderungen können zum Problem werden, wenn sie in HTML-Dateien hartcodiert sind
Fortgeschrittenere Dinge schreibe ich mit Django. Funktionen hinzuzufügen ist für mich damit sehr einfach
.md→.htmleinzubauen, aber bisher war das nicht nötigSchön ist auch, dass man die Site leicht über einen lokalen Server ansehen kann. Am besten wäre es, wenn sie auch über file:// betrachtbar wäre, aber ich habe die Struktur nicht vollständig aufgelöst und bin am Ende bei einem
make local-Schritt gelandet, der eine separate Kopie für dateibasiertes Ansehen erzeugtBei persönlichen Websites von Webentwicklern gibt es einen Faktor, der Komplexität erzeugt: lebenslaufgetriebene Entwicklung
Es gibt Fachleute, die persönliche Side Projects für lebenslaufgetriebene Entwicklung nutzen wollen, weil sie glauben, so weniger Gefahr zu laufen, Projekte ihrer Arbeitgeber kaputtzumachen
Zum Beispiel hatte ich noch heute Morgen eine unabhängige Website, die bald veröffentlicht werden sollte, und hauptsächlich aus Lebenslaufgründen ein beliebtes modernes Web-Framework verwendete; nun kann ich die Website nicht mehr aktualisieren
Ein NPM-Paket hatte ein kritisches Sicherheitsproblem, und beim Update geriet NPM in einen Konflikt wechselseitiger Abhängigkeiten, den es nicht automatisch auflösen konnte. Ironischerweise konnte ich genau deshalb kein Sicherheitsupdate auf die Produktionssite pushen
Für diese Site hätten fünf handgeschriebene HTML-Dateien, ein wenig Inline-JS und zwei kleine Perl-CGI-Skripte ausreichen können. Dann hätte sie auch nach 25 Jahren noch perfekt funktioniert
Stattdessen gibt es allein im NodeJS-Teil 129 NPM-Pakete, häufig nötige Sicherheitsupdates und einen undurchsichtigen Source-Tree aus Template-Schnipseln, TS-Konfiguration und Handlern
Aber Fachleute können es sich nicht leisten, Dinge nicht auf absurd komplexe Weise zu tun. Wenn zum Beispiel Perl im Lebenslauf steht, ist das ein schwerer Schlag für die Beschäftigungsfähigkeit. Selbst Leute, die den Lebenslauf nicht wegen Altersdiskriminierung wegwerfen, werden einen für dumm halten, weil man keine lebenslaufgetriebene Entwicklung betrieben hat
In meinem Fall interessieren mich Lebensläufe oder Pitches überhaupt nicht, aber ich will trotzdem etwas Ergonomischeres, als HTML aus JS/Python-Templates auszuspucken. Deshalb sind meine Sites eine Kombination aus TypeScript, Mithril, Express und einigen Utility-Libraries
Wie viele Pakete das sind, weiß ich nicht und es ist mir auch egal. Hauptsache, die Dinge, die ich einbinde, sind reif und bringen nicht alle paar Minuten ein neues Feature samt Schwachstelle hervor
Du hast den Stack nicht genannt, aber es klingt sehr wahrscheinlich nach React und seinem „ständig besser werdenden, aber niemals fertigen“ Ökosystem. Als ungefragter Rat: Es ist besser, nicht an eine falsche Dichotomie zu glauben. Zwischen reinem HTML und dem schlimmsten Morast liegt ein großer Raum, und die Situation in der React-Welt ist React-spezifisch und repräsentiert nicht alles außerhalb davon
Die Killer-App von WordPress sind Kommentare. Statische Site-Generatoren erlauben per Definition praktisch keine Kommentare, aber in WordPress-Blogs sind sie fast immer eingebaut.
Wenn etwas wie Hugo im Blog-Bereich wirklich durchstarten will, müsste man nur ein gut aussehendes Theme mit Kommentaren bauen. Man müsste es einfach in großem Maßstab lösen. Zum Beispiel könnte man pro Blog geshardetes SQLite verwenden, sodass ein Drittanbieter es sehr günstig hosten kann. Dann hätte man eine kleine Gans, die goldene Eier legt.
Kommentare und Diskussionen zu Artikeln finden in Drittanbieter-Communities wie Reddit, HN oder Facebook statt. Was ist wohl größer: die Zahl der Leute, die die Kommentarliste unter einem Substack-Artikel überfliegen, oder die Zahl derer, die ein oder zwei Seiten HN-Kommentare zum selben Artikel lesen?
Bei technischen Artikeln ist die HN-Diskussion ziemlich sicher hochwertiger als die Kommentar-Threads eines bestimmten Artikels. Denn HN hat bereits eine größere Leserschaft angezogen als 99,9 % aller Blogs.
Der wichtigste Vorteil direkter Kommentare unter einem Blogbeitrag ist nur, dass der Autor sie viel wahrscheinlicher sieht. Ein kurzer Auftritt auf der HN-Startseite ist vergänglich.
Das WordPress-Ökosystem ist das genaue Gegenteil. Es besteht aus milliardenschweren Unternehmen, die sehr genau verstehen, was Betreiber von CMS und Websites in ihren jeweiligen kleinen Marktnischen brauchen; dieser Markt umfasst ungefähr 500 Millionen Websites.
Der Autor dieses Artikels mag zwar klug sein, aber bei den praktischen Einsatzfällen von CMS ist er es eindeutig nicht. Das Weltbild „statische HTML-Sites sind besser, aber wegen böser Unternehmen nicht populär“ stellt sich als ziemlich falsch heraus, sobald man ein- oder zweimal gegen Bezahlung Websites gebaut hat.
Statische HTML-Site-Generatoren werden mit hoher Wahrscheinlichkeit nicht alles können, was Kunden wollen. WordPress hat schon vor langer Zeit erkannt, wie breit und vielfältig dieser Markt ist, und deshalb Plugin-Unterstützung implementiert.
Ich stimme zu 100 % zu, dass Kommentare einer der ursprünglichen Gründe sind, im Web etwas CMS-Ähnliches statt eines statischen Site-Generators zu verwenden. Aber daneben gibt es noch eine Million andere Anwendungsfälle.
Mit rein statischen HTML-Dokumenten kommt man nicht besonders weit. Sobald man den minimalistischen Entwicklerblog verlässt, braucht man viel Programmlogik, um das zu tun, was echte Nutzer und Kunden wollen. Also nutzt man ein CMS, das zu den Anforderungen passt, und cached aggressiv, wenn es viel Traffic aushalten soll. Auch das gehört zur Arbeit.
Ich verstehe einfach nicht, warum Entwickler, die sich für besonders toll halten, das Rad neu erfinden wollen, statt ein wenig zu lernen, wie Caching funktioniert, und es anzuwenden. Ist das etwa auch so ein langweiliges „gelöstes Problem“?
Ich nutze selbst Hugo, aber auch wenn der Footprint aus Engineering-Sicht unnötig groß ist, ist die User Experience bei WordPress deutlich freundlicher.
Nicht jede Business-Website will Kommentare, aber wahrscheinlich will sie ein Kontaktformular. Eine E-Mail-Adresse zu veröffentlichen ist ebenfalls eine Option, aber es ist besser, die Eingabe-Pipeline zu verwalten.
Bei statischen Sites muss man einen vertrauenswürdigen Service finden, der die Einreichungen verarbeitet, und ihn sauber in die Site integrieren. Das ist ein weiteres bewegliches Teil, kann eine zusätzliche Rechnung bedeuten und ist ein weiterer Faktor, um den man sich kümmern muss, wenn die Branche konsolidiert.
https://hn.algolia.com/?q=%22disqus%22
Facebook bot ebenfalls ein Kommentarsystem an, das viele Sites nutzten, verlor aber durch mehrere Skandale Vertrauen und Reichweite.
Ich passe auch in dieses Paradox. Ich habe meine persönliche Website in modernem PHP neu geschrieben, ohne Framework oder Datenbank.
Sie ist größtenteils statisch, aber ich nutze PHP, um Header einzufügen und Listen wie die Liste der Blogbeiträge zu verarbeiten. Es war etwas bequemer, nicht vollständig statisch zu sein. Ich schreibe einen Beitrag, committe und pushe, und er ist sofort online. Die meisten statischen Site-Generatoren fühlten sich mir zu kompliziert an.
Der Code einer einzelnen Seite sieht ungefähr so aus:
title = "Blog Article Title";,$this->shortTitle = "Title";,$this->date = mktime(0,0,0,1,27,2024);,if ($this->mode == PageMode::Meta) return;, danach folgt roher HTML-Content.Der Router fügt automatisch Header und Footer der Site hinzu, und wenn man einem Ordner eine Datei
_layout.phphinzufügt, kann man den Unterseiten eine weitere Layout-Ebene geben. Die Blog-Listenseite durchsucht die einzelnen Beitragsdateien im Ordner und baut daraus einen Index.Hier kommt
$this->mode == PageMode::Metazum Einsatz. Der Code jeder Datei wird ausgeführt, um Metadaten zu erhalten, und bricht ab, bevor der Rest gerendert wird. Wenn der Content stark wächst, skaliert das nicht besonders gut, aber wenn es zum Problem wird, passe ich es an.Der gesamte PHP-Code meines „Frameworks“ besteht nur aus vier Dateien:
init.php,functions.php,Layout.php,Page.php.Der Vorteil als Entwickler ist, dass man Code statt Konfiguration oder Daten verwenden kann. Man kann Code auch nutzen, um Content effizienter zu schreiben.
Das Ergebnis ist noch ziemlich unfertig, aber hier ist es: https://www.codaris.com/
include()in PHP.Aus Sicht der User Experience für Website-Betreiber ist das nicht wirklich ein Paradox. WordPress macht die Dinge absurd einfach, auch wenn der Overhead viel größer ist.
Es wirkt nur dann wie ein Paradox, wenn man es als Trade-off gegenüber der Zeit betrachtet, die man in das Einrichten diverser Dinge steckt. Für die meisten Leute ist die Alternative, jemanden dafür zu bezahlen, ihnen eine Website zu bauen.
Wenn man einen WYSIWYG-Editor für Hugo bauen würde und den Weg von der Domain-Registrierung bis zur Veröffentlichung der Site mit ein paar Klicks erledigen könnte, ließe sich damit viel Geld verdienen.
Ich verstehe aber, was gemeint ist. Auch wenn solche Unternehmen dem Beschriebenen schon nahekommen: Wenn jemand die kleinen Zwischenschritte übernehmen kann, wäre das für manche ein großer Vorteil.
[1] https://micro.blog
Der Teil „Als ich SuperHTML veröffentlicht habe, wusste ich, dass es der erste Language Server für HTML ist, der Nutzern Diagnosen meldet. Ich habe einen Blogbeitrag geschrieben, er landete auf der Hacker-News-Startseite, und niemand hat mich korrigiert, also stimmt es“ liegt vermutlich daran, dass die meisten IDEs so etwas schon jahrelang gemacht hatten, lange bevor Microsoft LSP herausbrachte.
Vim, Neovim, Helix, Zed und VSCode teilten sich alle dieselbe grundlegende Implementierung ohne Diagnose-Unterstützung.
Helix wird SuperHTML ab dem nächsten Release standardmäßig aktivieren: https://github.com/helix-editor/helix/pull/11609