Working Draft

Diese Folge sprechen wir mit Florian Sowade über eines der zuverlässigsten Rabbit Holes der Softwareentwicklung: Datum und Zeit. Was zunächst nach ein paar Timestamps und Zeitzonen klingt, entwickelt sich schnell zu einer Reise durch Sommerzeiten, historische Kalendersysteme, Schaltsekunden und allerlei politische Entscheidungen, die unsere vermeintlich so präzisen Zeitangaben beeinflussen.

Dabei geht es uns vor allem um ein brauchbares mentales Modell für den Entwickleralltag: Welche unterschiedlichen Arten von Zeitangaben gibt es eigentlich, warum reicht ein einzelner Date-Typ oft nicht aus und wie helfen APIs wie Temporal dabei, die unvermeidbare Komplexität wenigstens explizit zu machen?

code.talks 2026 — 4. & 5. November, Kinopolis Hamburg.

Norddeutschlands größte Developer-Konferenz, seit 2010: 3.500 Entwickler:innen, 100+ Talks, 14 Tracks — von GenAI über Architecture und Security bis Frontend, DevEx und Geek-Out. 90% der Talks ohne Sponsor dahinter, kuratiert von Praktiker:innen statt von Sales-Teams. Auf der Bühne u.a. Eric Evans und Dex Horthy.

Im Ticket enthalten: alle Sessions, à la carte Lunch, Drinks, Popcorn & Nachos und die Party auf der Reeperbahn.

Derzeit spart ihr so richtig, denn es läuft die Crazy Back to Office Aktion. Vom 1.9. – 14.9. bekommt ihr das all-in-one Ticket für 549€ statt 799€.

Agenda & Tickets: 👉 codetalks.com

Die Regeln dafür stammen aus der Timezone Database. Zeitzonen können sich durch politische Entscheidungen kurzfristig ändern. Selbst Deutschland besitzt mit Europe/Berlin und Europe/Büsingen zwei Einträge. Für Anwendungen bedeutet das, Zeitzonendaten aktuell zu halten und etwa bei Cronjobs zu berücksichtigen, dass „nachts“ nicht dasselbe ist wie eine feste UTC-Uhrzeit.

Die JavaScript Temporal API macht solche Unterschiede explizit und modelliert verschiedene Zeitkonzepte mit eigenen Typen. Das hilft auch bei Berechnungen: Ein Tag hat durch Zeitumstellungen nicht immer 24 Stunden und drei Monate entsprechen keiner festen Anzahl Sekunden.

Weitere Sonderfälle sind Schaltsekunden und unterschiedliche Kalendersysteme. So werden Shakespeare und Cervantes beide mit dem 23. April 1616 als Todestag geführt, obwohl England und Spanien damals unterschiedliche Kalender verwendeten. Auch Schwedens missglückter schrittweiser Wechsel zum gregorianischen Kalender zeigt, wie schwierig historische Datumsangaben werden können.

Florians Fazit: Annahmen wie „ein Tag hat 24 Stunden“ hinterfragen und möglichst High-Level-APIs und Libraries verwenden, die unterschiedliche Zeitkonzepte ausdrücklich modellieren. Welche Bedeutung eine Zeitangabe konkret hat, bleibt dabei eine Frage der jeweiligen Anwendung.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

Wir sprechen mit Andreas Spannbauer und Werner Krauß über das Silverstripe CMS, ein PHP-basiertes Open-Source-CMS, das sich vor allem an Entwickler:innen und individuell entwickelte Webprojekte richtet. Werner arbeitet seit mehr als 15 Jahren mit Silverstripe und ist in der Open-Source-Community aktiv, Andreas setzt das System mit seiner Wiener Webagentur vor allem für langfristige, maßgeschneiderte Kundenprojekte ein.

Neben Architektur, Datenmodellierung, Frontend und Headless-Betrieb geht es um die europäische Silverstripe-Community, den Verein S2-Hub und die StripeCon Europe, die vom 16. bis 18. September 2026 in Salzburg stattfindet. Für die Konferenz verlosen wir außerdem drei Tickets. Schreibt dafür ne E-Mail mit „Ich will zur Stripecon“ im Betreff bis zum 07.09.2026 an [email protected].

Wir sprechen darüber, warum diese Herangehensweise insbesondere für individuelle und langfristig betriebene Projekte interessant ist. Entwickler:innen definieren Datenstrukturen und Möglichkeiten, während Redakteur:innen im Backend eine auf ihre Aufgaben zugeschnittene Oberfläche erhalten. Dadurch lässt sich beispielsweise vermeiden, dass dieselben Informationen als voneinander unabhängige Textblöcke auf mehreren Seiten gepflegt werden. Stattdessen können Entitäten wie Händler oder Produkte als eigene Datenobjekte modelliert und anschließend an unterschiedlichen Stellen und in verschiedenen Sprachversionen verwendet werden.

