TL;DR. En djupanalys av en Rust-webbplatsgenerator: säkerhet vid kompilering, WCAG-grindar och lokal AI, luckorna i v0.0.41 och en företagsfärdplan till 1.0.

Viktiga slutsatser

Nuvarande styrkor. Kodbasen static-site-generator uppvisar flera särskiljande ingenjörsbeslut som skiljer den från äldre JavaScript- och Go-motorer:.
Luckor och verkliga förhållanden. Trots dessa exceptionella styrkor avslöjar en noggrann kodgranskning av v0.0.41 flera arkitektoniska, funktionella och utvecklarupplevelserelaterade luckor mellan dokumentationens påståenden och den faktiska rust-koden:.
Arkitektoniska luckor vi saknar (nya upptäckter). Utöver luckorna i v0.0.41 lyfter en bedömning av projektet mot en riskprofil av finansklass fram flera funktioner som det ännu inte erbjuder men som en företagsköpare skulle kräva:.
Den strategiska färdplanen till 1.0. Följande färdplan integrerar både de åtgärdade luckorna och de nyupptäckta företagsklassade funktionerna i ett strukturerat, kronologiskt release-ramverk.

Statisk webbplatsgenerator (SSG): strategisk djupanalys och arkitektonisk färdplan för företag

Forskningsdatum: 2026-06-22. Baserat på kodgranskning av static-site-generator vid v0.0.41 och webbresearch av SSG-landskapet 2026.

För en reglerad utgivare är en statisk webbplatsgenerator inte längre ett designverktyg; den är en del av den operativa riskperimetern. Den öppna Rust-baserade static-site-generator är byggd på den premissen och flyttar säkerhet, tillgänglighet, internationalisering och AI-innehållspipelines till kompileringstid, så att en misslyckad kontroll stoppar bygget i stället för att nå produktion. Denna analys skiljer vad version 0.0.41 faktiskt levererar från vad dokumentationen ännu bara utlovar, redogör för fem företagsfunktioner den ännu saknar och föreslår en stegvis väg till en 1.0-release anpassad till DORA, den europeiska tillgänglighetsakten och moderna standarder för leveranskedjan.

Sammanfattning för ledningen

Publicering är nu en operativ riskperimeter. Under DORA, den europeiska tillgänglighetsakten och GDPR är varje publikt tillgänglig resurs en potentiell ingång för kompromettering av leveranskedjan, defacement och regulatorisk exponering. En kompileringstidsmodell smalnar av den perimetern genom att avvisa icke-efterlevande utdata innan den skeppas.

Motorns särdrag är kompilatorframtvingade, inte dokumenterade förhoppningar. forbid(unsafe_code) över hela arbetsytan, äkta SHA-256/384 SRI, automatisk CSP-extraktion och en WCAG 2.2 AA-grind vid byggtid förvandlar säkerhet och tillgänglighet från efterhandsgranskningar till hårda byggfel.

Version 0.0.41 har en lucka mellan dokumentation och kod. Nativ minifiering, inkrementella ombyggnader via en beroendegraf och AVIF-stöd är beskrivna men inte fungerande; artikeln namnger varje lucka mot den exakta källkodsplatsen.

Vägen till 1.0 är en sekvens, inte en önskelista. Robusthet först (0.0.42), sedan inkrementell korrekthet (0.1.0), sedan de företagsfunktioner, WASM-sandlåda, lokal semantisk sökning och verifierbar SLSA-proveniens, som en reglerad köpare kräver (1.0.0).

Nuvarande styrkor

Kodbasen static-site-generator uppvisar flera särskiljande ingenjörsbeslut som skiljer den från äldre JavaScript- och Go-motorer:

