

Working Draft
Vanessa Otto, Peter Kröner, Hans Christian Reinl, Stefan Baumgartner, Christian »Schepp« Schaefer
Working Draft ist der deutschsprachige Podcast für Frontend-Entwicklung, Webdesign und UI Engineering.
Bei uns geht’s um HTML, CSS, JavaScript, Frameworks wie React, Vue und Angular, Responsive Webdesign, User-Interfaces, moderne UI-Patterns, Barrierefreiheit, Tooling, Design-Systeme, Webstandards und mehr.
Unser Team besteht aus erfahrenen Frontend-Entwickler:innen aus Deutschland und Österreich – mit Gästen aus der Praxis, die regelmäßig Einblicke in aktuelle Tech-Themen geben. Ob neue CSS-Features, die Zukunft von JavaScript, KI im Frontend-Workflow oder einfach gute UI-Erfahrungen: Wir reden drüber – jede Woche neu.
Bei uns geht’s um HTML, CSS, JavaScript, Frameworks wie React, Vue und Angular, Responsive Webdesign, User-Interfaces, moderne UI-Patterns, Barrierefreiheit, Tooling, Design-Systeme, Webstandards und mehr.
Unser Team besteht aus erfahrenen Frontend-Entwickler:innen aus Deutschland und Österreich – mit Gästen aus der Praxis, die regelmäßig Einblicke in aktuelle Tech-Themen geben. Ob neue CSS-Features, die Zukunft von JavaScript, KI im Frontend-Workflow oder einfach gute UI-Erfahrungen: Wir reden drüber – jede Woche neu.
Episodes
Mentioned books

Jan 12, 2021 • 1h 14min
Revision 459: Bazel
Hans, Stefan und Schepp reden heute mit Lukas Holzer von Dynatrace über Bazel, dem neuen Build Tool aus dem Hause Google.
Unser Sponsor
Geschmeidige Animationen, Webfonts, hochauflösende Fotos – eine Website muss heute viel anbieten. Oft scheint zu gelten: Viel hilft viel. Das führt aber zu durchschnittlichen Webseitegrößen von zwei MByte und der Browser muss fast ein halbes MByte JavaScript-Code verdauen. Lädt eine Seite dann zu lange, klicken Nutzer weiter. Auch Google hat offiziell angekündigt, dass die „Page Experience“ und damit die Performance zum Ranking-Faktor wird. Erfahre mehr dazu auf der Online-Konferenz c’t webdev am 9. Februar. Vertiefe dein Wissen am Folgetag in Workshops, u. a. zu Mobile App Entwicklung mit React Native.
Hol dir 15% Rabatt mit dem Code WEBDEVPOD21! Weitere Infos unter: heise.de/s/w58X
Schaunotizen
[00:01:52] Bazel
Lukas erzählt uns von seinen Erfahrungen mit Bazel, einem polyglotten Build-System, das schnelle, inkrementelle Builds sowohl lokal als auch auf CI/CD ermöglicht. Ziel von Bazel ist es einen sehr genauen Abhängigkeitsbaum zu definieren, der erlaubt nur Änderungen zu kompilieren. Wir vergleichen mit Gradle, Facebook’s Buck. Bazel startete als internes Tool bei Google, damals noch Blaze genannt. Da Google alles in einem großen Monorepo entwickelt, zahlt es sich aus wenn Zehntausenede Entwickler nicht immer alles durchbauen müssen, um kleine Änderungen festzustellen. In Bazel schreibt man eigene Build-Files mit Starlark, einem Python Dialekt. Mit Hilfe dieser Dateien baut Bazel einen Abhängigkeitsbaum auf, kann Kompilate dank Remote Cache Server sehr gut cachen. Der Unterschied zu Systemen wie Nx liegt vor allem darin, dass jedes Artefakt genau bestimmt werden kann und man so unabhängig von Git Commits wird. Zusätzlich erlaubt man den Einzug von schnellen und iterativen Entwicklungs-Tools, wie ES Dev Server, ES Build, u.ä. Zu guter Letzt reden wir auch noch von Sketchmine, einem ambitionierten Projekt aus Angular Sketch Files zu generieren. Videos gibt es dazu auch: Stahlstadt.js, Angular Connect. Lukas ist übrigens Contributor bei den Node.js Regeln von Bazel und freut sich über viel Feedback!