Technisch besteht Silverstripe aus einem Framework und dem darauf aufbauenden CMS. Das Framework lässt sich auch ohne klassischen Seitenbaum einsetzen, etwa als Backend für eine Anwendung. Mit dem CMS kommen unter anderem Seiten, Unterseiten, URLs und Navigation hinzu. Über Konventionen legt Silverstripe fest, wie Klassen, Konfigurationen und Templates strukturiert und wo sie abgelegt werden. Das dazugehörige CLI-Tool orientiert sich konzeptionell an Werkzeugen aus Ruby on Rails beziehungsweise Artisan aus Laravel.

Beim Hosting sind die Anforderungen überschaubar: Ein üblicher LAMP-Stack mit aktuellem PHP, MySQL oder MariaDB und Webserver reicht grundsätzlich aus. Praktisch hilfreich sind SSH-Zugang und Composer, weshalb sehr eingeschränkte Hosting-Pakete weniger geeignet sind.

Auch beim Frontend macht Silverstripe vergleichsweise wenige Vorgaben. Zwar gibt es ein eigenes Templating-System, der restliche Frontend-Stack kann aber frei gewählt werden. Gleichzeitig fehlen dadurch weitgehend fertige Themes und Starter-Projekte, wie man sie aus anderen CMS-Ökosystemen kennt. Das passt zur typischen Nutzung von Silverstripe für individuell gestaltete Projekte, führt beim Einstieg aber zu einer steileren Lernkurve. Neben der Komplexität des Frameworks müssen zunächst dessen Konventionen verstanden werden. Sind diese verinnerlicht, lassen sich Datenstrukturen und Anwendungen nach Einschätzung unserer Gäste sehr schnell aufbauen.

Silverstripe kann außerdem als Headless-CMS betrieben werden. Daten lassen sich beispielsweise über REST oder GraphQL an JavaScript-Anwendungen ausliefern. Andreas berichtet von Projekten mit Angular und React, weist aber darauf hin, dass Headless für eine klassische Website zusätzliche Komplexität mit sich bringt und deshalb durch die Anforderungen des Projekts gerechtfertigt sein sollte. Werner setzt bei passenden Projekten stattdessen auf statisch generierte Seiten und lädt dynamische Bestandteile bei Bedarf beispielsweise mit HTMX nach.

Ein weiteres wichtiges Konzept ist die Erweiterbarkeit der Datenobjekte. Über Extensions können bestehende Objekte um Felder, Relationen und Verhalten ergänzt werden, ohne dafür zwingend Subklassen erstellen zu müssen. Hooks wie onBeforeWrite und onAfterWrite ermöglichen zusätzliche Logik beim Speichern. Zusammen mit dem Form-Scaffolding können neue Felder teilweise automatisch im CMS auftauchen.

Als Beispiel sprechen wir über individuell entwickelte Shops. Während sich für einen klassischen Shop mit Standardprodukten ein fertiges Shopsystem anbieten kann, sieht Andreas Stärken von Silverstripe bei ungewöhnlichen Anforderungen: stark konfigurierbare Produkte, zusätzliche Metadaten, besondere Checkout-Prozesse, die enge Verzahnung von Commerce und Content oder Produkte mit mehreren Mehrwertsteuerklassen und Anbindung an ein Warenwirtschaftssystem. Auch blockbasierte Seiten lassen sich umsetzen, wobei Redakteur:innen bewusst nur vordefinierte Varianten angeboten werden können, um ein konsistentes Design zu erhalten.

Weniger geeignet ist Silverstripe dagegen für kurzlebige Landingpages, einfache One-Pager oder Projekte, bei denen weder strukturierte Daten noch langfristige Wartung eine Rolle spielen. Wer das System noch nicht kennt, müsste für solche kleinen Projekte zunächst vergleichsweise viel lernen. Für individuelle, skalierbare Anwendungen und Websites sehen Andreas und Werner dagegen seine wesentlichen Stärken.

Wir sprechen außerdem über die internationale Silverstripe-Community. Sie ist vergleichsweise klein, aber über Europa, Neuseeland, Australien und weitere Regionen verteilt und tauscht sich vor allem über Slack aus. Aus dieser Community entstand die jährlich an wechselnden europäischen Orten stattfindende StripeCon Europe. 2026 trifft sie sich vom 16. bis 18. September in den Stiegl-Brauwelten in Salzburg. Am ersten Tag gibt es einen Hack Day, an dem die Teilnehmer:innen gemeinsam an eigenen Projekten oder Issues arbeiten und sich gegenseitig unterstützen. An den beiden folgenden Tagen stehen Talks und insbesondere der persönliche Austausch im Hallway Track im Mittelpunkt. Inhaltlich geht es nicht ausschließlich um Silverstripe, sondern auch um angrenzende Themen aus Frontend- und Backend-Entwicklung, Barrierefreiheit und KI.

