Das Dokument ist die Anwendung: HTML als Ersatz für das Office-Paket

Der vorige Beitrag hat argumentiert, dass eine einzelne HTML-Datei eine Anwendung sein kann, die sich selbst verändert: Die Datei ist die Deployment-Einheit, der Agenten-Loop die Schnittstelle für Änderungen und der Browser-Tab der Lebensraum. Das war ein Argument über Software. Hier kommt dasselbe Argument, eine Ebene höher. Es geht um Dokumente.

Das Office-Paket (Word, Excel, PowerPoint und die PDFs, die wir daraus erzeugen) gehört längst ersetzt, und als Ersatz kam immer nur HTML infrage. Wasserdicht wird das Argument erst durch das, was reWritable gezeigt hat: Die Datei kann sich selbst bearbeiten, und die Benutzeroberfläche ist ein Satz.

Das Office-Paket ist ein Koordinationsprotokoll

Das Office-Paket ist im Kern eine Vereinbarung. Wir verwenden docx, xlsx, pptx und pdf, weil alle anderen es auch tun. Die Übergabe ist das Artefakt: Jemand erstellt eine Datei, hängt sie an ein E-Mail, und der Empfänger öffnet sie in einer kompatiblen Anwendung. Das funktioniert, weil drei Dinge zusammenhalten. Das Format wird breit unterstützt. Der Editor ist fast überall installiert. Der Viewer ist fast überall installiert. Fällt eines davon weg, bricht das Protokoll zusammen: Der Empfänger bekommt eine Datei, die er nicht öffnen kann, oder die er öffnen, aber nicht bearbeiten kann, oder die er bearbeiten kann, während die Formatierung verrutscht. Seit dreißig Jahren ist das Office-Paket der einzige Koordinationspunkt, der alle drei Bedingungen erfüllt.

Technisch sprach immer schon alles für HTML

HTML war spätestens seit 1997 der naheliegende Kandidat, um diesen Stack abzulösen. Universell. Textbasiert. Darstellbar auf jedem Gerät des letzten Vierteljahrhunderts. Gestalten mit CSS, rechnen mit JavaScript, präsentieren im Vollbild, drucken mit @media print. Es gab nichts, was die Office-Formate konnten und HTML nicht. HTML verlor in genau einem Punkt: Eine HTML-Datei ließ sich nicht so bearbeiten wie ein Word-Dokument. Wenn Sie report.html im Browser öffneten, sahen Sie das gerenderte Ergebnis. Zum Bearbeiten brauchten Sie ein separates Werkzeug, also einen Texteditor, eine IDE oder einen externen WYSIWYG-Editor. Die Bearbeitungsoberfläche der Datei war nicht die Datei selbst.

Dieser Lücke verdankte das Office-Paket seinen Platz. Nur Word öffnete ein Word-Dokument in bearbeitbarer Form. Das Format war der Burggraben.

Die Lücke hat sich gerade geschlossen

Was reWritable beiträgt, ist klein und vollständig. Eine HTML-Datei mit eingebetteter LLM-API ist ihr eigener Editor. Sie öffnen sie nicht im Browser zum Lesen und wechseln dann per Alt-Tab in ein anderes Programm, um sie zu ändern. Sie öffnen sie im Browser, und der Browser ist der Editor. ⌘K ist die Schreibfläche. Die Anweisung ist die Bearbeitung. Genau das hat das Office-Paket dreißig Jahre lang für sich behalten: ein Format, das sich im selben Artefakt öffnen, darstellen und ändern lässt. Microsoft hat das als Produkt verkauft. Es war nie ein Produkt. Es war eine Integration.

Diese Integration gibt es jetzt in zwanzig Zeilen Seed-HTML und einem OpenRouter-Key.

Der Chat ist kein Anhängsel

Das Interessante daran, das, was über „HTML holt Word ein“ hinausgeht, ist das, was ein LLM im Dokument kann und eine Word-Installation nie konnte.