Jan 5, 2021 • 1h 22min
Revision 458: Cypress
In dieser Revision dürften wir Priyanka Kore und Tobias Struckmeier von der Adesso als Gäste begrüßen und mit Ihnen über End-to-End-Testing mit Cypress sprechen.
Schaunotizen
[00:00:29] Cypress
Bevor sich unser Gespräch auf Cypress einschießt, klären wir, inwiefern Tests hilfreich sind, welche Software-Test-Methodiken es gibt, und wie diese alle sich zur berühmten Testing-Pyramide zusammenfügen:
End-to-End-Tests (E2E) decken das ganze System ab und sind damit die umfassendsten Tests, sie durchzuführen stellt einen allerdings vor so manche Herausforderung:
ggf. fehlt die nötige Infrastruktur dafür
das Setup ist aufwändig
sie laufen langsam und sind ressourcenhungrig
das Management von Testdaten ist nicht einfach
sie sind schwer in bestehende Projekte zu bringen
und sie harmonieren nicht immer mit hochdynamischen SPA
Die meisten der genannte Probleme lassen sich darauf zurückführen, dass E2E-Tests über das recht eigene Selenium Webdriver gesteuert und sie in üblichen Browsern auf diversen Betriebssystemen durchgeführt werden. Mit dieser Vorgehensweise bricht Cypress und löst damit die meisten der oben genannten Probleme – und nimmt natürlich auch gewisse Nachteile in Kauf.
Cypress nutzt vom Fleck weg bestehende Browser im System und unterstützt alle Chromium-basierten Browser und den Mozilla Firefox. Desweiteren bringt Cypress auch einen eigenen Browser mit für den Fall, dass kein unterstützter Browser vorhanden ist, sowie hilfreiche Zusatztools wie Mocha, eine Assertion Library, Launcher/Runner, Reporter und einen Proxy. Unterstützt wird all das von einer exzellenten Dokumentation Cypress ist also schnell und ohne großen Aufwand installiert, es läuft deutlich schneller als Selenium, zum einen weil es lokal läuft, zum anderen weil man bei der Interaktion mit dem DOM anders vorgehen kann als in Selenium und es lassen sich Dinge wie XHR-Calls und/oder Testdaten durch integrierte Tools sehr einfach simulieren. Und schließlich kann man Tests bei Fehlern sofort stoppen und ein Entwickler übernimmt die Fehlersuche in dem noch offenen Browser.
Wie erwähnt, hat Cypress natürlich auch Nachteile, welche die folgenden wären:
Es werden nur Chromium- und Mozilla-Browser unterstützt
Cypress kann keine Tests durchführen, die mehr als einen Origin gleichzeitig umfassen
Cypress kann nicht mehrere Tests parallel durchführen, sofern man nicht deren payed Service nutzt
Es gibt keinen Standard-Weg Up- und Downloads zu testen, stattdessen viele mögliche Hacks
Außerdem sprechen wir im Verlauf der Sendung über über die automatische Erzeugung von bebilderten Anleitungen via Cypress-Book und über das Testen von einzelnen Komponenten in Isolation.