Die StripeCon Europe versteht sich als Community-Konferenz und richtet sich sowohl an bestehende Silverstripe-Entwickler:innen als auch an Menschen, die das CMS kennenlernen möchten. Tickets kosten ungefähr 250 Euro für alle drei Tage inklusive Verpflegung und Abendprogramm, außerdem gibt es vergünstigte Tickets für Studierende. Wir verlosen drei Tickets: Wer teilnehmen möchte, schickt bis zum 7. September 2026 eine E-Mail mit „Ich will zur StripeCon“ im Betreff an die Adresse [email protected].

Hinter der europäischen Community steht außerdem S2-Hub, ein gemeinnütziger österreichischer Verein zur Förderung von Silverstripe in Europa. Die Idee dazu entstand 2019 bei der StripeCon in Krems. Der Verein soll die europäischen Community-Aktivitäten bündeln, Silverstripe bekannter machen und als Ansprechpartner gegenüber dem Silverstripe-Umfeld in Neuseeland dienen. Mitglieder und Board kommen aus verschiedenen europäischen Ländern und Agenturen. Überschüsse aus der StripeCon fließen zurück in diese Arbeit.

Zum Abschluss empfehlen Andreas und Werner allen Interessierten, Silverstripe selbst auszuprobieren und bei Fragen Kontakt zur Community aufzunehmen. Neben Slack und S2Hub bietet auch der Hack Day der StripeCon eine Gelegenheit, gemeinsam mit erfahrenen Community-Mitgliedern in das System einzusteigen.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

Wir werfen wieder einen Blick auf aktuelle Entwicklungen der Webplattform und sprechen über eine ganze Reihe neuer Browser-Features und Standards, die in den letzten Monaten ihren Weg in Chrome, Firefox oder Baseline gefunden haben. Dabei geht es sowohl um neue APIs und CSS-Features als auch um Verbesserungen für Accessibility und die Entwicklerwerkzeuge.

Alle reden von Automation – aber wo betreibst du eigentlich deine Tools?

Egal ob n8n oder andere Container-Setups: Mit dem Container-Hosting von mittwald läuft deine Anwendung in wenigen Minuten. Die nervige Konfiguration? Geht easy von der Hand – inklusive Vorschlägen für Umgebungsvariablen und Entrypoints.

Also: Fang an zu automatisieren. Dein erster Schritt ist ein Hosting bei mittwald. 👉 mittwald.de/workingdraft

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

Wir sprechen mit Alexander Lichter (LinkedIn / Mastodon) über die Übernahme von VoidZero durch Cloudflare. Nachdem wir in Revision 673 bereits über die Gründung von VoidZero und die Vision einer nachhaltigen Finanzierung moderner JavaScript-Infrastruktur gesprochen haben, ziehen wir nun Bilanz: Warum wurde VoidZero übernommen, was bedeutet das für Vite, Rolldown und Co., und wie verändert sich dadurch die Arbeit der Maintainer?

Außerdem sprechen wir über Open-Source-Finanzierung, die Rolle großer Unternehmen als Stewards wichtiger Infrastruktur, den Umgang mit AI-generierten Pull Requests, den neuen Vite Ecosystem Fund und darüber, warum Alex trotz Cloudflare-Anstellung weiterhin so viel Zeit in Framework-übergreifende Open-Source-Arbeit steckt.

Die NodeConf.eu ist eine ehrenamtlich organisierte Non-Profit-Konferenz von der Community für die Community. Dieses Jahr findet sie wieder im wunderschönen Bologna statt – eine Stadt, die sich perfekt für einen verlängerten Konferenztrip eignet.

Zum internationalen Vortragsprogramm gibt es reichlich Gelegenheit zum Netzwerken, denn im Ticketpreis ist auch ein mehrgängiges gemeinsames Abendessen enthalten. Wenn ihr JavaScript, Node.js und die Webplattform mögt, lohnt sich ein Blick auf die NodeConf.eu.

Anschließend widmen wir uns den Auswirkungen auf das Vite-Ökosystem. Wir sprechen über den neuen Vite Ecosystem Fund, das Advisor-Modell, die weiterhin unabhängige Governance der Projekte und darüber, weshalb Cloudflare die technische Ausrichtung von Vite nicht einfach bestimmen kann. Alex erläutert außerdem, wie sich sein Arbeitsalltag verändert hat, warum das gesamte Team gemeinsam zu Cloudflare gewechselt ist und welche Möglichkeiten sich durch den direkten Zugriff auf große Produktionssysteme ergeben.

