TL;DR. Analyse eines Rust-Static-Site-Generators: Sicherheit zur Compile-Zeit, WCAG-Gates, lokale KI, die Lücken in v0.0.41 und eine Enterprise-Roadmap zur 1.0.

Wichtige Erkenntnisse

Aktuelle Stärken. Die Codebasis von static-site-generator weist mehrere charakteristische Engineering-Entscheidungen auf, die sie von etablierten JavaScript- und Go-Engines abheben:.
Lücken und Realitäten der Praxis. Trotz dieser außergewöhnlichen Stärken deckt eine rigorose Code-Inspektion von v0.0.41 mehrere Lücken in Architektur, Funktionalität und Entwicklererfahrung zwischen den Dokumentationsaussagen und dem tatsächlichen…
Architektonische Lücken, die uns fehlen (neue Erkenntnisse). Über die Lücken in v0.0.41 hinaus fördert eine Bewertung des Projekts anhand eines Risikoprofils auf Finanzniveau mehrere Funktionen zutage, die es noch nicht bietet, ein Enterprise-Käufer aber verlangen würde:.
Die strategische 1.0-Roadmap. Die folgende Roadmap integriert sowohl die behobenen Lücken als auch die neu entdeckten Enterprise-Funktionen in ein strukturiertes, chronologisches Release-Framework.

Static Site Generator (SSG): Strategische Tiefenanalyse und Architektur-Roadmap für Unternehmen

Recherchedatum: 2026-06-22. Basierend auf einer Code-Inspektion von static-site-generator in v0.0.41 und Web-Recherche zur SSG-Landschaft 2026.

Für einen regulierten Publisher ist ein Static-Site-Generator kein Design-Werkzeug mehr, sondern Teil des operativen Risikoperimeters. Der quelloffene Rust-static-site-generator baut auf dieser Prämisse auf und verlagert Sicherheit, Barrierefreiheit, Internationalisierung und KI-Content-Pipelines in die Compile-Zeit, sodass eine fehlgeschlagene Prüfung den Build stoppt, statt in die Produktion zu gelangen. Diese Analyse trennt das, was Version 0.0.41 tatsächlich liefert, von dem, was die Dokumentation bislang nur verspricht, benennt fünf Enterprise-Funktionen, die noch fehlen, und schlägt einen stufenweisen Weg zu einem 1.0-Release vor, der an DORA (Digital Operational Resilience Act), den European Accessibility Act und moderne Lieferketten-Standards ausgerichtet ist.

Zusammenfassung für Entscheider

Publishing ist heute ein operativer Risikoperimeter. Unter DORA, dem European Accessibility Act und der DSGVO (Datenschutz-Grundverordnung) ist jedes öffentlich zugängliche Asset ein potenzieller Einstiegspunkt für Lieferketten-Kompromittierung, Defacement und regulatorische Exposition. Ein Compile-Zeit-Modell verengt diesen Perimeter, indem nicht konforme Ausgaben abgewiesen werden, bevor sie ausgeliefert werden.

Die Alleinstellungsmerkmale der Engine sind compilererzwungen, keine dokumentierten Absichten. Workspace-weites forbid(unsafe_code), echtes SHA-256/384-SRI, automatische CSP-Extraktion und ein WCAG-2.2-AA-Gate zur Compile-Zeit verwandeln Sicherheit und Barrierefreiheit von nachträglichen Audits in harte Build-Fehler.

Version 0.0.41 hat eine Lücke zwischen Dokumentation und Code. Native Minifizierung, inkrementelle Rebuilds über einen Abhängigkeitsgraphen und AVIF-Unterstützung sind beschrieben, aber nicht funktionsfähig; der Artikel benennt jede Lücke anhand der exakten Quellcode-Stelle.

Der Weg zur 1.0 ist eine Sequenz, keine Wunschliste. Zuerst Robustheit (0.0.42), dann inkrementelle Korrektheit (0.1.0) und dann die Enterprise-Funktionen, die ein regulierter Käufer verlangt: WASM-Sandboxing, lokale semantische Suche und verifizierbare SLSA-Provenienz (1.0.0).