Dec 29, 2020 • 1h 18min
Revision 457: Funktionale Programmierung mit Tobi Timm
Developer und Speaker Tobi Timm, Senior Product Engineer bei SinnerSchrader, Koorganisator bei Nodeschool MUX/AUX und React Munich, erzählte Stefan, Schepp und Vanessa über funktionale Programmierung und endliche Zustandsmaschinen in JavaScript.
Schaunotizen
[00:00:29] Funktionale Programmierung en Vogue
Durch die immer höhere Popularität von progressiven Frontend-Frameworks wie React.js und Vue.js, die jeweils Ansätze der Funktionalen Programmierung (FP) aufweisen, erlaubt die FP an sich einen Aufschwung in der Web Entwicklung. Neben Elm, ein von Haskell inspiriertes Framework, gibt es für JavaScript-Entwickler und -Entwicklerinnen die Bibliothek Ramda.js. Für ESLint steht das Plugin eslint-plugin-functional zur Verfügung. Das wohl wichtigste Paradigma der Funktionalen Programmierung besteht daraus, das ausschließlich Funktionen geschrieben werden. Die Konzepte kommen von Haskell, LISP, OCaml oder auch Scheme, einem Vorgänger von Javascript. Funktionen gelten als „First Class Citizen“ und werden dabei auch „Pure Functions“ genannt. Diese generieren bei gleichem Input immer den gleichen Output und verwenden keine Variablen außerhalb ihres Scopes. Ein Vorteil von Funktionaler Programmierung ist dadurch, dass Nebenläufigkeiten verhindert werden und der Code weniger fehleranfällig ist. Getestet werden müssen dann Werte von außerhalb, wie z.B. Nutzereingaben oder Antworten von APIs. Für den Einstieg in die FP in einer bestehenden Codebase, empfiehlt Tobi z.B. For-Schleifen durch Funktionen wie .map(), .filter() und .reduce() zu ersetzen. Zum Lernen empfehlen wir die Videos von Dr. Boolean.
Finite State Machines
Etwas, das ähnliche Effekte wie die FP erzeugt, sind State Machines und State Charts. XState von David Khourshid ist hier das Framework für pure Javascript Entwicklung. Wie auch bei der FP ist die Lernkurve allerdings etwas höher, doch es scheint sich zu lohnen, sich mit diesem Thema zu befassen.

Dec 22, 2020 • 1h 36min
Revision 456: Aktuelle Entwicklungen in Node.js mit Golo Roden
Node.js-Ninja Golo Roden, Big Boss bei The Native Web, schaute mal wieder vorbei (zuletzt: 160, 314) und informierte Stefan und Peter über die neuesten Neuerungen in Node.
Schaunotizen
[00:00:30] Neues aus Node.js
Anlässlich des Release von Node 15 ist ein Rundumschlag angebracht! Zu den wesentlichen Neuheuten gehört NPM 7, worin diverser Ärger mit package.json und package-lock.json ausgeräumt wird. Wir lassen es uns bei dem Thema natürlich nicht nehmen, auch die Volksfront von Judäa und die judäische Volksfront zu erwähnen, den Sinn von SemVer zu hinterfragen und am Ende in den etablierten Standardisierungs-Pessimismus abzugleiten. An konkreten Node-internen Änderungen bequatschen wir String#replaceAll, HTTP/3, den AbortController und das Hickhack um Streams in allen Formen. Warum es immer noch kein Fetch in Node gibt (nur als Library, wobei die populärere Löung ist) besprechen wir genau wie den aktuellen Stand an der Deno-Front (siehe auch: 10 Things I Regret About Node.js und Revision 428). Zum Abschluss kommen wir um das Thema Nachhaltigkeit in OSS nicht herum und plädieren für restriktivere Lizenzen (z.B. AGPL, wie’s auch Golo bei seinem Wolkenkit macht). Zum Ausprobieren der diversen Node-Versionen emfehlen wir nvm und Volta.

Dec 16, 2020 • 1h 3min
Revision 455: Sulu CMS
Heute haben wir gleich zwei Gäste zum Thema Sulu CMS: Thomas Schedler und Roland Golla.
Schaunotizen
[00:00:28] Sulu CMS
Sulu ist ein PHP-basiertes CMS, das mit dem Framework Symfony gebaut ist. Einst als Agentur CMS gestartet, erfreut es sich mittlerweile größerer Beliebtheit. Als Core-Developer gibt uns Thomas gute Einblicke in den Werdegang und die Features von Sulu CMS, Roland untermauert mit praxisnahen Beispielen.
Wer einen Start mit Sulu bekommen möchte, kann sich beispielsweise dieses Video anschauen. Außerdem hat Roland eine ganze Serie an Video-Tutorials zum Thema aufgenommen. Ein Demo-Projekt gibt’s hier. Auch zum Headless-Betrieb ist das CMS geeignet. Wer einen tieferen Einblick sucht, der ist mit der Dokumentation gut bedient.