Darüber hinaus diskutieren wir die Rolle großer Unternehmen als Stewards von Open Source, den Umgang mit AI-generierten Pull Requests, die Bedeutung guter Bug Reports sowie Alex‘ Beiträge zu React, Chromium und Nuxt. Zum Abschluss werfen wir noch einen Blick auf Vite+, die zukünftige Entwicklung der Toolchain und darauf, woran sich überhaupt erkennen lässt, ob die Übernahme von VoidZero langfristig ein Erfolg war.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

Wir sprechen mit Thomas Steiner (Mastodon, Bluesky, LinkedIn) von Google über einen neuen Vorschlag für die Webplattform: die Cross-Origin-Storage API. Tom war bereits mehrfach bei uns zu Gast, zuletzt in Revision 677.

Gemeinsam schauen wir uns an, welches Problem die API lösen soll, warum Browser heute identische Ressourcen mehrfach herunterladen und speichern und wie sich das mit einem hashbasierten, sicheren und datenschutzfreundlichen Ansatz vermeiden ließe. Dabei geht es längst nicht nur um KI-Modelle, sondern ebenso um WebAssembly-Pakete, Web Fonts und JavaScript-Bibliotheken.

Die NodeConf.eu ist eine ehrenamtlich organisierte Non-Profit-Konferenz von der Community für die Community. Dieses Jahr findet sie wieder im wunderschönen Bologna statt – eine Stadt, die sich perfekt für einen verlängerten Konferenztrip eignet.

Zum internationalen Vortragsprogramm gibt es reichlich Gelegenheit zum Netzwerken, denn im Ticketpreis ist auch ein mehrgängiges gemeinsames Abendessen enthalten. Wenn ihr JavaScript, Node.js und die Webplattform mögt, lohnt sich ein Blick auf die NodeConf.eu.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

Wir sind diesmal zu viert: Schepp, Vanessa und Peter diskutieren mit Jon Uhlmann über Utility-First CSS und insbesondere Tailwind CSS. Jon war bereits mehrfach bei uns zu Gast und meldete sich nach unserer Diskussion in Revision 715, weil ihm unsere damalige Einordnung von Tailwind zu einseitig erschien.

Wir nehmen das zum Anlass, Tailwind noch einmal ausführlicher mit klassischem CSS, komponentenbasierten Ansätzen und BEM zu vergleichen. Dabei geht es weniger um ein einfaches Dafür oder Dagegen als um Wartbarkeit, lokale und globale Abhängigkeiten, Designsysteme, unterschiedliche CSS-Kenntnisse in Teams sowie die Frage, wie sich Utility-Klassen auf KI-generierten Code auswirken.

Alle reden von Automation – aber wo betreibst du eigentlich deine Tools?

Egal ob n8n oder andere Container-Setups: Mit dem Container-Hosting von mittwald läuft deine Anwendung in wenigen Minuten. Die nervige Konfiguration? Geht easy von der Hand – inklusive Vorschlägen für Umgebungsvariablen und Entrypoints.

Also: Fang an zu automatisieren. Dein erster Schritt ist ein Hosting bei mittwald. 👉 mittwald.de/workingdraft

Wir vergleichen Tailwind zunächst mit BEM. Während BEM über semantische Klassennamen Komponenten und Varianten organisiert, setzt Tailwind auf präsentationsbezogene Utility-Klassen. Jon betrachtet beide Ansätze nicht als gegenseitigen Ersatz. Für komplexe Layouts oder Spezialfälle greift er weiterhin zu eigenem CSS, während sich wiederkehrende Abstände, Farben und einfache Layout-Eigenschaften gut mit Utilities abbilden lassen.

Tailwind nimmt Entwicklerinnen und Entwicklern das Verständnis von CSS nicht vollständig ab. Wer ein gutes Design umsetzen möchte, muss weiterhin wissen, wie Layout, Kaskade und CSS-Eigenschaften funktionieren. Das Framework liefert jedoch eine begrenzte Auswahl an Abständen, Farben und weiteren Design-Tokens. Dadurch kann es einen konsistenten visuellen Rhythmus fördern und gleichzeitig neue CSS-Funktionen sichtbar machen, die im Projekt bereits zuverlässig eingesetzt werden können.

Komponentenbibliotheken wie daisyUI oder shadcn/ui gehen noch einen Schritt weiter und stellen fertige Komponenten beziehungsweise wiederverwendbare Vorlagen bereit. Wir unterscheiden deshalb zwischen dem eigentlichen Utility-Ansatz und dem zusätzlichen Designsystem, den Konventionen und den Serviervorschlägen, die Tailwind mitbringt.

Ein kurzer Ausflug führt zu Tachyons. Das ebenfalls Utility-basierte Framework entstand unter anderem aus der Frage, welche Selektoren und CSS-Strukturen Browser besonders einfach verarbeiten können. Den praktischen Performancevorteil einzelner Utility-Klassen können wir nicht beziffern und halten ihn für die meisten Projekte nicht für den entscheidenden Grund, ein solches Framework einzusetzen. Viele Klassen im Markup sind jedenfalls nicht automatisch ein Performanceproblem und lassen sich bei der Übertragung gut komprimieren.