Aktuelle Stärken

Die Codebasis von static-site-generator weist mehrere charakteristische Engineering-Entscheidungen auf, die sie von etablierten JavaScript- und Go-Engines abheben:

Sicherheitshaltung zur Compile-Zeit: Workspace-weites #![forbid(unsafe_code)] bietet Speichersicherheitsgarantien zur Compile-Zeit. Die Build-Pipeline erzeugt echte SHA-256/SHA-384-Subresource-Integrity-Hashes (SRI) (src/plugins/assets.rs) und führt eine automatische Content-Security-Policy-Extraktion (CSP) durch, die unsafe-inline-Skripte und -Styles entfernt. Releases sind signiert, tragen eine Sigstore-Attestierung und erzeugen bei jedem Build ein CycloneDX-1.5-SBOM.
Compilererzwungenes Barrierefreiheits-Gate: Die Prüfungen der Web Content Accessibility Guidelines (WCAG) 2.2 Level AA laufen innerhalb der Kompilierungs-Pipeline über einen axe-core-Parser zur Compile-Zeit, gesteuert von Playwright. Barrierefreiheit wird zu einem harten Build-Gate statt zu einem Audit nach der Veröffentlichung: Fällt eine Seite durch, hält die Kompilierung mit exakten Zeilennummer-Fehlern an.
Datensouveräne KI-Pipeline: Eine lokale LLM-Pipeline für Übersetzung und Metadaten-Extraktion (über lokale Ollama- oder llama.cpp-Endpunkte) erlaubt es einer Institution, Content-Zusammenfassung, JSON-LD-Schema-Generierung und mehrsprachige Übersetzung zu automatisieren, ohne Vor-Bilanz-Veröffentlichungen oder sensibles geistiges Eigentum an öffentliche Cloud-KI-APIs zu senden.
Parallelisierte Kompilierung: Rusts Speichersicherheitsgarantien untermauern eine parallelisierte, Rayon-gesteuerte HTML- und Asset-Pipeline (src/core/pipeline.rs). Die Plugin-Pipeline führt fusionierte Transformationen aus, wobei SearchPlugin, SeoPlugin, CanonicalPlugin und JsonLdPlugin über par_iter() operieren, sodass jede Seite genau einmal von der Festplatte gelesen und darauf geschrieben wird.
Lieferketten- und Abhängigkeitshygiene: Die Migration der Template-Engine von Tera zu MiniJinja (v0.0.37) reduzierte die Binärgröße, entfernte transitive Abhängigkeiten wie rand zur Compile-Zeit und erzeugte einen kompakten Abhängigkeits-Fußabdruck, der die Exposition gegenüber Software-Lieferketten senkt.

Lücken und Realitäten der Praxis

Trotz dieser außergewöhnlichen Stärken deckt eine rigorose Code-Inspektion von v0.0.41 mehrere Lücken in Architektur, Funktionalität und Entwicklererfahrung zwischen den Dokumentationsaussagen und dem tatsächlichen Rust-Code auf:

Architektonische Lücken