Dec 10, 2020 • 1h 27min
Special Edition: State of CSS 2020
Stefan und Peter trafen sich um ausnahmsweise mal nicht über TypeScript zu sprechen! Stattdessen geht um die Ergebnisse des State of CSS 2020!
Schaunotizen
[00:00:45] State of CSS 2020
Wir sprechen über einige Teile der Umfrage-Ergebnisse im Detail (etwa Grid, Subgrid, Masonry-Layout und Flexbox) und überspringen die weniger spannenden. Ausgiebige Brandmarkung erfahren nervige Features (Scroll Snap, position:fixed) und nervige Trends (CSS in React), während wir erneut Anlass finden, BEM zu lobpreisen. Und besonders freut uns natürlich, dass ihr uns in der Kategorie „sonstige Podcasts“ auf einen Mittelfeld-Platz gewählt habt!

Dec 8, 2020 • 1h 31min
Revision 454: Late-Night mit Rust, TypeScript, Clojure, Micro-Frontends, uvm.
Wenn die Kinder schlafen und die Eltern gerade wieder wach geworden sind, ist es Zeit für eine Late-Night Show mit etlichen Themen, wenig rotem Faden, dafür gehörig viel Meinung. Kahlil und Stefan holen weit aus und schmieren gehörig Senf auf folgende Begriffe:
Unser Sponsor
Kennst Du das Gefühl… die Projektleitung benötigt dringend die Stunden für das Projekt rückgemeldet, Du hattest aber während der Arbeit am Projekt keine Zeit diese zu notieren? Nun musst Du mühsam alles zusammensuchen um die Stunden zu erfassen? timr unterstützt Dich und Dein Team dabei Eure Zeit mit minimalem Aufwand zu erfassen. Am Ende des Tages ist alles erfasst. Die Projektleitung freut sich weil sie täglich einen Überblick hat. Sie kann damit nicht nur reagieren, sondern agieren. Neben der Projektzeiterfassung könnt Ihr sogar Eure Arbeitszeit erfassen, inkl. Urlaubsanträge.
Teste timr 14 Tage kostenlos und hol Dir 10% Rabatt auf Deinen ersten Kauf unter timr.com/workingdraft.
Schaunotizen
[00:01:46]
TypeScript in 50 Lessons
Stefans Buch ist immer noch hoch im Interesse der Kollegen. Nach einer Revision zum Schreiben an sich, geht’s hier nochmal um ein paar inhaltliche Themen und den Versuch, möglichst lange relevant zu bleiben..
Rust
Seit Stefan das Rust Linz Meetup mitorganisiert, bestimmen die schönen Feinheiten dieser Sprache seinen Sinn für Programmieren.
Clojure
Eine funktionale Programmiersprache auf der JVM, die sich etlicher Beliebtheit in der Java Community erfreut. Wir referenzieren vor allem auf Rich Hickeys Vortrag Simple Made Easy
Micro Frontends
Noch nicht ganz bei Stefan angekommen, versorgt Kahlil mit den nötigen Nachschlagewerken zum Thema Micro Frontends. Gerade das Werk von DAZN VP of Architecture Luca Mezzalira ist eine der wichtigsten Ressourcen. Dazu gibt es auch ein Buch
Next.js
Next.js ist mehr als React and Jamstack, es ist mittlerweile eines der besten und angenehmsten Frameworks die es für komplexe und umfangreiche JavaScript Applikationen gibt. Das finden nicht nur Kahlil und Stefan, sondern natürlich auch der Erfinder Guillermo Rauch, der Wegweisendes in seinem Beitrag 7 Principles of Rich Web Applications geschrieben hat, und das schon 2014. Passend, die Keynote der Next.js Conf. Rauch hat auch seine Finger in Prisma, einer SaaS Datenbank.
Leo Li
Zum Folgen: Leo Li gibt einen tollen Svelte.js Crash Kurs in 10 Tweets. Das gleiche macht er auch für GraphQL.

Dec 1, 2020 • 1h 21min
Revision 453: Webtech-Bücher schreiben
Nachdem mit TypeScript in 50 Lessons Stefans zweites Buch erschienen ist, quatschte er mit Peter (seines Zeichens Autor der antiken HTML5-Steintafel HTML5. Webseiten innovativ und zukunftssicher) über das Schreiben von Webtech-Büchern.
Schaunotizen
[00:00:29] Schreiben von (Webtech-) Büchern
Stefan und Peter vergleichen die Entstehung ihrer drei Werke (TypeScript in 50 Lessons, HTML5. Webseiten innovativ und zukunftssicher und Stefans Erstwerk Front-End Tooling with Gulp, Bower, and Yeoman) unter den Gesichtspunkten Recherche, Workflow, Lernings, Wegen zum Buch-Deal, Halbwertszeit von verschriftlichtem Webtech-Wissen und Produktion. Wir klären, ob sich Webtech-Bücherschreiben lohnt (für verschiedene Definitionen des Wortes „lohnt“), besprechen den Umgang mit seltsamem Feedback und komischen Rezensionen und sinnieren ein wenig über Screencasting und Video-Produktion.

Nov 24, 2020 • 1h 25min
Revision 452: CORS, CORP, (C)ORB, COOP und COEP
Wie Ihr Euch erinnert, hatten wir in Revision 447 Frederik Braun von Mozilla zu Gast, mit dem wir über den Themenblock „Cross-Site-Scripting“ gesprochen haben. Wir hatten damals noch einen zweiten Themenblock auf der Agenda, nämlich „Site Isolation“, zu dem wir aus Zeitgründen nicht mehr kamen und den wir auf eine zukünftige Folge vertagt haben. Hier kommt sie!
Unser Sponsor
Kennst Du das Gefühl… die Projektleitung benötigt dringend die Stunden für das Projekt rückgemeldet, Du hattest aber während der Arbeit am Projekt keine Zeit diese zu notieren? Nun musst Du mühsam alles zusammensuchen um die Stunden zu erfassen? timr unterstützt Dich und Dein Team dabei Eure Zeit mit minimalem Aufwand zu erfassen. Am Ende des Tages ist alles erfasst. Die Projektleitung freut sich weil sie täglich einen Überblick hat. Sie kann damit nicht nur reagieren, sondern agieren. Neben der Projektzeiterfassung könnt Ihr sogar Eure Arbeitszeit erfassen, inkl. Urlaubsanträge.
Teste timr 14 Tage kostenlos und hol Dir 10% Rabatt auf Deinen ersten Kauf unter timr.com/workingdraft.
Schaunotizen
[00:01:46] CORS, CORP, (C)ORB, COOP und COEP
Zur Einführung gehen wir auf eine Angriffsmethode namens „Spectre“ und das Konzept der Site-Isolation ein, um das Problem zu verstehen, für das wir im Folgenden die Lösungen erörtern wollen. Außerdem rufen wir uns ins Gedächtnis, wie die „Same Origin Policy“ in den Browsern greift und wie man seit einigen Jahren per „Cross Origin Resource Sharing“ (CORS) darauf einwirken kann. Und wir klären den Unterschied zwischen „Same Site“ und „Same Origin“. Damit haben wir die Grundlagen gelegt, um einigermaßen neue, fest eingebaute Mechanismen wie (Cross) Origin Request Blocking (Video) ((C)ORB) zu Verstehen, aber vor allem auch, was es mit dem neuen „Cross-Origin Resource Policy“ (CORP) Header auf sich hat. Um es kurz zu machen: Während CORS dem Browser über Origin-Grenzen hinweg Zugriff auf per JavaScript weiterbearbeitete Ressourcen gewährt, verhindert entsprechend gesetztes CORP die passive Anzeige von von fremden Ursprüngen stammender, aber üblicherweise zulässiger Bausteinen wie etwa Bilder. Danach erörtern wir, was es mit einer Gruppe Sicherheitslücken namens „xsleaks“ auf sich hat, um zu verstehen, wie zwei weitere neue HTTP Header namens „Cross-Origin-Opener-Policy“ (COOP) und „Cross-Origin-Embedder-Policy“ (COEP) da hineinspielen. Weil diese ganzen Sicherheitsmaßnahmen die Funktionsweise der Seite stark beeinflussen, ist es ratsam, vor einem Scharfschalten von der Reporting API, respektive dem Report-to-Header Gebrauch zu machen (und Probleme zum Beispiel an sentry.io senden zu lassen). Ob wir am Ende alles richtig gemacht haben und unsere Seite erfolgreich abschotten konnten, können wir im Browser auf der globalen Property window.crossOriginIsolated / self.crossOriginIsolated abfragen. Als Belohnung für unsere Mühen eröffnet uns der Browser Zugang zu Features wie eine hohe Genauigkeit des DOMHighResTimeStamps, SharedArrayBuffers oder performance.measureMemory().

Nov 17, 2020 • 1h 16min
Revision 451: Neue Webstandard-Proposals und Podcast-Verstärkung!
Im Rahmen einer Throwback-Folge besprechen nicht nur die üblichen Schepp, Stefan und Peter neue Webstandards/Browser-APIs, sondern begrüßen auch Verstärkung im Podcast-Team!
Unser Sponsor
Kennst Du das Gefühl… die Projektleitung benötigt dringend die Stunden für das Projekt rückgemeldet, Du hattest aber während der Arbeit am Projekt keine Zeit diese zu notieren? Nun musst Du mühsam alles zusammensuchen um die Stunden zu erfassen? timr unterstützt Dich und Dein Team dabei Eure Zeit mit minimalem Aufwand zu erfassen. Am Ende des Tages ist alles erfasst. Die Projektleitung freut sich weil sie täglich einen Überblick hat. Sie kann damit nicht nur reagieren, sondern agieren. Neben der Projektzeiterfassung könnt Ihr sogar Eure Arbeitszeit erfassen, inkl. Urlaubsanträge.
Teste timr 14 Tage kostenlos und hol Dir 10% Rabatt auf Deinen ersten Kauf unter timr.com/workingdraft.
Schaunotizen
[00:01:46] Hallo Vanessa!
Willkommen im Team, Vanessa Böhner! Bekannt aus vergangen Workingdraft-Folgen, von Twitter, von den FrontendFoxes und durch Podcasts über Testing und Wein verstärkt sie nun auch diesen Podcast.
[00:11:15] DOM Parts Proposal
DOM-Parts verstärken das Template-Element, das eigentlich nur ein deklaratives DocumentFragment ist, um Features aus Template-Sprachen wie Handlebars. Im Rahmen des Über-Themas Templating sprechen wir auch über Frontend-Framework-Monokultur, Security, hyperHTML, JSX und statisch vs. dynamisch typsierte Programmiersprachen.
[00:31:20] CentralizedConsentAPI
Die API für die Reduktion von Cookie-Consent-Bannern wird kontrovers diskutiert! Während einige von uns an die API glauben, wittern andere eine Verschwörung gegen das Project Fugu und wieder andere berufen sich auf die via Brave Browser und uBlock Origin umgesetzte Castle Doctrine in der eigenen Web-Experience.
[00:50:10] Cookie-Store
Brauchen wir bessere Frontend-APIs für Coookies? Entsprechende jQuery-Plugins deuten darauf hin. Die neue API verspricht asynchrone Funktionen, Cookie-Events und Cookies im Service Worker. Wir vergleichen die Cookie-API und das entsprechende jQuery-Plugin mit der URL-API und Rodneys URI.js. Außerdem versuchen wir zu ergründen, ob wir asyncrhone APIs brauchen, warum es keinen Cookie-Observer angelehnt an den Mutation Observer gibt und gleichen das Proposal mit Mozillas Positionen zu divsersen Standards ab.


