Working Draft

Es geht in die nächste Runde Micro-frontends! Diesmal erzählt Simon Dittlmann (LinkedIn, Twitter), Head of Digital Architecture and Analytics bei ZEISS uns über viel über horizontale und vertikale Schnitte. Außerdem berichtet er über die technische Umsetzung der Micro-Frontends bei ZEISS mit Hilfe von Webpack Module Federation und Dapr. 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:38] MFs Architektur mit Webpack Module Federation und Dapr Zunächst besprechen Simon, Schepp und Vanessa die Split-Arten horizontal vs. vertikal, wie in dem Blogpost Micro-frontends decisions framework von Luca Mezzalira beschrieben. Weiterhin geht es um die Aufsetzung von Kompositionen und Routing in den Möglichkeiten Client-side, Edge-side oder Server-side. Ein neu geschaffenes Problem bei dem Einsatz von Micro-Frontends kann die Authentication und. Authorization sein. Simon stellt uns einen token basierten Login mit Split tokens und Phantom tokens vor. Im Anschluss geht Simon auf Rollen und attributbasiertes Rechtemanagement in verteilten System ein (siehe Open Policy Agent WebAssembly NPM Module und „How Netflix Is Solving Authorization Across Their Cloud„. Des Weiteren wird auf die Vor- und Nachteile von Polyrepositories und Monorepositories eingegangen, und wie mit Hilfe von Blackduck und OSS Review Toolkit (ORT) Lizensen überprüft werden können. Verwandte Revisionen Revision 511: Microfrontends bei REWE digital Revision 492: Der aktueller Status von Webpack Revision 407: Micro Frontends mit Project Mosaic Revision 384: Micro-Frontends | Working Draft

Nico Martin (Web, Twitter), Google Developer Expert und Webtech-Nerd, erklärt in dieser Revision Schepp und Peter alles zu WebBluetooth, WebUSB und WebNFC! Schaunotizen [00:01:01] Peripherie-APIs Es geht um Web NFC, Web USB, Web Blueooth und andere Peripherie-APIs aus dem Project Fugu (Working Draft berichtete in Revision 399). Während es Nico noch leicht fiel, Peter und Schepp die simple API für NFC im Web zu erklären, wird’s bei USB schon kniffliger. Zum anderen gibt’s neben Web USB auch noch Web HID und Web Serial, wobei gerade letzteres Sinnhaftigkeit ausgiebig diskutiert wird. Im Rahmen von Web USB empfiehlt Nico ein Tutorial, webadb.js und einen Talk von Sebastian Golasch. Wir lassen natürlich auch die Sicherheitsdiskussion nicht außer acht, debattieren die Kombination aus Web USB und der File System Access API und Nico berichtet von seinen persönlichen Web-USB-Abenteuern mit Tiptoi. Beim Thema Web Bluetooth jammert Peter zunächst über seinen einst gescheiterten Kampf gegen proprietäre Protokolle, bevor wir das Wesen von Bluetooth im Allgemeinen und Bluetooth LE (relevant für Web Bluetooth) im Speziellen beleuchten. Nico erzählt vom seinen Erfolgen in der webbasierten Ansteuerung einer Playbulb Sphere und davon, warum er am Ende dann doch lieber seine eigene Hardware gebastelt hat. Die Hauptzutaten: ein RaspberryPi, Node und bleno! Ergebnisse sind unter anderem die Ansteuerung einer kleinen LED Matrix (1, 2) und von Elektromotoren. Zum Ende hin diskutieren wir den deprimierenden Stand der Implementierung inkl. Webkit-Verweigerung, Sinn und Zweck von Peripherie-APIs und Tracking-Prevention (u.A. die von Webkit).

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. 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] 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. Im weiteren Verlaufen gehen Hans, Vanessa und Joe auch auf die Testing Pyramide und Testing Trophy ein. Besonders spannend bei der Testing Library sind die Guiding Principles. Sonstige Links Playwright, der Nachfolger von Puppeteer https://conf.vuejs.de/ https://workshops.de/ Verwandte Revisionen Revision 462: Jest Revision 442: „Next Level“-End-to-End-Testing Revision 436: Frontend Unit-Testing Revision 375: Frontent-Testing

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.