Säkerhetshållning vid kompilering: #![forbid(unsafe_code)] över hela arbetsytan ger minnessäkerhetsgarantier vid kompilering. Byggpipelinen genererar äkta SHA-256/SHA-384 Subresource Integrity-hashar (SRI) (src/plugins/assets.rs) och utför automatisk extraktion av Content Security Policy (CSP) som tar bort unsafe-inline-skript och -stilar. Releaser signeras, bär Sigstore-attestering och producerar en CycloneDX 1.5-SBOM vid varje bygge.
Kompilatorframtvingad tillgänglighetsgrind: Kontroller enligt Web Content Accessibility Guidelines (WCAG) 2.2 nivå AA körs inuti kompileringspipelinen via en axe-core-parser vid byggtid driven av Playwright. Tillgänglighet blir en hård byggrind snarare än en granskning efter publicering: om en sida underkänns stoppas kompileringen med exakta radnummerfel.
Datasuverän AI-pipeline: En lokal LLM-pipeline för översättning och metadataextraktion (via lokala Ollama- eller llama.cpp-endpoints) låter en institution automatisera innehållssammanfattning, generering av JSON-LD-scheman och flerspråkig översättning utan att skicka förhandsrapporter eller känslig immateriell egendom till publika moln-AI-API:er.
Parallelliserad kompilering: Rusts minnessäkerhetsgarantier utgör grunden för en parallelliserad, Rayon-driven HTML- och tillgångspipeline (src/core/pipeline.rs). Pluginpipelinen utför fuserade transformationer, där SearchPlugin, SeoPlugin, CanonicalPlugin och JsonLdPlugin verkar över par_iter(), så att varje sida läses och skrivs till disk en gång.
Leveranskedje- och beroendehygien: Migreringen av mallmotorn från Tera till MiniJinja (v0.0.37) minskade binärstorleken, tog bort transitiva beroenden som rand vid kompilering och gav ett kompakt beroendeavtryck som sänker exponeringen i mjukvaruleveranskedjan.

Luckor och verkliga förhållanden

Trots dessa exceptionella styrkor avslöjar en noggrann kodgranskning av v0.0.41 flera arkitektoniska, funktionella och utvecklarupplevelserelaterade luckor mellan dokumentationens påståenden och den faktiska rust-koden:

Arkitektoniska luckor

Blankstegskomprimering kontra nativ minifiering: Även om README lovar ”nativ JS/CSS-minifiering” fungerar MinifyPlugin (src/plugins/plugins.rs:96-116) enbart som en naiv blankstegskomprimerare. Den kortsluter på <pre>-element och komprimerar blankstegssekvenser i HTML, men utför inte syntaktiskt medveten nativ CSS- eller JS-minifiering. Dessutom bearbetar den bara sidor på toppnivå och går inte rekursivt igenom underkataloger (som /blog/ eller /tags/), vilket lämnar djupt liggande sidor ominifierade.
Död inkrementell infrastruktur: Beroendespårningsgrafen (DepGraph i src/core/depgraph.rs) kompileras och laddas in i PluginContext.dep_graph men fylls aldrig faktiskt i produktionskod. Metoden add_dep() anropas endast i enhetstester, vilket gör READMEs påstående om ”inkrementella ombyggnader via beroendegrafer” till en förhoppning för närvarande.
Batchvis kompilering kontra strömmande kompilering: Modulen streaming::compile_batch (src/core/streaming.rs) strömmar inte i egentlig mening. I stället kompilerar den sidor i batcher till en temporär katalog, kör staticdatagen::compile från grunden för varje batch och slår samman utdata. Detta resulterar i betydande disk-I/O-omkostnader och redundant parsning, vilket avviker från en verkligt strömmande arkitektur.
Överträdelser av pluginens livscykelfaser: Plugins som genererar nya HTML-sidor under byggprocessen, som TaxonomyPlugin, PaginationPlugin och I18nPlugin, skriver direkt till disk i after_compile i stället för att använda livscykeln transform_html. Följaktligen kringgår sidor som genereras av dessa plugins kritiska efterbearbetningsplugins (som CanonicalPlugin, JsonLdPlugin, RobotsPlugin och AccessibilityPlugin) om dessa plugins registrerades tidigare. Detta lämnar tagg-, kategori- och pagineringssidor utan korrekta kanoniska länkar, JSON-LD-scheman eller tillgänglighetsvalideringar.
Skalanrop till curl i LlmPlugin: Den lokala LLM-innehållspipelinen (src/plugins/llm.rs) gör skalanrop direkt till värdens curl-binär för att fråga lokala endpoints. Detta introducerar allvarliga plattformsövergripande buggar (t.ex. på Windows-värdar utan curl i PATH), utgör en säkerhetsrisk (vektorer för skalinjektion) och misslyckas i låsta eller nätverksisolerade CI-miljöer.
Naiv stränghantering vid HTML-omskrivning: Extraktorerna image_plugin.rs och search.rs skriver om HTML-strängar med bräckliga str::find- och str::rfind-operationer. Detta tillvägagångssätt är mycket sårbart för trasiga HTML-taggar, <img>-taggar inuti kommentarer, teckenentiteter i alt-text eller redan befintliga srcset-egenskaper, vilket kan resultera i korrupt utdata.
Oimplementerat AVIF-stöd: Även om AVIF-bildkodning är omfattande dokumenterad är implementationen i image_plugin.rs en stubbe där avif_variants helt enkelt returnerar Vec::new(), vilket lämnar funktionen icke-fungerande.
Pollningsbaserad bevakare: Den lokala utvecklingsserverns bevakare (src/server/watch.rs) använder pollning i stället för filsystemets händelse-API:er, vilket leder till onödigt hög CPU-användning i viloläge och latens under en sekund vid ändringar.

