Eine einzelne Datei, portabel, selbstaktualisierend: Pure-HTML-Web-Apps

 (hyperclay.com)
26 Punkte von GN⁺ 2025-08-19 | 7 Kommentare | Auf WhatsApp teilen
  • Hyperclay unterstützt die Erstellung von Web-Apps, bei denen UI, Logik und Daten in einer einzigen HTML-Datei integriert sind
  • Änderungen können direkt in der Datei vorgenommen werden, mit sofortiger Bearbeitung und Live-Freigabe; sogar Aussehen, Verhalten und Bearbeitungsweise der App lassen sich direkt steuern
  • Bietet eine Struktur für sofortige Ausführung und Speicherung ohne separaten Build- oder Deployment-Prozess, Datenbank oder komplexes Backend
  • Mit nur einer HTML-Datei lässt sich die App im Browser, auf dem Server oder offline – überall ausführen; alle Änderungen werden versioniert und können wiederhergestellt werden
  • Entwickelt, um die Komplexität moderner Webentwicklung zu reduzieren und es jedem leicht zu machen, interaktive Apps zu erstellen, die in Echtzeit lebendig sind

Einführung: Lebendige Web-Apps aus nur einer HTML-Datei mit Hyperclay

  • Hyperclay bietet Programmierern die Erfahrung, Web-Apps wie ein Produkt zu formen – ohne komplexes Infrastrukturmanagement und mit nur einer portablen HTML-Datei
  • Ziel ist eine in sich abgeschlossene Struktur, die allein mit einer Datei auskommt und Konfigurationsdateien, Builds, Frameworks und Deployment-Pipelines überflüssig macht, die in klassischer Webentwicklung als unverzichtbar gelten

Zentrales Konzept und Vorteile

  • Die App besteht aus einer einzigen HTML-Datei
  • Über eine visuelle UI kann die Datei selbst in Echtzeit bearbeitet werden, und diese Änderungen werden sofort dauerhaft als Zustand der App gespeichert
  • UI, Logik und Daten sind gemeinsam dynamisch in einer Datei enthalten
  • Nutzer können die App wie ein Dokument sofort bearbeiten, Änderungen direkt teilen oder herunterladen und auch offline verwenden
  • Ähnlich wie bei „Google Docs for interactive code“ sind Teilen, Bearbeiten und Kontrolle über Eigentümerschaft frei möglich

Zusammenfassung der Hauptfunktionen

  • Direkte Manipulation: Die App kann während der Ausführung sofort bearbeitet werden. Änderungen werden ohne Kompilieren oder Neuladen direkt übernommen
  • What you see is what you build: Wenn die UI angepasst oder der Quellcode direkt bearbeitet wird, ändert sich die App sofort – ohne Zwischenschicht
  • Echte Portabilität: Die App kann als HTML-Datei exportiert und überall (Server oder offline) identisch ausgeführt werden. Jede Speicherung wird versioniert und kann wiederhergestellt werden
  • All das funktioniert ohne spezielle Technik, ausschließlich mit einer einzigen Standard-HTML-Datei

Technische Struktur

  • Hyperclay besteht aus einem NodeJS-Server und einer clientseitigen JS-Bibliothek
  • Wenn die HTML-Seite ihren DOM selbst verändert, wird das geänderte document.body.outerHTML an den Server gesendet, und genau diese HTML-Datei wird aktualisiert
  • Änderungen innerhalb der App, etwa das checked-Attribut einer Checkbox, werden dauerhaft im HTML-Code gespeichert, sodass beim nächsten Aufruf derselbe Zustand reproduziert werden kann
  • Unterstützung für Versionsverwaltung sowie Lese-/Schreibrechteverwaltung

Konkrete Beispiele

  • Von direkt bearbeitbaren Blogs bis zu Checklisten für Arbeitszeiten lassen sich alle Apps in einer einzigen HTML-Datei erstellen und speichern
  • Mit dem Attribut contenteditable oder in der Form `` wird der Zustand der App direkt im Dokument festgehalten