Whitespace-Kollabierung vs. native Minifizierung: Während die README „native JS/CSS-Minifizierung“ verspricht, agiert das MinifyPlugin (src/plugins/plugins.rs:96-116) lediglich als naiver Whitespace-Kollabierer. Es bricht bei <pre>-Elementen ab und kollabiert Whitespace-Folgen in HTML, führt aber keine syntaxbewusste native CSS- oder JS-Minifizierung durch. Zudem verarbeitet es nur Seiten der obersten Ebene und durchläuft Unterverzeichnisse (etwa /blog/ oder /tags/) nicht rekursiv, sodass tief liegende Seiten unminifiziert bleiben.
Tote Inkrementell-Infrastruktur: Der Abhängigkeitsverfolgungs-Graph (DepGraph in src/core/depgraph.rs) wird kompiliert und in PluginContext.dep_graph geladen, aber im Produktionscode nie tatsächlich befüllt. Die Methode add_dep() wird nur in Unit-Tests aufgerufen, was die Aussage der README zu „inkrementellen Rebuilds über Abhängigkeitsgraphen“ derzeit zu einer Absicht macht.
Batch-Kompilierung vs. Streaming-Kompilierung: Das Modul streaming::compile_batch (src/core/streaming.rs) streamt nicht wirklich. Stattdessen kompiliert es Seiten in Batches in ein temporäres Verzeichnis, führt staticdatagen::compile für jeden Batch von Grund auf aus und führt die Ausgaben zusammen. Das verursacht erheblichen Festplatten-E/A-Overhead und redundantes Parsing und weicht von einer echten Streaming-Architektur ab.
Verstöße gegen Plugin-Lebenszyklusphasen: Plugins, die während des Builds neue HTML-Seiten erzeugen, etwa TaxonomyPlugin, PaginationPlugin und I18nPlugin, schreiben in after_compile direkt auf die Festplatte, statt den transform_html-Lebenszyklus zu nutzen. Folglich umgehen die von diesen Plugins erzeugten Seiten kritische Nachbearbeitungs-Plugins (etwa CanonicalPlugin, JsonLdPlugin, RobotsPlugin und AccessibilityPlugin), sofern diese Plugins zuvor registriert wurden. Das lässt Tag-, Kategorie- und paginierte Seiten ohne korrekte Canonical-Links, JSON-LD-Schemata oder Barrierefreiheitsprüfungen.
Shell-Aufruf von curl im LlmPlugin: Die lokale LLM-Content-Pipeline (src/plugins/llm.rs) ruft direkt das curl-Binary des Hosts auf, um lokale Endpunkte abzufragen. Das führt zu schwerwiegenden plattformübergreifenden Fehlern (z. B. auf Windows-Hosts ohne curl im PATH), stellt ein Sicherheitsrisiko dar (Shell-Injection-Vektoren) und schlägt in abgeschotteten oder netzwerkisolierten CI-Umgebungen fehl.
Naive String-Manipulation beim HTML-Rewriting: Die Extraktoren image_plugin.rs und search.rs schreiben HTML-Strings über fragile str::find- und str::rfind-Operationen um. Dieser Ansatz ist höchst anfällig für defekte HTML-Tags, <img>-Tags innerhalb von Kommentaren, Zeichenentitäten im Alt-Text oder bereits vorhandene srcset-Attribute, was zu beschädigter Ausgabe führen kann.
Nicht implementierte AVIF-Unterstützung: Obwohl die AVIF-Bildkodierung ausführlich dokumentiert ist, ist die Implementierung in image_plugin.rs ein Stub, bei dem avif_variants schlicht Vec::new() zurückgibt, was die Funktion funktionslos lässt.
Polling-basierter Watcher: Der Watcher des lokalen Entwicklungsservers (src/server/watch.rs) nutzt Polling statt Dateisystem-Event-APIs, was zu übermäßiger Leerlauf-CPU-Auslastung und einer Änderungslatenz im Sub-Sekunden-Bereich führt.

Funktionale und DX-Lücken

Keine transitive Abhängigkeitsverfolgung: Der Abhängigkeitsgraph kann verschachtelte Abhängigkeiten nicht verfolgen (z. B. Änderungen an einem Sub-Template, das ein Layout und damit eine Seite beeinflusst), wie der Unit-Test transitive_not_tracked bestätigt.
Kein CLI-Flag für inkrementelle Kompilierung: Es gibt kein --incremental-CLI-Flag, das mit dem ausführenden Compiler verdrahtet ist, wodurch Entwickler keine gecachten Builds nutzen können.
HMR ist auf CSS beschränkt: Hot Module Replacement (HMR) unterstützt nur CSS; jede Änderung an HTML-, Layout- oder Markdown-Dateien löst ein vollständiges Neuladen der Seite aus, was die Entwicklergeschwindigkeit mindert.
Fehlende Unterbefehle: Entwickler müssen umständliche Flags manuell übergeben (ssg -s public -w), weil Standard-Unterbefehle wie ssg dev, ssg build, ssg check und ssg lint nicht existieren.