Als wesentlichen Vorteil beschreibt Jon die Verbindung von lokalem HTML und globalem CSS. Klassische Stylesheets können Regeln enthalten, deren Verwendung und Abhängigkeiten in großen Projekten kaum noch überschaubar sind. Entfernt man eine Komponente, bleibt das zugehörige CSS möglicherweise zurück. Entfernt man eine vermeintlich ungenutzte Regel, kann an anderer Stelle etwas kaputtgehen. Bei Tailwind stehen die benötigten Utilities direkt am Markup, und der Build-Prozess übernimmt nur die tatsächlich verwendeten Klassen. Fällt eine Komponente weg, verschwinden damit auch deren nicht mehr benötigte Styles.

Vanessa ergänzt die Entscheidungen, die beim klassischen CSS regelmäßig anfallen: Braucht eine neue Komponente eine eigene Klasse, kann eine vorhandene Klasse wiederverwendet werden, oder entsteht daraus eine zu generische Abstraktion? Tailwind ermutigt stärker zur lokalen Wiederholung. Das widerspricht zwar zunächst dem erlernten DRY-Prinzip, kann aber verhindern, dass nur oberflächlich ähnliche Komponenten unnötig miteinander gekoppelt werden.

Dieser lokale Ansatz hat auch Grenzen. Lange Klassenlisten können kopiert werden und dabei überflüssige oder widersprüchliche Utilities übernehmen. In Code-Reviews besteht die Gefahr, über die Tailwind-Klassen hinwegzulesen, statt das resultierende CSS bewusst zu prüfen. Außerdem kann die niedrige Hürde für individuelle Abstände und Varianten zu inkonsistenten Oberflächen führen. Ein explizites Designsystem und eine Person, die Verantwortung für dessen Weiterentwicklung übernimmt, bleiben deshalb auch mit Tailwind sinnvoll.

Wir sprechen außerdem über unterschiedliche Kenntnisstände in Teams. Nicht alle Beteiligten beschäftigen sich gleich intensiv mit CSS, Layout, Typografie oder neuen Browserfunktionen. Tailwinds Dokumentation, Editorintegration und Autovervollständigung können dabei helfen, vorhandene Möglichkeiten zu entdecken und konsistente Lösungen zu verwenden. Die gute Dokumentation und die produktähnliche Präsentation des Frameworks sehen wir als wichtigen Teil seines Erfolgs. Als vergleichbares Beispiel für die Wirkung einer solchen Präsentation nennt Peter ts-reset.

Jon berichtet von einem Redaktionssystem, in dem ein technisch versierter Redakteur mit einem integrierten Editor und Tailwind eigene Inhaltselemente zusammenstellen konnte. Vorgegebene Farben und Abstände erhöhten die visuelle Konsistenz, ohne dass für jede Variante eine neue Komponente entwickelt werden musste. Beim Veröffentlichen wurden neu verwendete Klassen erkannt und das Stylesheet automatisch aktualisiert.

Neue native Browserfunktionen spielen dabei ebenfalls eine Rolle. Über Initiativen wie Open UI kommen immer mehr Interaktionsmuster direkt in HTML und CSS an, die zuvor häufig JavaScript benötigten. Tailwind lässt sich durch eigene Utilities und Plugins um solche Funktionen ergänzen. Jon empfiehlt dennoch, das Framework nicht dogmatisch einzusetzen und komplexe Grids oder spezielle Komponenten weiterhin mit passendem Custom CSS zu lösen. Einen Überblick über aktuelle CSS-Möglichkeiten findet man unter anderem bei Kevin Powell.

Anschließend diskutieren wir, ob Tailwind auch für KI-generierte Frontends besonders geeignet ist. Vanessa beobachtet, dass Agents häufig besser mit zusammenhängenden Markup-Blöcken und direkt darin enthaltenen Utility-Klassen umgehen als mit semantischen Klassen, deren Definitionen in anderen Dateien liegen. Gut dokumentierte und weitverbreitete Klassen bieten außerdem viele Beispiele im Trainingsmaterial. Offen bleibt, ob Code deshalb gezielt für Agents optimiert werden sollte oder ob dies nur eine Momentaufnahme aktueller Modelle ist.

KI kann Menschen mit wenig Frontend-Erfahrung zu brauchbaren Ausgangspunkten verhelfen und Eigenschaften wie aspect-ratio einsetzen, die ihnen vorher unbekannt waren. Die Ergebnisse benötigen jedoch weiterhin Reviews, weil überflüssige Klassen, unnötige Wiederholungen und veraltete Lösungswege entstehen können. Besonders neue Browserfunktionen kennt ein Modell nicht zwangsläufig, weshalb aktuelle Dokumentation und Quellen weiterhin wichtig bleiben.

