Wir setzen unsere Hörendenfragen aus Revision 703 [https://workingdraft.de/703/] fort und sprechen diesmal ausführlich über den Zustand von PWAs im Jahr 2026 sowie über die Frage, warum sich Browser gefühlt kaum noch weiterentwickeln. Dabei landen wir bei Install-Prompts, App-Stores, Browser-Engines, alternativen Suchmaschinen und der immer gleichen Chromium-Basis unter vielen modernen Browsern.

Außerdem diskutieren wir über neue Browser-Ideen wie den OpenAI Atlas Browser [https://chatgpt.com/de-DE/atlas/], schauen auf die Rolle von Projekten wie Electron [https://www.electronjs.org/] und Tauri [https://v2.tauri.app/] und fragen uns, ob echte Browser-Innovation heute überhaupt noch stattfindet oder ob sich das Web längst in einer Konsolidierungsphase befindet.

Shownotes

[00:05:36] The State of PWAs in 2026 [https://developer.chrome.com/blog/install-element-ot] Angestoßen durch die entsprechende Hörerfrage von Jan Gregor Emge-Triebel [https://jangregor.me/] und Søren Birkemeyer [https://annualbeta.com/] diskutieren wir, wie es Progressive Web Apps aktuell geht und warum sie trotz vieler technischer Fortschritte nie ganz den Durchbruch geschafft haben. Wir sprechen über Installierbarkeit, Browser-Chrome, fehlende Sichtbarkeit im Alltag und warum sich native App-Stores weiterhin als dominante Plattform behaupten.

Außerdem schauen wir auf neue Möglichkeiten wie das experimentelle <install>-Element [https://developer.chrome.com/blog/install-element-ot] von Chrome und Edge und diskutieren, ob bessere Install-Prompts oder integrierte App-Verzeichnisse PWAs langfristig helfen könnten. Dabei vergleichen wir PWAs auch mit Ansätzen wie Electron [https://www.electronjs.org/] und Tauri [https://v2.tauri.app/], die Webtechnologien in klassische Desktop-Anwendungen verpacken.

Auch Apples Verhältnis zu Web-Apps bleibt Thema. Wir sprechen über die jüngsten Entwicklungen rund um deklarative Push-Notifications in WebKit [https://webkit.org/blog/16535/meet-declarative-web-push/] und die Frage, wie ernst Plattformbetreiber das offene Web als App-Plattform tatsächlich nehmen.

[00:23:01] Browser-Innovation und die Chromium-Monokultur Im zweiten großen Themenblock sprechen wir über eine weitere Frage von Jan Gregor Emge-Triebel [https://jangregor.me/]: What happened to Browser-Innovation? Ausgangspunkt ist die Beobachtung, dass Browser heute zwar technisch leistungsfähig sind, sich ihre Interfaces und Konzepte aber nur noch langsam verändern.

Wir sprechen über neue Ideen wie den OpenAI Atlas Browser [https://chatgpt.com/de-DE/atlas/] und fragen uns, ob AI-gestützte Interfaces tatsächlich eine neue Browser-Generation einläuten könnten oder ob sich dahinter am Ende doch wieder nur Chromium verbirgt. Dazu passt auch unsere ältere Folge Revision 688: Browser-Engine-Diversity [https://workingdraft.de/688/], die wir erneut aufgreifen.

Danach geht es um alternative Browser und Suchmaschinen. Wir diskutieren die Wahrnehmung von Brave [https://brave.com/de/], den historischen Hintergrund von Vivaldi [https://vivaldi.com/de/] und die Rolle von Kagi [https://kagi.com/], unter anderem anhand eines Mastodon-Posts von Nileane [https://mastodon.social/@nileane@nileane.fr/116609418951205339] über die Plattform.

Außerdem schweifen wir kurz zu älteren Browser- und Präsentationsideen ab und erinnern uns an Peters HTML-basiertes Präsentationsframework Pik [https://www.peterkroener.de/pik7-ein-html5-praesentationsframework-fuer-nerds/]. Zum Schluss sprechen wir noch über den Essay Never Forgive Them [https://www.wheresyoured.at/never-forgive-them/] von Ed Citron und darüber, wie sich das Web und seine Plattformen in den letz

Revision 715: Hörendenfragen zu PWAs, Tailwind und Browsern

Wir sprechen mit Bastian Allgeier (Web [https://bastianallgeier.com/] / Mastodon [https://mastodon.social/@bastianallgeier] / Bluesky [https://bsky.app/profile/bastianallgeier.com] / LinkedIn [https://www.linkedin.com/in/bastianallgeier/]) darüber, wie sich Kirby [https://getkirby.com/] nach mehr als 14 Jahren weiterentwickelt und was es bedeutet, ein kommerzielles CMS langfristig zu pflegen. Dabei geht es um Verantwortung gegenüber Kundinnen, Kunden und Community, um Wartbarkeit, Refactoring und die Frage, warum Beständigkeit gerade in schnelllebigen Zeiten ein eigenes Feature ist.

Außerdem diskutieren wir, wie sich KI auf CMS-Entwicklung, Content-Workflows, Plugins, Support und Produktentscheidungen auswirkt. Bastian beschreibt, warum Kirby KI nicht als fest eingebautes Kernfeature behandelt, sondern weiterhin auf Offenheit, Erweiterbarkeit und Unabhängigkeit setzt.

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 [https://mittwald.de/workingdraft?ref=workingdraft.de]

Shownotes

[00:00:59] Kirby, KI und die Verantwortung langlebiger Software Bastian erzählt, wie aus einem Nebenprojekt für eigene Kundenprojekte nach und nach Kirby [https://getkirby.com/] wurde. Seit 2017 arbeitet er Vollzeit daran. Wir erinnern uns an frühere Besuche bei Working Draft, unter anderem Revision 592 [https://workingdraft.de/592/] zu zehn Jahren Kirby und Revision 167 [https://workingdraft.de/167/], sowie an Bastians Auftritt bei der Nightly Build [https://www.nightlybuild.de/].Ausgehend von einem Talk von Oliver Reichenstein [https://beyondtellerrand.com/events/dusseldorf-2026/speakers/oliver-reichenstein] über iA Writer [https://ia.net/de/writer] sprechen wir darüber, warum schnell erzeugte Software nicht dasselbe ist wie über Jahre gepflegte Software. Bastian betont, dass der eigentliche Aufwand oft erst nach dem ersten funktionierenden Prototyp beginnt: Wartung, Support, Weiterentwicklung, Migrationspfade, alte Abhängigkeiten und das Vertrauen der Nutzerinnen und Nutzer.

Ein großer Teil der Diskussion dreht sich um KI und sogenannte Vibe-Coding-Workflows. Bastian beobachtet, dass KI den Wechsel von anderen Systemen zu Kirby erleichtern kann, weil Migrationen schneller umsetzbar werden. Auch Plugins lassen sich heute leichter für spezifische Projekte bauen. Gleichzeitig entstehen neue Support-Probleme, wenn KI falschen Code erzeugt und Nutzerinnen und Nutzer die Fehler zunächst dem CMS zuschreiben.

Wir sprechen darüber, warum Kirbys dateibasierter Ansatz in dieser neuen Werkzeuglandschaft unerwartet gut funktioniert. Inhalte und Code liegen als Text vor, wodurch KI-Werkzeuge leichter Kontext erfassen können, ohne erst komplexe Datenbankzugriffe oder Schnittstellen zu benötigen. Kirby wird dabei weniger als klassisches Plug-and-Play-CMS beschrieben, sondern eher als flexibler Werkzeugkasten oder Klebersystem zwischen Website, Apps, Enterprise-Systemen und individuellen Workf

Revision 714: Kirby, KI und die Verantwortung langlebiger Software, mit Bastian
Allgeier

Wir drehen wieder am ARIA-Glücksrad [https://workingdraft.de/gluecksrad/] und sprechen mit Daniela [https://dnikub.dev/], Paweł [https://www.linkedin.com/in/pawe%C5%82-masarczyk-3a68b2117/] und Peter Krautzberger [https://www.peterkrautzberger.org/] über Rollen und Attribute, die man im Alltag teils nie sieht, teils besser nicht selbst nachbauen sollte. Dabei geht es um abstrakte Rollen, Menü-Patterns, deaktivierte Zustände, Dialoge, Präsentationswerkzeuge und einige ARIA-Fallen, die erst in Kombination mit Screenreadern richtig sichtbar werden. Diesmal müssen wir leider auf unser Runden-Mitglied Marco [https://www.linkedin.com/in/marco-bretschneider-norderstedt/] verzichten.

Shownotes

[00:02:33] ARIA Sectionhead Role [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/sectionhead_role] Die erste gezogene Rolle ist eine abstrakte ARIA-Rolle. sectionhead ist nicht für Autorinnen und Autoren gedacht, sondern dient innerhalb der ARIA-Ontologie als übergeordnete Rolle für Dinge, die den Kopf eines Bereichs bilden, etwa Headings, Column Header, Row Header oder Tabs. Laut Spezifikation sollen User Agents solche abstrakten Rollen nicht auf Accessibility APIs mappen, was sie für die praktische Arbeit eher zu einem Stolperstein beim Lernen macht. [00:08:04] ARIA Menuitemcheckbox Role [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/menuitemcheckbox_role] menuitemcheckbox passt in Menüs von Web-Apps, die sich an native Anwendungen annähern. Beispiele sind Menüleisten, Quick Settings und das Pattern aus den ARIA Authoring Practices für Menubars [https://www.w3.org/WAI/ARIA/apg/patterns/menubar/], etwa bei einem Texteditor, in dem Einträge wie Bold oder Italic direkt einen aktivierten Zustand haben können.

Paweł erzählt außerdem von QuentinC’s Playroom [https://www.qcsalon.net/de/], einer Plattform für Brett- und Kartenspiele für blinde Menschen, die Web-App-Patterns und ARIA-Rollen kreativ nutzt, um komplexe Spieloberflächen per Tastatur und Screenreader bedienbar zu machen.

[00:13:33] ARIA Disabled [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-disabled] aria-disabled kam schon in Revision 707 [https://workingdraft.de/707/] vor, wir beleuchten es aber noch einmal im Kontext bestimmter UI-Komponenten. Daniela bringt nämlich zwei Beispiele mit: einen Button mit Loading-, Success- und Fail-State sowie einen selbstgebauten Date Picker, in dem einzelne Tage nicht verfügbar sind.

Beim Date Picker stellt sich die Frage, ob nicht verfügbare Tage weiterhin per Pfeiltasten erreichbar sein sollten. Paweł plädiert dafür, sie im Grid sichtbar und erreichbar zu lassen, damit Screenreader-Nutzende die Struktur des Kalenders verstehen und nicht durch übersprungene Tage irritiert werden. Idealerweise sollte zusätzlich der Grund kommuniziert werden, etwa dass ein Datum nicht verfügbar oder bereits gebucht ist. Als Bezug dient das Date Picker Dialog Beispiel der ARIA Authoring Practices [https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/datepicker-dialog/].

[00:18:58] ARIA Radio Role [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/radio_role] Die radio-Rolle macht im Grunde das, was man erwartet, sollte aber möglichst nicht selbst nachgebaut werden, solange native Radio-Inputs funktionieren. Das Gespräch dreht sich schnell um Radio-Groups, die abhängig von der Auswahl weitere Formularfelder einblenden.

Paweł beschreibt ein Pattern, bei dem neue Felder im DOM direkt zwischen Radio-Optionen eingefügt werden. Bei kurzen Formularen kann das noch verständlich sein, bei längeren Abschnitten verliert ma

Revision 713: ARIA-Glücksrad – von Dialogen, Definitionen und Datepickern

We speak with Niels Leenheer [https://nielsleenheer.com/] about playful browser experiments, strange hardware, and why the web is still a great runtime for doing things it was never really designed for.

After a short recap of beyond tellerrand [https://beyondtellerrand.com/] Düsseldorf and Niels’ earlier appearances in Revision 273 [https://workingdraft.de/273/] and Revision 358 [https://workingdraft.de/358/], we dig into clocks, oscilloscopes, DMX lights, lasers, Doom, and a lot of CSS.

Shownotes

[00:03:08] HTML5 Test and old browser API experiments [https://html5test.com/] Niels introduces himself as a Dutch web developer who has been playing with the web since 1993. We talk about HTML5 Test [https://html5test.com/], a project that once gamified browser support for new HTML5 features and even influenced browser vendors to implement APIs they had not originally prioritized. Today the test is mostly obsolete, but that is also because HTML5 succeeded. [00:07:42] beyond tellerrand and creative web work We recap beyond tellerrand [https://beyondtellerrand.com/] Düsseldorf, where Niels gave a talk about his browser-based tinkering projects. The conversation also touches on the current AI-heavy mood in the industry, Oliver Reichenstein’s perspective on AI copycats, and why conferences like beyond tellerrand are valuable because they show creative, non-mainstream work that does not feel easily replaceable by AI-generated output. [00:14:56] Stubborn clocks, Raspberry Pi and physics Niels explains how he got interested in clocks through Vasilis and projects like the Diagon Clock [https://vasilis.nl/clocks/diagon-clock/23d/]. His own clock runs Chrome fullscreen on a round touchscreen attached to a Raspberry Pi. Instead of simply showing the correct time, it deliberately behaves badly: it misunderstands daylight saving time, forgets midnight, and keeps adding hours. Later, he added gravity using Box2D [https://box2d.org/] via box2d.js [https://github.com/kripken/box2d.js/], turning the clock hands into physical objects that can be flicked, dropped and bounced around. [00:20:56] Oscilloscope drawings with SVG, CSS and Web Audio Niels then describes how his obsession with clocks led him to an oscilloscope. Instead of drawing to a normal screen, he uses Web Audio to generate left and right channel signals that steer the oscilloscope beam on the X and Y axes. The shapes come from SVG: browser APIs such as path length and point sampling are used to turn SVG geometry into audio waves. CSS transforms add an extra challenge because the raw path coordinates need to be combined with transformation matrices. [00:37:26 ] DMX lights, smoke machines and WebUSB We talk about controlling stage hardware from the browser. Niels uses DMX [https://de.wikipedia.org/wiki/DMX_(Lichttechnik)], a protocol based on 512 values sent repeatedly to connected devices. With a USB-to-DMX dongle and WebUSB, a JavaScript array can be translated into packets that control lights, smoke machines and, in theory, a stage flamethrower. The browser is not replacing a classic driver here, but JavaScript acts as the converter between the web app and the device protocol. [00:38:18] Lasers, ILDA and Asteroids The laser project builds on the oscilloscope work. Niels wanted to draw with lasers, inspired by Seb Lee-Delisle’s Asteroids laser projector work [https://www.youtube.com/watch?v=FkHjG759ABY]. A USB dongle converts browser-generated coordinates into ILDA [https://de.wikipedia.org/wiki/International_Laser_Display_Association], the protocol understood by laser projectors. Because the oscilloscope project already generated X/Y coordinates, Niels

Revision 712: The Web Beyond the Edges of the Browser Window, with Niels
Leenheer

Wir sprechen darüber, wie man aktuelle Sprach- und Bildmodelle zu Hause betreiben kann, welche Hardware dafür realistisch ist und warum das Thema gerade zwischen Datenschutz, Kostenkontrolle und digitaler Souveränität interessant wird. Schepp erzählt von seinem Setup mit einem gebrauchten Mac Studio, LM Studio [https://lmstudio.ai/], ComfyUI [https://www.comfy.org/], lokalen Modellen und Open WebUI [https://openwebui.com/] als Weboberfläche für die Familie.

Dabei geht es nicht nur um die Technik, sondern auch um die Frage, wie nachhaltig die aktuellen Abo- und Credit-Modelle großer AI-Anbieter sind, wie viel RAM Modelle und Kontextfenster wirklich brauchen und wo lokale LLMs im Alltag schon nützlich sind.

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 [https://geenen-it-systeme.de/?src=workingdraft#podcast]

Shownotes

[00:01:01] LLMs zuhause betreiben Schepp berichtet von seinem Heim-Setup für lokale KI-Modelle: Ein gebrauchter Mac Studio mit M1 Max und 32 GB RAM läuft in der Rumpelkammer und hostet unter anderem ein Gemma [https://ai.google.dev/gemma/docs/core?hl=en]-Modell von Google, Bildgenerierung über ComfyUI [https://www.comfy.org/] und Open WebUI [https://openwebui.com/] als Weboberfläche, über die auch andere Familienmitglieder zugreifen können. Motivation ist weniger ein günstigerer oder besserer Ersatz für kommerzielle Dienste, sondern eher der Wunsch, bestimmte Daten nicht an externe Anbieter ausleiten zu müssen.

Technisch landet man schnell bei Speicherfragen: Modelle müssen in den RAM passen, und zusätzlich braucht das Kontextfenster eigenen Speicher. Schepp erklärt grob die Faustregel, dass große Modelle mit vielen Parametern entsprechend viel Speicher benötigen, und dass zusätzliche Kontextlänge schnell mehrere Gigabyte belegen kann. In LM Studio [https://lmstudio.ai/] lassen sich Open-Weights-Modelle wie Qwen [https://huggingface.co/Qwen/Qwen3.6-35B-A3B] oder Gemma [https://huggingface.co/mlx-community/gemma-4-26b-a4b-it-nvfp4] von Huggingface [https://huggingface.co/], dem NPM der KI-Modelle, laden und austauschen. Die ganz großen Frontier-Modelle von OpenAI, Anthropic oder Google bekommt man lokal allerdings nicht.

Ein wichtiger Hebel ist Quantisierung [https://ngrok.com/blog/quantization]: Statt Modelle in voller 16-Bit-Auflösung zu betreiben, werden sie auf kleinere Bitbreiten komprimiert, zum Beispiel 4 Bit. Dadurch werden sie deutlich kleiner und laufen auf erschwinglicherer Hardware, verlieren aber je nach Modell und Grad der Quantisierung an Genauigkeit. Schepp erwähnt außerdem Mixture-of-Experts-Modelle, bei denen zwar das ganze Modell im Speicher liegt, aber pro Anfrage nur ein Teil aktiv arbeitet.

Für Bildgenerierung nutzt Schepp

Revision 711: LLMs zuhause betreiben

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 [https://hans-christian-otto.de/] 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

Working Draft Revision 710: React- & TypeScript-Glücksrad, mit Hans-Christian
Otto

Diese Woche ist Max Inden [https://max-inden.de] (Mastodon [https://mastodon.social/@mxinden]) 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 [https://geenen-it-systeme.de/?src=workingdraft#podcast]

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 [https://www.mozilla.org/] 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 [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol]: Während HTTP/1 durch parallele TCP-Verbindungen und deren Limitierungen geprägt war, brachte HTTP/2 [https://de.wikipedia.org/wiki/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 [https://de.wikipedia.org/wiki/Transmission_Control_Protocol].

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 [https://de.wikipedia.org/wiki/User_Datagram_Protocol] 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 Sicherhei

Revision 709: HTTP/3 und WebTransport, mit Max Inden

Diese Woche haben wir Philipp Dunkel [https://www.linkedin.com/in/pipobscure/] (Bluesky [https://bsky.app/profile/pipobscure.com]) zu Gast und sprechen mit ihm über Temporal [https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/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 [https://www.youtube.com/watch?v=M8I16MgMsgY], 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 [https://mittwald.de/workingdraft?ref=workingdraft.de]

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 [https://momentjs.com/], Luxon [https://moment.github.io/luxon/] und date-fns [https://date-fns.org/], um die Rolle von Intl [https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Intl] und ECMA 402 [https://ecma-international.org/publications-and-standards/standards/ecma-402/] sowie um die vielen politischen, technischen und semantischen Fallstricke, die bei Datum und Uhrzeit eben dranhängen.

Shownotes

[00:00:54] Temporal [https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/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 [https://momentjs.com/], Luxon [https://moment.github.io/luxon/] und date-fns [https://date-fns.org/] 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 [https://maggiepint.com/], 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

Revision 708: Temporal, mit Philipp Dunkel

Wir spielen mal wieder ARIA-Glücksrad und haben uns dafür mit Paweł Masarczyk [https://www.linkedin.com/in/pawe%C5%82-masarczyk-3a68b2117/] (Mastodon [https://dragonscave.space/@Piciok]), Peter Krautzberger [https://www.peterkrautzberger.org/] (LinkedIn [https://www.linkedin.com/in/peter-krautzberger/] / Mastodon [https://bonn.social/@pkra]) und Marco Bretschneider [https://www.linkedin.com/in/marco-bretschneider-norderstedt/] (Mastodon [https://norden.social/@meise2000]) in bekannter Runde zusammengefunden. Daniela Kubesch [http://<a href=] musste diesmal krankheitsbedingt leider aussetzen 😥. Wir bedienen erneut unseren Zufallsgenerator [https://workingdraft.de/gluecksrad/], 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 [https://beyondtellerrand.com?ref=workingdraft.de]

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 [https://developer.mozilla.org/de/docs/Web/API/Element/ariaSelected] 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 [https://w3c.github.io/aria/#valuetype_true-false-undefined] kennt. [00:17:22] aria-level [https://developer.mozilla.org/de/docs/Web/API/Element/ariaLevel] 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 [https://github.com/whatwg/html/issues/11655]. [00:28:14] aria-owns [https://w3c.github.io/aria/#aria-owns] und

Revision 707: ARIA-Glücksrad, die Dritte

In dieser Revision sprechen wir mit Leo Reuter von Vercel [https://vercel.com/] (LinkedIn [https://www.linkedin.com/in/leo-reuter] / E-Mail [mail%40leo-re%75ter%2E%64e]) ü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 [https://mittwald.de/workingdraft?ref=workingdraft.de]

Ausgangspunkt ist dabei unsere bisherige Beschäftigung mit Vibe Coding [https://workingdraft.de/690/] 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 [https://v0.app/] 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 [https://v0.app/] und Vercel [https://vercel.com/] 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 [https://nextjs.org/] 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 [https://v0.app/]. 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

Revision 706: v0 und Vercel, mit Leo Reuter

Der wöchentliche Podcast für Webdesigner:innen und -entwickler:innen. Supported
uns bei Patreon: https://patreon.com/workingdraft