Architektonische Lücken, die uns fehlen (neue Erkenntnisse)

Über die Lücken in v0.0.41 hinaus fördert eine Bewertung des Projekts anhand eines Risikoprofils auf Finanzniveau mehrere Funktionen zutage, die es noch nicht bietet, ein Enterprise-Käufer aber verlangen würde:

1. WebAssembly-Plugin-Sandboxing (Zero-Trust-Erweiterung)

Zwar ist das Compiler-Binary selbst in sicherem Rust geschrieben, doch beliebige Drittanbieter-Plugins nativ auf Host-Systemen auszuführen, führt eine schwerwiegende Lieferketten-Schwachstelle ein. Ein kompromittiertes Drittanbieter-Plugin könnte mühelos auf das Dateisystem des Hosts zugreifen, proprietäre Markdown-Dateien lesen oder private Zugangsdaten exfiltrieren.

Fehlende Funktion: Eine gesandboxte Ausführungsumgebung. Für eine Zero-Trust-Kompilierung sollte der Compiler Drittanbieter-Plugins innerhalb einer eingebetteten WebAssembly-Laufzeit (etwa wasmtime) ausführen. Plugins sollten mit dem Host ausschließlich über ein eingeschränktes WebAssembly System Interface (WASI) interagieren, das ihren Zugriff strikt auf die gerade transformierte Seite begrenzt.

2. Zero-Copy-HTML-Parsing über Streaming-AST (`lol_html`)

Die HTML-Parsing-Schicht auf eine vollständige In-Memory-DOM-Bibliothek (wie Kuchiki oder html5ever) zu migrieren, führt bei Sites mit über 100.000 Seiten zu erheblichem Speicher-Overhead und Verarbeitungspausen.

Fehlende Funktion: Ein streamender Zero-Copy-HTML-Rewriter. Der Einsatz von Cloudflares lol_html (Low-Output-Latency-HTML-Rewriter) erlaubt es dem Compiler, HTML-Elemente in einem einzigen Streaming-Durchlauf mit nahezu null Speicherallokation zu parsen, zu inspizieren und zu modifizieren, passend zum Ziel des parallelen Streaming-Compilers von Builds im Sub-Sekunden-Bereich.

3. Lokale semantische Vektorsuche (lokales RAG)

Der aktuelle Suchindex (SearchPlugin) erzeugt einen schweren, flachen JSON-Index, der einfache clientseitige String-Vergleiche durchführt und keine Unterstützung für Fuzzy-Suche, Stemming oder semantische Abfragen bietet. Pagefind ist eine Verbesserung, setzt aber weiterhin auf das Herunterladen eines großen Index.

Fehlende Funktion: Eingebettete semantische Suche. Der Compiler sollte zur Build-Zeit ein lokales, leichtgewichtiges Rust-natives Vektor-Embedding-Modell nutzen (etwa ein MiniLM-L6-Modell, ausgeführt über candle oder ort / ONNX Runtime). Es sollte dichte Vektor-Embeddings für jeden Seitenabsatz erzeugen und einen kompakten Vektorindex ausgeben. Das clientseitige, zu WASM kompilierte Such-Widget kann dann eine echte semantische Offline-Suche direkt im Browser durchführen.

4. Deterministisches Übersetzungs- und Inferenz-Caching

Da lokale LLM-Inferenz (z. B. über Ollama oder Llama.cpp) sehr CPU-/GPU-intensiv ist, ist es rechnerisch nicht vertretbar, bei jedem Build Metadaten für Tausende von Seiten zu übersetzen oder zu erzeugen.