Peter stellt Tailwind eine möglichst werkzeugfreie Alternative gegenüber: Probleme sollten zunächst durch kleine, klar abgegrenzte Komponenten und ein explizites Designsystem vermieden werden. Ist CSS sauber auf Komponenten begrenzt, verlieren globale Namenskollisionen und weitreichende Seiteneffekte an Bedeutung. In kleinen Scopes können einfache Klassennamen ausreichen, ohne dass dafür BEM oder ein Utility-Framework notwendig wäre.

Wir besprechen in diesem Zusammenhang @scope. Native CSS Scopes könnten einen Teil des ursprünglichen Problems lösen, auf das BEM, CSS-in-JS und Utility-Frameworks reagieren: CSS ist standardmäßig global, während Komponenten und Templates lokal organisiert sind. Jon wirft deshalb die Frage auf, wie Tailwind aussähe oder ob es in derselben Form entstanden wäre, wenn CSS von Anfang an einen brauchbaren Scoping-Mechanismus besessen hätte.

Bei kurzfristigen Sonderfällen plädiert Peter für möglichst einfache Lösungen, etwa ein Style-Attribut, bis genügend Wiederholungen für eine belastbare Abstraktion vorhanden sind. Schepp weist allerdings darauf hin, dass Inline-Styles bei einer entsprechend strengen Content Security Policy für Styles nicht ohne Weiteres erlaubt sind.

Am Ende bleibt kein universeller Sieger. Tailwind kann Wartbarkeit, Produktivität und Konsistenz verbessern, besonders in größeren oder heterogenen Teams und in Projekten mit vielen frei kombinierbaren Komponenten. Scoped CSS, kleine Komponenten und ein bewusst gepflegtes Designsystem können dieselben Grundprobleme ohne zusätzliches Framework lösen. Entscheidend ist, die jeweiligen Abhängigkeiten zu verstehen und Tailwind nicht als Ersatz für CSS-Kenntnisse, sondern als eine mögliche Organisationsform für CSS einzusetzen.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

Wir sprechen mit Jonas Ulrich von der Ruhmesmeile in Bonn über Designsysteme, Headless-CMS-Workflows und darüber, warum kickstartDS nicht nur als Komponentenfundament, sondern auch als strukturierte Wissensbasis für KI-gestützte Redaktionsarbeit interessant ist.

Nachdem Jonas bereits in Revision 538 und Revision 607 bei uns zu Gast war, schauen wir diesmal darauf, wie sich Designsysteme, JSON Schema, Model Context Protocol und Headless-Systeme wie Storyblok zu einem Workflow verbinden lassen, der Frontend, CMS und Redaktion enger zusammenbringt.

Im Webcafé, dem Podcast zu Webentwicklung, Webdesign und Unternehmenskultur, nehmen euch Felix und Kay mit auf eine spannende Reise durch die Welt moderner Softwareentwicklung. Gerade ihre unterschiedliche Perspektive macht dabei den Reiz aus: Felix schaut als Geschäftsführer der Geenen IT-Systeme GmbH auf Strategie, Führung und Unternehmensentwicklung, Kay bringt als Technical Lead den Blick auf Technik, Tools und Architektur ein. Genau daraus entstehen ehrliche, fundierte und persönliche Gespräche über Webtechnologien, Zusammenarbeit und die Herausforderungen digitaler Arbeit.

Jetzt reinhören: geenen-it-systeme.de

Wir sprechen darüber, wie kickstartDS aus der eigenen Agenturpraxis heraus entstanden ist: als wiederverwendbares Fundament für Marketing-Websites, Landingpages und ähnliche Oberflächen, bei denen sich Informationsarchitektur und Komponentenbedarf oft stärker ähneln, als man zunächst denkt. Wichtig ist Jonas dabei, dass kickstartDS nicht das nächste Bootstrap sein will, sondern eine systematische Anschubhilfe, auf deren Basis Teams weiterhin eigene Komponenten und spezifische Lösungen bauen können.

Ein großer Teil des Gesprächs dreht sich um die Verbindung von Designsystemen mit Headless-CMS-Systemen. Jonas erklärt, wie Ruhmesmeile Komponenten, Templates und Seitenstrukturen über JSON Schema beschreibt und daraus CMS-Konfigurationen ableitet. Die Schema-Beschreibungen dienen dabei als Contract zwischen Frontend, Redaktion und Backend. So kann ein Converter Strukturen wie Page-Templates, Blog-Templates, Sections und Komponenten ins CMS übertragen und später auch Änderungen kontrolliert nachziehen. Dadurch wird Drift zwischen Frontend-Code und CMS-Modell reduziert.