Das PDF eines Vertrags ist undurchsichtig. Sie lesen es. Wenn etwas unklar ist, fragen Sie einen Anwalt. Ein Finanzmodell als Word-Dokument ist auf dieselbe Weise undurchsichtig: Sie können Zahlen ändern, aber die Logik des Modells hat jemand anderer gebaut, und wer sie ändern will, muss sie verstehen. Das Artefakt erklärt sich nicht selbst. Ein HTML-Dokument mit einem LLM darin kann das. Der gesamte Quelltext liegt im Kontextfenster des Agenten: Prosa, Styles, Daten, Formeln, Struktur. Der Benutzer kann fragen: Was verlangt Klausel 7 eigentlich? Was würde sich ändern, wenn ich diesen Absatz streiche? Fasse die Annahmen in diesem Modell zusammen. Rechne die Prognosen mit 15 % weniger Umsatz neu.

Das Dokument ist nicht mehr bloß etwas, das Sie lesen. Es ist etwas, das Sie befragen können. Und weil derselbe Agent, der die Fragen beantwortet, auch die Datei neu schreiben kann, kann aus jeder Befragung eine Bearbeitung werden. Diese Funktion können PDF, Word und Excel strukturell nicht haben. Ihre Formate sind nicht der Kontext des Agenten. Die Anwendung liest das Format, der Agent hat keine Beziehung dazu. Sie können Copilot oder ChatGPT-in-Word dranschrauben, aber das sind externe Dienste, die externe Momentaufnahmen lesen. Dokument und Assistent sind zwei Dinge, die zur Laufzeit zusammengeflickt werden. In einer HTML-Datei mit eingebettetem LLM sind sie eines. Das Dokument ist der Kontext. Der Kontext ist das Dokument.

Was ersetzt was

Das Office-Paket ist ein Bündel, und dieses Bündel zerfällt je nach Format anders.

Office-Format	Ersatz	Was schwieriger ist
Word (.docx)	HTML mit Prosa-Styling und der Runtime	Nichts Wesentliches
Excel (.xlsx)	HTML mit einem JS-Grid und IndexedDB für die Daten	Dreißig Jahre Muskelgedächtnis und eine installierte Basis an Makros
PowerPoint (.pptx)	HTML mit Vollbild-Folien	Nichts Wesentliches: revealjs hat längst bewiesen, dass das Format funktioniert
PDF	HTML, ohne Runtime, schreibgeschützt	PDF behält eine echte Nische für „dieses Artefakt darf sich nicht ändern“: Eingaben bei Gericht und Behörden, unterzeichnete Verträge, Archivdokumente

Bei Prosadokumenten und Präsentationen ist die Ablösung sauber. Bei Tabellenkalkulationen ist sie langsam, aber unausweichlich: Das neue Artefakt ist dem alten in jeder Hinsicht überlegen, die bei nicht trivialen Modellen zählt, und Excels Lock-in ist ein Koordinationsproblem, kein Fähigkeitsproblem. Bei PDFs ist die Ablösung partiell: HTML übernimmt die Weitergabe aus Bequemlichkeit (das sind in der Praxis die meisten PDFs), und PDF behält das, wofür es entworfen wurde: das Einfrieren des Artefakts.

Die Datei ist die Version

Wenn ich das Dokument bearbeite und die Änderungen in meinem Browser liegen, was passiert dann, wenn ich die Datei an ein E-Mail hänge? Bekommt der Empfänger meine Änderungen oder das Original? Hängen Sie die Seed-Datei an, bekommt der Empfänger gar nichts. Der Seed ist der Bootstrap: bewusst zustandslos, beim ersten Öffnen baut er alles von Grund auf. Ihre Änderungen liegen in Ihrem Browser, nicht in der Datei, die Sie heruntergeladen haben.