Fehlende Funktion: Content-Hash-basiertes Inferenz-Caching. Der Compiler muss einen deterministischen Cache aller LLM-Operationen führen. Stimmt der SHA-256-Hash des Inhalts einer Markdown-Datei und ihrer Übersetzungsparameter mit einem Cache-Eintrag überein, sollte der Compiler die gecachte Übersetzung und Metadaten wiederverwenden und redundante lokale Inferenz umgehen.

5. Asynchrone Datei-E/A für parallele Skalierung

Zwar ist die Plugin-Pipeline über Rayon parallelisiert, doch standardmäßige synchrone Festplattenschreibvorgänge blockieren die OS-Threads von Rayon und erzeugen beim Schreiben von Zehntausenden Seiten einen E/A-Engpass.

Fehlende Funktion: Asynchrone, nicht blockierende Festplatten-E/A. Der Compiler sollte CPU-intensive Aufgaben (Markdown-Parsing, Minifizierung) von festplattengebundenen Schreibvorgängen entkoppeln und asynchrone E/A-Thread-Pools oder Linux-io_uring-Bindings (über rio oder tokio) nutzen, um kompilierte Seiten parallel zu schreiben, ohne die parallelen CPU-Executor zu blockieren.

Die strategische 1.0-Roadmap

Die folgende Roadmap integriert sowohl die behobenen Lücken als auch die neu entdeckten Enterprise-Funktionen in ein strukturiertes, chronologisches Release-Framework.

Phase 1: 0.0.42 (Der Robustheits- und Korrektheits-Patch, 1 bis 2 Wochen)

MinifyPlugin neu aufbauen: Integration von minify-html, oxc_minifier und lightningcss für native, syntaxbewusste HTML-, JS- und CSS-Minifizierung. Sicherstellen, dass das Plugin alle verschachtelten Verzeichnisse unter site_dir rekursiv durchläuft.
Die KI-Pipeline absichern: LlmPlugin von nativen curl-Shell-Aufrufen auf ureq (einen leichtgewichtigen, synchronen, sicheren Rust-HTTP-Client) portieren, um plattformübergreifende Kompatibilität sicherzustellen und Shell-Injection-Schwachstellen zu beseitigen.
Die AVIF-Implementierung fertigstellen: ravif direkt in die Bild-Asset-Pipeline einbinden, um hochperformante AVIF-Kodierung neben WebP und PNG zu ermöglichen.
HrefLang- und Multi-Locale-Zuordnung automatisieren: Parallele übersetzte Seiten in mehrsprachigen Builds automatisch erkennen und standardkonforme, Google-taugliche <link rel="alternate" hreflang="..." />-Tags in den Head jeder kompilierten HTML-Datei einfügen.
JSON-Feed-1.1-Unterstützung: Einen dedizierten JSON-Feed-1.1-Emitter neben den Standard-Syndication-Kanälen RSS 2.0 und Atom 1.0 ausliefern.

Phase 2: 0.1.0 (Der Glaubwürdigkeits- und Inkrementell-Minor, 2 bis 3 Monate)

DepGraph befüllen und --incremental aktivieren: DepGraph vollständig verdrahten, um Template-zu-Seite- und Markdown-zu-Seite-Abhängigkeiten zu verfolgen. Eine Cache-Invalidierungsschicht implementieren und das --incremental-CLI-Flag verdrahten, mit dem Ziel von Rebuilds unter 200 ms für Umgebungen mit warmem Cache.
Streaming-AST-Rewrite über lol_html: Fragiles String-Rewriting in image_plugin.rs, search.rs und CSP-Injektionen durch einen streamenden, Zero-Copy-HTML-Rewriter auf Basis von lol_html ersetzen.
Event-getriebener Watcher und Komponenten-HMR: Das Watch-Modul von Polling auf den ereignisgesteuerten notify-Crate portieren und CSS-only- sowie Partial-HTML-Hot-Reloading für Browser-Updates unter 100 ms implementieren.
Vereinheitlichte Befehls-CLI: Die Compiler-Schnittstelle neu strukturieren, um Standard-Unterbefehle zu unterstützen: ssg dev, ssg build, ssg check (Barrierefreiheits-/SEO-Audit) und ssg deploy.
Deterministischer Inferenz-Cache: Eine Content-Hash-Caching-Schicht für alle lokalen LLM-Aufgaben zu Übersetzung, Zusammenfassung und Metadaten-Extraktion implementieren.