Daraus ergibt sich auch der KI-Teil des Gesprächs: Weil die Frontend-Struktur bereits maschinenlesbar beschrieben ist, lässt sie sich gut mit LLMs verwenden. Jonas beschreibt, wie Structured Outputs und JSON Schema genutzt werden können, um Inhalte direkt im erwarteten Format generieren zu lassen, statt lose Texte zu erzeugen und anschließend per Copy and Paste ins CMS zu übertragen. Das Ergebnis kann als Preview gerendert, über denselben Konverter in ein CMS-spezifisches Format gebracht und anschließend redaktionell weiterbearbeitet werden.

Damit die Ergebnisse nicht beliebig wirken, analysiert Ruhmesmeile bestehende Inhalte im CMS. Daraus lassen sich Muster ableiten: Welche Komponenten stehen typischerweise an welcher Position? Wie viele Features werden normalerweise gezeigt? Welche Breiten oder Layout-Optionen sind in bestimmten Kontexten üblich? Diese Informationen werden wiederum in die JSON-Schema-Beschreibungen injiziert und damit Teil des Prompts. So entsteht ein KI-gestützter Workflow, der sich stärker am bestehenden System, am Tonfall und an den gewachsenen Inhaltsmustern orientiert.

Wir sprechen außerdem über das Model Context Protocol als eine Art API-Verschalung für LLMs. Ein MCP-Server kann bestehende APIs so zugänglich machen, dass ein LLM die passenden Tools, Prozesse und Kontextinformationen bekommt. Jonas vergleicht das mit einem Backend-for-Frontend, nur mit einem LLM als Adressaten. Ruhmesmeile nutzt diesen Ansatz, um Storyblok, Designsystem-Wissen und Content-Workflows miteinander zu verbinden.

Ein praktischer Aspekt ist die Bedienung durch Redakteurinnen und Redakteure. Jonas beschreibt eine Prompt-Komponente im CMS, die wie ein Inhaltsblock eingesetzt werden kann: entweder auf einer leeren Seite, um mehrere Sektionen vorzuschlagen, oder an einer bestimmten Position, um gezielt ein Element zu erzeugen. Zusätzlich können externe Chat-Interfaces oder Automatisierungstools angebunden werden, etwa um Blogpost-Entwürfe aus RSS-Feeds zu generieren oder Varianten für unterschiedliche Zielgruppen vorzubereiten. Veröffentlicht wird dabei aber nicht automatisch. Der Mensch bleibt bewusst im Loop.

Zum Schluss sprechen wir über Grenzen und Nebenwirkungen von KI. Jonas betont, dass LLMs beim Schreiben helfen können, aber weiterhin halluzinieren und besonders bei Bildern nicht automatisch gute redaktionelle Entscheidungen treffen. Als pragmatische Lösung nutzt Ruhmesmeile Platzhalterbilder, deren Text vom LLM beschreibt, welches Bild an dieser Stelle sinnvoll wäre. Außerdem diskutieren wir, wie KI Coding, Dokumentation und Lernen verändert, warum Review und Verständnis weiterhin wichtig bleiben und warum Junior-Entwicklung nicht einfach durch Prompting ersetzt werden kann.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

The conversation is not only about building more renewable energy. Chris also highlights the importance of battery storage and making smarter use of the energy that is already available. The goal is to take advantage of periods with abundant renewable power and reduce the need to rely on fossil fuel generation.

A central theme is the growing demand for compute, particularly because of the current boom in generative AI. While large parts of the tech industry had been moving towards decarbonisation, the Green Web Foundation now sees signs of a reversal, with new data centres being built that increase dependence on fossil fuels instead of reducing it.

From the State of the Fossil-Free Internet 2026 report, Chris derives three main areas of action. First, we need to manage demand for compute more consciously. Efficient software, thoughtful architecture and a more deliberate use of resources matter more than ever.

Second, we need to actually green the energy supply. Instead of relying only on certificates or offsetting emissions on paper, companies should choose providers that organise their power supply through a meaningful mix of renewable energy sources and storage.

The third point concerns the structure of the market itself. Chris argues for a more diverse ecosystem of hosting and cloud providers and warns against increasing concentration among a small number of hyperscalers. Their priorities do not always align with wider societal or climate goals, while a more diverse provider landscape can create more accountability and better sustainability outcomes.

In the end, the takeaway is that the energy powering digital services is not an abstract background detail. As developers and operators of digital products, we should understand where that energy comes from and which choices we can make to help build a more fossil-free internet.

The video of the talk will be available soon on mittwald’s YouTube channel.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

Wir spielen wieder ARIA-Glücksrad und sprechen mit Paweł Masarczyk (Mastodon), Peter Krautzberger (LinkedIn / Mastodon) und Marco Bretschneider (Mastodon) über ARIA-Rollen und -Attribute, die uns unser Glücksrad ausspuckt. Daniela Kubesch (LinkedIn / Bluesky / Mastodon) musste leider erneut aussetzen, und Paweł wurde später von seiner Internetverbindung aus der Runde gewürfelt.