Funktionella luckor och DX-luckor

Ingen transitiv beroendespårning: Beroendegrafen kan inte spåra nästlade beroenden (t.ex. ändringar i en undermall som påverkar en layout som påverkar en sida), vilket verifieras av enhetstestet transitive_not_tracked.
Ingen CLI-flagga för inkrementell kompilering: Det finns ingen --incremental-CLI-flagga kopplad till körkompilatorn, vilket hindrar utvecklare från att använda cachade byggen.
HMR är begränsad till CSS: Hot Module Replacement (HMR) stöder endast CSS; varje ändring i HTML-, layout- eller markdown-filer utlöser en fullständig sidomladdning, vilket sänker utvecklartempot.
Brist på underkommandon: Utvecklare måste manuellt ange utförliga flaggor (ssg -s public -w) eftersom standardunderkommandon som ssg dev, ssg build, ssg check och ssg lint inte finns.

Arkitektoniska luckor vi saknar (nya upptäckter)

Utöver luckorna i v0.0.41 lyfter en bedömning av projektet mot en riskprofil av finansklass fram flera funktioner som det ännu inte erbjuder men som en företagsköpare skulle kräva:

1. WebAssembly-pluginsandlåda (nolltillitsutökning)

Även om själva kompilatorbinären är skriven i säker Rust introducerar det en allvarlig sårbarhet i leveranskedjan att låta godtyckliga tredjepartsplugins köras nativt på värdsystem. Ett komprometterat tredjepartsplugin skulle enkelt kunna komma åt värdens filsystem, läsa proprietära Markdown-filer eller exfiltrera privata inloggningsuppgifter.

Saknad funktion: En sandlådeisolerad exekveringsmiljö. För att uppnå nolltillitskompilering bör kompilatorn köra tredjepartsplugins inuti en inbäddad WebAssembly-runtime (som wasmtime). Plugins bör interagera med värden enbart via ett begränsat WebAssembly System Interface (WASI), vilket strikt begränsar deras åtkomst till den sida som transformeras.

2. Nollkopierings-HTML-parsning via strömmande AST (`lol_html`)