Phase 3: 1.0.0 (Der Enterprise- und Produktions-Major, 6 bis 12 Monate)

Zero-Trust-WASM-Plugin-Sandboxing: Eine WebAssembly-Laufzeit (wasmtime oder wasmer) einbetten, um Drittanbieter-Plugins in einer vollständig gesandboxten Umgebung mit fähigkeitsbasiertem Dateisystem- und Netzwerkzugriff auszuführen.
Lokale semantische Vektorsuche (lokales RAG): Ein lokales Rust-natives Embedding-Modell (über candle oder ort) einbetten, um dichte Absatz-Embeddings in einen kompakten Index zu kompilieren und private, clientseitige semantische Suche zu ermöglichen.
Server Islands und WASM-Edge-Target: Die Ausführung von <ssg-island>-Komponenten auf Edge-Laufzeiten (etwa Cloudflare Workers, Vercel Edge oder Netlify Edge) implementieren, aufbauend auf dem kompilierten ssg-wasm-Kern.
Asynchrone parallele E/A-Engine: Das Dateisystem-Schreibmodul neu strukturieren, um asynchrone E/A-Thread-Pools und io_uring-Bindings zu nutzen und CPU-Worker-Blockaden bei parallelen Schreibvorgängen zu beseitigen.
SLSA-v1.1-Build-Provenienz und SPDX-3.0-Konformität: Mathematisch verifizierbare SLSA-Level-3-Build-Provenienz bereitstellen und SPDX-3.0-konforme SBOMs erzeugen, um moderne Sicherheitsstandards der Software-Lieferkette vollständig zu erfüllen.

Wettbewerbsmatrix (Landschaft 2026)

Die folgende Matrix vergleicht static-site-generator (Ziel v1.0) mit den führenden Web-Publishing-Engines des Jahres 2026:

Funktion	static-site-generator v1.0	Hugo v0.155+	Zola v0.19+	Astro 5	Eleventy 3
Sprache / Laufzeit	Rust (Zero Unsafe)	Go	Rust	JS (Node/V8)	JS (Node/V8)
A11y-Build-Gate	AST-Validierung zur Build-Zeit	Keine	Keine	Post-Build-Linter	Post-Build-Linter
Sicherheitshärtung	SHA-384-SRI und CSP-Injektion	Manuell	Manuell	Manuell	Manuell
Lieferkettensicherheit	SLSA L3 + SPDX 3.0 + WASM-Sandbox	Minimal	Minimal	Schwerer NPM-Baum	Schwerer NPM-Baum
KI-Content-Pipeline	Privat, Local-First (lokales LLM)	Keine	Keine	Nur öffentliche API	Nur öffentliche API
Inkrementelle Geschwindigkeit	<200ms (warmer Cache)	<100ms	<150ms	~1.5s	~140ms
Dynamische Interaktivität	Server Islands (WASM-Targets)	Keine	Keine	Server Islands (JS)	Islands (JS)
Suchmaschine	Lokale semantische WASM-Suche	Einfacher String	Einfacher String	Pagefind (JS)	Pagefind (JS)

Positionierung bei 1.0

Bei 1.0 ist die angestrebte Positionierung ein Static-Site-Generator, konzipiert als standardmäßig sichere Software-Infrastruktur: Autorenarbeit gestützt durch Local-First-KI-Pipelines; Kompilierung von über 100.000 Seiten durch eine parallele Streaming-Pipeline; WCAG 2.2 AA sowie strikte CSP und SRI als Build-Gates erzwungen; und gesandboxte dynamische Islands, alles innerhalb eines einzigen, speichersicheren Rust-Binaries. Jede Aussage dieses Satzes verweist auf einen konkreten Punkt der obigen Roadmap statt auf eine Marketing-Absicht.