⌘S ist genau dafür da. Speichern ist in diesem Modell Exportieren. Beim Speichern wird document.documentElement.outerHTML serialisiert, also die gesamte laufende App samt Runtime, und als neue .html-Datei heruntergeladen. Die Runtime schreibt außerdem alle IndexedDB-Daten in einen <script type="application/json" id="app-seed-data">-Tag in dieser Datei. Öffnet der Empfänger sie, erkennt die Runtime den Tag, befüllt IndexedDB daraus, entfernt den Tag, und die Datei macht genau dort weiter, wo der Absender aufgehört hat.

Diese Datei hängen Sie an. Nicht den Seed.

In Word überschreibt Speichern die Datei, die Sie geöffnet haben. In reWritable erzeugt Speichern eine neue Datei: Jeder Speichervorgang ist eine portable Momentaufnahme. Es gibt keine Unklarheit darüber, welche Version Sie geschickt haben: Die Datei ist die Version. Git-Diffs funktionieren, weil es Text ist. Die Datei, die Sie gestern heruntergeladen haben, ist nicht die mit Ihren Änderungen. Die Datei mit Ihren Änderungen ist die, die Sie gerade exportiert haben. Die Runtime hilft dabei (nach fünf Neuschreibungen ohne Export blendet sie einen nicht modalen Hinweis ein), aber die Regel für den Benutzer passt in eine Zeile. Speichern heißt eine neue Datei erzeugen. Schicken Sie diese.

Das ist das E-Mail-Modell, nicht das Google-Docs-Modell. Paralleles Bearbeiten durch zwei Personen ist kein Problem, das das Format löst. Dieses Problem wird an git weitergeschoben, an einen gemeinsamen Null-Origin-Ordner oder an die Sync-Schicht, die der Benutzer wählt. Das ist der Preis dafür, ohne Server auszukommen. Denselben Kompromiss hatten PDFs und Word-Dokumente immer schon, nur dass hier die Annahme des eingefrorenen Artefakts wegfällt.

Die Einwände

Formatierung. Modernes CSS kann alles, was die Druck-Engines der 1990er konnten. Paged Media, Seitenumbrüche, laufende Kopfzeilen, Schriftkontrolle, Spalten. Der Browser gehört zu den leistungsfähigsten Layout-Engines, die je ausgeliefert wurden, und ist die einzige, die auf jedem Gerät installiert ist. Das Argument „aber das Layout geht kaputt“ stimmte vor zwanzig Jahren. Heute stimmt es nicht mehr.

Offline. Dateien funktionieren offline. Die Runtime funktioniert offline. Der Aufruf des Agenten braucht ein Netzwerk, und mit derselben Einschränkung leben Microsoft 365, Google Docs, Notion und jedes Cloud-Office-Produkt. Die Local-First-Variante ist eindeutig besser: Die Datei funktioniert offline, nur Änderungen brauchen Netz.

Dateigröße. Eine docx ist ein ZIP aus XML. Eine pptx ist ein ZIP aus XML und Bildern. Ein HTML-Dokument mit eingebetteten Assets ist vergleichbar groß, oft kleiner, weil der XML-Overhead wegfällt.

Archivierung. HTML ist das stabilste Format, das je ausgeliefert wurde. Die ursprünglichen Seiten vom CERN aus den frühen 1990ern werden immer noch dargestellt. PDF ist ähnlich stabil. Word ist es bekanntlich nicht. Wenn Sie sich fragen, „lässt sich das 2050 noch öffnen“, ist HTML Ihre sicherste Wahl.

Vertrauen. „Aber da ist ausführbarer Code drin.“ Ja. Den hat auch jede Excel-Datei mit Makro, jedes PDF mit eingebettetem JavaScript, jedes E-Mail mit Anhang. Die Runtime ist klein und einsehbar, und die Seed-Datei ist Text, den Sie in fünf Minuten von Anfang bis Ende lesen können. Das ist transparenter als jedes Binärformat, das das Office-Paket mitbringt.