Att migrera HTML-parsningslagret till ett fullständigt DOM-bibliotek i minnet (som Kuchiki eller html5ever) introducerar betydande minnesomkostnader och bearbetningspauser vid hantering av webbplatser med över 100 000 sidor.

Saknad funktion: En strömmande nollkopierings-HTML-omskrivare. Att använda Cloudflares lol_html (Low-Output-Latency HTML rewriter) låter kompilatorn parsa, inspektera och modifiera HTML-element i ett enda strömmande pass med nära noll minnesallokering, vilket matchar den parallella strömmande kompilatorns mål om byggen på under en sekund.

3. Lokal semantisk vektorsökning (lokal RAG)

Det nuvarande sökindexet (SearchPlugin) genererar ett tungt, platt JSON-index som utför enkla strängmatchningar på klientsidan och saknar stöd för fuzzy-sökning, stamning eller semantiska frågor. Pagefind är en förbättring, men förlitar sig fortfarande på att ett stort index laddas ner.

Saknad funktion: Inbäddad semantisk sökning. Kompilatorn bör utnyttja en lokal, lättviktig Rust-nativ vektorinbäddningsmodell (som en MiniLM-L6-modell körd via candle eller ort / ONNX Runtime) vid byggtid. Den bör generera täta vektorinbäddningar för varje sidas stycke och producera ett kompakt vektorindex. Sökwidgeten på klientsidan, kompilerad till WASM, kan sedan utföra äkta semantisk sökning offline direkt i webbläsaren.

4. Deterministisk översättnings- och inferenscachning

Eftersom lokal LLM-inferens (t.ex. via Ollama eller Llama.cpp) är mycket CPU/GPU-intensiv är det beräkningsmässigt oöverkomligt att översätta eller generera metadata för tusentals sidor vid varje bygge.

Saknad funktion: Innehållshashbaserad inferenscachning. Kompilatorn måste upprätthålla en deterministisk cache över alla LLM-operationer. Om SHA-256-hashen av en markdown-fils innehåll och dess översättningsparametrar matchar en cachepost bör kompilatorn återanvända den cachade översättningen och metadatan och kringgå redundant lokal inferens.

5. Asynkron fil-I/O för parallell skalning

Även om pluginpipelinen är parallelliserad via Rayon blockerar vanliga synkrona diskskrivningar Rayons OS-trådar, vilket skapar en I/O-flaskhals vid skrivning av tiotusentals sidor.

Saknad funktion: Asynkron, icke-blockerande disk-I/O. Kompilatorn bör frikoppla CPU-intensiva uppgifter (Markdown-parsning, minifiering) från diskbundna skrivningar och använda asynkrona I/O-trådpooler eller Linux io_uring-bindningar (via rio eller tokio) för att skriva kompilerade sidor parallellt utan att blockera de parallella CPU-exekverarna.

Den strategiska färdplanen till 1.0

Följande färdplan integrerar både de åtgärdade luckorna och de nyupptäckta företagsklassade funktionerna i ett strukturerat, kronologiskt release-ramverk.

Fas 1: 0.0.42 (robusthets- och korrekthetspatchen, 1 till 2 veckor)

Bygg om MinifyPlugin: Integration av minify-html, oxc_minifier och lightningcss för nativ, syntaktiskt medveten minifiering av HTML, JS och CSS. Säkerställ att pluginet rekursivt går igenom alla nästlade kataloger under site_dir.
Säkra AI-pipelinen: Porta LlmPlugin från nativa curl-skalanrop till ureq (en lättviktig, synkron, säker Rust-HTTP-klient) för att säkerställa plattformsövergripande kompatibilitet och eliminera sårbarheter för skalinjektion.
Slutför AVIF-implementationen: Koppla in ravif direkt i bildtillgångspipelinen och möjliggör högpresterande AVIF-kodning vid sidan av WebP och PNG.
Automatisera HrefLang- och flerspråksmappning: Upptäck automatiskt parallella översatta sidor i flerspråkiga byggen och injicera standardiserade, Google-kompatibla <link rel="alternate" hreflang="..." />-taggar i huvudet på varje kompilerad HTML-fil.
JSON Feed 1.1-stöd: Leverera en dedikerad JSON Feed 1.1-emitter vid sidan av standardkanalerna RSS 2.0 och Atom 1.0.