Wir arbeiten uns durch abstrakte Landmark-Rollen, praktische Landmark-Navigation, die Rolle option, aria-required, ariaNotify() und schließlich role="form". Dabei geht es wie immer darum, was die Spezifikation meint, was Browser und assistive Technologien daraus machen und wo native HTML-Elemente fast immer die bessere Wahl sind.

In diesem Zusammenhang bringt Peter ariaNotify() ins Spiel. Die neue API soll Benachrichtigungen an assistive Technologien deutlich einfacher machen als klassische Live Regions. Dazu verlinken wir erste Erfahrungen und Browser-Tests von Oida Is Des: First Look und Browser Support. Zum Schluss schweifen wir noch zu Declarative Partial Updates ab und überlegen, ob sich damit sogar Live-Regionen ohne eigenes JavaScript befüllen ließen.

Außerdem lernen wir, dass ein Formular ohne zugänglichen Namen zwar weiterhin als Formular erkannt wird, aber nicht mehr als Landmark erscheint. Das ist sinnvoll, um unnötige Landmark-Einträge zu vermeiden, insbesondere bei versteckten oder rein technischen Formularen.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

Wir waren dieses Jahr erneut auf der Head in the Cloud von mittwald in Espelkamp unterwegs und haben dort mit Torben Mallwitz über einen Vortrag gesprochen, den man so vermutlich nur selten auf einer Konferenz hört. Torben, CTO von guenstiger.de, hat sehr offen darüber berichtet, wie das Unternehmen im April 2025 Opfer eines Ransomware-Angriffs wurde und welche technischen, organisatorischen und menschlichen Herausforderungen die folgenden Tage und Wochen geprägt haben.

Torben beschreibt sehr eindrücklich, wie professionell die hinter der Qilin-Ransomware stehende Organisation arbeitet. Ransomware wird mittlerweile als „Ransomware as a Service“ betrieben. Die Angreifer agieren wie ein Unternehmen mit klaren Strukturen, Support, Hierarchien und sogar Partnerprogrammen. Die Kommunikation läuft über ein Chatfenster im Darknet und fühlt sich, von der kriminellen Komponente abgesehen, erstaunlich ähnlich zu einer gewöhnlichen Geschäftsbeziehung an.

Für guenstiger.de war schnell klar, dass externe Hilfe benötigt wird. Noch am ersten Tag wurden Spezialisten für Incident Response und Forensik hinzugezogen, die bei der Analyse, der Verhandlung mit den Angreifern und der Wiederherstellung der Systeme unterstützten. Ein wichtiges Learning aus dem Vorfall: In einer solchen Situation sollte man nicht versuchen, alles selbst zu lösen. Die emotionale Belastung und die Vielzahl der gleichzeitig auftretenden Probleme machen einen kühlen Blick auf die Lage nahezu unmöglich.

Besonders spannend ist die wirtschaftliche Perspektive, die Torben auf das Thema einnimmt. Die Entscheidung, Lösegeld zu zahlen, wurde nicht aus Panik getroffen, sondern als nüchterne Business-Entscheidung. Der Zeitgewinn bei der Wiederherstellung der Systeme und die Bedeutung eines möglichst geringen Vertrauensverlusts gegenüber Kunden und Partnern überwogen letztlich die Alternative, alles ausschließlich aus Backups und manuellen Prozessen wieder aufzubauen.

Überraschend ist auch die Professionalität der Angreifer nach der Zahlung. Als die bereitgestellten Entschlüsselungswerkzeuge nicht überall funktionierten, gab es tatsächlich Support und Nachbesserungen. Das mag zunächst absurd wirken, folgt aber einer internen Logik: Das Geschäftsmodell der Erpresser basiert darauf, dass sich herumspricht, dass nach einer Zahlung auch tatsächlich geliefert wird.

Natürlich blieb es nicht bei der Wiederherstellung. Der Vorfall wurde genutzt, um die eigene Infrastruktur grundlegend zu modernisieren. Neue Sicherheitsmaßnahmen, Multi-Faktor-Authentifizierung, stärker zentral verwaltete Geräte und eine überarbeitete Systemarchitektur sollen zukünftige Angriffe erschweren. Daneben setzt das Team inzwischen verstärkt auf Notfallübungen und Planspiele, um im Ernstfall schneller und koordinierter reagieren zu können.

Ein zentrales Fazit des Gesprächs lautet dabei: Absolute Sicherheit gibt es nicht. Moderne IT-Systeme sind zu komplex und die Angriffsvektoren zu vielfältig. Ziel kann daher nur sein, die eigenen Systeme möglichst widerstandsfähig und als Angriffsziel möglichst unattraktiv zu machen.

Das Video zum Talk wird zeitnah auf dem YouTube Kanal von Mittwald verfügbar sein.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/