Was das Office-Paket wirklich verkauft hat

Das Office-Paket hat drei Dinge verkauft, und nur eines davon war das Dateiformat. Das erste war ein Standard-Editor. Den hat HTML jetzt auch: jeder Browser, dazu das LLM als Schreibassistent. Das zweite waren Netzwerkeffekte. Alle verwenden docx, also muss ich docx verwenden. Das ist der stärkste Lock-in. Er bricht nicht innerhalb eines einzigen Nachrichtenzyklus. Er bricht so, wie das Papier dem PDF wich: langsam, dann auf einmal, an jenen Stellen, an denen das neue Artefakt gut genug ist, um die Koordinationskosten zu überwinden. Das dritte war die Illusion eines stabilen Artefakts. Die Datei, die Sie verschickten, und die Datei, die der Empfänger öffnete, sollten dasselbe sein. Wer schon einmal eine docx über zwei Word-Versionen hinweg gemailt hat, weiß, dass das zum Teil Fiktion ist. HTML ist das Format, bei dem das Artefakt über alle Viewer hinweg wirklich stabil ist: Es gibt genau ein Rendering-Ziel, und jeder Browser implementiert es.

Rechnet man zusammen, was das Office-Paket tatsächlich leistet (einen Editor, ein Netzwerk und eine Stabilitätsgarantie), dann kann HTML jetzt alle drei. Dazu kommt ein Unterscheidungsmerkmal, mit dem das Bündel strukturell nicht mithalten kann: Das Dokument kann Fragen über sich selbst beantworten.

Was als Nächstes kommt

Das schwierigere Problem ist nicht technisch. Das Office-Paket ist ein Workflow, nicht nur ein Format. Die Leute erwarten, dass Anhänge auf .docx enden. Compliance-Teams haben Microsoft-365-Deployments freigegeben. Prüfer suchen nach .xlsx-Artefakten. Das Format ist das Protokoll, und das Protokoll zu ändern ist die eigentliche Arbeit.

Zwei Dinge lassen mich glauben, dass das schneller geht als der Übergang von docx in die Cloud. Erstens muss bei HTML niemand migriert werden: Es läuft in dem Werkzeug, das alle schon haben. Zweitens ist die entscheidende Fähigkeit asymmetrisch. Sobald ein Team in einer Organisation entdeckt, dass seine RFP-Antworten, Verträge oder Finanzmodelle als selbsterklärende HTML-Datei ungleich nützlicher sind, ordnen sich die Werkzeuge rundherum neu um dieses Team an.

Das Office-Paket war ein Koordinationsprotokoll, das ein bestimmtes Problem gelöst hat: Wie arbeiten viele Menschen an derselben Art von Datei? Gelöst hat es das, indem es auf ein Bündel inkompatibler Formate und den Editor eines einzigen Herstellers standardisiert hat. Das Problem ist weiterhin real. Die Lösung gehört längst ersetzt.

So sieht der Ersatz aus: ein Ordner voller HTML-Dateien mit eingebetteten Agenten. Das Format ist das native Format des Browsers. Der Editor ist die Datei selbst. Die Kollaborationsschicht ist dieselbe wie seit vierzig Jahren: Dateien verschicken. Der neue Baustein, der das Ganze endlich zusammenhält, ist, dass das Dokument an seiner eigenen Nutzung teilnimmt. Sie öffnen es nicht nur. Sie fragen es.

Das Web sollte ein Read/Write-Web sein. Das Office-Paket war der Workaround für den Teil des Read/Write-Webs, der nie ausgeliefert wurde.

Jetzt ist er ausgeliefert.

Quellcode und Spezifikation: github.com/ikangai/rewritable
Der vorige Beitrag: reWritable: Software that knows how to change itself
Der direkte Vorfahre: github.com/ikangai/clive

Aus dem Englischen übersetzt: zum Originalbeitrag