Fas 2: 0.1.0 (trovärdighets- och inkrementell delrelease, 2 till 3 månader)

Fyll DepGraph och aktivera --incremental: Koppla DepGraph fullständigt för att spåra beroenden från mall till sida och från markdown till sida. Implementera ett lager för cacheinvalidering och koppla --incremental-CLI-flaggan, med målet ombyggnader under 200 ms för miljöer med varm cache.
Strömmande AST-omskrivning via lol_html: Ersätt bräcklig strängomskrivning i image_plugin.rs, search.rs och CSP-injektioner med en strömmande nollkopierings-HTML-omskrivare driven av lol_html.
Händelsedriven bevakare och komponent-HMR: Porta bevakningsmodulen från pollning till den händelsedrivna notify-craten, och implementera hot reload för enbart CSS och partiell HTML för webbläsaruppdateringar under 100 ms.
Enhetlig kommando-CLI: Bygg om kompilatorgränssnittet för att stödja standardunderkommandon: ssg dev, ssg build, ssg check (tillgänglighets-/SEO-granskning) och ssg deploy.
Deterministisk inferenscache: Implementera ett innehållshashbaserat cachningslager för alla lokala LLM-uppgifter inom översättning, sammanfattning och metadataextraktion.

Fas 3: 1.0.0 (företags- och produktionsmajor, 6 till 12 månader)

Nolltillits-WASM-pluginsandlåda: Bädda in en WebAssembly-runtime (wasmtime eller wasmer) för att köra tredjepartsplugins i en fullständigt sandlådeisolerad miljö med förmågebaserad filsystems- och nätverksåtkomst.
Lokal semantisk vektorsökning (lokal RAG): Bädda in en lokal Rust-nativ inbäddningsmodell (via candle eller ort) för att kompilera täta styckeinbäddningar till ett kompakt index och möjliggöra privat, klientsidesbaserad semantisk sökning.
Serveröar och WASM-edge-mål: Implementera exekvering av <ssg-island>-komponenter på edge-runtimes (som Cloudflare Workers, Vercel Edge eller Netlify Edge) byggda ovanpå den kompilerade ssg-wasm-kärnan.
Asynkron parallell I/O-motor: Bygg om filsystemsskrivmodulen för att använda asynkrona I/O-trådpooler och io_uring-bindningar, och eliminera blockeringar av CPU-arbetare under parallella skrivningar.
SLSA v1.1-byggproveniens och SPDX 3.0-efterlevnad: Tillhandahåll matematiskt verifierbar SLSA nivå 3-byggproveniens och generera SPDX 3.0-kompatibla SBOM:er, vilket fullt ut uppfyller moderna säkerhetsstandarder för mjukvaruleveranskedjan.

Konkurrentmatris (landskapet 2026)

Följande matris jämför static-site-generator (mål v1.0) mot de ledande webbpubliceringsmotorerna 2026:

Funktion	static-site-generator v1.0	Hugo v0.155+	Zola v0.19+	Astro 5	Eleventy 3
Språk / runtime	Rust (noll unsafe)	Go	Rust	JS (Node/V8)	JS (Node/V8)
Tillgänglighetsgrind vid bygge	AST-validering vid byggtid	Ingen	Ingen	Linter efter bygge	Linter efter bygge
Säkerhetshärdning	SHA-384 SRI och CSP-injektion	Manuell	Manuell	Manuell	Manuell
Leveranskedjesäkerhet	SLSA L3 + SPDX 3.0 + WASM-sandlåda	Minimal	Minimal	Tungt NPM-träd	Tungt NPM-träd
AI-innehållspipeline	Privat, lokal först (lokal LLM)	Ingen	Ingen	Endast publikt API	Endast publikt API
Inkrementell hastighet	<200 ms (varm cache)	<100 ms	<150 ms	~1,5 s	~140 ms
Dynamisk interaktivitet	Serveröar (WASM-mål)	Ingen	Ingen	Serveröar (JS)	Öar (JS)
Sökmotor	Lokal semantisk WASM-sökning	Enkel sträng	Enkel sträng	Pagefind (JS)	Pagefind (JS)

Positionering vid 1.0

Vid 1.0 är den avsedda positioneringen en statisk webbplatsgenerator konstruerad som säker-som-standard-mjukvaruinfrastruktur: författande med stöd av lokala AI-pipelines; kompilering av 100 000-plus sidor genom en parallell strömmande pipeline; WCAG 2.2 AA samt strikt CSP och SRI framtvingade som byggrindar; och sandlådeisolerade dynamiska öar, allt inom en enda, minnessäker Rust-binär. Varje led i det uttalandet motsvarar en specifik punkt i färdplanen ovan snarare än en marknadsföringsförhoppning.

Integration med regelverk och efterlevnad

Inom företags- och finanssektorer med höga insatser utvärderas mjukvara genom efterlevnadens och riskkapitalets lins. Den arkitektoniska färdplanen för static-site-generator är direkt anpassad till centrala regulatoriska mandat:

DORA artikel 6 (IKT-riskhantering): Beräkningen och injiceringen vid kompilering av SHA-384 SRI-hashar och strikta Content Security Policies uppfyller kravet att skydda digitala publiceringskanaler mot injektion i leveranskedjan, webb-defacement och vektorer för cross-site scripting (XSS).
DORA artikel 7 (motståndskraft i IKT-system): Genom att gå över till oföränderliga, kompileringstidsverifierade statiska tillgångar eliminerar finansinstitut sårbarheter i databaser och körningsservrar, vilket sänker den operativa riskmultiplikatorn och minskar de krävda riskkapitalreserverna enligt Basel III.
Europeiska tillgänglighetsakten (EAA), direktiv (EU) 2019/882: Att flytta tillgänglighetsgranskning vänsterut in i kompileringspipelinen som en hård kompilatorgrind garanterar 100 % efterlevnad före driftsättning, vilket eliminerar risken för varumärkesskada och civilrättsliga tvister enligt EAA och ADA avdelning III.
GDPR artikel 25 (inbyggt dataskydd): Att köra översättnings- och metadatapipelinen på lokal, nätverksisolerad hårdvara håller proprietära utkast, finansiella mätvärden och personuppgifter borta från publika tredjeparts-moln-LLM-leverantörer, vilket stödjer efterlevnad av principer för datasuveränitet.

Vanliga frågor

Vad levererar version 0.0.41 faktiskt i dag, jämfört med vad README påstår? Säkerhets- och tillgänglighetsmodellen är verklig och framtvingad i kod: forbid(unsafe_code) över hela arbetsytan, generering av SHA-256/384 SRI, CSP-extraktion, signerade releaser med Sigstore-attestering och en CycloneDX-SBOM, samt en byggstoppande WCAG 2.2 AA-grind. Tre dokumenterade funktioner är inte fungerande i v0.0.41. MinifyPlugin är en blankstegskomprimerare snarare än en syntaxmedveten minifierare; DepGraph som skulle driva inkrementella ombyggnader kompileras men fylls aldrig i produktionskod; och AVIF-kodningen är en stubbe vars avif_variants returnerar en tom vektor.

