Mit zehnjähriger Geschichte und über 5000 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.
Das Thema Testing begleitet uns seit vielen Jahren. Glücklicherweise scheint es immer leichter zu werden. Joe Ray Gregory (Twitter / Website), Senior Software Engineer und Trainier bei workshops.de, bringt uns diesmal das Framework Testing Library mit.
Psst, Geheimtipp: Joe verrät uns, dass es aktuell Early Bird Tickets für die Vue.js Konferenz in Berlin am 22. September gibt.
Schaunotizen
[00:01:36] Unit-Testing / Testing Library
Die Testing Library von Kent C. Dodds und anderen Beitragenden ist eine Familie von Bibliotheken, um Best Practices in das Testen zu bringen. Sie ist framework-agnostisch und kann daher mit Vue, React und Co. verwendet werden. Sie funktioniert mit Jest,Cypress und vermutlich auch Vitest (Obacht: Alpha!), aber auch alleinstehend benutzt werden. Im Laufe der Revision geht Joe darauf ein, was die Testing Library eigentlich ist, warum man sie nutzen sollte und wie man sie einsetzt. Dabei geht er auch darauf ein, dass es keine aktive Mitarbeit von seitens Facebook (Meta) seit Jahren mehr an Jest gibt. Außerdem gäbe es bei Jest das Problem des fehlenden ESM Supports.
Gast Florian Dreier (Github) erzählt Peter und Vanessa von der Modernisierung eines Legacy-Frontends!
Schaunotizen
[00:02:00] Modernisierung einer Legacy-Frontend-Codebase
Florians Arbeitgeber war mit einem alten Frontend auf Basis von Googles Closure-Tools gesegnet, das modernisiert werden wollte. Zunächst listen wir die zahlreichen Gründe für das Ersetzen des alten Stacks auf (schlechte DX, Inkompatibilität zum restlichen JS-Ökosystem) und sprechen dann über die Vorarbeiten für die Umstellung. Wichtig dabei: Buy-In auf allen Ebenen ereichen, POCs zusammenhacken und nicht einfach alles neu schreiben.
Für die Überführung der Closure-Module in ES-Module wurde ein Konverter programmiert, die TypeScript-Migration mithilfe des Closure-TS-Coverters halbautomatisch und Schritt für Schritt durchgeführt. Natürlich kommen wir nicht umhin, die Entscheidung für React in Anbetracht der zahllosen Alternativen zu hinterfragen, ebenso die Entscheidung für Vite anstelle von Webpack, diskutieren die Ob und Wie von Feature-Entwicklung während des Umbaus und fragen uns natürlich auch, wie es zu verhindern ist, dass der aktuelle Code schlimmes Legacy 2.0 wird. Am Ende fasst Florian die positiven Ergebnisse des Umbaus zusammen und gibt Abschließende Empfehlungen für vergleichbare Migrationsprojekte.
Was ist der unterste Webstandard- und Hardware-Stand, den Webentwickler:innen zu berücksichtigen haben? Alan Dávalos kommt zum Ergebnis, dass Safari der ollste relevante Browser und Supermarkt-Androids die langsamste relevante Plattform sind. In Zuge der Artikeldiskussion kommen React, Transpiler, CSS Grid, fehlender Support für Subgrids und display: contents zur Sprache.
Mit structuredClone() kommt ein neuer Weg zum Klonen von JS-Objekten die Browser (z.Z. noch nur Firefox und Safari). Wir debattieren die diversen halbgaren Alternativen und die schlechten Aussichten für einen Polyfill.
Es lebt! Das neue iOS bzw. der neue Safari rüsten in Sachen Webstandards auf. Spannender als einzelne Features (PWA, Push API, scroll-behavior, :has(), <dialog>, Web Locks API (s. Revision 445)) finden wir aber den Blick auf die Gesamtsituation am Browser-Markt. Safari verwahrlost, ist (noch) der einzige Browser auf iOS und Firefox ist im Zombie-Modus auf dem Weg in die Bedeutungslosigkeit. Wir fabulieren über Wettbewerbsrecht, Verschwörungstheorien und die Zukunft der Browsermarkts.
Lange ist es her, dass wir uns zuletzt über ein CMS unterhalten haben – nun war es wieder soweit. Daniel Wentsch (Website / Twitter) war unser Gast, und das (PHP-)CMS, welches er im Gepäck hatte, Statamic.
Statamic, dessen name ein Mix aus „Static“ und „Dynamic“ darstellt, ist ein sogenanntes „Flat File“-CMS, das mit Laravel programmiert ist und das von so namhaften Playern wie dem SPIEGEL genutzt wird. Der größte Pluspunkt des CMS‘ ist, dass es Designern, Entwicklern und Redakteuren gleichmaßen gut von der Hand geht – also keiner der genannten Parteien Steine in den Weg legt. Wir reden über die Funktionsprinzipien im Umgang mit Statamic, als da wären: Content-Modeling (via Interface oder YAML) als Collections, Blueprints, Fieldsets, Fields, sowie die Bestandteile Forms und Taxonomy. Wir reden auch über den den zentralen Asset-Manager, welcher für Bilder Art-Direction unterstützt, über das Templating-System namens Antlers, sowie über Starterkits wie Peak eines ist. Schlussendlich geht um Multisite-Setups und Internationalisierung.
Die von Daniel erwähnten Statamic Tutorials vom Statamic-Experten und DER SPIEGEL Entwickler Jonas Siewertsen. Aktuell noch in Beta. Am Besten beim Newsletter anmelden!
Nachdem wir in der Vergangenheit bereits zu Tailwind 1 und Tailwind 2 entsprechende Episoden aufgenommen haben, haben wir uns anlässlich des Erscheinens der Version 3 erneut mit unserem letztmaligen Gast Milan zusammengesetzt.
Wir beginnen mit einem kurzen Recap, was das Tailwind-Framework sein möchte. Wir stellen beim Blick in The State of CSS fest, dass Tailwinds Bekanntheitsgrad und Popularität in den letzten zwei Jahren stark gestiegen ist. Mit der Version 3 haben sich die Macher dank eines neuen Just-in-Time-Compilers von bisherigen Limitierungen befreit – und dabei das Ego von JIT-Compiler-Pionieren gekränkt. Ob die Macher des Prettier-Plugins Headwind ob der Einführung eines offiziellen Plugins zum automatischen Sortieren von Tailwind-Klassen in HTML beleidigt sind, ist hingegen nicht überliefert. Für Entwickler, welche kein Node in ihren Stacks verbauen dürfen oder möchten, gibt es ebenfalls neu die eigenständige Tailwind CLI. Ansonsten bringt Tailwind 3, von allen Fesseln befreit, mehr von bislang schon Bewährtem: Mehr moderne CSS APIs, mehr Farben, mehr Media Queries, mehr Internationalisierung und mehr Feinschliff.
Marc J. Schmidt (Twitter, Github, Web), Founder bei deepkitIO und TypeScript-Nerd, hat sich Gedanken (und noch einiges mehr als bloße Gedanken) zu TypeScript-Runtime-Typen gemacht. In dieser Revision stellt er sich Peters kritischen Fragen, und stellt seine Pläne für eine neue TypeScript-Zukunft vor.
Schaunotizen
[00:01:01] TypeScript Runtime Types/Reflection
TypeScript ist de facto ein Linter und für alles, was zur Laufzeit passieren soll, braucht es Schema-Validatoren wie zod, die Schema-DSL von Prisma, JSON Schema oder eins der zahlreichen anderen Projekte aus dieser Kategorie. Wenn aber auf Client wie Server TypeScript laufen, dann, so Marc, könnten Runtime-Typen die bessere Lösung sein! Marc und Peter diskutieren den allgemeinen Wert von Typen für allerlei Use Cases, die Limitierungen der Ableitung von TS-Typen aus Runtime-Tools Branded/Nominal Types und Decorators. Der althergebrachten Debatte um Runtime Types/Reflection nähren wir uns, indem wie die Möglichkeiten des Typsystems (Declaration Merging, Control flow analysis und alles, was ts-sql möglich macht) und die Eigenheiten des Projektmanagements des Produkts TypeScript (ständige Breaking Changes, keine Spezifikation) durchkauen. Wie könnten Runtime Types umgesetzt werden? Marc hat ausführlichausgearbeitet, wie Runtime-Type-Bytecode in der Praxis aussehen könnte! Wir sprechen über den Weg zur Umsetzung, den Kampf mit privaten Compiler-Hooks und eine mögliche Zukunft für Runtime Types/Reflection im Angesicht der offiziellen Anti-Ziele von TypeScript.
Mit Frederik Braun (Github, Twitter), Firefox-Security-Großmeister und Workingdraft-Dauergast (bekannt aus den Revisionen 447 und 452) beleuchteten Schepp und Peter diverse Aspekte rund um ASTs und Security.
Schaunotizen
[00:01:02] Linting und AST
Zu Beginn klären wir erst mal, was ein Abstract Syntax Tree überhaupt ist und wie wir ihn mit dem AST explorer erforschen können. Es gibt unterschiedliche Formate und zahlreiche Use Cases (u.A. Statische Analyse via z.B. ESLint und Minifier). Den Weg zum AST via Lexer und Parser beschreiben wir grob, empfehlen für Details aber das Standardwerk Compilers: Principles, Techniques, and Tools. Freddys Use Case für AST-Arbeit ist das ESLint-Plugin no-unsanitized, das seine Ursprünge im Zusammenhang mit Firefox OS (RIP) hat. Über diesen Weg kommen wir, wie sollte es anderes sein, zu Sanitizer- und Security-Geschichten aus Freddys Alltag, v.a Multi Account Containers in Firefox, die HTML-Sanitizer-API (Specs, Workdingdraft-Revision 447, WWSIV-Folge zum Thema, Playground) sowie zu Morphdom, Tücken des HTML-Sanitizer-Baus und des HTML-Parsings, Custom Elements und allgemeinen Securityfragen. Unser Fazit: Unsicherheit hat sich als Konzept nicht bewährt und sollte abgeschafft werden.
Nicos Aufhänger für das Thema ist der Umgang mit Komplexität speziell im Bootcamp-Kontext. Davon ausgehen kommen wir zur Rule of least power, grübeln über den Mindshare-Bonus von komplexen Tools und rekapitulieren Entwicklung der Webtechnologien und die Expansion der Use Cases für Webtechnologien. Wir erzählen nicht nur Komplexitäts-Geschichten aus der Praxis (vergleichbar mit denen von htmhell.dev), sondern überlegen auch, wie es jeweils so weit kommen konnte. Gegen Ende geht’s außerdem um Titel und Stufen, Nachhaltigkeit und Mehrdeutigkeitstoleranz.
Es ist so weit, wir sprechen wieder mit Nikolaus Rademacher über agile Methoden. Der zweite Sprint, in Revision 510 angekündigt, nun geht es rund.
[00:00:59] Shownotes
Agile II – Refinement, Wasserfall, Kanban
Nachdem es in der letzten Sendung viel um die Grundlagen und die Aufgaben eines:r Entwickler:in im agilen Kontext ging, widmeten wir uns dies Mal den ganz praktischen Themen.
Die Zusammenarbeit zwischen unterschiedlichen Disziplinen wird oft unterschiedlich gehandhabt: UX/UI arbeitet einen Sprint voraus, QA hinten dran – oder doch lieber parallel. Wir sprechen, ob das sinnig ist und wie man dagegen ankommt.
Doch bevor es überhaupt in die Umsetzung geht, sollte man sich mit dem Prozess davor beschäftigen: von der Idee bis zur Umsetzung – und dann vor allem refinen, refinen, refinen.
Anschließend geht es darum, wie man in einem eher klassischeren Unternehmen mit agilen Methoden „embedded“ werden kann, um dann noch auf das Thema Feedback-Kultur zu sprechen zu kommen.
Wir schließen ab mit einer Diskussion rund um die Methode Kanban, sprechen dazu, wann es sinnig sein kann, diese zu verwenden und welche Kriterien erfüllt sein sollten.
Mit Nils Roehrig und Kevin Schoenfeld von REWE digital quatschen Vanessa, Peter und REWE-Digital-Veteran Hans über Microfrontends in der allgemeinen Theorie sowie unter dem Gesichtspunkt der konkreten Umsetzung im Arbeitsalltag von Nils und Kevin.
Schaunotizen
[00:00:59] Microfrontends
Über das Thema Microfrontends (zuletzt behandelt in den Revisionen 384 und 407) berichten Nils und Kevin aus der Perspektive von für REWE digital tätigen Frontend-Nerds. Nach kurzem rekapitulieren der Grundbegrifflichkeiten (Microfrontends = anwendung der Microservice-Idee für Web-Frontends) geht es direkt an’s Eingemachte: wir bequatschen Tradoffs von Dependency-Handling und Komponenten-Entkopplung, Herausforderungen in der Kommunikation (sowohl innerhalb größerer Organisationen als auch auf technischer Ebene) und den Umgang mit Designsystemen. Anhang von Beispielen für große und kleine Microfrontends bei Rewe digital beleuchten wir Fragen rund um Modularisierung, Komposition und Aufteilung von Microfrontends, diskutieren wie Microfrontends mit Server-Side-Rendering verheiratet werden können, streifen den Problemkomplex „Serverseitige Web Components“ und kommen dann auf Performance-Optimierung und Caching zu sprechen. Zum Ende geht’s um Project Mosaic, den Umgang mit zentralisierten Ressourcen (LocalStorage, Routing o.Ä.), Event-Handling, die Migration weg vom Frontend-Monolithen, das Zusammenspiel von Microfront- und Microbackend sowie Aspekte, die nicht sauber in eine Domäne passen. Tradeoffs, wohin man auch schaut!
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.