Integration von Regulatorik und Compliance

In hochsensiblen Enterprise- und Finanzsektoren wird Software durch die Linse von Compliance und Risikokapital bewertet. Die Architektur-Roadmap von static-site-generator ist direkt an wichtige regulatorische Vorgaben ausgerichtet:

DORA Artikel 6 (IKT-Risikomanagement): Die Berechnung und Injektion von SHA-384-SRI-Hashes und strikten Content-Security-Policies zur Compile-Zeit erfüllen die Anforderung, digitale Publikationskanäle vor Lieferketten-Injektion, Web-Defacement und Cross-Site-Scripting-Vektoren (XSS) zu schützen.
DORA Artikel 7 (Resilienz von IKT-Systemen): Durch den Wechsel zu unveränderlichen, zur Compile-Zeit verifizierten statischen Assets beseitigen Finanzinstitute Datenbank- und Laufzeitserver-Schwachstellen, senken den operativen Risikomultiplikator und reduzieren die unter Basel III geforderten Risikokapitalreserven.
European Accessibility Act (EAA), Richtlinie (EU) 2019/882: Das Vorverlagern der Barrierefreiheitsprüfung in die Kompilierungs-Pipeline als hartes Compiler-Gate garantiert 100 % Konformität vor dem Deployment und beseitigt das Risiko von Markenschäden und zivilrechtlichen Klagen unter EAA und ADA Title III.
DSGVO Artikel 25 (Datenschutz durch Technikgestaltung): Der Betrieb der Übersetzungs- und Metadaten-Pipeline auf lokaler, netzwerkisolierter Hardware hält proprietäre Entwürfe, Finanzkennzahlen und personenbezogene Daten aus öffentlichen Drittanbieter-Cloud-LLMs heraus und unterstützt die Einhaltung von Datensouveränitätsprinzipien.

Häufig gestellte Fragen

Was liefert Version 0.0.41 heute tatsächlich, im Vergleich zu dem, was die README behauptet? Das Sicherheits- und Barrierefreiheitsmodell ist real und im Code erzwungen: workspace-weites forbid(unsafe_code), SHA-256/384-SRI-Generierung, CSP-Extraktion, signierte Releases mit Sigstore-Attestierung und ein CycloneDX-SBOM sowie ein Build-stoppendes WCAG-2.2-AA-Gate. Drei dokumentierte Funktionen sind in v0.0.41 nicht funktionsfähig. Das MinifyPlugin ist ein Whitespace-Kollabierer statt eines syntaxbewussten Minifiers; der DepGraph, der inkrementelle Rebuilds antreiben würde, wird kompiliert, aber im Produktionscode nie befüllt; und die AVIF-Kodierung ist ein Stub, dessen avif_variants einen leeren Vektor zurückgibt.

Ist das Barrierefreiheits-Gate ein echtes Compiler-Gate oder ein Post-Build-Linter? Es ist ein Build-Gate. Die WCAG-2.2-AA-Prüfungen laufen innerhalb der Kompilierungs-Pipeline über einen axe-core-Parser zur Compile-Zeit, gesteuert von Playwright, und eine durchfallende Seite hält die Kompilierung mit exakten Zeilennummer-Fehlern an, statt nachträglich eine Warnung auszugeben. Das ist genau die Eigenschaft, die eine Verpflichtung aus dem European Accessibility Act benötigt: Nicht konforme Ausgaben können das Deployment nicht erreichen.

