Mit zwölfjähriger Geschichte und über 5.000 Downloads pro Folge ist Working Draft
der etablierteste Podcast für Webentwickler im deutschsprachigen Raum.
Wenn ihr neue Entwicklerkollegen sucht oder ein Produkt für Webentwickler
anbietet, schreibt uns unter sponsoring@workingdraft.de.
Sobald „TypeScript“ im Titel steht, ist das quasi die Lizenz zum Abschweifen. Schnallt euch also an, die Alten Herren nehmen euch mit in den statisch typisierten Mindpalast.
Da das nächste TS-Release gelandet ist, sinnieren Peter und Stefan mal wieder über Architektur, Fehlermeldungs-Ergonomie und frische TypeScript-Details. Ausgangspunkt: Browser-Errors vs. Rust („FromEntries + Sparse Array“ lässt grüßen) und warum viele DevTools dabei schwächeln.
Danach geht’s in die 5.9-Notes: das verschlankte tsc --init, „Deferred Module Evaluation“ (import defer) als reine Syntax-Durchreiche, sowie der neue Zielwert module: node20 inkl. Import-Attributes (vormals Assertions) für JSON/CSS/WASM & Co. Wir sprechen über Modul-Laden in Browsern vs. Node, warum Bundler zunehmend nach Legacy riechen, ob Import-Maps und ein „print module graph“ aus TSC den Build-Step ablösen könnten – und wieso Lighthouse-Scores dabei wenig helfen.
Auf Editor-Seite freuen wir uns über MDN-Kurzbeschreibungen in DOM-Tooltips, expandierbare Typ-Hovers (endlich beides: kompakt und detailliert) und ein konfigurierbares Hover-Limit. Unter der Haube gibt’s Performance-Gewinne und ein wichtiges Typing-Fix: ArrayBuffer ist nicht länger (fälschlich) Supertyp diverser Typed Arrays. Am Ende blicken wir nach vorn: 6.x als „Glattbügel-Serie“ auf dem Weg zu TS 7 (Go-Rewrite), nebst den unvermeidlichen Ecosystem-Reibungen zwischen Node, Deno, Web-Streams & Freunden.
Diese Revision plaudern wir mit Alexander Lichter (LinkedIn / Mastodon) und Ulrich-Matthias „Ulima“ Schäfer (LinkedIn) über Ecosystem Performance, kurz „e18e“: Warum es sich lohnt, das JavaScript-Ökosystem aufzuräumen, wie die Community organisiert ist und wo jede:r sofort mitmachen kann.
Im Fokus der e18e-Bewegung stehen die Themen Cleanup, Speedup, Level-Up: alte Dependencies durch moderne, kleinere Alternativen ersetzen (z. B. Lodash-Funktionen/-ES, Tiny Globby statt Globby), Dev-Tooling messbar beschleunigen (u. a. neue Prettier-CLI, schnellere Lint-Setups) und Bibliotheken so gestalten, dass sie klaren Scope haben und aktuelle Node-LTS/ESM-Realität widerspiegeln. Wir sprechen über Grenzen (Deep-Deps, Battle-testing, Baseline-Support), über Publint für saubere Exports und über die neue e18e-CLI, die Codemods und Checks bündelt.
Außerdem: Wie man Einstiegshürden senkt (gute Doku, Replacement-Guides), warum Dev-Dependencies oft den größten Hebel haben, und welche Trade-offs Toolchains heute treiben (ESLint ↔︎ oxlint/Biome, Type-aware-Linting, Plugins in JS vs. Rust/Go). Praxisstories gibt’s zu Renovate, Pre-Commit-Hooks („no-verify“ lässt grüßen) und zu Contribution-Etikette gegenüber Maintainer:innen.
Wir drehen wieder am „Glücksrad“ – diesmal allerdings ausschließlich mit ARIA-Attributen! Schepp hat sich als Mitspielende Accessibility Engineer Daniela Kubesch (LinkedIn / Bluesky / Mastodon) und Frontend/Design-Systems Engineer Marco Bretschneider eingeladen. Der Zufall spuckt ARIA-Attribute aus und wir sezieren sodann deren Einsatzfälle, Stolpersteine und ggf. sinnvolle Alternativen: von aria-placeholder über erklärende Verknüpfungen mit aria-details (plus ariaDetailsElements) bis hin zu großen, virtuellen Listen mit aria-posinset/aria-setsize. Außerdem sprechen wir über gute modale Dialoge (aria-modal & <dialog>) und wagen einen Blick nach vorn mit dem brandneuen aria-brailleroledescription aus WAI-ARIA 1.3.
Entspricht inhaltlich dem HTML-placeholder – verschwindet also, sobald Nutzer:innen tippen. In der Praxis deshalb eher nicht verwenden: wichtige Hinweise gehören dauerhaft sichtbar neben/unter das Feld. Als Notnagel kann der Placeholder in der Accessible-Name-Ermittlung herangezogen werden, falls kein Label vorhanden ist (trotzdem immer ein richtiges <label> setzen). Möglicher Spezialfall: contenteditable. Weiterführend: HTML placeholder, Accessible Name Computation.
Verknüpft ein Widget mit einer längeren, „reichen“ Zusatzbeschreibung (z. B. FAQ-Inhalt, Größentabelle, Bildbeschreibung). Anders als aria-describedby beeinflusst aria-details nicht den Accessible Name; Screenreader können die Details kontextuell anbieten. Über die DOM-Property element.ariaDetailsElements lässt sich die referenzierte(n) Beschreibung(en) als Elemente abrufen (nützlich für Tests/Tooling). Wichtig: Informationen auch visuell zugänglich machen! Weiterführend: aria-describedby, aria-labelledby, aria-description.
Für „Teilmengen“ großer Sets (virtuelle Listen/Tabellen, Pagination): aria-setsize gibt die Gesamtzahl der Elemente an (falls unbekannt: -1), aria-posinset markiert die Position des jeweils sichtbaren Items. Typische Anwendung bei endlosem Scrollen oder chunkweisem Nachladen („250 von 3000 geladen“). Setzt man auf den einzelnen Listeneinträgen/Zeilen; die Information landet zuverlässig im Accessibility Tree. Weiterführend: listitem role, row role.
Kennzeichnet einen modalen Dialog (meist mit role="dialog" oder nativem <dialog>): Inhalte außerhalb sind für Assistive Technologien „inert“ also deaktiviert, der Fokus bleibt im Dialog. Gute Praxis: Dialog immer beschriften (aria-labelledby), eine kurze Erklärung mit aria-describedby verknüpfen, Fokus beim Öffnen auf ein sinnvolles Start-Ziel setzen (nicht zwingend das erste Input). Bei modalen Dialogen beginnt die Überschriftenhierarchie sinnvoll erneut (z. B. H1 im Dialog). Für die visuelle/Pointer-Sperre der Seite am besten das native <dialog> mit .showModal() verwenden (der Browser inertet den Rest). Weiterführend: <dialog>, inert, WAI-ARIA APG: Dialog (Modal) Pattern.
Liefert eine speziell für Refreshable Braille Displays geeignete, kurze Rollenbeschreibung (z. B. Abkürzungen wie „BTN“ statt „Button“). Wird von AT/Plattform-APIs ausgewertet; im Markup sparsam und nur mit etablierten, verständlichen Kürzeln einsetzen. Ergänzt die bestehende Rollenkommunikation (ähnlich zu aria-roledescription, aber gezielt für Braille-Ausgaben). Weiterführend: WAI-ARIA 1.3: aria-brailleroledescription, aria-roledescription.
a11yphant ist eine von Daniela bereitgestellte, kostenlose, offene Lernplattform für Web-Accessibility. Statt langer Texte übst du die Basics direkt in interaktiven Coding-Challenges und kurzen Quizzes – ohne Account startklar, optional mit Anmeldung zum Fortschrittsspeichern.
Nuxt 4 markiert einen wichtigen Meilenstein für das populäre Vue-Framework. Obwohl das Release keine großartigen Breaking Changes mitbringt, steckt unter der Haube viel Neues, das den Workflow und die Performance nachhaltig verbessern soll.
Für diese Folge haben wir nochmal Alexander Lichter (LinkedIn / Mastodon) zu Gast, der uns als Nuxt-Core-Team-Member tiefere Einblicke in den Nuxt 4 Release, die technischen Hintergründe und die aktuelle Situation mit Vercel gibt.
Das neue Nuxt bringt, anders als seine Vorversion, keine umfangreichen Breaking Changes mit. Einzige sichtbare Änderung ist die neue Verzeichnisstruktur, die man aber nicht übernehmen muss – bestehende Strukturen funktionieren weiterhin problemlos.
Der Hauptfokus lag unter der Haube. Die CLI wurde verbessert, wie auch das Data Fetching. Die neue Version der Nitro-Engine, die für API-Routing, Build-Prozesse, Middleware und Deployment zuständig ist, steckt leider noch in der Entwicklung und hat das Nuxt 4 Release deutlich verzögert. Bis heute gibt es keine finale Version von Nitro, was auch hier und da Auswirkungen auf das weitere Ökosystem hat.
Alex erklärt, wie die Abhängigkeit von Nitro entstand und welche Herausforderungen das für Entwickler:innen von Frameworks bedeutet, die darauf setzen.
Sodann schwenken wir um auf das heißdiskutierte Thema der Akquisition von NuxtLabs, also der Wiege von Nuxt, durch Vercel.
Wir beleuchten, was es heißt, dass Nuxt ein Multi-Company Open-Source-Projekt ist und wie die Übernahme von NuxtLabs durch Vercel die Entwicklung in diesem Kontext beeinflusst.
Wir spekulieren über Vercels Motivation, NuxtLabs zu übernehmen und warum das Unternehmen aktuell möglicherweise versucht, seinen Ruf im Open-Web-Bereich zu verbessern – auch durch die Unterstützung von Community-Projekten wie TanStack. Überraschend ist, dass trotz der Übernahme Netlify weiterhin Hauptdeployment-Partner von Nuxt bleibt.
In dieser Folge nehmen wir euch mit hinter die Kulissen des JSCraftCamp – einer der sympathischsten Community-Konferenzen im deutschsprachigen Raum. Gemeinsam mit den Organisatoren Wolfram Kriesing und Jörn Bernhardt sprechen wir über das Konzept, die Organisation und was das Event so besonders macht.
Wie einleitend erwähnt, sprechen wir in dieser Folge mit Wolfram und Jörn über das JSCraftCamp – ein kostenloses Barcamp für JavaScript-Interessierte, das seit 2016 jährlich in München stattfindet. Wir erfahren, wie sich das Event über die Jahre entwickelt hat, warum es sich wie ein Klassentreffen anfühlt und wie neue Teilnehmende durch Pull Requests über GitHub direkt in die Community einsteigen.
Wir reden darüber, wie das Orga-Team die Sessions plant (Spoiler: gar nicht – das machen alle zusammen vor Ort, siehe Sessionplan), wie neun parallele Tracks trotzdem überschaubar bleiben und warum es keine festen Themenvorgaben gibt. Auch Themen abseits von JavaScript, wie CSS, Projektmanagement oder das Programmieren mit Kindern, sind willkommen.
Wolfram und Jörn geben Einblicke in ihre GitHub-basierte Orga-Struktur, sprechen über Herausforderungen bei der Sponsorensuche, Nachhaltigkeit beim Catering und warum veganes Mittagessen alle glücklich macht. Außerdem berichten sie von ihren Ideen zur besseren Inklusion und Diversität, von spontanen Sessions mit Kindern, Kaffee-Fails, T-Shirt-Verteilung per Motivationstrick – und wie jede:r ihr Format einfach forken kann.
The funnest multiplayer game with 300K+ web designers & developers. Replicate the target images using CSS – the shorter your code, the higher your score! Happy coding!
Stefan und Peter geben ihre Einschätzungen rund um das Rewrite des TypeScript-Compilers zum besten!
Schaunotizen
[00:02:03] TypeScript goes native!
TypeScript bekommt einen Rewrite in Go und nach der Veröffentlichung der ersten Previews sehen wir Besprechungsbedarf. Wir diskutieren, ob und unter welchen Umständen ein Komplett-Rewrite sinnvoll ist und ob Go eine bessere Wahl als denkbare Alternativen wie Rust oder C# ist. Dabei sprechen wir unter anderem über die Limitierungen von JavaScript-Tools unter heutigem Umständen, XXL-Enums, Effekte auf andere Tools aus dem TS-Universum (u.A. Deno, Bun und Supabase) und Perspektiven für neue TypeScript-Features in der mittelfernen Zukunft..
In dieser Folge sprechen wir mit Andreas Kottre (CEO & Technical Lead bei typedigital) & Tim Olbrich (Geschäftsführer und Inhaber der Bitory GmbH) von der Hackerkiste Augsburg, einem einzigartigen Event, das seit 2017 regelmäßig die Web- und Tech-Community zusammenbringt. Wir tauchen ein in das besondere Setting: eine ehemalige Siemens-Halle, die zum kleinen Festival-Dorf mit Plaza, weitläufigem Gelände, großen Stages und verwinkelten Bereichen wurde. Außerdem ergründen wir den barcampartigen Rahmen mit 10-Min-Talks, Call for Papers, First-Time-Speakers-Betreuung – und am Ende erwartet euch eine grandiose Verlosung!
Schaunotizen
[00:00:58] Hackerkiste Augsburg
Inhaltlich bietet die Hackerkiste ein volles Programm: Rund dreißig Speaker:innen und ein Dutzend Barcamp-Sessions locken jedes Jahr etwa dreihundert Teilnehmende nach Augsburg. Das Format ist bietet mehrere Stages, inklusive ausführlichen Vorträgen auf den großen Stages und Lightning Talks. Es gibt dabei Sage und Schreibe ganze vier Tracks zu besuchen! Lightning Talks dauern nur (bis zu) zehn Minuten, eingebettet in halbstündige Sessions, die zum Austausch einladen und Barcamp-Charakter haben. Angesprochen sind Entwickler:innen, UX-Interessierte, Community-Macher:innen und alle, die Lust auf neue Impulse haben.Besonders spannend ist der Umgang mit neuen Speaker:innen. Über den Call for Papers können sich erfahrene Vortragende genauso wie Newcomer melden. Wer zum ersten Mal auf die Bühne geht, wird von Stage Hosts betreut und bekommt Unterstützung bei Vorbereitung, Ablauf und Stressmanagement. So wird der Einstieg leicht gemacht, ohne dass die Qualität leidet.
Neben der eigentlichen Konferenz prägt die Hackerkiste auch das Community-Leben in Augsburg. Unter anderem veranstalten die Organisator:innen das Meetup Web and Wine, das nicht nur technische Themen, sondern auch Metaebenen wie den Umgang mit Stress aufgreift. Damit wird deutlich, dass es bei der Hackerkiste nicht allein um Technologie, sondern auch um Austausch und Gemeinschaft geht.
Und weil wir es bis zum Schluss spannend machen wollen: Am Ende dieser Revision wartet noch eine Verlosung auf euch. Mehr verraten wir hier nicht. Außer, dass es sich lohnt, dranzubleiben.
In dieser Folge schauen wir gemeinsam hinter die Kulissen der Veranstaltungsorganisation: Wie läuft das bei einem Team, das zwar einen Tech-Hintergrund hat, aber keine Eventagentur ist? Und was war der Antrieb, überhaupt eine eigene Konferenz zu machen?
Natürlich reden wir auch über Community-Arbeit ganz generell – und was es bedeutet, wenn eine Firma Zeit und Raum schafft, sich aktiv in die Szene einzubringen. Die Programmierbar macht das nicht nur mit ihrer Konferenz, sondern auch mit ihren regelmäßigen Formaten wie dem Backend- und dem Frontend-Meetup.
Am Ende steht die Einladung: Kommt vorbei, sprecht Jan an!
Am 29. und 30. Oktober 2025 bringt die programmier.con in Bad Nauheim die Web- und KI-Community zu zwei Tagen voller Vorträge, Keynotes und Austausch zusammen.
Der Flutter Day war eine deutschsprachige Konferenz mit spannenden Talks von Expert:innen und bot technisch anspruchsvolle, aber zugleich zugängliche Themen für Flutter-Interessierte und Web-Entwickler:innen.
In schönen Bad Nauheim teilen Sprecher:innen ihre Erfahrungen zu Web- und App-Entwicklung, danach gibt’s Austausch in entspannter Runde mit Snacks und Drinks.
Local AI, also KI-Modelle, die direkt auf dem Gerät laufen, statt in der Cloud, gewinnen aktuell enorm an Bedeutung. Einen neue Ansatz dafür bieten die neuen Chrome Built-in AI APIs, mit denen Entwickler:innen direkt im Browser auf mächtige KI-Funktionalitäten zugreifen können – ganz ohne eigene Modelle zu laden oder Cloud-Anfragen ausführen zu müssen. Diese lokal ausgeführten Modelle schützen die Privatsphäre, ermöglichen Offline-Nutzung und sparen Ressourcen – was für Nutzer:innen und Firmen gleichermaßen attraktiv sein kann.
Für diese Folge haben wir Thomas Steiner (Web / Mastodon / Bluesky), eingeladen, der nicht nur Google Developer Relations Engineer ist, sondern auch tief im Thema steckt. Gemeinsam mit Vanessa und Schepp spricht Thomas darüber, wie die Chrome APIs funktionieren, welche Features sie bieten und welche Herausforderungen es aktuell noch gibt. Außerdem beleuchten wir die Perspektiven anderer Browser-Hersteller und die Zukunft der Local AI im Web.
Schaunotizen
[00:01:37] Local AI
Warum ist Local AI wichtig? Thomas erklärt, dass lokale Ausführung vor allem Datensicherheit bedeutet – Daten werden nicht an einen Server geschickt. Obendrein sind entsprechende Anwendungen auch offline nutzbar und für Firmen günstiger, weil keine Cloud-Anfragen nötig sind. Der Browser stellt dabei ein generisches KI-Modell bereit, etwa Gemini Nano, das mit nur 4,29 GB auf der Festplatte auch auf Durchschnittsgeräten läuft.Die APIs sind einfach per wenigen Zeilen JavaScript nutzbar und bieten mächtige Funktionen, z.B. Übersetzung (Translation API), Schreiben (Writer API), Korrektur (Proofreader API) und generelle Eingabe per Prompt API. Multimediale Eingaben wie Bilder oder Audio werden unterstützt, was spannende Usecases erlaubt: zum Beispiel Audio transkribieren, bestimmte Audioinhalte filtern, Bilder für assistive Technologien beschreiben oder Personalausweise clientseitig auf Plausibilität prüfen.Ein Grund für mehrere dedizierte APIs statt nur einer Prompt API liegt darin, dass Gemini Nano ein vergleichsweise kleines, aber leistungsfähiges LLM ist. Das erlaubt die Nutzung auf Geräten mit begrenzter Hardware – aktuell läuft die KI auf GPU, aber es wird daran gearbeitet, dass sie auch auf CPU-only Geräten läuft, z.B. günstigen Android-Geräten. Techniken wie „early exit“ helfen, auf mobilen Geräten Energie zu sparen, indem man Antworten frühzeitig abschließt.
Derzeit werden entsprechend nur MacOS, Windows und Linux unterstützt, Chrome OS fehlt neben Android ebenfalls noch. iPad und iOS sind durch WebKit noch eingeschränkt, hier fehlen derzeit viele Freiheiten.
Wir diskutieren auch den Gegenwind von anderen Browserherstellern: Bedenken gibt es wegen möglichem Fingerprinting, obwohl die Modelle statisch sind und nicht lernen. Ein weiteres Thema ist die Testbarkeit nicht-deterministischer KI-Features, hier experimentiert man mit Quizfragen, um die Qualität zu prüfen. Außerdem sind die lokal verfügbaren Modelle derzeit auf Englisch beschränkt, was der globalen Web-Community nicht gerecht wird.
Zum Schluss wagen wir einen Ausblick: Wenn man den Anwendungsfall klar entkoppelt, z.B. reine Übersetzung, steigt die Chance, dass auch andere Browser wie Apple Safari eigene KI-APIs nachziehen. Die Entwicklung ist dynamisch, und mit Initiativen wie dem W3C Web Machine Learning Group und Firebase AI entstehen Standards für die Zukunft.
Elf Jahre (und 501 Revisionen) nach seinem letzten Besuch in Revision 175 war Jan Lehnardt (LinkedIn / Mastodon / Bluesky) wieder bei uns zu Gast. Mit Schepp und Vanessa spricht er über die Idee hinter „Local First“.
Schaunotizen
[00:01:09] Local First
Was heißt eigentlich „Local First“? Wir starten mit einer Rückblende auf das Jahr 2013: Damals war „Offline First“ das neue heiße Ding – erdacht von Jan höchstselbst und in Worte gegossen von Jans Mitstreiter Alex Feyerke im A List Apart Essay. Aus seiner Arbeit an CouchDB und PouchDB heraus entstand der Gedanke, dass Applikationen auch ohne Verbindung zum Internet sinnvoll funktionieren sollten. Dabei nutzt man ein System verteilter Datenbanken, sei es im Internet, im Intranet oder auf dem Anwendergerät selbst zwischen denen Daten in Form von Dokumenten synchronisiert werden. Ähnlich wie es mit Git möglich ist. Anders als bei Git, treten Merge-Konflikte allerdings schon dann auf, wenn gleichzeitig dasselbe Dokument verändert wurde. Diese Konflikte gilt es dann manuel zu lösen.
Wir sprechen über spannende Anwendungsfälle, die der „Offline First“-Ansatz überhaupt erst möglich gemacht hat – von Ebola-Krisenhilfe über die COVID-Impf-Infrastruktur in Bayern bis hin zur Koordination und Planung humanitärer Konvois in Krisengebieten.
„Local First“ setzt im Grunde auf ähnliche Prinzipien wie einige Jahre zuvor „Offline First“, wie es auch die sieben Prinzipien von „Local First“ dokumentieren. Technisch ist „Local First“ allerdings etwas anspruchsvoller, weil es stärker darauf ausgerichtet ist, dass Nutzende an ein und demselben Dokument gleichzeitig arbeiten können. Realisiert wird das über Conflict-free Replicated Data Types (CRDT).
y.js, JSON CRDTs, Operational Transforms (wie einst bei Google Wave) und Automerge sind Werkzeuge, die einem hier feingranulare Synchronisation und Konfliktlösungen ermöglichen. Jan erklärt, dass auch CouchDB mittlerweile gelernt hat, Konflikte automatisch zu lösen und es damit auch besser für gleichzeitige Arbeiten am selben Dokument gerüstet ist.
Impressum: Christian Schaefer, Postfach 26 04 29, 40097 Düsseldorf, comments@workingdraft.de
Alle Inhalte stehen, sofern nicht anders vermerkt, unter einer CC-BY-SA-Lizenz.