Hintergrund und Problemstellung

  • Beim Erstellen dutzender Websites pro Jahr entstand der Wunsch, dass sich das Programmieren von Web-Apps so natürlich wie Schreiben anfühlen sollte
  • Traditionelle statische Websites sind flüchtig: Änderungen durch Nutzer werden nicht gespeichert
  • Um Datenpersistenz im Web umzusetzen, ist normalerweise übermäßiger Aufwand nötig – etwa für Datenbanken, APIs, Templates oder Account-Systeme
  • Für Prototypen, einfache Tools, persönliche Entwicklungslogs oder Blogging ist das ineffizient, wenn man Dinge schnell erstellen, in Echtzeit bearbeiten und teilen möchte

Wie Hyperclay das löst

  • UI, Zustand und Verhalten sind in einer einzigen HTML-Datei integriert
  • Wie beim Öffnen einer Desktop-App lässt sich alles einfach öffnen und sofort bearbeiten, und das Ergebnis kann direkt online übernommen werden
  • Es führt das Konzept persistenter digitaler Objekte ein: shared, cloneable, persistent
  • Einsetzbar für Website-Builder, Dokument-, Diagramm- und Präsentationstools, Dashboards, Blogs, Umfragen, Quiz-Erstellung, Datenvisualisierung und viele weitere Werkzeuge

Gesamtüberblick des Konzepts

  • Die meisten Web-Apps nutzen ohnehin bereits HTML
  • Wenn Zwischenschritte entfallen, kann eine HTML-Datei die Rolle von gesamter Datenbank / API / UI übernehmen, wodurch sich der Stack auf nur wenige Zeilen vereinfacht
  • Entwickler können Komplexität reduzieren und mit minimalem Code Apps erstellen, die sich gut nutzen und warten lassen

Anwendungsbeispiele mit Hyperclay

  • Ob Blog, Checkliste oder andere App: Alles kann mit nur einer HTML-Datei erstellt, verteilt, geteilt und bearbeitet werden
  • Direkt nutzbar in der Form `Mein Blog!

`; mit `` wird jeder Zustand dauerhaft im Dokument gespeichert

Fazit

  • Hyperclay zeigt einen neuen Weg auf, wie jeder ohne die Umständlichkeit klassischer Webentwicklung leichte, portable interaktive Web-Apps erstellen und in Echtzeit teilen, speichern und wiederherstellen kann
  • Es ist eine Web-App-Plattform der nächsten Generation, die nicht nur für Entwickler und Designer, sondern für alle leicht nutzbar ist

Verwandte Beiträge

7 Kommentare

 
bobross0 2025-09-03

Interessant.
 
aobamisaki 2025-08-21

Das ist im Funktionsprinzip ähnlich wie die Web-Editoren, die früher überall verbreitet waren, aber ich finde es interessant, dass dafür schon eine einzige HTML-Datei ausreicht. Persönlich wirkt das auf mich auch wie eine Art Proof of Concept, aber ehrlich gesagt bin ich auch neugierig, was daraus werden könnte, wenn man das geschickt nutzt.
 
ifmkl 2025-08-20

Funktioniert das nicht im Grunde genauso wie der Editor, der früher unter https://de.news.hada.io/topic?id=19611 gepostet wurde? Ich habe hier auch zum Self-Hosting auf dem Server ein einfaches Backend mit Node.js drangehängt, damit sich mit dem Editor geschriebene Posts speichern lassen, und zusätzlich zwei Funktionen eingebaut, die die Liste in index.html laden und anzeigen, sodass ich es als schlichtes Blog-/Board-System nutze. Wenn ich mich so umschaue, fühlt es sich im Grunde identisch an.
 
reagea0 2025-08-19

Interessant!
Ich frage mich, wie es um die Sicherheit steht.
 
m00nlygreat 2025-08-19

Interessante Idee. tiddlyWiki war auch spannend.
 
developerjhp 2025-08-19

Interessant..
 