Warum ist der Shell-Aufruf von curl im LLM-Plugin von Bedeutung? Die lokale LLM-Pipeline (src/plugins/llm.rs) ruft das curl-Binary des Hosts auf, um lokale Endpunkte zu erreichen. Das koppelt den Build an eine ausführbare Datei des Hosts, schlägt auf Systemen ohne curl im PATH fehl, öffnet eine Angriffsfläche für Shell-Injection und bricht in netzwerkisolierter CI. Die Portierung des Aufrufs auf einen Rust-HTTP-Client wie ureq beseitigt die externe Abhängigkeit und den Injektionsvektor, weshalb dies der zweite Punkt im 0.0.42-Patch ist.

Was ist der einzige wichtigste Punkt auf dem Weg zur 1.0? Das Befüllen des DepGraph und das Verdrahten des --incremental-Flags. Inkrementelle Rebuilds sind die Glaubwürdigkeitslücke zwischen der dokumentierten und der tatsächlichen Engine, und jede nachgelagerte Aussage über Builds im Sub-Sekunden-Bereich bei über 100.000 Seiten hängt davon ab, dass der Abhängigkeitsgraph Template-zu-Seite- und Markdown-zu-Seite-Kanten verfolgt, statt reine Test-Infrastruktur zu bleiben.

Quellen

Cloudflare, lol-html: Low-Output-Latency streaming HTML rewriter ⧉. [Der streamende Zero-Copy-HTML-Rewriter, der in Phase 0.1.0 die fragile String-Manipulation ersetzen soll.]
W3C, Web Content Accessibility Guidelines (WCAG) 2.2 ⧉. [Die Level-AA-Erfolgskriterien, die das Barrierefreiheits-Gate zur Compile-Zeit erzwingt.]
European Union, Regulation (EU) 2022/2554 (DORA) ⧉. [Die Artikel zu IKT-Risikomanagement und Resilienz, auf die die Sicherheitshaltung abbildet.]
OpenSSF, Supply-chain Levels for Software Artifacts (SLSA) v1.0 ⧉. [Das Build-Provenienz-Framework, das für eine verifizierbare Level-3-Attestierung bei 1.0 angestrebt wird.]
Armin Ronacher, MiniJinja template engine ⧉. [Die abhängigkeitsarme Engine, die Tera ersetzte und den transitiven Baum verschlankte.]
CycloneDX, Software Bill of Materials specification v1.5 ⧉. [Das SBOM-Format, das bei jedem Build für das Lieferketten-Audit erzeugt wird.]
European Union, Directive (EU) 2019/882 (European Accessibility Act) ⧉. [Die Barrierefreiheitsverpflichtung, die das WCAG-Gate zur Compile-Zeit erfüllen soll.]

Zuletzt geprüft im Juli 2026. Ursprüngliche Analyse basierend auf der Inspektion der static-site-generator-Codebasis in v0.0.41; Quellen werden zitiert, nicht reproduziert. Versionsnummern und Funktionsstatus ändern sich schnell, vor einer erneuten Veröffentlichung gegen das Repository verifizieren. Lizenziert unter CC-BY-4.0.

Zuletzt überprüft 2026-07-24.

Diesen Artikel republizieren

Static Site Generator (SSG): Architektur-Roadmap für Unternehmen — Sebastien Rousseau

Analyse eines Rust-Static-Site-Generators: Sicherheit zur Compile-Zeit, WCAG-Gates, lokale KI, die Lücken in v0.0.41 und eine Enterprise-Roadmap zur 1.0.

Dieser Artikel ist lizenziert unter Creative Commons Attribution 4.0 International. Eine Republikation erfordert Attribution zur kanonischen URL.

Static Site Generator (SSG): Architektur-Roadmap für Unternehmen — Sebastien Rousseau

Analyse eines Rust-Static-Site-Generators: Sicherheit zur Compile-Zeit, WCAG-Gates, lokale KI, die Lücken in v0.0.41 und eine Enterprise-Roadmap zur 1.0.

Originally published at https://sebastienrousseau.com/de/2026-07-22-ssg-enterprise-strategic-deep-dive-architectural-roadmap/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER