Was ist eigentlich Satz?
Satz? Wie der Satz?
Ja, richtig. satz ist mein neues Tooling, das unter anderem diesen Blog antreibt, mir das Schreiben von Posts ermöglicht und auch das gesamte Backend im Hintergrund stellt. Das Ganze folgt meinen Konventionen, die ich seit ein paar Wochen immer wieder aktualisiere, verfeinere und umbaue und die sich nach und nach immer mehr herauskristallisieren.
Der Name passt übrigens ganz gut: Im Buchdruck ist der Satz das Setzen von Text zu fertigen Seiten, und genau das passiert hier mit meinen Posts.

Konventionen?
Ja! Wenn ich ein neues Tool baue, verwende ich jetzt folgenden Ansatz:
| Name | Was ist es? |
|---|---|
satz |
Das CLI-Tool, das ich auf der Kommandozeile verwende |
satzd |
Der Server im Hintergrund, der alle API-Anfragen beantwortet, optional mit einer MCP-Komponente, damit KI-Modelle auch mit ihm sprechen können |
satz-gui |
Eine GUI, also eine grafische Anwendung, die auf dem Desktop läuft |
satz-core |
Die Hauptlogik, die sogenannte Domain-Logik, also alles, was die CLI, der Server und eine GUI gleichermaßen brauchen |
satz-web |
Die Website, die sich ihre Daten vom Server holt (und auf der du gerade diesen Post liest) |
Kleine Anmerkung:
satz-guigibt es nicht. Aber meine Konvention reserviert die Namen direkt, falls ich ein Projekt um eine GUI erweitere.
Der Vorteil: Egal welches Projekt ich aufmache, ich weiß sofort, welcher Teil was macht und wie er heißt. Und die CLI redet immer nur über die API mit dem Server, nie direkt mit den Dateien dahinter.
Warum?
Weil ich es kann? Spaß beiseite: Die alten Projekte hatten ein paar Probleme, die sich nicht mehr schön reparieren ließen.
The old and bold
Pyblog, Sveblog und blogli, die alten Projekte, mit denen ich den Blog verwaltet habe, waren an sich okay, aber schrecklich zu warten. Außerdem entsprachen sie nicht mehr dem Stack, mit dem ich arbeite, zumindest Pyblog und blogli (beide in Python) nicht mehr. Die drei lagen in getrennten Repos, und die Fehler steckten meistens genau zwischen ihnen: blogli hat zum Beispiel beim Veröffentlichen die Sprache eines Posts verschluckt, und Pyblog hat daraufhin die falsche Datei überschrieben. Sveblog habe ich als Vorlage für dieses Redesign genommen, und da der Stack der gleiche ist (Svelte/SvelteKit/Vite), war das auch gar kein so großer Umstand; einige Sachen konnten recycelt werden.
New and shiny
satz und die anderen Komponenten sind in Rustrust-lang.org geschrieben. Der Vorteil, der sich daraus ergibt: Jedes Werkzeug ist eine einzelne Binary, die ich überall installieren kann. Ja, es muss vorher kompiliert werden, dafür ist es aber wesentlich einfacher, daraus ein fertiges Image zu bauen, das immer gleich ist.
Außerdem wollte ich sowieso mal wieder (oder endlich richtig) in die Welt der kompilierten Sprachen eintauchen, also habe ich direkt eine moderne, aktiv entwickelte Sprache mit großer Community genommen.
Dazu kommt: Alle Teile liegen jetzt zusammen in einem Repo. Ändert sich etwas zwischen ihnen, merkt das der Compiler und nicht erst ich beim Schreiben.
...außerdem ist das Maskottchen von Rust eine Krabbe 🦀...

Was kann es denn nun?
Abgesehen von dem, was du auf der Website sehen kannst, ist die Seite an sich jetzt schneller, weil die Textverarbeitung vorab passiert: satzd macht aus dem Markdown direkt HTML, samt Inhaltsverzeichnis, Lesezeit und Syntax-Highlighting.
Das bedeutet so viel wie: Die Links, die in einem Post als Chips (die runden Dinger) sichtbar sind, baut der Builder, eine Komponente von satz-web, schon beim Erstellen der Seite ein und nicht mehr erst in deinem Browser.
Bilder liegen direkt neben der fertigen Seite, statt dass sie erst über die API geladen werden müssen.
Und weil jede Seite fertig gebaut ausgeliefert wird, stehen Titel und Beschreibung direkt im HTML, sodass auch Signal, Mastodon und Co. beim Teilen eines Links eine ordentliche Vorschau zeigen.
satz selbst ist einfacher zu verwenden, und das Verhalten ist jetzt einheitlich. Das ist für dich als Leser weniger relevant, aber für mich als Schreiber macht das einen Riesenunterschied.
# Damit habe ich diesen Post hier angelegt!
# Das Bild von der Krabbe hochladen; was mit ! herauskommt, kopiere ich in diesen Post.
# Schnell noch was bearbeiten...
# Den deutschen Post als Vorlage für den englischen kopieren
# Den deutschen Post veröffentlichen
# Ach ja, den englischen auch
Das sieht jetzt erst mal nach Mumbo-Jumbo aus, ist aber tatsächlich sehr eingängig, wenn man Terminalarbeit gewohnt ist!
Jeder Befehl folgt dem gleichen Muster: erst das Ding (post, asset), dann was damit passieren soll (add, edit, publish).
Und jetzt?
Wie, und jetzt? Happy fun beim Lesen! Und ich habe happy fun beim Schreiben!
Als Nächstes steht bei satzd noch die MCP-Komponente auf der Liste, dann kann ich auch mit KI-Modellen an meinen Posts arbeiten.