GN⁺ 2025-08-19
Hacker-News-Kommentare
  • Hyperclay ermöglicht es HTML-Seiten über einen NodeJS-Server und eine Frontend-JS-Bibliothek, das DOM zu aktualisieren und die geänderte .html-Quelle zu ersetzen, sodass die Seite dauerhaft aktuell bleibt
    Wenn man zum Beispiel ein Kontrollkästchen anklickt, wird das Attribut checked hinzugefügt, und dieser Zustand von document.body.outerHTML wird mit Hyperclay global gespeichert, sodass er beim nächsten Besuch genauso wieder erscheint
    Automatische Versionsverwaltung sowie Lese-/Schreib-Berechtigungen werden ebenfalls unterstützt
    Ich denke, am nützlichsten ist das, wenn Entwickler und Content-Editor dieselbe Rolle sind, denn wenn mehrere Editoren gleichzeitig arbeiten, können sie die Änderungen der anderen überschreiben
  • Wenn ein NodeJS-Server zwingend erforderlich ist, bin ich verwirrt, denn dann scheint es kein vollständig eigenständiges HTML-Datei-Konzept mehr zu sein
  • Ich habe diesen Inhalt direkt so auf der Homepage ergänzt
    Zur Info: Ich arbeite gerade an einer Möglichkeit, „DOM-basierte Schema-Migrationen“ an alle vom Entwickler geforkten Apps auszurollen
  • Ich habe gehört, dass TiddlyWiki die Inspiration war, aber war der Kern von TiddlyWiki nicht gerade, dass kein Server nötig ist?
    In der Praxis kommt man beim Bauen einfacher Web-Apps zwar irgendwann an einen Punkt, an dem ein Server nötig wird, aber die Kombination aus serverlosem Ansatz und Server-Kopplung wirkt etwas widersprüchlich
    Ein Vorteil wäre allerdings die bessere geräteübergreifende Zugänglichkeit, und Online-Bearbeitung dürfte einfacher sein
    In meinem Fall bearbeite ich auf dem Handy in einem Texteditor und synchronisiere per Sync-App mit dem Laptop
  • Ich wünschte, die Web-Standards würden lokal über das file://-Protokoll ausgeführte Dateiseiten besser unterstützen
    Jedes Mal, wenn ich eine einfache HTML/Vue-Mini-App baue, stoße ich auf Probleme und muss immer Workarounds suchen
    Zum Beispiel können lokale HTML-Dateien keine lokalen JS-Module importieren oder andere lokale Dateien wie Audio öffnen
    Ich verstehe, dass Einschränkungen nötig sind, um unkontrollierten Zugriff zu verhindern, aber eine Freigabe über bestimmte Dateiendungen oder explizit angegebene Verzeichnisse wäre hilfreich
    Jedes Mal einen Webserver hochzufahren ist zu umständlich und wirkt übertrieben — ideal wäre es, einfach die URL einzugeben und die App startet sofort
    • Eine große Einschränkung bei Generator-Web-Apps ist, dass nur per HTTPS geladene Seiten die Clipboard API nutzen dürfen, daher funktioniert Kopieren unter file:/// nicht
      Selbst bei vollständig offlinefähigen Apps ohne Build-Schritt und Abhängigkeiten muss man wegen dieser Grenze statt eines Buttons ein Textfeld verwenden, was lästig ist
      Für lokale Server kann man VS Code devcontainer nutzen, dann startet der Server automatisch, und mit einem zusätzlichen Befehl ist lokal auch HTTPS möglich
    • Früher gab es unter Windows HTA: HTML-Dateien mit anderer Endung, ohne Browser-Menüs und mit Zugriff auf das Dateisystem
      Sicherheitstechnisch war das schwach, aber eine moderne Variante auf Electron-Basis mit Zugriff auf Ordner oder eine sqlite-DB wäre heute durchaus brauchbar
      Eine Alternative sind auch wasm-App-Builder wie Orca, die ohne Browser/DOM nur Canvas bereitstellen
    • Ich verstehe die Risiken lokaler HTML-Dateien, aber es wäre schön, wenn Browser einen „nur offline“-Modus hätten, der lokales Dateisystem und externe Seiten voneinander trennt
      Das wäre keine perfekte Lösung, aber als einfacher und intuitiver Weg, den Browser als eingeschränkten lokalen Server zu nutzen, wäre es schon sehr nützlich
    • Es hat mich immer etwas gestört, dass HTML als lokale Plattform eingeschränkt wurde
      Andererseits funktionieren Audio, JavaScript usw. zumindest teilweise noch, und einen Webserver zu starten geht mit python/node direkt, also ist es nicht extrem schwer
      Ein webserver_here-Befehl im Terminal oder ein dauerhaft laufender Server löst das Problem
      Eher lässt mich die Gefahr lokaler HTML-Dateien inzwischen noch strengere Grenzen wollen
    • Kürzlich hatte ich hier und hier ähnliche Überlegungen
      Im Moment sind localStorage und manuelles Exportieren/Importieren die einzigen Alternativen
      Hyperclay hat mich auf die Idee gebracht, und ich interessiere mich für eine Electron-App, die man einmal installiert und dann viele Mini-Apps lädt — ähnlich wie Electron Fiddle
  • Ich war neugierig, wie Hyperclay technisch implementiert ist
    Es war unklar, ob es einfach um localStorage geht oder ob Dateien direkt per FileSystemAPI überschrieben werden; zur genauen Funktionsweise fehlten Details
    Ich fragte mich auch, ob beim Speichern ohne „Speichern unter“-Dialog automatisch übernommen wird
    • Hyperclay hat zwei Modi
      1. Hosting: Mehrere HTML-Apps rufen ihren eigenen /save-Endpunkt auf, um HTML zu speichern und zu überschreiben (mit Backups und Versionsverwaltung)
      2. Lokal: Man lädt das Open-Source-Projekt Hyperclay Local(Link) herunter und betreibt es selbst; auch hier wird über einen /save-Endpunkt gespeichert, Backups sind möglich, und man kann es auf dem eigenen Server hosten, wenn man nur Auth implementiert
    • Wenn man noch einen Schritt weitergeht: Ist das dann im Kern nicht sehr ähnlich zu PHP oder WordPress mit zusätzlich eingebauter Server-Syntax?
      Systeme vervielfachen sich und werden immer komplexer, sodass am Ende eher die Last steigt als eine echte Verbesserung entsteht
    • Die Inszenierung mit der Botschaft „den Lärm moderner Webentwicklung ignorieren und die Erfahrung bauen, die ich will“ zwischen kurzen Texten und Meme-Bildern wirkte auf mich etwas seltsam
      Ich hätte lieber eine klare Kernerklärung, einen nachvollziehbaren Hintergrund und Diagramme nur dort, wo sie wirklich nötig sind
    • Es gibt eine DB auf dem Server, und darin wird HTML gespeichert
      Also nicht JSON-basiert mit nur den Änderungen, sondern eher vollständige HTML-Snapshots pro Zeitpunkt
    • So wie ich es verstehe, wird die HTML-Datei selbst aktualisiert
      Änderungen an Formularen, Attributen, Tags usw. werden direkt in den HTML-Quelltext geschrieben
  • Es fühlt sich an, als würde man der ursprünglichen Vision des WWW wieder näher kommen
    Die ersten Webbrowser (die Tim-Berners-Lee-App für NeXT) enthielten ja auch Editor-Funktionen
    Dass frühe HTML-Bearbeitung aus dem Web verschwand, lag daran, dass
    1. es die HTTP-Methode PUT nicht gab, sodass geändertes HTML nicht ins Web, sondern nur lokal gespeichert werden konnte
    2. Browser wie Mosaic aus Gründen der Komplexität usw. ohne Editor-Funktion ausgeliefert wurden und die Verbreitung so eine andere Richtung nahm
    • Ein Web, in dem man lesen, kommentieren und schreiben kann, ist schon lange das Web, das ich mir wünsche
      Es ist cool, wenn wie bei Hyperclay jede Seite ihr eigenes Toolkit baut, aber eigentlich wäre es wünschenswerter, wenn Browser bzw. User Agents standardisierte Werkzeuge auf dieser Ebene überall bereitstellen würden
    • Das W3C hat mit Amaya über mehr als zehn Jahre einen Web-Editor gepflegt
      Ich fand das eine gute Idee, und als Testbed hat es seine Rolle ebenfalls gut erfüllt
      Schade, dass es verschwunden ist, denn es entsprach der ursprünglichen Vision sehr klar
    • Im frühen Kontext von TBL (Tim Berners-Lee) war lokales Speichern gleichbedeutend mit Web-Speichern
      Auf Uni-Workstations wurden Netzfreigaben wie NFS genutzt, sodass Dateien praktisch öffentlich gespeichert und unter derselben Maschinenadresse erreichbar waren
      Auf SGI-Workstations funktionierte das nach der Netzwerkkonfiguration sofort perfekt
      Der Fokus des Webs lag außerdem darauf, Informationen zu strukturieren, und nicht so sehr auf dem äußeren Erscheinungsbild
      Mit der Zeit verlagerte sich der Fokus durch WYSIWYG-Modelle und den Missbrauch von Tabellen/Divs auf die Optik, wodurch der ursprüngliche Geist verwässert wurde
      Ein einfaches Design zu schaffen, das jeder verstehen kann, ist wirklich schwer; heute ist daraus eine ziemlich komplexe Struktur geworden, die nur noch eine kleine Expertengruppe vollständig versteht
      Es ist bedauerlich, dass HTML zwar weiterhin leicht zu schreiben ist, in moderner Entwicklung aber zu einer komplexen Spezialtechnik geworden ist
      Es scheint, als hätten nur noch wenige das ursprüngliche TBL-Verständnis wirklich im Blick
    • Zum Punkt „Der Webbrowser ist auch ein Editor“
      Heutige Browser erlauben ja alle über Developer Tools Live-Änderungen an HTML/JS/CSS, sodass man sich fragen kann, ob nicht ohnehin jeder Browser ein Editor ist
      Ich frage mich, ob die Leute einfach keine Devtools benutzen oder nur mit React bzw. TS statt mit Vanilla JS/HTML arbeiten
      Chrome-, Firefox- und Safari-basierte Browser bieten inzwischen Funktionen auf dem Niveau einer eingebauten IDE, sodass man auch direkt darin coden kann
  • Nachdem ich mir Hyperclay angesehen habe, scheint es auf DOM (virtuellem DOM) zu basieren
    Ein paar Shopify-artige Richtlinien und rechtliche Hinweise wären ebenfalls hilfreich
    In meinem HN-Profil sieht man, warum ich das cool finde und zugleich das Gefühl habe, dass der rechtliche Teil wichtig ist
  • Ich habe schon einmal etwas Ähnliches für Spielstand-Dateien ausprobiert
    Die erste Zeile sah aus wie <!DOCTYPE html><html><head><script>const rawData =, die zweite Zeile enthielt den gesamten Zustand
    Beim Klick auf den Speichern-Button habe ich document.documentElement.outerHTML genommen, die zweite Zeile mit dem aktuellen Zustand ersetzt und das Ganze heruntergeladen
    Das funktionierte ohne Server
    Zugehöriger Code
    • In Chrome kann man das folgende data:-URL-Lesezeichen anlegen, um in einem Tab einen Notepad-artigen Editor offen zu haben; solange man den Tab nicht schließt, bleibt der Zustand erhalten 
      data:text/html,<html><head><title>Notepad</title><style>html,body{margin:0;padding:0;}textarea{padding:10px;font-family:Courier;font-size:16px;height:100%;width:100%;border:none;outline:none;}</style></head><body><textarea style="height:100%;width:100%;font-size:16px;padding:10px;"></textarea><script>document.getElementsByTagName('textarea')[0].focus()</script></body></html>
    • Ich habe ebenfalls ein Spiel gebaut, das als einzelne HTML-Datei läuft
      Nach dem Bearbeiten des Texts kann man es als neue lokale Version speichern
      Unter Android + Brave funktioniert das gut, unter iOS + Safari wird es nicht unterstützt
  • TiddlyWiki ist in diesem Bereich ebenfalls ein Tool mit über 20 Jahren Geschichte
    Hyperclay scheint den Schwerpunkt stärker auf Mehrbenutzerfähigkeit/Multi-Tenancy und DB-basierte Persistenz zu legen
    Auch TiddlyWiki ist einen Blick wert
  • Das wirkt wie ein Projekt von jemandem, der ein Windows-98-HTA-Archiv wiederentdeckt hat
    HTA-Wiki
    • HTA war so etwas wie das ursprüngliche Electron
      Nur war Debugging in der alten IE-Umgebung die Hölle
    • HTA war eine ihrer Zeit voraus gute (und zugleich furchtbare) Technologie
      Es sah einfach wie eine Webseite aus, war aber IE-spezifisch und hatte sogar Rechte zum Starten lokaler Prozesse
      Die Persistenzverwaltung war das Problem, und die Ähnlichkeit ist nur sehr begrenzt
    • Davor hatte Outlook Web Access wohl eine ähnliche Rolle
      Outlook on the web
    • Genau das Gleiche dachte ich auch und wollte es gerade kommentieren
  • Ich finde die Idee einzigartig und möchte sie irgendwann unbedingt ausprobieren
    Als ich mir die Website angesehen habe, gefiel sie mir insgesamt, aber ich frage mich realistisch, wo ihre Grenzen sichtbar werden
    Sicherheit: Wenn ich eine Seite ändern kann, können es dann auch andere? Wie werden Berechtigungen verwaltet?
    Wann wird die Verwaltung schwierig, wenn Codeumfang und Logik wachsen? Was passiert bei mehr Daten?
    Wenn ich zum Beispiel eine Bierverwaltungs-App baue: Können andere einfach nur die App ohne meine Daten kopieren und separat nutzen?
    • Sicherheit: Das Vertrauensmodell ist praktisch dasselbe wie bei SquareSpace und fast allen anderen Website-Buildern
      Nutzer können ihre eigene Website frei verändern
      Wenn ein Nutzer dieses Vertrauen missbraucht, verliert er den Zugriff auf sein bezahltes Konto und haftet, falls anderen Schaden entsteht
    • Bearbeitungsrechte: Jeder, der eine App erstellt hat, kann sie ändern
      Wenn man die Funktion „signups“ aktiviert, können andere Nutzer die App leicht forken, und die Herkunft zum Original bleibt nachvollziehbar
      An einer Funktion zum Pushen von Updates in geforkte Apps wird gearbeitet
    • Wartungsaufwand: Pieter Levels von NomadList betreibt auch eine App mit monatlich 60.000 Dollar Umsatz aus nur einer einzigen index.php; letztlich hängt es also davon ab, wie man seinen Code organisiert und wie viel Unschönheit man toleriert
    • Andere können die App forken und so betreiben, dass nur ihre eigenen Daten gespeichert werden
      Künftig sind auch Kollaborationsfunktionen geplant, aber im Moment passt es am besten für Einzelpersonen
  • Die Idee wirkt originell
    Das Projekt Webstrates experimentiert mit etwas Ähnlichem
    Dort wird das DOM als Persistenzschicht genutzt, um Kollaborationssoftware für kleine Gruppen zu bauen; der Unterschied ist, dass Hyperclay diesen Mechanismus direkt auf klassische Webseiten anwendet
    In letzter Zeit wird mit MyWebstrates auch ein Local-First-Ansatz ausprobiert
    Ich frage mich, ob Hyperclay mit Webworker-Unterstützung ebenfalls Offline-Bearbeitung ermöglichen könnte
    • Clemens hier, ich bin jemand, der von Webstrates tief beeindruckt war
      Als ich letztes Jahr über Hyperclay nachdachte, bin ich zum ersten Mal darauf gestoßen
      Ich würde wirklich gern eine Local-First-Version von Hyperclay bauen, und ich halte Offline-Bearbeitung für einen Grundpfeiler persönlicher Software
      Hättest du vielleicht Lust, dich per Videocall dazu auszutauschen?