Är tillgänglighetsgrinden en verklig kompilatorgrind eller en linter efter bygget? Det är en byggrind. WCAG 2.2 AA-kontroller körs inuti kompileringspipelinen genom en axe-core-parser vid byggtid driven av Playwright, och en underkänd sida stoppar kompileringen med exakta radnummerfel snarare än att avge en varning i efterhand. Det är egenskapen som en skyldighet enligt den europeiska tillgänglighetsakten kräver: icke-efterlevande utdata kan inte nå driftsättning.

Varför spelar skalanropet till curl i LLM-pluginet någon roll? Den lokala LLM-pipelinen (src/plugins/llm.rs) anropar värdens curl-binär för att nå lokala endpoints. Det kopplar bygget till en körbar fil på värden, misslyckas på system utan curl i PATH, introducerar en angreppsyta för skalinjektion och havererar i nätverksisolerad CI. Att porta anropet till en Rust-HTTP-klient som ureq tar bort det externa beroendet och injektionsvektorn, vilket är anledningen till att det är den andra punkten i 0.0.42-patchen.

Vilken är den enskilt viktigaste punkten på vägen till 1.0? Att fylla DepGraph och koppla in --incremental-flaggan. Inkrementella ombyggnader är trovärdighetsluckan mellan den dokumenterade och den faktiska motorn, och varje efterföljande påstående om byggen under en sekund vid 100 000-plus sidor beror på att beroendegrafen spårar kanter från mall till sida och från markdown till sida snarare än att förbli infrastruktur endast för tester.

Referenser

Cloudflare, lol-html: strömmande HTML-omskrivare med låg utdatalatens ⧉. [Den strömmande nollkopierings-HTML-omskrivaren som föreslås ersätta bräcklig stränghantering i 0.1.0-fasen.]
W3C, Web Content Accessibility Guidelines (WCAG) 2.2 ⧉. [Framgångskriterierna på nivå AA som framtvingas av tillgänglighetsgrinden vid kompilering.]
Europeiska unionen, Förordning (EU) 2022/2554 (DORA) ⧉. [De artiklar om IKT-riskhantering och motståndskraft som säkerhetshållningen motsvarar.]
OpenSSF, Supply-chain Levels for Software Artifacts (SLSA) v1.0 ⧉. [Ramverket för byggproveniens som är målet för verifierbar attestering på nivå 3 vid 1.0.]
Armin Ronacher, MiniJinja-mallmotorn ⧉. [Den beroendelätta motorn som ersatte Tera och beskar det transitiva trädet.]
CycloneDX, specifikation för Software Bill of Materials v1.5 ⧉. [SBOM-formatet som avges vid varje bygge för granskning av leveranskedjan.]
Europeiska unionen, Direktiv (EU) 2019/882 (europeiska tillgänglighetsakten) ⧉. [Den tillgänglighetsskyldighet som WCAG-grinden vid byggtid är utformad att uppfylla.]

Senast granskad juli 2026. Ursprunglig analys baserad på granskning av kodbasen static-site-generator vid v0.0.41; källor citeras, återges inte. Versionsnummer och funktionsstatus ändras snabbt, verifiera mot repositoriet före återpublicering. Licensierad under CC-BY-4.0.

Senast granskad 2026-07-24.

Återpublicera den här artikeln

Statisk webbplatsgenerator (SSG): djupanalys och färdplan — Sebastien Rousseau

En djupanalys av en Rust-webbplatsgenerator: säkerhet vid kompilering, WCAG-grindar och lokal AI, luckorna i v0.0.41 och en företagsfärdplan till 1.0.

Den här artikeln är licensierad under Creative Commons Attribution 4.0 International. Återpublicering kräver attribution till den kanoniska URL:en.

Statisk webbplatsgenerator (SSG): djupanalys och färdplan — Sebastien Rousseau

En djupanalys av en Rust-webbplatsgenerator: säkerhet vid kompilering, WCAG-grindar och lokal AI, luckorna i v0.0.41 och en företagsfärdplan till 1.0.

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

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER