Working Draft

Gast Florian Dreier (Github) erzählt Peter und Vanessa von der Modernisierung eines Legacy-Frontends! Unser Sponsor Diese Folge wird gesponsert von REWE digital. Seit 2014 digitalisiert das Kölner Unternehmen den Lebensmitteleinzelhandel mal so richtig. Mit knapp 500 agilen Expert:innen setzt man auf eigenverantwortliches Arbeiten, Teamautonomie, modernste Technologien, individuelle Weiterentwicklung und Innovation an jeder Ecke. So leistet man wertvolle Pionierarbeit für einen der größten Handels- und Touristikkonzerne Europas. Neugierig geworden? Dann schaut jetzt auf rewe-digital.com, LinkedIn, Twitter oder YouTube vorbei und hört in REWE digitals eigenen Tech-Podcast Codes und schmerzlos rein! 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.

Schepp sprachen in dieser Throwback-Revision über diverse Browserfeatures (neu und alt) sowie die aktuelle Gesamtsituation im Browser-Markt. Unser Sponsor Factorial ist eine Digitalagentur mit einem internationalen Team und dem Fokus auf Open Source Technologien, die für regionale und internationale Kunden digitale Lösungen entwickelt. Mit Kompetenzen im Bereich Development, Design und Projektmanagement treibt die Agentur die digitale Transformation ihrer Kunden voran. Zu den Anwendungsbereichen zählen unter anderem Hosting, Content Management, Qualitätssicherung, Automatisierung und die Integration heterogener Systemlandschaften. Mehr Infos zu den aktuellen Stellenausschreibungen gibt es hier: www.factorial.io/de/jobs. In diesem Video stellt unser Kollege Julian den Frontend Job bei Factorial vor: https://bit.ly/3tZJjHz. Schaunotizen [00:02:35] The baseline for web development in 2022 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. [00:23:59] structuredClone() 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. [00:31:14] Neue Web-Features in iOS 15.4 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. [01:03:54] Keine Schaunotizen Fuite Sehr einfach zu benutzender Memory-Leak-Detektor. DOM City Spielerisch die DOM-API lernen. free-for.dev Absurd lange Liste von Services mit kostenlosen Angeboten oder zumindest Trials.

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. Unser Sponsor Diese Folge wird gesponsert von lemon.markets, einem FinTech aus Berlin, das eine Trading API für Developer anbietet. Mit lemon.markets können über 8000 Aktien und ETFs per API gehandelt werden. Neben der Verwaltung des eigenen Portfolios können auch aktuelle und historische Kursdaten abgerufen werden. Developer in der lemon.markets Community automatisieren ihre Sparpläne, bauen sich eigene Integrationen in Tools wie Telegram und Slack oder entwickeln ihre eigenen Trading Apps oder Bots. In der lemon.markets Developer Community tauschen sich zudem schon über 500 Entwickler:innen zu allen Fragen rund um die Trading API und den Aktienmarkt aus. Weitere Informationen zum Produkt und der Firma gibt es hier. Schaunotizen [00:01:36] 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. (Keine) Schaunotizen Statamic Tutorials 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! Videos der Statameet 2021 Im September 2021 fand eine kleine Konferenz zu Statamic statt, deren Talks Ihr hier schauen könnt. Vergangene Episoden mit inhaltlichem Bezug zur aktuellen Folge: Revision 342: Was gibt es Neues in Laravel? Revision 499: Laravel Livewire Revision 490: Alpine JS & Petit Vue mit Jon Uhlmann Algolia Ein gehostetes Elastic Search, für das es einen sogenannten Statamic-„Driver“ gibt.

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. Schaunotizen [00:00:59] Tailwind CSS v3.0 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ührlich ausgearbeitet, 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.

Mit 1,5 Gästen in Person von Nico König (Bootcamps und Training bei coding-bootcamps.eu) und Joschi Kuphal (tollwerk.de) eruieren Vanessa, Peter und Schepp Wohl und Wehe von Komplexität in Webtechnologien. Schaunotizen [00:00:58] Komplexität 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! Weiterführende Links: micro-frontends.org Micro-Frontends im REWE Shop – Evolution eines Headers (Slides) Example integration-patterns (Beispiele von REWE digital)

Über das Thema der Rolle und Verantwortung von Entwicklern und Entwicklerinnen in agilen Teams reden unsere Hosts Hans, Peter und Vanessa heute mit Nikolaus Rademacher, Senior Frontend Entwickler bei sipgate. Da sich das Thema als unendlich erweist, betrachten wir diese Revision als einen ersten Sprint und lassen in ein paar Wochen Teil 2 folgen. Schaunotizen [00:00:58] Die Rolle & Verantwortung von Entwickler:innen in agilen Teams Wir versuchen zu ergründen, wie sich Methoden des agilen Arbeitens in große Unternehmen einführen lassen. Wir diskutieren, ob sich Scrum und die anderen Techniken und Prinzipien des Agile Manifesto am besten von oben oder von unten einführen lassen. Über die Umsetzung von agilen Techniken kommen wir zu Fragen der Wissenvermittlung und dem Unterschied zwischen echtem agilen Arbeiten in Kontrast zum gedankenloses Anwenden von Regeln. Wir singen ein Loblied auf Retro und Refinement, beleuchten (unter dem Eindruck von log4j) den Umgang mit plötzlichen Bugs und Notfällen und deklarieren die Woche zur optimalen Sprit-Dauer. Zum Ende hin kommen wir zum Auf- und Abbau von technischen Schulden, diskutieren die Tradeoffs der Tschernobyl-Betonsarg-Ansatzes für Tech Debt und beschließen den nächsten Revisions-Sprint der agilen Workingdraft.