Working Draft

By Vanessa Otto, Peter Kröner, Hans Christian Reinl, Stefan Baumgartner, Christian »Schepp« SchaeferNews Technology Education How To Tech News

Working Draft episodes

April 28 Revision 710: React- & TypeScript-Glücksrad, mit Hans-Christian Otto
Wir spielen wieder Glücksrad und lassen uns durch eine bunte Mischung aus React- und TypeScript-Themen treiben. Mit dabei sind diesmal Stefan, Peter und Hans-Christian Otto und wie schon beim letzten Mal zeigt sich schnell: Ein einzelnes Thema reicht locker für eine halbe Stunde Diskussion.
Wir hangeln uns vom React-Compiler über TypeScript Assertion Signatures bis hin zu useState und verlieren uns dabei genüsslich in Details, Meinungen und Abschweifungen zu Compilern, CDNs und Programmierparadigmen.
Shownotes
[00:02:13] React Compiler
Der React Compiler wird als neue Möglichkeit diskutiert, Performance-Optimierungen automatisch durch statische Analyse vorzunehmen. Statt manuell useMemo, useCallback oder React.memo einzusetzen, soll der Compiler diese Optimierungen eigenständig einfügen. Dabei steht weniger die tatsächliche Performance im Vordergrund als vielmehr die Reduktion von Boilerplate und die Verbesserung der Lesbarkeit von Komponenten.
Gleichzeitig wird kritisch hinterfragt, wie sinnvoll diese automatischen Optimierungen sind, da Memoization selbst Kosten verursacht und in vielen Fällen kaum messbare Vorteile bringt. Zudem kann der Compiler problematisch werden, wenn Code nicht den üblichen React-Konventionen folgt und dadurch unerwartete Bugs entstehen.
Ein weiterer Diskussionspunkt ist die grundsätzliche Rolle von Compile-Schritten im JavaScript-Ökosystem. Während Compiler-Optimierungen etabliert sind, wird auch kritisiert, dass Bundling und ähnliche Techniken moderne Browserfähigkeiten wie deduplizierte Ressourcen oder modulare Nutzung aushebeln können. In diesem Zusammenhang wird auch nostalgisch auf frühere CDN-Modelle geblickt, bei denen Bibliotheken zentral geladen wurden, mit allen Vor- und Nachteilen bezüglich Performance, Sicherheit und Kontrolle.
[00:29:36] TypeScript Assertion Signatures
Assertion Signatures sind ein TypeScript-Feature, mit dem sich der Typ eines Wertes nach einem Funktionsaufruf verändern lässt, ohne dass die Funktion selbst einen Rückgabewert liefern muss. Ähnlich wie bei Type Predicates wird dem TypeScript-Compiler signalisiert, dass ein Wert nach erfolgreichem Durchlauf einer Funktion einen engeren Typ besitzt.
Typische Anwendungsfälle sind Assertions wie in Testframeworks oder Validierungsfunktionen, bei denen im Fehlerfall eine Exception geworfen wird. Nach erfolgreichem Durchlauf kann der Code davon ausgehen, dass bestimmte Bedingungen erfüllt sind.
Die Diskussion zeigt aber auch Schwächen in der TypeScript-Dokumentation auf: Manche Features sind schwer auffindbar oder nur in Release Notes dokumentiert. Zudem wird darauf hingewiesen, dass Keywords wie is oder asserts besondere Aufmerksamkeit erfordern, da sie direkten Einfluss auf das Typsystem nehmen.
Neben der eigentlichen Funktionalität wird auch über die Komplexität des TypeScript-Ökosystems gesprochen, etwa beim Schreiben eigener Parser oder beim Umgang mit nicht vollständig dokumentierten Sprachfeatures.
[00:51:01] React useState
useState wird als grundlegender Mechanismus beschrieben, um Zustand in funktionalen React-Komponenten zu speichern. Da Komponenten bei jedem Render neu ausgeführt werden, ermöglicht useState das Persistieren von Werten zwischen Renderings.
Die Diskussion zeigt jedoch deutliche Kritik an der API: Die Syntax wird als umständlich empfunden, insbesondere bei komplexeren Zuständen oder wenn Werte voneinander abhängen. Auch typische Fehlerquellen wie asynchrone Updates oder falsche Nutzung beim Ableiten neuer Zustände werden thematisiert.
Ein wiederkehrendes Problem ist, dass viele Entwickler useState verwenden, um Werte zu speichern, die eigentlich nur aus anderen Zuständen berechnet werden sollten. Das führt zu unnötigen Re-Renders und erhöht die Komplexität.
Darüber hinaus wird useState im Kontext von Programmierparadigmen diskutiert. Während React stark funktional geprägt ist, kommen viele Entwickler aus objektorientierten Hintergründen und erwarten andere Modelle, etwa Klassen mit Properties. Diese Diskrepanz führt häufig zu Missverständnissen und erschwert den Einstieg.
Gleichzeitig wird anerkannt, dass React durch seine Architektur Vorteile für zukünftige Konzepte wie paralleles Rendering bietet, auch wenn diese in der Praxis bisher selten eine Rolle spielen.
Links
React Compiler
Offizielle Einführung in den React Compiler und seine Ziele zur automatischen Optimierung.
TypeScript 3.7 Release Notes
Release Notes, in denen Assertion Signatures ursprünglich eingeführt wurden.
useState
Dokumentation zum React Hook für lokalen Zustand in funktionalen Komponenten.
Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/
1 hr 21 min
April 21 Revision 709: HTTP/3 und WebTransport, mit Max Inden
Diese Woche ist Max Inden (Mastodon) von Mozilla zu Gast. Mit ihm sprechen wir über den Networking-Stack von Firefox und arbeiten uns dabei von HTTP/1 über HTTP/2 bis zu HTTP/3 und QUIC vor. Ausgangspunkt ist die Frage, warum es nach den Versprechen von HTTP/2 überhaupt noch eine weitere HTTP-Version brauchte und welche praktischen Probleme im echten Netz dabei eine Rolle spielen.
Unser Sponsor
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
Dabei geht es nicht nur um schnellere Verbindungen, sondern auch um Dinge wie Head-of-Line-Blocking, Connection-Setup, Congestion Control, Connection Migration sowie um angrenzende Themen wie verschlüsseltes DNS, Encrypted Client Hello und WebTransport. Die Folge bleibt dabei bewusst nah an den Grundlagen und erklärt, warum viele Eigenschaften des heutigen Web-Stack genau so aussehen, wie sie aussehen.
Shownotes
[00:00:56] HTTP/3 und WebTransport
Max stellt zunächst seinen Hintergrund als Networking-Ingenieur bei Mozilla vor und beschreibt seine Arbeit am Firefox-Netzwerkstack mit Fokus auf QUIC, HTTP/3 und verwandte Technologien. Ausgangspunkt der Diskussion ist die Entwicklung von HTTP: Während HTTP/1 durch parallele TCP-Verbindungen und deren Limitierungen geprägt war, brachte HTTP/2 mit Multiplexing, Header-Compression und Server Push deutliche Verbesserungen. In der Praxis zeigten sich jedoch neue Probleme, insbesondere durch die Abhängigkeit von TCP.
Ein zentrales Thema ist das sogenannte Head-of-Line-Blocking: Wenn auf TCP-Ebene ein Paket verloren geht, blockiert dies potenziell alle nachfolgenden Daten – selbst wenn diese eigentlich unabhängig wären. Dadurch entstehen Latenzen, die besonders im Web-Kontext mit vielen kleinen Requests spürbar sind. Auch der Verbindungsaufbau ist ein Thema: Zwischen TCP-Handshake, TLS-Handshake und dem eigentlichen Request vergehen mehrere Roundtrips, was sich summiert.
QUIC setzt genau hier an und wird als neues Transportprotokoll über UDP realisiert. Es übernimmt die Vorteile von TCP wie Zuverlässigkeit und Congestion Control, erlaubt aber gleichzeitig mehrere unabhängige Streams ohne transportseitiges Head-of-Line-Blocking. Zusätzlich führt QUIC Datagrams ein, also bewusst unzuverlässige, unabhängige Nachrichten, die sich besonders für latenzkritische Anwendungsfälle wie Echtzeitkommunikation eignen.
Ein weiterer Vorteil ist der reduzierte Verbindungsaufbau: QUIC kombiniert Transport- und Sicherheitsschicht, sodass statt mehrerer Roundtrips nur noch einer nötig ist (One-RTT), und bei wiederholten Verbindungen sogar Zero-RTT möglich wird. Außerdem ermöglicht QUIC durch eine eigene Connection-ID sogenannte Connection Migration, wodurch Verbindungen auch bei IP-Wechsel stabil bleiben können.
Darüber hinaus sprechen wir über angrenzende Entwicklungen im modernen Networking-Stack. Dazu gehört HTTP/3 als Protokoll, das auf QUIC aufsetzt, sowie Themen wie DNS over HTTPS, das DNS-Anfragen verschlüsselt, und Encrypted Client Hello, das verhindert, dass der Ziel-Hostname bereits im TLS-Handshake sichtbar ist.
Zum Abschluss werfen wir einen Blick auf WebTransport, eine moderne Alternative zu WebSockets, die auf HTTP/3 aufbaut und sowohl Streams als auch Datagrams zur Verfügung stellt. Damit eröffnen sich neue Möglichkeiten für Echtzeit- und Streaming-Anwendungen im Web.
Links
Firefox Public Data Report
Der Firefox Public Data Report bietet öffentlich zugängliche, aggregierte Telemetriedaten aus Firefox, die Einblicke in Nutzung, Performance und technische Eigenschaften des Webs geben.
Max‘ FOSDEM 2026 Talks
Vorträge von Max Inden auf der FOSDEM 2026 rund um QUIC, HTTP/3 und moderne Netzwerktechnologien.
Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/
1 hr 40 min
April 14 Revision 708: Temporal, mit Philipp Dunkel
Diese Woche haben wir Philipp Dunkel (Bluesky) zu Gast und sprechen mit ihm über Temporal, also die neue JavaScript-API für Datum, Uhrzeit, Zeitspannen und Zeitzonen. Aufhänger ist ein Vortrag von Jason Williams auf der State of the Browser, von dem aus wir in die Geschichte, die Designprinzipien und die praktische Modellierung von Zeit in JavaScript einsteigen.
Unser Sponsor
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
Dabei geht es nicht nur um einen Ersatz für das alte Date-Objekt, sondern auch um die lange Vorgeschichte mit Libraries wie Moment.js, Luxon und date-fns, um die Rolle von Intl und ECMA 402 sowie um die vielen politischen, technischen und semantischen Fallstricke, die bei Datum und Uhrzeit eben dranhängen.
Shownotes
[00:00:54] Temporal
Temporal ist ein neuer API-Komplex für Datum, Uhrzeit, Zeitpunkte, Intervalle und Zeitzonen in JavaScript. Dabei soll es nicht einfach nur ein „besseres Date“ sein. Das bisherige Date-Objekt wird als historisch gewachsener Fehlgriff gesehen, der auf einem frühen, aus Java übernommenen Modell basiert und bis heute viele Probleme mit sich herumschleppt. In der Praxis führte das dazu, dass Entwicklerinnen und Entwickler auf Libraries wie Moment.js, Luxon und date-fns ausweichen mussten. Gerade diese Erfahrungen aus der Library-Welt sind aber in Temporal eingeflossen: Die Maintainer und Champions rund um das Proposal, darunter auch Maggie Johnson-Pint, haben über Jahre hinweg versucht, das Thema Zeit in JavaScript endlich semantisch sauber modellierbar zu machen.Ein zentraler Punkt ist dabei, dass Temporal unterschiedliche Konzepte nicht mehr in ein einziges Universalobjekt presst. Stattdessen gibt es getrennte Typen für das, was wir im Alltag tatsächlich unterscheiden: PlainTime für reine Uhrzeiten, PlainDate für reine Kalenderdaten, PlainDateTime für Datum plus Uhrzeit ohne Zeitzone, MonthDay für wiederkehrende Datumsangaben wie Weihnachten, YearMonth für Monatsangaben und Instant für einen exakten Zeitpunkt auf der Zeitachse. Dazwischen vermittelt ZonedDateTime, das einen Zeitpunkt mit einer Zeitzone verbindet. Dazu kommen Duration und weitere Objekte für Zeitspannen und Berechnungen. Genau diese explizite Trennung ist laut Philipp der eigentliche Fortschritt: Wenn Daten semantisch korrekt modelliert werden, wird auch der Umgang damit sehr viel robuster.
Im weiteren Verlauf geht es um die vielen Randbedingungen, die bei Datums- und Zeitverarbeitung eben nicht bloß technische Details sind. Zeitzonen, Sommer- und Winterzeit, regionale Sonderfälle, politische Entscheidungen und kurzfristige Änderungen machen das Thema notorisch kompliziert. Philipp nennt dafür Beispiele wie Marokko mit Ramadan-bedingten Anpassungen, historische Sonderfälle in Großbritannien oder abweichende Regelungen innerhalb einzelner Länder. Genau deshalb orientiert sich Temporal konsequent an bestehenden Standards und Datenquellen, statt neue Konventionen zu erfinden. Für Zeitzonen wird das IANA-Schema verwendet, für Datums- und Zeitstrings ISO 8601, und die enge Zusammenarbeit mit Intl beziehungsweise ECMA 402 (ECMAScript® internationalization API specification) war ein wichtiger Teil der Arbeit.
Besonders spannend ist die Schilderung des langen Standardisierungswegs. Über neun Jahre hinweg wurde nicht nur am API-Design gearbeitet, sondern auch an Interoperabilität, Spezifikationstext, Tests und Implementierungen. Ein wichtiger Baustein war dabei, die IANA-Zeitzonen-Notation überhaupt in einen relevanten Standardkontext zu bringen, damit sie sauber in Temporal verwendet werden kann. Philipp beschreibt außerdem die lange Stage-3-Phase, in der von außen wenig sichtbar war, intern aber Implementierungen in Browser-Engines und Projekten wie temporal_rs vorangetrieben wurden.
Zu guter Letzt sprechen wir noch über die API-Gestaltung selbst. Dazu gehören die bewussten Namensentscheidungen wie das Präfixe Plain und Zoned, die Immutability aller Objekte, die Vermeidung von versteckten Seiteneffekten und der Anspruch, sinnvolle Defaults zu liefern, ohne Spezialfälle unmöglich zu machen. Gerade bei Rechenoperationen rund um Sommerzeitwechsel oder Monatsarithmetik zeigt sich, warum Temporal so differenziert ist: Es gibt oft nicht die eine „richtige“ Antwort, sondern unterschiedliche fachlich sinnvolle Interpretationen. Temporal soll diese Fälle nicht kaschieren, sondern kontrollierbar machen. Zum Schluss spekulieren wir noch darüber, wie gut sich die API in der Praxis durchsetzt, ob Adapter für bestehende Libraries sinnvoll wären und wann der Punkt erreicht sein wird, an dem man die bisherigen Datumsbibliotheken endgültig hinter sich lassen kann.
Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/
57 min
April 07 Revision 707: ARIA-Glücksrad, die Dritte
Wir spielen mal wieder ARIA-Glücksrad und haben uns dafür mit Paweł Masarczyk (Mastodon), Peter Krautzberger (LinkedIn / Mastodon) und Marco Bretschneider (Mastodon) in bekannter Runde zusammengefunden. Daniela Kubesch musste diesmal krankheitsbedingt leider aussetzen 😥. Wir bedienen erneut unseren Zufallsgenerator, das „Glücksrad“, welches uns verschiedene ARIA-Properties ausspuckt, über die wir aus Sicht von Spezifikation, Implementierung und praktischer Nutzung mit assistiven Technologien sprechen.
Event-Tipp
Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €.
Alle Infos gibt’s auf beyondtellerrand.com
Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen!
Dabei geht es weniger um trockene Attributkunde als um die Frage, was von den ARIA-Versprechen im Alltag tatsächlich bei Screenreadern und Browsern ankommt. Wir streifen typische Einsatzfälle, problematische Altlasten, offene Support-Lücken und die Unterschiede zwischen dem, was in Spezifikationen steht, was Browser daraus machen und was bei Nutzerinnen und Nutzern schließlich wirklich nutzbar ist.
Shownotes
[00:05:05] aria-selected
Zum Einstieg landen wir bei aria-selected und sprechen darüber, wo dieser Zustand überhaupt erlaubt ist, etwa bei Optionen, Tabs, Grid-Zellen oder Tree-Items. Dabei geht es unter anderem um Mehrfachauswahl in komplexeren Widgets, um den Unterschied zwischen Fokus und Auswahl sowie um die Frage, warum ARIA hier neben true und false auch noch den Zustand undefined kennt.
[00:17:22] aria-level
Danach schauen wir uns aria-level an. Das Attribut kennen viele vor allem im Zusammenhang mit selbstgebauten Überschriften, also etwa bei Elementen mit role="heading", aber es spielt auch in Baumstrukturen, Kommentarhierarchien und ähnlichen Konstruktionen eine Rolle. Wir sprechen über Heading-Level jenseits von HTMLs sechs Überschriftsebenen, über Unterschiede zwischen Browsern und Screenreadern und über aktuelle Arbeiten rund um tiefere Überschriftenstrukturen, einschließlich der Diskussion um neue HTML-Mechanismen wie im WHATWG-Issue zu Heading Offsets.
[00:28:14] aria-owns und ariaOwnsElements
Von dort aus geht es zu aria-owns und der zugehörigen DOM-API ariaOwnsElements. Wir erklären, dass damit der Accessibility-Tree umgebaut werden kann, indem Inhalte semantisch an eine andere Stelle gezogen werden als im DOM. Genau das macht das Attribut mächtig, aber auch fehleranfällig. Entsprechend diskutieren wir die Risiken, verweisen auf die bekannte Kritik an aria-owns und kommen auch auf Konfliktauflösung bei widersprüchlicher Semantik zu sprechen, etwa im Zusammenspiel mit role="presentation", role="none" oder aria-hidden. In diesem Zusammenhang erwähnen wir auch den Beitrag von Manuel Matuzović zu präsentationalen SVGs, in dem es um aria-hidden="true" als robustere Lösung geht.
[00:42:39] aria-disabled
Mit aria-disabled wird es scheinbar einfacher, aber auch hier zeigt sich schnell, dass die Praxis komplizierter ist. Wir sprechen darüber, warum viele Teams lieber das native HTML-disabled nutzen, warum aria-disabled allein nur ein Signal für assistive Technologien ist und keinerlei Funktionalität automatisch abschaltet, und wie sich das auf Fokusreihenfolge, Tastaturbedienung und Screenreader-Ansagen auswirkt. Dabei kommt auch zur Sprache, wie sich deaktivierte Elemente im Browse-Modus und im Formularmodus von Screenreadern unterschiedlich verhalten und warum man bei selbstgebauten Widgets zusätzliche Logik mit JavaScript und oft auch CSS ergänzen muss.
[00:57:20] aria-controls und ariaControlsElements
Ein längerer Block dreht sich um aria-controls und die dazugehörige DOM-API ariaControlsElements. Wir diskutieren den ursprünglichen Gedanken dahinter, nämlich Beziehungen zwischen steuernden und gesteuerten Elementen explizit zu machen, etwa in komplexen Formularen, Menüs oder Tabellen-Interfaces. Gleichzeitig wird deutlich, dass die tatsächliche Unterstützung in Screenreadern dünn ist und dass unklar bleibt, wie Nutzerinnen und Nutzer sinnvoll zwischen solchen verknüpften Elementen navigieren sollen. Im Gespräch fallen dazu auch andere ARIA-Mechanismen wie aria-expanded, aria-describedby, aria-description und aria-details.
[01:00:32] Support-Realität von Browsern, Screenreadern und Testprojekten
Ausgehend von aria-controls sprechen wir grundsätzlicher über die Lücke zwischen Spezifikation und tatsächlicher Unterstützung. Dabei kommen Unterstützungsmatrizen und Testprojekte wie a11ysupport.io, AT-Driver, Tetralogicals HTML-Support-Projekt und WebAIM zur Sprache. Außerdem geht es um praktische Tests mit Screenreadern wie JAWS und um den Wert von Open-Source-Projekten wie NVDA, bei denen Verbesserungen durch Beiträge aus der Community direkt möglich sind.
[01:15:20] KI, Agenten und Semantik im Web
Am Rand streifen wir auch die Frage, wie agentische Browser und KI-Systeme künftig auf Semantik zugreifen könnten. Dazu fällt der Blick auf WebMCP und auf die Sorge, dass ARIA von manchen Systemen überinterpretiert werden könnte. Als Aufhänger dazu wird Adrian Rosellis Kritik an OpenAI, ARIA und SEO erwähnt.
[01:22:33] aria-orientation
Zum Schluss erwischen wir noch aria-orientation. Hier geht es um die Ausrichtung von Widgets wie Slidern, Scrollbars oder Tablisten und darum, ob vertikale oder horizontale Bedienmuster gegenüber Nutzerinnen und Nutzern kommuniziert werden sollten. Dabei kommen fehlende oder lückenhafte Unterstützung in Screenreadern, Standardannahmen bei der Tastaturbedienung und native HTML-Parallelen wie orient bei zur Sprache.
Links
Revisionen 683 und 699
Unsere vorangegangenen ARIA-Glücksrad-Runden.
Invoker Commands API
Die API fällt im Zusammenhang mit der Frage, ob neue HTML-Mechanismen Beziehungen wie bei aria-controls künftig nativer abbilden könnten.
Visually Hidden Content and the Clip Path Hack
Der Artikel ergänzt den allgemeinen Accessibility-Kontext der Folge.
Bad UI
Eine Sammlung absichtlich schlecht gestalteter Formulareingaben, die typische UX- und Accessibility-Probleme greifbar und erlebbar machen.
User Inyerface
Ein interaktives Spiel, das Nutzerinnen und Nutzer durch einen frustrierenden Dark-Pattern-Flow schickt und dabei schlechte UX-Praktiken überspitzt demonstriert.
Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/
1 hr 40 min
March 31 Revision 706: v0 und Vercel, mit Leo Reuter
In dieser Revision sprechen wir mit Leo Reuter von Vercel (LinkedIn / E-Mail) über den Wandel von Deployment- und Hosting-Plattformen hin zu AI-gestützten Entwicklungswerkzeugen.
Unser Sponsor
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
Ausgangspunkt ist dabei unsere bisherige Beschäftigung mit Vibe Coding und der Frage, wie sich solche Werkzeuge in reale Entwicklungsprozesse einfügen, statt nur schnelle Demos und Prototypen zu erzeugen.
Gemeinsam schauen wir uns an, wo v0 heute steht, wie sich das Tool von einem Generator für einzelne React-Komponenten zu einem System für komplette Anwendungen entwickelt hat und warum Themen wie bestehende Codebasen, Designsysteme, Branch-Workflows und Skills inzwischen wichtiger sind als das bloße Erzeugen von UI aus natürlicher Sprache.
[00:02:48] v0 und Vercel
Leo stellt zunächst seinen Weg vom Frontend-Engineering über langfristige Projektarbeit bis zu seiner Rolle als Solution Architect bei Vercel vor. Von dort aus steigen wir in die Geschichte von Next.js und Vercel ein: Ausgangspunkt war der Wunsch nach mehr Guardrails im React-Ökosystem, etwa für Routing und Framework-Konventionen, und später die Frage, wie sich solche Anwendungen ohne den üblichen DevOps-Aufwand produktionsreif deployen lassen. Wir sprechen darüber, wie Vercel genau diese Lücke gegenüber klassischen Hyperscalern geschlossen hat und warum schnelle Rollbacks, Preview-Deployments und einfache Infrastruktur bis heute ein wichtiges Argument sind.
[00:09:12] Von Komponenten zu kompletten Anwendungen
Danach geht es um die AI-Produkte rund um Vercel und vor allem um v0. Leo beschreibt, wie intern zunächst mit frühen GPT-Modellen experimentiert wurde, um einzelne Komponenten zu erzeugen, und wie daraus Schritt für Schritt ein Tool entstand, das heute komplette Full-Stack-Anwendungen aus natürlicher Sprache erzeugen kann. Wir diskutieren, was inzwischen alles möglich ist, von Rapid Prototyping über Datenbank- und Payment-Anbindungen bis hin zu realistischen Produktideen, und wo die Grenze zwischen schneller Visualisierung und belastbarer Software verläuft.
[00:12:50] Vom Prototyp zur produktiven Anwendung
Ein Schwerpunkt der Folge ist die Frage, was „production-ready“ in diesem Kontext überhaupt bedeutet. Leo erklärt, dass v0 lange vor allem für schnelles Prototyping genutzt wurde, der Übergang in produktive Systeme aber oft daran scheiterte, dass Designsysteme, Komponenten oder der eigentliche Tech-Stack nicht übereinstimmten. Genau deshalb spielt der Git-Import inzwischen eine so große Rolle: Bestehende Projekte lassen sich in v0 laden, dort bearbeiten und über Branches und Pull Requests wieder in den normalen Entwicklungsprozess zurückführen. Wir vergleichen diesen Browser-zentrierten Ansatz mit lokalen AI-Coding-Tools und arbeiten heraus, warum v0 gerade für weniger technische Rollen interessant ist, die nicht erst lokale Entwicklungsumgebungen, Environment-Variablen und Build-Prozesse aufsetzen wollen.
[00:17:31] Architektur, Laufzeit und Tech-Stack-Fragen
Im weiteren Verlauf sprechen wir über die technische Architektur hinter v0. Leo beschreibt den Wechsel von einer browserbasierten Laufzeit hin zu Micro-VMs mit vollständiger Entwicklungsumgebung in einer Sandbox, was mehr Stabilität und vor allem mehr Offenheit gegenüber verschiedenen Frameworks ermöglichen soll. Damit wird v0 nicht nur für bestimmte Standard-Setups, sondern perspektivisch auch für andere bestehende Projekte interessanter. In diesem Zusammenhang reden wir auch darüber, warum sich im AI-Umfeld ein Stack aus TypeScript, React, Next.js und Tailwind CSS so stark durchgesetzt hat: Einerseits, weil Modelle mit Utility-Klassen direkt im Markup besser zurechtkommen, andererseits, weil genau dieser Stack in den öffentlichen Trainingsdaten besonders stark vertreten ist.
[00:25:52] Composite Models, Planning und Designsy steme
Außerdem werfen wir einen Blick darauf, wie v0 intern arbeitet. Leo erklärt, dass hinter v0 kein eigenes Foundation Model steckt, sondern ein Composite-Ansatz, bei dem verschiedene Modellteile zusammenspielen, darunter auch ein eigener Auto-Fixer für Korrekturen. Wir sprechen über agentisches Arbeiten, über Planning Modes und darüber, warum es gerade bei größeren Brownfield-Projekten sinnvoll ist, Features erst gemeinsam mit dem Tool zu planen, bevor Code erzeugt wird. Von dort aus landen wir fast zwangsläufig bei Designsystemen: Heute lassen sich in v0 bereits Themes und Tokens hinterlegen, künftig soll aber vor allem die Wiederverwendung echter Unternehmens-Komponenten deutlich besser werden. Genau das ist für größere Organisationen spannend, die bestehende Component Libraries zusammenbringen müssen und vermeiden wollen, dass AI-generierter Code zwar ähnlich aussieht, aber nicht auf den tatsächlich verwendeten UI-Bausteinen basiert.
[00:49:16] Skills, Demokratisierung und die Rolle von Entwicklerinnen und Entwicklern
Zum Ende der Folge geht es um Skills als wiederverwendbares Wissen für Agenten. Leo erklärt, wie Markdown-basierte Skills zusätzlichen Kontext bereitstellen können, ohne dauerhaft das gesamte Kontextfenster zu belegen, und wie sich damit Best Practices oder domänenspezifisches Wissen in Tools einspeisen lassen. Von dort aus diskutieren wir die größere Frage, was solche Werkzeuge für den Beruf bedeuten. Unsere gemeinsame Stoßrichtung ist dabei klar: Nur weil mehr Menschen Software erzeugen können, verschwindet Softwareentwicklung nicht. Vielmehr verschieben sich Anforderungen und Werkzeuge, ähnlich wie früher bei Browser-Hacks, Test-Setups oder Designsystemen. Wer sich mit den neuen Möglichkeiten auseinandersetzt, hat eher Vorteile, während Verweigerung gegenüber diesen Veränderungen langfristig problematischer sein dürfte als der Einstieg von Junior-Entwicklerinnen und -Entwicklern in eine AI-geprägte Arbeitswelt.
Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/
1 hr 5 min
March 24 Revision 705: Browser-News-Roundup
Nach rund 20 Wochen Pause haben wir uns mal wieder zusammengesetzt und durch die aktuellen Browser-Releases gewühlt. Diesmal haben uns vor allem Firefox und Safari angeschaut, während Chrome eher im Hintergrund mitlief.
Event-Tipp
Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €.
Alle Infos gibt’s auf beyondtellerrand.com
Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen!
Dabei sind wir über eine ganze Reihe spannender Neuerungen gestolpert – von großen CSS-Features über neue APIs bis hin zu kleineren, aber wichtigen Verbesserungen im Detail. Wir gehen die Highlights durch und diskutieren, was davon wirklich relevant ist und wo noch Fragen offen bleiben.
Schaunotizen
[00:03:39] Anchor Positioning wird interoperabel
Mit Anchor Positioning ist ein lange erwartetes CSS-Feature jetzt in allen Browsern angekommen. Es erlaubt, Elemente direkt relativ zu anderen Elementen zu positionieren – etwa für Popovers, Tooltips oder Dropdowns – ohne Wrapper-Hacks oder komplexes JavaScript. Der Browser übernimmt dabei auch das Umschalten von Positionen, wenn Inhalte am Viewport-Rand abgeschnitten würden. Besonders hilfreich ist der Artikel von Temani Afif, der typische Edge Cases beschreibt. Ergänzend verweisen wir auf einen Talk von Bramus van Damme, der sich ausführlich mit dem Feature beschäftigt.
[00:30:27] CSS Module Scripts in Firefox
Firefox unterstützt nun ebenfalls CSS Module Scripts, sodass Styles direkt über ECMAScript-Module importiert werden können. Das ermöglicht neue Patterns für komponentenbasiertes Arbeiten, etwa in Kombination mit adoptedStyleSheets. Gleichzeitig diskutieren wir die Auswirkungen auf Performance und Architektur, insbesondere bei hybriden Ansätzen wie „Islands of Reactivity“, wo klassische Stylesheets und modulbasierte Styles zusammenkommen.
[00:47:09] Navigation API und URL Pattern API
Die Navigation API ist jetzt auch in Firefox verfügbar und ersetzt die alte History API durch ein moderneres, eventbasiertes Modell. Navigationen können abgefangen, kontrolliert und mit eigenen Logiken versehen werden. Zusammen mit URL Pattern Matching entsteht so eine solide Grundlage für clientseitiges Routing ohne Frameworks. Die API ist Teil der Interop-Bemühungen, wie sie etwa im Interop 2026-Programm definiert sind.
[00:51:49] Customizable Select und neue Form Controls
Safari bringt Fortschritte bei anpassbaren Form-Controls. Das -Element lässt sich künftig über appearance: base-select komplett stylen. Ziel ist es, native Controls flexibler zu machen, ohne sie vollständig neu implementieren zu müssen. Dabei stellt sich auch die Frage, wie sich solche Anpassungen auf mobile Plattformen auswirken, wo bisher systemeigene UI-Komponenten dominieren.
[00:59:08] Iterator Helpers und neue JavaScript-APIs
Firefox implementiert neue Iterator-Methoden wie Iterator.zip() und Iterator.zipKeyed(). Diese arbeiten auf der Ebene von Iterables und Iterators und erlauben das Kombinieren unterschiedlicher Datenstrukturen wie Arrays, Sets oder NodeLists. Dabei wird deutlich, dass viele dieser APIs lazy arbeiten und andere Rückgabetypen liefern als klassische Array-Methoden, was ein Umdenken beim Umgang mit Daten erfordert.
[01:11:35] Streams, Transferables und Worker-Kommunikation
Safari erweitert seine Unterstützung für Streams deutlich: ReadableStreams sind jetzt asynchron iterierbar (for await...of), können mit Readable.from() erzeugt werden und sind als transferable Objekte nutzbar. Dadurch lassen sich Datenströme direkt an Web Worker übergeben, ohne komplexe postMessage-Protokolle bauen zu müssen.
[01:16:50] Popover, CloseWatcher und Dialog-Verhalten
Firefox ergänzt die Popover API um sogenannte Hints, die automatisch auf Basis von Nutzerverhalten erscheinen können. Zusätzlich gibt es mit dem CloseWatcher eine API, die plattformabhängige „Schließen“-Gesten abstrahiert. Ergänzend dazu erlaubt das closeby-Attribut bei Dialogen ein einheitliches Light-Dismiss-Verhalten.
[01:21:31] Neue CSS-Pseudo-Klassen und Units
Es gibt eine Reihe weiterer CSS-Erweiterungen: Die :heading-Pseudo-Klasse selektiert alle Heading-Elemente, während :open geöffnete Elemente anspricht. Zusätzlich unterstützt Firefox jetzt Root-Varianten klassischer Längeneinheiten wie rcap, rch, rex und ric.
[01:22:25] Weitere Verbesserungen und Fixes
Firefox behebt einen langjährigen Quirk rund um about:blank-Load-Events in iframes. Safari unterstützt jetzt Scroll Anchoring und bringt mit Zstandard-Kompression sowie Verbesserungen bei Streams und Kompression zusätzliche Performance-Features. Außerdem ist die Sanitizer API nun auch in Firefox verfügbar, die wir bereits in Revision 695 besprochen haben.
[01:30:27] WebGPU als moderner WebGL-Nachfolger
Mit WebGPU ist eine moderne API für GPU-Berechnungen jetzt auch in Safari angekommen. Im Gegensatz zu WebGL ist sie besser erweiterbar, unterstützt Multithreading und erlaubt neben Grafik auch allgemeine Berechnungen auf der GPU, etwa für Simulationen oder KI-Anwendungen.
Links
CSS Carousel als Theme Switcher
Experiment von Schepp, das moderne CSS-Features unorthodox kombiniert.
The Web We Want
Event rund um die Frage, wie wir das Web in Zukunft gestalten wollen.
CSS Articles
Sammlung von Artikeln von Temani Afif zu modernen CSS-Techniken.
Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/
1 hr 40 min
March 17 Revision 704: Der Tech-Stack des NABU, mit Eleonora Heiden und Christoph Wolff
Wir sprechen in dieser Folge mit Eleonora und Christoph (Mastodon) vom NABU darüber, wie digitale Infrastruktur in einer großen, föderal organisierten NGO funktioniert. Ausgangspunkt ist das NABU-Netz: ein Intranet mit zentralem Login, das Mitglieder und vor allem Ehrenamtliche mit Werkzeugen für Kommunikation, Weiterbildung, Zusammenarbeit und Webarbeit versorgt.
Event-Tipp
Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €.
Alle Infos gibt’s auf beyondtellerrand.com
Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen!
Im Mittelpunkt steht dabei der Webbaukasten für die vielen lokalen NABU-Gruppen. Wir schauen uns an, warum die bisherige Lösung auf Jimdo zwar lange gut funktioniert hat, inzwischen aber an Grenzen stößt, und wie der NABU den Auswahlprozess für ein neues CMS angeht: mit Anforderungsmatrix, Rückkopplung aus dem Support, Einbindung von Ehrenamtlichen und einer Menge Fragen rund um Authentifizierung, Corporate Design, Migration und langfristige Wartbarkeit.
Schaunotizen
Der Tech-Stack des NABU
Das NABU-Netz ist das zentrale Intranet des Verbands. Mitglieder können sich über einen gemeinsamen Login authentifizieren und erhalten darüber Zugriff auf verschiedene Werkzeuge, die die Verbandsarbeit unterstützen. Dazu gehören unter anderem ein Wiki auf Basis von BookStack, ein Chat mit Matrix und Element, eine E-Learning-Plattform sowie eine Cloud auf Basis von OpenCloud. Für die zentrale Authentifizierung und Rechtevergabe nutzt der NABU Keycloak, damit die verschiedenen Systeme trotz unterschiedlicher technischer Grundlagen mit einem einheitlichen Login zusammenarbeiten.
Die lokalen Gruppen des NABU arbeiten sehr eigenständig, brauchen aber trotzdem Werkzeuge, mit denen sich Websites und Druckprodukte in einem gemeinsamen Erscheinungsbild erstellen lassen. Der bestehende Webbaukasten auf Basis von Jimdo wurde ursprünglich gewählt, weil er mit seinem What-you-see-is-what-you-get-Ansatz für technische Laien gut nutzbar war. Über die Jahre sind jedoch immer mehr Sonderfälle, Designanpassungen und technische Nachrüstungen dazugekommen: JavaScript-Anpassungen für das Erscheinungsbild, manuelle HTML-Einbindungen, Cookie-Themen, fehlende Suchfunktion, problematische Statistiklösung und zusätzliche Kosten für Domains und E-Mail-Adressen. Dadurch ist aus einer einfachen Lösung ein System geworden, das für die gewachsene Komplexität des Verbands nur noch bedingt geeignet ist.
Für den Nachfolger des bisherigen Baukastens haben Eleonora und Christoph eine Anforderungsmatrix erstellt und verschiedene Systeme untersucht. In Betrachtung gezogen werden dabei unter anderem Drupal, Directus, Kirby, Wagtail und WordPress. Wichtig ist ihnen, dass das neue System sowohl für wenig technikaffine Ehrenamtliche zugänglich bleibt als auch fortgeschrittenen Nutzerinnen und Nutzern genug Möglichkeiten bietet. Gleichzeitig soll es sich an den NABU-Login anbinden lassen, über viele Jahre tragfähig sein und sich für hunderte Websites betreiben lassen. Besonders ausführlich sprechen wir über WordPress mit dem Gutenberg-Editor, über Beispiele wie den Wechsel beim CERN und über die Frage, wie sich ein langlebiges System bauen lässt, ohne sich von Plugins und Update-Zyklen abhängig zu machen.
Neben der CMS-Auswahl ist die Migration bestehender Inhalte ein zentrales Thema. Beim NABU liegen derzeit mehrere hundert Websites im bisherigen System, auf denen teils wichtige Informationen zu Projekten, Gruppen und Aktionen veröffentlicht sind. Genau hier zeigt sich ein weiterer Nachteil von Jimdo: Inhalte lassen sich nicht einfach per API exportieren, sondern müssten eher aufwendig herausgelöst oder gescrapet werden. Für den NABU ist deshalb entscheidend, dass ein neues System nicht nur bessere Redaktionsmöglichkeiten bietet, sondern auch den Umzug von Inhalten, Strukturen und idealerweise URLs so unterstützt, dass Gruppen nicht alles manuell neu aufbauen müssen.
Links
Greenpeace
Die Organisation dient als weiteres Beispiel für einen Website-Builder auf WordPress-Basis.
Planet4
Der von Greenpeace genutzte Website-Builder, auf den Christoph im Zusammenhang mit WordPress verweist.
Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/
57 min
March 11 Revision 703: Hörenden-Fragen – Progressive Enhancement, Bildformate und JavaScript Disposables
In dieser Revision beantworten wir Fragen aus der Hörerschaft. Wir, Peter und Schepp, haben uns einige Themen aus einer längeren Liste herausgepickt und diskutieren darüber, warum bestimmte Web-Techniken sich in der Praxis manchmal schwerer durchsetzen als man erwarten würde.
Event-Tipp
Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €.
Alle Infos gibt’s auf beyondtellerrand.com
Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen!
Dabei sprechen wir unter anderem über Progressive Enhancement, den aktuellen Stand moderner Bildformate im Web sowie eine neue JavaScript-Funktion für explizites Ressourcen-Management. Wie üblich schweifen wir dabei gelegentlich ab, schauen uns Implementation-Details an und versuchen herauszufinden, was davon im Alltag von Webentwickler:innen wirklich relevant ist.
Schaunotizen
[00:10:26] Warum wird Progressive Enhancement so selten genutzt?
Ausgangspunkt ist eine Frage von Tom: Wenn Progressive Enhancement theoretisch so sinnvoll ist, warum setzen viele Entwickler:innen neue Web-Features trotzdem erst ein, wenn sie in allen Browsern vollständig unterstützt werden? Wir diskutieren mögliche Gründe dafür. Ein Punkt ist sicherlich, dass viele Entwickler:innen neue Plattform-Features schlicht nicht wahrnehmen oder sie in ihrem Alltag keine große Rolle spielen. Wer hauptsächlich mit Frameworks arbeitet, wartet oft darauf, dass neue Features dort integriert werden, statt sie direkt zu nutzen.Ein anderer Faktor ist die Komplexität beim Testen: Progressive Enhancement bedeutet letztlich, mehrere mögliche Laufzeitumgebungen zu berücksichtigen. Man müsste also systematisch testen, wie sich eine Anwendung verhält, wenn einzelne Features fehlen – etwa in unterschiedlichen Browsern, auf verschiedenen Geräten oder unter speziellen Bedingungen wie deaktiviertem JavaScript. In der Praxis passiert das jedoch selten. Wir sprechen außerdem über mögliche Tools und Ideen, die solche Tests vereinfachen könnten.
[00:26:35] Welche Bildformate sollte man heute im Web verwenden?
Anschließend beschäftigen wir uns mit einer praktischen Performance-Frage: Welche Bildformate sind heute sinnvoll im Web? Klassische Formate wie JPEG oder PNG werden zunehmend von moderneren Alternativen abgelöst. Besonders relevant sind hier WebP und AVIF, die beide aus Videocodecs entstanden sind (VP- und AV1-Familie) und deutlich bessere Kompressionsraten bieten.Wir sprechen über Unterschiede bei Kompression, Decoding-Geschwindigkeit und praktischen Einsatzszenarien. Während AVIF häufig die bessere Kompression liefert, kann das Encoding deutlich rechenintensiver sein – insbesondere bei On-Demand-Bildgenerierung auf Servern. WebP ist in solchen Szenarien oft pragmatischer. Außerdem diskutieren wir progressive Bilddarstellung bei JPEG, Tricks für progressive Wahrnehmung sowie zukünftige Entwicklungen wie JPEG XL oder kommende Codecs wie AV2.
[00:58:56] Explicit Resource Management und using in JavaScript
Zum Abschluss schauen wir uns ein relativ neues Feature im JavaScript-Ökosystem an: explizites Ressourcen-Management über das using-Keyword. Dabei geht es darum, Objekte mit einer deterministischen Aufräumlogik zu versehen. Statt sich darauf zu verlassen, dass die Garbage Collection irgendwann Ressourcen freigibt, kann ein Objekt über Symbol.dispose oder Symbol.asyncDispose definieren, wie es aufgeräumt werden soll, sobald eine using-Variable ihren Scope verlässt.Das ist besonders interessant für Szenarien, in denen JavaScript-Objekte externe Ressourcen repräsentieren – etwa offene Dateien, Netzwerkverbindungen oder temporäre Dateien in Node.js. Wir sprechen außerdem über mögliche Edge Cases, darunter klassische „Use-after-free“-Probleme und darüber, wie man solche Situationen mit Proxies oder zusätzlicher Logik verhindern könnte.
Links
Progressive Enhancement
Grundprinzip der Webentwicklung, bei dem Anwendungen auch ohne neue Features funktionieren und zusätzliche Fähigkeiten nur dort genutzt werden, wo sie verfügbar sind.
HTML -Element
Ermöglicht es, unterschiedliche Bildformate oder Auflösungen abhängig vom Browser oder Device auszuliefern.
AVIF
Modernes Bildformat basierend auf dem AV1-Videocodec, das besonders gute Kompressionsraten für Webbilder bietet.
WebP
Von Google entwickeltes Bildformat mit Unterstützung für Transparenz und Animation sowie deutlich besserer Kompression als JPEG.
JPEG XL
Modernes JPEG-Nachfolgeformat mit besserer Kompression, Multithreading-Support und Kompatibilität zu klassischen JPEG-Bildern.
Explicit Resource Management Proposal
JavaScript-Proposal, das das using-Keyword sowie Symbol.dispose und Symbol.asyncDispose für deterministisches Ressourcen-Management einführt.
Squoosh
Web-App zum Vergleichen und Konvertieren von Bildformaten direkt im Browser, inklusive verschiedener Encoder und Qualitätsvergleiche.
Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/
1 hr 32 min
March 03 Revision 702: Das <geolocation>-Element, mit Thomas Steiner
In dieser Revision sprechen wir mit Thomas Steiner von Google über einen lange offenen Schmerzpunkt im Web: Permission-Dialoge. Ausgangspunkt ist das neue -Element, das Chrome eingeführt hat und das Permissions kontextueller, deklarativer und weniger fehleranfällig machen soll.
Event-Tipp
Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €.
Alle Infos gibt’s auf beyondtellerrand.com
Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen!
Dabei schauen wir zurück auf die Geschichte der Geolocation API, diskutieren Permission-Spam, Browser-Mitigations wie den „Blue Chip“ und werfen einen Blick auf PEPC (Page Embedded Permission Control) als ursprünglichen Ansatz. Außerdem geht es um UX, Security, Styling-Grenzen und die Frage, wie neue Webstandards sich in einer Welt voller Frameworks und KI-Generatoren durchsetzen können.
Schaunotizen
[00:01:42] Das -Element
Permissions im Web waren lange implizit oder API-getrieben: Wer etwa navigator.geolocation.getCurrentPosition() aufruft, triggert einen Browser-Dialog. Alternativ gibt es explizite Anfragen wie Notification.requestPermission(). Beide Varianten haben über die Jahre zu Permission-Spam, „Permission Fatigue“ und UX-Problemen geführt.
Ein früher Versuch zur Vereinheitlichung war navigator.permissions.request(), der jedoch nach Diskussionen im W3C Permissions Repository (Issue #83) wieder verworfen wurde. Stattdessen entstand bei der TPAC 2023 die Idee der Page Embedded Permission Control (PEPC): ein deklaratives -Element mit type-Attribut und optionalem type-ext für Details wie Präzision oder Constraints.
Daraus wurde schließlich ein spezialisierter Ansatz: Statt eines generischen Elements gibt es nun dedizierte Elemente wie . Chrome hat dieses Element mittlerweile geshipped (siehe Blogpost, Feature-Status auf ChromeStatus). Es kapselt nicht nur die Permission-Abfrage, sondern liefert direkt Positionsdaten – deklarativ und mit Events statt Callback-basierter Legacy-API.
UX-seitig bringt das neue Modell einige Änderungen: Der Dialog wird zentriert angezeigt, der Hintergrund kann abgedunkelt werden, und es gibt differenzierte Zustände („Allow on every visit“, „Allow this time“, „Continue not allowing“). Damit soll „Permission Regret“ reduziert werden – also das nachträgliche Bereuen einer Entscheidung.
Es gibt außerdem Styling-Regeln: Bestimmte CSS-Eigenschaften sind eingeschränkt, um Clickjacking oder visuelle Täuschung zu verhindern. Pseudo-Klassen wie :granted oder :invalid sowie Events wie onvalidationstatuschange, onpromptaction und onpromptdismiss ermöglichen dennoch eine Integration ins UI.
In der Standardisierungsdiskussion gab es unterschiedliche Positionen: WebKit und Mozilla äußerten zunächst Vorbehalte gegenüber dem generischen Permissions-Element. Mit dem fokussierten -Ansatz scheint sich die Lage zu entspannen; Mozilla signalisiert vorsichtige Zustimmung, während WebKit noch prüft.
Weitere Stichworte unseres Gesprächs sind die „Line of Death“ (Abgrenzung zwischen Web-Content und Browser-UI), User Activation (siehe User Activation in Chrome) sowie Browser-Mitigations gegen Spam, etwa ML-gestützte Heuristiken und der nicht-modale „Blue Chip“ bei Notification-Prompts (siehe Origin Trial zum Permission-Element und Best Practices).
Links
The HTML element
Vorstellung des neuen deklarativen Geolocation-Elements im Chrome-Entwicklerblog.
WICG/PEPC
Repository zur ursprünglichen Page Embedded Permission Control-Idee.
PEPC Issue #59
Diskussionen zur Weiterentwicklung und Aufsplittung des Permission-Ansatzes.
W3C Permissions Issue #83
Debatte zur Entfernung von navigator.permissions.request().
WebKit Standards Position (PEPC)
WebKits Einschätzung zum ursprünglichen Permissions-Element.
Mozilla Standards Position (PEPC)
Mozillas Positionierung zur deklarativen Permission-Kontrolle.
WebKit Kommentar zu Permission-Details
Diskussion zu UX- und Sicherheitsaspekten rund um Permission-Dialoge.
Mozilla Standards Position (Geolocation Element)
Aktuelle Diskussion zur Unterstützung des neuen Geolocation-Elements.
Permission Element Origin Trial
Erfahrungen und Erkenntnisse aus dem Origin Trial des ursprünglichen Permission-Elements.
Permissions Best Practices
Empfehlungen zum verantwortungsvollen Umgang mit Permissions im Web.
Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/
1 hr 24 min
February 24 Revision 701: Der Government Site Builder (GSB) – mit Daniel Fau
In dieser Folge sprechen wir mit Daniel Fau (CEO der TYPO3 GmbH) über den aktuellen Stand des Government Site Builder (GSB).
Event-Tipp
Noch nichts vor am 28. Februar? 👀
Bei der State of the Browser 2026 erwarten euch Talks zu CSS Anchor Positioning, Accessibility jenseits von Checkbox-Compliance, der Temporal API, Performance, minimalistischen Web-Erlebnissen und sogar einem 2D-Scroller-Spiel im Browser 🎮✨
👉 https://2026.stateofthebrowser.com
Remote-Ticket jetzt mit diesem Link zum halben Preis (£10): https://ti.to/lws/sotb2026/discount/Status_des_Browsers
Nachdem wir zuletzt vor allem über fehlende Ansprechpartner, 404-Links und Kommunikationshürden gestolpert sind, wollten wir genauer verstehen, wie GSB 11 technisch und organisatorisch aufgestellt ist.
[00:01:09] GSB 11: Standardisiertes TYPO3-CMS für die öffentliche Verwaltung
Der Government Site Builder (GSB) existiert seit 2003 und wurde ursprünglich vom Bundesverwaltungsamt (BVA) in Zusammenarbeit mit Materna entwickelt. Später übernahm die „Bundesstelle für Informationstechnik“ (BIT) Betrieb und Hosting, bevor diese Aufgaben 2016 im ITZBund gebündelt wurden. Mit GSB 11 erfolgt nun der strategische Wechsel auf TYPO3 als technische Basis.
Frühere Versuche wie GSB 10 setzten zwar auf Open-Source-Komponenten, blieben aber ohne echte Community-Anbindung. GSB 11 wird dagegen explizit als standardisiertes CMS auf TYPO3-Basis entwickelt – mit Fokus auf Sicherheit, Barrierefreiheit, Wartbarkeit und Automatisierung. Daniel verweist in diesem Zusammenhang auch auf Marktdaten wie den CMS Census, der TYPO3 insbesondere im Public-Sector-Umfeld stark positioniert.
Technisch liegt die Distribution auf OpenCoDE, der Open-Source-Plattform der öffentlichen Verwaltung. Das Projekt ist über die zugehörige GitLab-Instanz einsehbar; dort finden sich Distribution, Extensions sowie – seit 2025 – auch ein öffentlich verfügbares Default-Frontend. Releases erfolgen in regelmäßigen Zyklen, während die Roadmap transparent im Projekt hinterlegt ist.
Organisatorisch wurde GSB 11 in drei Losen ausgeschrieben: Produktentwicklung (Los 1), Betrieb (Los 2) und Migration/Relaunch (Los 3). Die Vergabe erfolgte im Rahmen des deutschen bzw. europäischen Ausschreibungsrechts (Kontext: TED – Tenders Electronic Daily, eVergabe). Das Gesamtvolumen liegt im dreistelligen Millionenbereich über mehrere Jahre – ein erheblicher Open-Source-Invest.
Für Bundesbehörden stehen sogenannte Mandantenentwicklungsoptionen (MEO) zur Verfügung: MEO 1 bedeutet weitgehend standardisierte Nutzung inklusive Hosting, Wartung und Sicherheitsprüfung (u. a. mit Bezug auf Prüfmechanismen im Umfeld des BSI), MEO 2 erlaubt weitergehende Anpassungen, bringt aber mehr Eigenverantwortung mit sich. Darüber hinaus bleibt das DIY-Modell möglich: Distribution herunterladen, selbst betreiben – Open Source eben.
Zielsetzung ist ein „One-for-All“-Ansatz im Sinne übergreifender Standardisierung (Kontext: IT-Planungsrat) statt individueller Neuentwicklung. Gleichzeitig diskutieren wir die Kommunikationsrealität rund um GSB 11: lange Vergabeprozesse, NDA-Sensibilität, vorsichtige öffentliche Aussagen – und die Frage, wie offen sich Open Source im öffentlichen Sektor anfühlen kann und sollte.

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