Working Draft

Hans, Schepp und Peter drehen am Glückrad bis das Frameset kommt!

Schaunotizen

[00:03:02] break-inside

Die an sich nur mäßig insprierende CSS-Property verleitet Schepp dazu, Multicolumn Layout zu lobpreisen, das seiner Meinung nach so manches kann ( u.A. Quasi-Masonry), das mit Grid Layout nicht drin ist.

[00:11:00] paint-order

Wir stellen fest, dass paint-order unter anderem für Textumrandungen ganz praktisch ist. Es gäbe dafür auch -webkit-text-stroke, das mittlerweile in der Bibel für Web-Kompatibilität aufgeführt und deshalb in praktisch allen Browsern zu finden ist.

[00:18:35] unload-Event

Wir grenzen das abgeranzte unload-Event von seinen cooleren Kollegen beforeunload, pagehide und Beacon API ab, diskutieren Interaktionen mit dem bfcache und überkegen, was es bedeutet, eine Webseite oder -App zu „schließen“.

[00:29:17] MIDIAccess

Wir haben in Summe ca. null Erfahrung mit MIDI, wundern uns aber nicht über die API: schließlich gib’s auch Web USB und Web Serial – und dass letzteres noch extrem verbreitet ist, hat Peter beim Cathode Ray Dude gelernt.

[00:34:58] Location, Location, Location

Wir berichten von unseren Interaktionen mit der Location-API. Peter stringifiziert sie gern, der Rest bedient sich ausgefeilterer Features wie replace oder greift gleich zur History API.

[00:39:37] Destructuring Assignment

Wir präsentieren verschiedene Stunts rund um Destructuring.

[00:45:15] fetch()

Wir listen der Abwechslung halber die zahlreichen Vorteile von XMLHttpRequest auf, wozu u.A. synchrone Requests (benutzt von Partytown) und einfaches Abbrechen gehören.

[00:52:48] Popover API

Popover war bereits das fast einzige Thema von Glücksrad-Revision 615, aber über das abstrakte Invoker-Konzept hatten wir damals noch nicht philosophiert.

[01:01:52] <frameset>

Schepp fragt sich, ob Framesets mit Grid Layout kombiniert werden können (Antwort: nope!), wonach wir über Hypermedia, Frontpage, Dreamweaver und andere Artefakte aus der Jungsteinzeit sinnieren.

Nicole Rauch sorgt in dieser Revision dafür, dass Vanessa und Peter endlich mal anfangen, brauchbaren Programmcode zu produzieren.

Schaunotizen

[00:02:19] Thema

Nicole berichtet von ihrem Einstieg in die wunderbare Welt von Software Craftsmanship und Clean Code, u. a. über die SoCraTes-Konferenzserie. Clean Code definiert sich laut Nicole darüber, was er nicht ist, nämlich räudiger Legacy-Code (siehe Cheat Sheet). Dessen Räudigkeit manifestiert sich meist durch schlechten Stil, fehlende Tests und mangelndes fachliches Verständnis-Fundament. Wie viel fachliches Know-How einem ohnehin überforderten Entwicklerhirn zuzumuten ist, (und inwiefern Entwicklungs-Techniken wie Entities, Value Objects, immutable Objekte, Test-Driven Development und das in Revision 556 beleuchtete Domain-Driven Design helfen können) wird eifrig diskutiert. Am Thema Coding Conventions kommen wir natürlich auch nicht vorbei und stellen fest, dass die Zeit der Yolo-Styles definitiv vorbei ist; neuere Sprachen wie Go und Rust liefern schließlich ab Werk Formatierungs-Tools mit. Zum Einüben von varausschauender Entwicklung empfiehlt Nicole Code Katas (z.B. via CodeKata, jskatas.org, Coding Dojo und das dank Retro-Style damit nicht verwechselbare Cyber Dojo). Dazu passen Pair- und Ensemble Programming, Strategien für den Umgang mit Schlipsen, die Clean-Code-Bemühungen torpedieren und was immer das Gegenteil von Refucktoring ist.

Es ist mal wieder Zeit für (angeblich) TypeScript und (tatsächlich) sehr viele andere Themen mit Stefan und Peter!

Schaunotizen

[00:02:16] Peak TypeScript

Zum Start erzählen wir uns semi-frustrierende Geschichten aus der TypeScript-Praxis und diskutieren, ob TypeScript überhaupt bei der Fehlervermeidung hilft – und wenn nicht, wozu es sonst gut sein könnte. Das Ausbleiben von Revolutionen in neuen TypeScript-Releases lässt uns vermuten, dass wir Peak TypeScript erreicht haben. Wir quatschen ein wenig über Rust, Web Assembly, TypeScript-Externalitäten (z.B. Bugs in Non-TS-Projekten) und machen am Ende noch einen Speedrun durch die Feature-Listen von TS 5.3, 5.4 und 5.5

In dieser Episode hat sich Schepp mit Svelte Core Team Member Simon Holthausen (LinkedIn / Mastodon / Twitter) zusammengesetzt, um über die kommende Version von Svelte zu sprechen: Svelte 5! Leider hatte Simon während der Aufnahme einen Frosch im Hals 🐸, aber er hat sich tapfer durchgebissen.

Schaunotizen

[00:01:50] Svelte 5

Wir starten mit einer Einführung, was Svelte eigentlich ist und wie es sich von anderen Frameworks unterscheidet. Simon erklärt uns, was Svelte so besonders macht und warum es sich von anderen beliebten Frameworks abhebt. Anschließend gehen wir auf den Anlass für das neue Major Release ein. Simon erläutert, warum es Zeit für Svelte 5 wurde und welche Probleme in Version 4 die Entwickler zum Handeln bewegt haben.

Die wichtigste Änderung ist das neue Konzept der Runes. Simon gibt uns eine Einführung in diese Neuerung und erklärt den Unterschied zu den bereits bekannten Syntaxen und auch zu Signals. Dies hilft uns zu verstehen, wie Runes das Arbeiten mit Svelte 5 beeinflussen werden.

Wir reden ebenfalls über die neuen Snippets und erfahren, wie diese das Arbeiten mit Svelte 5 noch einfacher und effizienter machen. Ein weiteres Thema ist die überarbeitete Template-Syntax für Events. Simon erläutert, warum diese Änderung notwendig war und welche Vorteile sie mit sich bringt.

Abschließend sprechen wir über den Upgrade-Pfad von Version 4 zu Version 5. Simon erklärt, wie der Upgrade-Prozess abläuft und welche Stolpersteine zu beachten sind. Zum Schluss sprechen wir darüber, was das Core-Team nach dem großen Release plant. Wird direkt an neuen Features gearbeitet oder ist erst einmal Urlaub angesagt?

Herzlich willkommen zum zweiten Teil unserer Mini-Serie zur Internationalisierung. In dieser Folge tauchen wir gemeinsam mit Schepp tiefer in die Herausforderungen und Best Practices ein, die mit der Anpassung von digitalen Produkten für unterschiedliche Märkte und Kulturen verbunden sind.

In dieser Folge bauen wir auf der Revision 613, dem ersten Teil, auf und beleuchten weitere vielfältige Aspekte, die bei der Internationalisierung berücksichtigt werden müssen, beispielsweise, wenns um Währungen oder die Uhrzeit geht.

Schaunotizen

[00:01:30]

Wir starten mit Use-Cases und Problemen aus der Community in die Internationalisierung.
Danach geht’s weiter mit weiteren Themen:

• Telefone: Verschiedene Vorwahlnummern und Formate.
• Datum und Zeit: Unterschiedliche Datums- und Uhrzeitformate, Sommer- und Winterzeit.
• Geld: Verschiedene Währungen und Untereinheiten.
• Einheiten: Unterschiedliche Maßeinheiten (z.B. metrisches System vs. imperiales System).
• Kultur: Kulturelle Gepflogenheiten (z.B. Glücks- und Unglückszahlen, Farben).

Danke an den Schepp, dass du uns die Themen näher gebracht hast.

In diese Revision haben wir Thomas „Tom“ Bachem aus Berlin zu Gast. Tom ist Unternehmer, Softwareentwickler, Angel-Investor, und vor allem Gründer der innovativen Tech-Hochschule CODE. Und um die geht es in dieser Folge auch.

Schaunotizen

[00:02:20] CODE Berlin

„CODE“ steht als Akronym für „Curiosity Driven Education“ – dem Lernkonzept hinter der Hochschule. Gegründet hat Tom sie, weil er selbst so eine Art Ansatz in seiner Jugend vermisst hat. Wir diskutieren über individualisierte Lernansätze, kollaboratives projektbasiertes Lernen und die Bedeutung von Inspiration und Peer-Learning in der Tech-Branche. Wir sprechen über die starke Networking-Kultur, die an der CODE forciert und gepflegt wird, über die zahlreich von ehemaligen CODE-Student*innen gegründeten Startups und über die breite Unterstützung der Projekts CODE durch deutsche Unternehmer.

Irgendein Spezialexperte dachte sich, dass ein Proposal für die Standardisierung von Signals Grund genug sei, einen Nachfolger von Revision 572 aufzunehmen. Hört euch gern an, wie der Spezialexperte zusammen mit Stefan und Gast Bernhard Mayr (Mastodon, Twitter) zum zweiten Mal erfolglos versucht, den Signals-Hype zu verstehen.

Schaunotizen

[00:01:12] Signaaaaaals!

Das Signals-Proposal lädt zu Vergleichen mit dem (eingeschlafenen) Proposal für Standard-Observables ein. Wie bei Signals gibt es reichlich JS-Implementierungen (RxJS, Bacon.js) und nicht wirklich einen offensichtlich erkennbaren Drang nach der einen Standard-Lösung. Wir spekulieren dennoch über Alternativen zu (und besseren Wegen für) Standard-Signals (z.B. ein Standard-Event-Target als Schritt 0), über die Motivation (offizielle Angaben hierzu sind eher dünn), Perspektiven der Weiterentwicklung von JavaScript allgemein und den Zustand des ECMAScript-Standards und des größeren JS-Ökosystems.

Mit Gast Hans-Christian Otto (Chef bei Suora und Tröter bei @[email protected]) starteten Schepp und Peter einen Glücksrad-Versuch.

Schaunotizen

[00:11:13] Popover und die Weiterentwicklung der Web-Plattform allgemein

Über das Popover-Attribut nebst der kompletten Popover-API und das verwandte <dialog>-Element entspann sich eine Diskussion über Polyfills (u.A. für die Popover-API) und die Weiterentwicklung der Webplattform allgemein. Von Turbolinks über View Transitions bis zu ExtJS und TailwindCSS und ts-reset mäandern wird und glauben, auf Abschweif-Rekordkurs zu sein …

[01:04:38] Character class escapes

Peter glaubt, endlich mal ungestört über reguläre Ausdrücke und speziell das v-Flag und seine Implikationen für Unicode Character Class Escapes referieren zu dürfen, doch wir bleiben nur kurz beim Thema. magic-regexp, ein Proposal für den x-Mode sowie eine Empfehlung für Regexr passen noch in den Relevanzkorrididor, doch das lässt sich über die Folgethemen nur bedingt sagen. Unter anderen sprechen wir über:

• den PHP-Package-Manager Composer
• TurbineCSS, ein altes Projekt von Schepp und Peter
• die Programmiersprache MUMPS
• die ähnlich elegante Programmiersprache Go
• Optionale Tags im Google HTML-Guide
• Peters Artikel zu MutationObserver-Performance
• Intersection Observers
• das scrollmargin-Feature des Intersection Observer
• die checkVisibility-API
• Lazy Loading in seinen diversen Facetten

Anlässlich eines tiefgehenden Metatalks, den Vanessa auf der VueJS Amsterdam 2024 von ihm erleben durfte, luden wir Niklas Dzösch, Developer Relations bei Shopware und selbst Podcaster, zu uns ins virtuelle Studio ein.

Schaunotizen

[00:02:13] Zusammenarbeit in der Software-Entwicklung – eine Diskussionsrunde

Diesmal hatten wir keinen roten Faden, an welchem wir uns lang arbeiten wollten. Stattdessen nahmen wir Niklas‘ Talk als Aufhänger, um in die Welt der fehlerhaften und gelungenen zwischenmenschlichen Interaktionen in der Software-Entwicklung einzutauchen. So kommen wir von Hölzchen auf Stöckchen und möglicherweise wurde das Ganze mehr eine Therapiesitzung mit uns allen abwechselnd auf der roten Couch :)

Links

Covve

Die von Niklas erwähnte App zur Beziehungspflege.

DevRelCon

Die Konferenz mit und über Developer Relations.

Schepp tritt in dieser Revision als Gast auf und lässt Vanessa und Peter an seinen gesammelten Fun Facts rund um Internationalisierung und Lokalisierung teilhaben.

Schaunotizen

[00:01:58] Fun Facts zu Internationalisierung und Lokalisierung

Wir starten mit den zahllosen Herausforderungen schon bei der einfachen Übersetzung von Texten, wie z.B. der Sortierung von Sprachen in einem Sprach-Auswahl-UI (für das man natürlich keinesfalls Landesflaggen verwenden sollte). In mäandernder Form sprechen wir unter anderem über kulturell suboptimale Typografie, welche Sprache die längsten Wörter hat, die extrem relevanten Unterschiede zwischen ISO 639 (Sprachcodes) und ISO 3166-1 (Ländercodes) und die unterschiedliche alphabetische Sortierung in verschiedenen Sprachen (kein Problem mit Intl.Collator). Nebenher kommen auch text-overflow, <marquee>, die für Übersetzungen möglicherweise sehr relevante CSS-Funktion attr(), automatische Übersetzungen, LINGsCARS und erste Fragen zu Webdesign zur Sprache. Nach einem unerklärlichen Exkurs zu Macbook-Tastaturlayouts stellen wir fest, dass Namen beliebige Strings sein müssen, Adressen ebenso (u.A. dank Besonderheiten in Japan, Costa Rica und Mannheim) und dass diese Revision ein Mehrteiler wird werden müssen.

Schepp, Vanessa und Peter setzen ihre Reise durch die Webtech-Features im neuesten Safari-Release fort.

Schaunotizen

[00:01:07] Re-Match Switch vs. Checkbox

Nach einer Woche des Mental-Marinierens haben wir neue Gedanken zu <input type="checkbox" switch> ausgebrütet. Zusammenfassend lässt sich festhalten, dass Entwickler:innen (unter anderem) auch die Komplexität von Checkboxes, Selects und Formularen allgemein unterschätzen. Auch die WHATWG ist mit dem Switch-Thema noch nicht am Ende!

[00:10:20] Alternativtext für generated content

Der CSS-Property content kann ein Alternativtext mitgegeben werden. Wir denken auf Screenreader-Kompatibilität herum und überlegen wie :lang() bei der Internationalisierung und @supports bei der Implementierung helfen könnte.

[00:17:55] Discrete Transitions

Mit transition-behavior können wir festlegen, wie sich zu Transitions nicht kompatible CSS-Properties verhalten sollen. View Transitions haben damit nur am äußersten Rande zu tun, kommen aber natürlich trotzdem auch zur Sprache.

[00:30:23] Custom Properties für ::backdrop

Ging bisher nicht, weil Top Layer, geht jetzt aber schon!

[00:36:18] checkVisibility()

Nomen est Omen, aber die Use Cases für u.A. Web Components und ggf. in Kombination mit dem Intersection Observer bedürfen genaueren Durchkauens. Peter überlegt, ob er nach seiner großen Mutation-Observer-Profiling-Kampagne nun auch 100.000 Intersection Observer testen muss.

[00:48:37] Custom State Set

Kurzes Referat über CustomStateSet und warum es nützlich ist.

[00:53:24] Promise.withResolvers()

Wir besprechen, ob das neue Promise.withResolvers() oder das weniger neue new Promise() besser als Wrapping-Mechanismus für den gänzlich antiken FileReader taugt. Nebenher stellt sich raus, dass CSS einen infinity-Wert kennt!

[01:12:30] Object.groupBy() und Map.groupBy()

Peter erklärt schnell die Unterschiede zwischen den beiden neuen Gruppierungs-Features (Spoiler: eins macht Objekte, eins macht Maps) und was die beiden mit den neuen Iterator Helpers zu tun haben (Spoiler: nichts).

[01:15:58] Neuer Mechanismus für die Source-Auswahl bei Media-Elementen

Wer soll entscheiden, welche Quelldatei mit welchem Codec geladen werden soll, Entwickler:in oder Browser? Schepp argumentatiert recht überzeugend für letzteres.

Schepp, Vanessa und Peter nehmen ein neues Safari-Release zum Anlass, ausschließlich über neue Web-APIs zu philosophieren. Kontroverse Themen wie der Digital Markets Act oder Peters randständige Feature-Wünsche spielen keine Rolle, wir blicken stattdessen positiv in die Zukunft!

Schaunotizen

[00:04:05] <input type="checkbox" switch>

Ein neues Input-Element? Das eigentlich nur eine Checkbox ist? Und bloß etwas anders aussieht? Und per HTML statt per appearance in die Welt gesetzt wird? Wir sind leicht überfordert und bemühen Vergleiche zum mit <details> gebauten Accordion und dem Close-Watcher-Proposal. Auch der Indeterminate-State von Checkboxen findet Erwähnung

[00:28:33] <hr> in <select>

Ähnlich wie bei <input type="checkbox" switch> sind wir uns nicht ganz über die Notwendigkeit dieses HTML-Features im klaren und probieren Alternativen mit <optgroup> zu formulieren.

[00:40:10] align-content in Block- und Table-Layouts

Exotisch, aber nicht unwillkommen.

[00:43:10] CSS Scoping

Peter bekommt den Unterschied zwischen @scope und :scope nochmal neu erklärt und moniert dann, dass weder das eine noch das andere seine absurden Anforderungen zu 111% bedient.

Erneut haben wir uns Alexander Lichter (LinkedIn / Mastodon / Twitter) in die Sendung eingeladen, der sich als Web-Engineering-Consultant, Trainer und Video–Streamer nicht nur mit Vue.js, Nuxt oder UnJS auskennt, sondern auch in den hohen Künsten der Suchmaschinenoptimierung, kurz SEO.

Gast Markus Stahmann klärt in dieser Revision über Farbsehschwäche und Farbblindheit auf. Markus ist 1. Vorsitzender des Interessenverbands der Farbsehschwachen und Farbenblinden (der die hervorragende Webseite farbsehschwaeche.de betreibt) und außerdem Webentwickler bei New Data Services, was ihn zu einem einmaligen Kompetenzknäul für uns macht!

Schaunotizen

[00:02:21] Farbsehschwäche und Farbblindheit

Wie beginnen mit den Grundlagen (Definition, Entstehung und Häufigkeit der Farbfehlsichtigkeiten) und steigen danach sogleich in Alltagsbeispiele ein. Bananen stellen sich als ein größeres Problem als der Straßenverkehr heraus, Luft- und Wasserstraßen bleiben für die Farbefehlsichtigen durch den Lanterntest gleich ganz gesperrt. Best und Worst Practices in Web und Webentwicklung kommen natürlich auch nicht zu kurz; wer die drei Regeln einhält, ist meist schon ganz gut aufgestellt. In Hinblick auf das Big Picture kauen wir mögliche Effekte des European Accessibility Act durch und überlegen wie wir in ganz alltäglichen Web-Projekten Farbsehschwächen-Kompatibilität erhöhen können.

Diese Revision wollten wir uns mit Nuxt und UnJS befassen und haben uns als Gesprächspartner Alexander Lichter (LinkedIn / Mastodon / Twitter) eingeladen, der sich nicht nur als Web-Engineering-Consultant, Trainer und Video–Streamer betätigt, sondern auch Mitglied der Nuxt- und UnJS-Teams ist.

Nach rund anderthalb Jahren, in denen wir uns mit dem Thema nicht mehr dediziert befasst haben, haben wir uns erneut Jonas Ulrich (Twitter / LinkedIn) und Daniel Ley (Twitter / LinkedIn) von kickstartDS in die Sendung eingeladen, um mit ihnen über den Stand der Dinge in Sachen Design-Systeme zu sprechen.

Schaunotizen

[00:01:31] Design-Systeme im Jahr 2024

Was wir in unserem Gespräch zunächst einmal feststellen, ist dass die Bedeutung von Design-Systemen stetig zuzunehmen scheint. Gefühlt ist das Ganze vor 10 Jahren langsam bei den ersten großen Playern losgegangen, und mittlerweile gibt es sie überall. Wir vermuten, das hat ganz stark mit Tools wie React und Figma zu tun, die Design-System-freundliche Ansätze verfolgen.

Es liegt aber auch daran, dass Design-Systeme mit vielen Vorteilen locken: Sie unterstützen bei der Zusammenarbeit zwischen Entwicklung und Design, weil sie ein gemeinsames Verständnis der Sprache des anderen etablieren helfen. Dem Management wiederum bieten sie Vorteile in Form von Skalierung einerseits und Kostenersparnis andererseits. Auch schneiden wir das Thema ROI eines Designsystems an und sprechen darüber wie die Einführung in einer Organisation erleichtert werden kann, um eine bessere Adaption zu erzielen. Wir sind uns aber darin einig, dass ein wesentlicher Teil des Erfolgs nicht von technischen Aspekten, sondern auch von Stakeholder-Management und Kommunikation abhängt.

Apropos Technik: natürlich diskutieren wir über Vor- und Nachteile verschiedener Frontend-Stacks wie React und Web-Komponenten, welches Framework für die Zukunft relevant sein wird und wie der Transfer von Code zwischen verschiedenen Frameworks erleichtert werden könnte. Weiterhin erörtern wir, wer in einem Unternehmen oder Team für das Design-System verantwortlich sein sollte und wie Entscheidungen in diesem Zusammenhang getroffen werden können. Und schließlich weisen wir darauf hin, dass Design-Systeme am Ende immer nur so gut sind wie die sie Nutzenden ein Verständnis der darunter liegenden Konzepte haben.

Das zeigen auch Jonas‘ und Daniels Erfahrungen beim Einsatz ihres Open-Source Design-System-Frameworks kickstartDS bei Kunden: So mächtig das Framework auch ist, so unklar ist vielen unerfahrenen Neu-Design-System-Nutzenden, wie sie zu einem großen ganzen zusammenfügen und es an Ihre bestehenden Systeme anbinden können. Deshalb stand das letzte Jahr bei kickstartDS ganz im Zeichen der Weiterentwicklung hin zu einem nunmehr schlüsselfertigen Frontend, mit typischen UI-Komponenten, Adaptern für Storyblok, Eleventy & Co. und einem anschaulichen Showcase obendrauf.

[00:00:00] Keine Schaunotizen

Jonas‘ Artikel zum Thema JSON-Schema

Part 1: https://www.kickstartds.com/blog/unlocking-the-frontend-pt1/
Part 2: https://www.kickstartds.com/blog/unlocking-the-frontend-pt2/

Ruhmesmeile

Jonas‘ und Daniels Web-Agentur aus Bonn

In heldenhafter Manier setzte sich Martin Dilger einem durch Vanessa und Peter veranstaltetem Kreuzverhör aus, um die frohe Kunde der Einheit von Dev, Business, Design und Marketing zu verkünden. Martin war zuletzt in Revision 594 (Vom Chaos zum Code) zu Gast.

Schaunotizen

[00:02:12] Requirement Engineering mit Event Modelling

Martin identifiziert das Ermitteln und Kommunizieren von Requirements als das größte Problem im Software-Engineering und stellt seinen Event-Modelling-Ansatz als Lösungsvorschlag vor. Mit uns spielt er einen entsprechenden Workshop durch, der alle Stakeholder an einen Tisch holt und die umzusetzende Software als eventgetriebenes System planen lässt. Von der Philosophie des Ansatzes über Parallelen zu Domain Driven Design (siehe Revision 556) bis hin zur Weiterentwicklung des Modells über die Zeit wird keine Plaungsphase außer acht gelassen.

⚠️ Content-Warnung: In dieser Episode sprechen wir über Depressionen. Bitte beachtet, dass einige Inhalte möglicherweise belastend sein könnten. Wenn ihr Unterstützung benötigt, wendet euch bitte an professionelle Hilfsangebote, wie beispielsweise die Stiftung Deutscher Depressionshilfe.

Diesmal sind Pepo (Pascal Szewczyk) und Pia Hofmeier mit dabei. Wir sprechen über mentale Gesundheit.

Schaunotizen

[00:02:04] Mentale Gesundheit

Das Thema mentale Gesundheit am Arbeitsplatz ist für uns sehr wichtig. Wir sind deshalb froh, dass wir Pepo und Pia für die Sendung gewinnen konnten. Peter schildert seine Erfahrungen mit Depression als Betroffener und zeigt anhand einiger Beispiele, welchen Einfluss und Auswirkungen die Depression auf seine Arbeit und das Leben allgemein hat. Pia hilft uns dies allgemein einzuordnen und wir sprechen darüber, wie man mit Menschen mit Depression umgehen und diesen helfen kann.

Wir hoffen, dass wir mit dieser Sendung mehr Sensibilität für das Thema schaffen können und Betroffenen sowie Helfenden, das Gespräch darüber erleichtern können.

In dieser Episode tauchen wir, zusammen mit unserem Gast Martin Helmich, in die faszinierende Welt der Kommandozeilenprogramme und deren Bedeutung für die Developer Experience ein. Martin, Experte in Software- und Cloud-Architektur sowie Developer Relations bei Mittwald, teilt seine umfassenden Einblicke und Erfahrungen mit uns. Wir entdecken eine spannende Wetteranwendung für das Terminal und diskutieren, wie die Effizienz und Vorteile der Kommandozeile für Power-User nicht nur die alltägliche Arbeit erleichtern, sondern auch eine besondere Form der User Experience darstellen.

Schaunotizen

[00:01:42] UX auf der Kommandozeile

In unserem Gespräch erkunden wir die Vielfalt der „Command Line Interface“- aka CLI-Tools und deren Einsatzmöglichkeiten in unterschiedlichen Szenarien. Von der einfachen Verwendung für Git-Operationen, über Brew bis hin zu spezialisierten Anwendungen für Cloud-Dienste und Content-Management-Systeme, die Kommandozeile ist ein mächtiges Werkzeug in der Entwicklerwelt.

Martin betont, wie wichtig eine gute Developer Experience ist, um effektiv und effizient mit Kommandozeilenprogrammen arbeiten zu können. Wir sprechen über die Herausforderungen und Lösungen bei der Erstellung benutzerfreundlicher CLI-Programme, die sowohl für Einsteiger als auch für erfahrene Entwickler geeignet sind.

Wir lernen, dass wir grundsätzlich jede Programmiersprache zum Schreiben von Kommandozeilen-Werkzeugen hernehmen können, es aber deutlich angenehmer wird, wenn wir uns Hilfe von darauf spezialisierten Frameworks holen, die von Haus aus Lösungen für viele typische Anwendungsszenarien anbieten:

• JavaScript: Open CLI Framework (OCLIF), commander.js
• Go: Cobra
• PHP: symfony/console
• Python: Click

In OCLIF tauchen wir tiefer ein und lernen Dinge über Flags, über interaktive vs. non-interaktive CLI-Programme, dass eine Ausgabe rückwärtskompatibel, da „grep-bar“ sein sollte, und dass CLI-Werkzeuge responsive sein müssen, nämlich in der Form, dass sie automatisch bemerken, ob sie in einem ausgabefähigen Terminal („TTY“) laufen oder nicht, und sich daran anpassen.

Gegen Ende werden wir fast des Wahnsinns fette Beute, als wir nämlich hören, dass es sogar ein React-basiertes Framework zum Bauen von CLI-Tools namens Ink gibt. 🤯

In einer etwas speziellen Folge haben sich Peter, Vanessa und Hans zusammengesetzt und einfach drauf losgeplappert. Ein richtiges Thema gab es nicht, weswegen es zwar nicht um Gott und die Welt, aber um Bohrhämmer und UML-Diagramme ging.

Schaunotizen

[00:03:00] Werkzeuge im Meatspace

Wenn ihr schon immer mal wissen wolltet, auf welcher Seite der Hilti-vs.-Bosch-Debatte wir stehen und ob „entspinnifizieren“ mit Kabel oder Akku besser geht, klären wir das ein für allemal. Außerdem geht es kurz um Fahrräder und das Reinigen von Fahrrädern, wahlweise mit spezialisiertem Tooling oder ausgedienten Spülbürsten.

[00:18:50] Kaffee, Kaffeezubehör und Koffein-Trägersubstanzen

Hans nerdet über Espresso ab und wir debattieren über den Wert von unterschiedlichen Kaffees in unterschiedlichen Lebenslagen. Wir klären, wie viel Esspresso kommt aus dem „„„„„Esspressokocher“““““ herauskommt, überlegen ob die 9Barista Espresso Machine ihren Mondpreis wert sein könnte und debattieren die Qualitätsunterschiede von Kaffeemühlen. In qualifiziert gibt’s mehr von dem Thema auf Youtube bei James Hoffmann.

[00:46:23] Software-Empfehlungen

Wir empfehlen und diskutieren unterschiedlichste Software-Produkte aus allen möglichen Kategorien, beginnend bei den Bildschirm-Wach-Haltern Amphetamine (Mac) und Caffeine (Linux). Der Zettelwirtschaft treten wir mit Obsidian und Passwordmanagern wie 1Password entgegen, warnen aber auch davor, sich darauf zu sehr zu verlassen (1Password im speziellen hat erhöhtes Risiko für Enshittificaton und/oder Exitus). Zum reviewen und mergen von Code stellen Graphite, Git Tower und Sourcetree ernstzunehmende Alternativen füreinander dar, während die einzige Alternative zu DevUtils räudige Textareas auf shady Websites sind. Hans spricht sich für den „Pocket Coach“ Ahead aus, Vanessa für den CV-Generator Oh My CV!, aber im allgemeinen taugt auch schieres HTML/CSS als LaTeX-Ersatz für schöne Dokumente. Für visuelles empfehlen wir Mermaid (ASCII->Diagramm-Transformator) (Online-Grafiktool) (Offline-Vektorgrafikeditor) und („visueller Workspace“), für Präsentationen unter anderem Pitch und Slidev. Nachdem wir eine Lanze für selbstgeschriebene Software gebrochen haben (xkcd) beenden wir die Sendung mit den Mastodon-Clients Ivory (iOS) und Elk (Web) dem Kalender Cron, dem Task-Manager Things, dem Mail-Client Superhuman und einer Diskussion rund um Podcast-Apps wie Overcast und Spotify.

In dieser Revision haben Hans und Schepp Besuch von Florian Geierstanger (Web / LinkedIn / Mastodon) und Simon Praetorius (Web / LinkedIn / Mastodon), ihres Zeichens TYPO3-Frontend-Dompteur und TYPO3-Core-Entwickler und Berater.

Schaunotizen

[00:02:20] Komponentenbasierte Frontends in TYPO3

Diese Revision interessiert uns, ob, und wie man im Content-Management-System TYPO3 ein komponentenbasiertes Frontend konstruieren kann. Bevor wir in diese Frage eintauchen, lassen wir uns von unseren Gästen den Werdegang, die Philosophie und die aktuelle Stellung von TYPO3 im Markt erklären. Nach einigen Höhen und Tiefen ist TYPO3 nun schon seit Längerem wieder in guten Fahrwassern und es sind zahlreiche gute Dinge hineingeflossen und neue in der Roadmap geplant. Was TYPO3 im Core nicht mitbringt, rüsten zahlreiche TYPO3-Extensions nach, von denen einige auch den offiziellen Segen des Core-Teams haben – was bedeutet, dass sie gut gepflegt sind. Das mächtige Template-System basiert auf XML und nennt sich Fluid. Headless lässt es sich ebenso betreiben wie mit „Head“. Und natürlich besitzt TYPO3 seine Version von Hotwire namens „Topwire„.

TYPO3 mischt im deutschsprachigen Markt als einziges Open Source System im Enterprise-Umfeld mit und hat so einen guten Ruf, dass sogar der Bund drauf setzt. In den letzten Jahrzehnten hat sich rund um TYPO3 eine große Community geformt, die sich regelmäßig Online austauscht, sich zu Meetups trifft, oder auf den jährlich stattfindenden TYPO Developer Days.

Als vom Backend her entwickeltes System, ist TYPO3 nicht „out of the Box“ auf die komponentenbasierte Entwicklung von Frontends ausgelegt. In diese Lücke stieß nun Simon und lotete aus, was sich machen ließ. Was nicht passt, wird passend gemacht und so ergibt es sich, dass man für sein Frontend letztendlich doch Komponenten-Bibliotheken/-Styleguides einsetzen kann, und/oder Bootstrap, und man alles mit Vite verdrahten kann, das einem alle Assets zusammenschnürt.

Mit unserer Gästin, der Entwicklerin und Trainerin Martina Kraus sprachen wir zuletzt über das Thema Revision 482: Angular im Jahr 2021. Dieses Mal sollte es nicht um Angular gehen, sondern um WebAssembly. Fasten your seatbelts!

Schaunotizen

[00:01:33] WebAssembly – Vergangenheit, Gegenwart und Zukunft

Wir beginnen mit einem kleinen Recap, was WebAssembly denn überhaupt ist: WebAssembly ist eine von JavaScript-Engines abgeleitete, plattformunabhängige Ausführungsumgebung, die es ermöglicht, Code aus anderen Programmiersprachen dafür umzuwandeln und ihn dann nahezu in Originalgeschwindigkeit auszuführen.

Die ersten Umgebungen, die WebAssembly unterstützt haben, waren die Browser. Alle aktuellen Browser, aber auch Node, Deno oder Bun unterstützen die Ausführung von WebAssembly. Mit Hilfe von wasm-bindgen kann WASM-Code mit JavaScript kommunizieren und zusammenarbeiten.

Neuerdings gibt es, dank des WASI-Standards aber auch eigenständige Ausführungsumgebungen für WebAssembly, um Code plattformunabhängig auszuführen – die bekannteste derzeit: Wasmer inklusive Packet-Registry.

Die Zukunft von WebAssembly sieht Martina in der Nutzung als „Serverless Functions“, also in Form von schnell erzeugtem „Fire and Forget“-Code, der irgendwo in der Cloud läuft.

Keine Schaunotizen

Das V8 Blog

Hier posten die V8-Ingenieure regelmäßig über die Verbesserungen an der Engine.

Debug C/C++ WebAssembly

Hier findet Ihr beschrieben, wie Ihr mit den Chrome Devtools WebAssembly-Code debuggen könnt. Ein Video-Tutorial gibt es auch.

Willkommen zur 600ten Revision unseres Podcasts, die wir am Sonntag, den 7. Januar 2024, in Form einer live abgehaltenen Fishbowl-Diskussion mit etwas über zwanzig Gästen durchgeführt haben. Wir haben dabei über drei verschiedene Themenblöcke gesprochen, die wir per Voting bestimmt haben:

1. Web Components
2. Erwartungen an den Framework-Jungle 2024
3. Design Systeme

Unsere Teilnehmerschar bestand aus ehemalige Gästen wie z.B. Marvin Hagemeister, Jens Grochtdreis oder Alexander Lichter, aber auch aus vielen neuen Gesichtern. Darüber haben wir uns sehr gefreut!

Schaunotizen

[00:10:38] Web Components

Wir starteten mit den Web Components. Zunächst ging es darum, ob Web Components überhaupt „einsatzbereit“ seien. Und wir diskutierten, wie sich Web Components mit anderen Frontend-Frameworks verbinden lassen. Zum Glück gab es bereits Artikel darüber, wie Frameworks und „Custom Components“ erfolgreich kombiniert werden können, wie z.B. der „Custom Components Everywhere„. Besonders spannend war, dass die Seite Reddit anscheinend teilweise bereits mit Web Components erstellt wurde. Dies war jedoch noch nicht für alle Benutzer verfügbar – in diesem Fall half der Inkognito-Modus und das Ausloggen -, aber dann konnten die Teilnehmer die neue Webseite mit Web Components betrachten. Wir haben natürlich über den Shadow DOM und die damit einhergehenden Probleme gesprochen. Wenn jemand noch auf der Suche nach überzeugenden Argumenten für Web Components auf Management-Ebene war, empfahlen wir das Lesen dieses Web Components Elevator Pitchs.

• https://nolanlawson.com/2023/12/30/shadow-dom-and-the-problem-of-encapsulation/
• https://blog.jim-nielsen.com/2023/html-web-components-an-example/
• https://custom-elements-everywhere.com/
• https://jakelazaroff.com/words/web-components-eliminate-javascript-framework-lock-in/
• https://gomakethings.com/the-elevator-pitch-for-web-components/
• https://openui5.org/
• https://sap.github.io/ui5-webcomponents/
• https://livebook.manning.com/book/micro-frontends-in-action/
• https://caniuse.com/declarative-shadow-dom

[00:56:54] Erwartungen an den Framework-Jungle 2024

Die Diskussion ging nahtlos zum Thema Frontend-Frameworks über. Zuerst haben wir darüber gesprochen, ob die Teilnehmer:innen zu dieser Zeit „FOMO“ (Fear of missing out) in Bezug auf die aktuellen Frontend Frameworks empfanden. Danach haben wir erörtert, wie viele verschiedene Frameworks tatsächlich in der „Realität“, also in Arbeitsprojekten, verwendet wurden. Einige Personen haben ihre Erfahrungen geteilt, wie sie Frameworks oder Bibliotheken wie NPM-Pakete komplett ausgetauscht haben. Wir haben die Vor- und Nachteile der Verwendung von Bibliotheken im Allgemeinen besprochen. Marvin hat in diesem Zusammenhang passenderweise den Link zu einem XKCD-Comic über Bibliotheken im Web geteilt.

• https://workingdraft.de/595/ (HTML over the Wire)
• https://workingdraft.de/576/ (Qwik)
• https://workingdraft.de/584/ (Solid & Solidstart)
• https://workingdraft.de/552/ (Frontend-Development im Jahr 2023)
• https://workingdraft.de/405/ (rollup.js)
• https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-8/
• https://vinxi.vercel.app/
• https://github.com/unjs/
• https://workingdraft.de/565/ (Quo Vadis Frontend-Tooling?)
• https://socket.dev/blog/when-everything-becomes-too-much

[01:59:55] Design Systeme

Mit einer fulminannten Überleitung von Hans gelangten wir zum Thema Design Systeme. Sowohl in der Live-Diskussion als auch im Chat gingen viele Themen hin und her. Wir sprachen darüber, wer in Projekten für die Instandhaltung von Pattern Libraries verantwortlich ist. Es stellte sich auch heraus, dass es bei dem Thema viel um Kommunikation geht. Die Teilnehmenden nannten Tools wie Storybook, story.to.design, Histoire, UXPin und Ladle. Schließlich eröffnete Hannah die Diskussion darüber, wer tatsächlich mit „Design Systemen“ und nicht nur Pattern Libraries im Designbereich, beispielsweise mit Figma, arbeitete.

• https://histoire.dev/guide/getting-started.html
• https://help.figma.com/hc/en-us/articles/360045003494-Storybook-and-Figma
• https://story.to.design/
• https://www.uxpin.com/
• https://ladle.dev/
• https://fractal.build/
• https://www.youtube.com/watch?v=qtAu1V6v6YQ (Exploring the Anatomy of Design Systems)
• https://esilva.net/sociotechnical/sociotechnical-architecture_why-and-what.html

In der letzten Revision vor der großen Jubiläumsfolge wir nochmal heftigst am Glücksrad gedreht! Ungeplant purzelt aus unserem Zufallsgenerator dabei recht viel SVG-eskes!

Schaunotizen

[00:02:57] Das class-Attribut

Zunächst einmal wollen wir wissen, wie lange es dieses Attribut schon im HTML-Standard gibt. Stellt sich aber heraus, es ist gar nicht so einfach, das herauszufinden! Hans erinnert sich an die Möglichkeit, mit bestimmten Attribut-Selektoren nur nach Teilen des Klassennamens suchen zu lassen und so Klassen „(de-)composable“ zu machen. Dank MDN lernen wir, dass Klassennamen case-sensitiv sind. Wir outen uns als große Fans des classList-DOM-Interfaces. Wir kommen sodann zurück zur Anfangsfrage, da Peter zwischenzeitlich erfolgreich recherchiert hat, seit wann es das Attribut gibt. Wir erfahren, dass es nach dem ersten Proposal von HTML und vor HTML 2.0 noch ein Proposal namens HTML+ gab und dass das class-Attribut schon Teil von HTML 2.0 aus 1995 war. Das ganze erscheint uns vorausschauend auf das 1996 standardisierte CSS.

[00:09:19] <style>

Hans erinnert sich, dass es mal ein scope-Attribut gab, mit dem sich der Wirkungsbereich eines <style>-Elements auf den DOM-Zweig begrenzen ließ, in dem es selbst eingehängt war. Weil aber zu wenig Browser das Attribut implementiert haben (und vermutlich wegen der Erfindung von Shadow-DOM) wurde es später wieder aus dem HTML-Vokabular entfernt. Es schicken sich nun aber als Ersatz die „Scoped Styles“ in Form der @scope-Rule an, die in Chrome und der Safari Technology Preview schon unterstützt werden. Peter hätte gerne die Möglichkeit, so ein Verhalten by default zu aktivieren – möglicherweise per HTML customized built-ins. Aber die wollte das Webkit-Team nie implementieren und so kann man sie als gescheitert ansehen. Wir schauen uns anschließend noch an, welche Attribute oder Eigenschaften <style>-Element unterstützen. Peter weiß zu berichten, dass es eine per JavaScript zugängliche Eigenschaft namens .disabled gibt, mit der man einzelne Stylesheets imperativ aktivieren oder deaktivieren kann. Außerdem arbeitet man ganz neu an einem blocking-Attribut, mit dem man dem Browser z.B. mitteilen kann, dass das Rendern (nicht aber das Parsen) einer Seite so lange ausgesetzt werden soll, bis die mit einem blocking="render" markierte Ressource geladen ist. Wollen könnte man das im Zusammenspiel mit den neuen Multi-Page-View-Transitions.

[00:27:26] SVG Text Positioning (dy)

Zufällig weiß Schepp, was dieses Attribut macht, weil er für den örtlichen, jährlich stattfindenden Trödelmarkt immer das Stand-Layout mit per JavaScript generiertem SVG erstellt. Und dabei verwendet er das dy-Attribut zu Hauf, um Dinge relativ zur letzten verwendeten Position zu zeichnen. Ein weiteres sehr praktisches Attribut in SVG ist lengthAdjust, mit dem man Text in die Breite einer Box genau einpassen kann.

[00:37:32] border-top-style

Schepp meint, hier benutzt er ausschließlich solid oder none. Alle anderen Styles hält er für überflüssig. Peter hält dagegen, dass er gerne die dotted-Variante nutzt, dem Schepp aber dashed vorziehen würde. Hans führt die Property zu dem Thema, dass man mit border-Tricksereien immer Tooltip-Pfeile gebaut hat. Und wenn man einen Tooltip-Schatten möchte, der das Pfeilchen mit umfasst, dann nimmt man statt box-shadow besser filter: drop-shadow(), was wiederum nur einen Shortcut für einen SVG-Filter darstellt.

[00:43:19] CSS‘ <position>-Datentyp

Dieser Datentyp besteht aus zwei Positionsangaben (als Keyword wie z.B. center, als absoluter oder als Prozentwert) und wird z.B. in der CSS-Eigenschaft background-position verwendet. Zudem lässt sich seit einigen Jahren vor jede Nicht-Keyword-Längenangaben mit einem… Keyword die Ausrichtung bestimmen, von der aus sie arbeitet: bottom 12vmin right -6px. Schepp weist zudem noch auf die gerne übersehene Tatsache hin, dass die Positionsangaben nicht nur auf die Position in einem Container einwirkt, sondern sie auch den Ankerpunkt in dem zu positionierenden Objekt verschiebt. Andernfalls könnte ein Objekt nicht gleichzeitig bei einem Wert von 0% links, und bei einem Wert von 100% rechts am Container anliegend positioniert werden – siehe absolute Positionierung. Zur Verdeutlichung dessen hat er dieses Codepen erstellt. Wir sind uns außerdem darin einig, dass der Default für background-repeat irgendwie doof ist. Aber das hat ja sogar die CSS Working Group selbst erkannt. Am Ende spannen wir den Bogen nochmal zu SVG zurück, weil das keine Hintergrundbilder kennt, oder sie nicht so unterstützt wie HTML und man z.B. für einen vollflächig eingefärbten Hintergrund ein gefärbtes Rechteck über die gesamte SVG-Canvas ziehen muss. Peter weiß noch zu berichten, dass wenn man dem <body>-Element ein Hintergrundbild gibt, dieses in aller Regel „nach oben“ ans <html>-Element promoted wird und es daher auch bei komplett leerer Webseite und in der Höhe kollabiertem <body>-Element zu einem vollflächigen Hintergrund kommt.

[00:58:08] CSS‘ <url>-Datentyp

In die url()-Funktion lässt sich nicht nur eine Bild-URL einbauen, sondern auch Data-URIs. Und welche ist uns da die liebste? Natürlich Inline-SVG! Hans muss plötzlich an altertümliche Internet-Explorer-Hackereien mit der (deprecateten) behavior-Eigenschaft und CSS3Pie zurückdenken. Und an die Webseite browserhacks.com. Sodann driften wir in eine Diskussion darüber ab, ob Webentwicklung wohl eher früher oder eher heute komplexer war/ist. Schwer zu sagen. Den Faden wieder aufnehmend, verweist Schepp auf ein Blogpost von Stefan Judis, das sich damit befasst, dass man in der url()-Funktion keine Custom Properties verwenden kann, was daran liegt, dass der Inhalt von url() einfach nicht eindeutig parsebar ist, was wiederum daran liegt, dass man Inhalte genau so gut mit wie ohne doppelte Anführungszeichen hineinsetzen kann. Ein schöner Spec-Fuckup! Repariert wird das durch die Nachfolger-Funktion src(), die im Grunde ein Alias von url() ohne extra Parserregeln ist, die derzeit aber noch in keinem Browser implementiert ist. Dieses Spec-Fuckup entführt uns gedanklich zu den CSS-Pseudoklassen :empty und :blank, die ebenfalls nicht ganz zu Ende gedacht waren.

Keine Schaunotizen

JScript

Microsofts Take von JavaScript

Dynamic HTML (DHTML)

Die ersten Gehversuche in dynamisch gescripteten Webseiten

Anmeldung zur Revision 600 im Online Format

Hier geht’s zur Anmeldung auf MeetUp

Feiert am 07.01. von 15 bis 18 Uhr mit uns die 600. Podcast-Episode bei einem einzigartigen Online-Event! Wir veranstalten eine Fishbowl-Diskussion, bei der einige Teilnehmer im ‘inneren Kreis’ diskutieren, während andere im ‘äußeren Kreis’ zuhören und dann einsteigen können. Es ist eine interaktive und dynamische Form des Austauschs, perfekt, um tief in das Thema Webentwicklung einzutauchen. Wir freuen uns auf euch!

Seit nunmehr gut vier Jahren unterstützt uns Autorin, Sprecherin und Radiomoderatorin Sabine bei der Post-Produktion unserer Podcastfolgen. Das hat nicht nur für lang ersehnte Entlastung bei uns Hosts gesorgt, sondern auch die Qualität unseres Audio deutlich nach oben geschraubt. Sabine gibt uns nämlich Tipps für besseres Sprechen und nimmt sich auch immer die Zeit, jede Folge im Detail abzuhören und überflüssige Pausen und „Ähms“ herauszuschneiden.

Dafür von uns tausend Dank an Dich, Sabine!🙏🥰 Und ebenso tausend Dank an Euch Hörer*innen und Sponsor*innen, dass wir durch Euch die notwendigen finanziellen Mittel dafür haben ❤️.

Sabines akribisches Durchhören der Episoden hat außerdem noch einen tollen Nebeneffekt: Wir bekommen am Ende eines jeden Jahres nun immer Outtakes, die sie über das Jahr verteilt sammelt und uns und Euch als Weihnachtsgeschenk zusammenschnürt 🎄🎁. Und die sind immer fantastisch – hört selbst und rutscht anschließend gut!✨

In der jüngsten Ausgabe erörtern Hans und Vanessa das komplexe Thema „Onboarding“. Sie knüpfen an ihre frühere Diskussion (Link siehe unten) über das Einstellen von Webentwickler:innen an und bieten wertvolle Einblicke in die verschiedenen Aspekte und Herausforderungen des Onboarding-Prozesses.

Schaunotizen

[00:02:51] Erfolgreiches Onboarding – Einblicke mit Hans & Vanessa

Zunächst beleuchten Vanessa und Hans die Bedeutung einer gut durchdachten Checkliste, die den Übergang für neue Teammitglieder erleichtern soll. Schon vor dem ersten Arbeitstag, im Rahmen des Preboardings, können wichtige Grundlagen gelegt werden. Dazu gibt praktische Tipps zur Bestellung und Einrichtung von Laptops sowie zum Einrichten notwendiger Zugänge.

Ein zentraler Punkt ist die Vermittlung von implizitem Wissen, das für die Arbeit mit jeder Codebasis unerlässlich ist. Die Schaffung verständlicher Readme-Dateien und Troubleshooting-Dokumentationen ist dabei ein Schlüssel zum Erfolg. Hans und Vanessa diskutieren auch über die täglichen Routinen und Prozesse wie Git, Ticketing, Code Reviews und Testing, die für die Aufrechterhaltung der Codequalität und eine effektive Teamarbeit entscheidend sind.

Der erste Tag des Onboardings wird als entscheidend für den weiteren Verlauf der Einarbeitung hervorgehoben, ebenso wie die Einführung von Mentor- oder Buddy-Programmen, die neuen Teammitgliedern als Orientierungshilfe dienen. Die Bedeutung regelmäßiger Feedback-Gespräche, insbesondere zur Halbzeit der Probezeit, wird unterstrichen, um den Fortschritt zu bewerten und konstruktives Feedback zu liefern.

Darüber hinaus erläutern sie die Wichtigkeit, den neuen Entwickler:innen eine Übersicht über Karrierepfade im Unternehmen zu geben. Sie diskutieren, wie automatisierte Onboarding-Prozesse dazu beitragen können, die Einarbeitungsphase effizienter zu gestalten. Dabei gehen sie auch darauf ein, wie viel Onboarding verschiedene Personen gebrauchen könnten. Brauchen z.B. Junior Developer mehr Onboarding als Senior Developer? Abschließend wird die Bedeutung hervorgehoben, das eigene Produkt aus der Nutzerperspektive zu verstehen und zu erleben, was ein tiefgreifendes Verständnis für die Arbeit der Entwickler:innen fördert.

Ähnliche Revisionen

• Revision 593: Webentwickler:innen erfolgreich einstellen – Einblicke mit Hans & Vanessa

Anmeldung zur Revision 600 im Online Format

Hier geht’s zur Anmeldung auf MeetUp

Feiert am 07.01. von 15 bis 18 Uhr mit uns die 600. Podcast-Episode bei einem einzigartigen Online-Event! Wir veranstalten eine Fishbowl-Diskussion, bei der einige Teilnehmer im ‘inneren Kreis’ diskutieren, während andere im ‘äußeren Kreis’ zuhören und dann einsteigen können. Es ist eine interaktive und dynamische Form des Austauschs, perfekt, um tief in das Thema Webentwicklung einzutauchen. Wir freuen uns auf euch!

Diverse Release-Ankündigungen des Apple-Teams stellten für Peter und Schepp den Anlass, zu schauen, was sich bei Team WebKit so tut. Und das ist eine ganze Menge! Deshalb haben wir es auch nicht in eine Revision quetschen können, sondern sie benötigten derer zwei. Wir stützen uns dabei auf die Release-Notes von Safari 17 und 17.2 Beta sowie den Safari Technology Previews 178, 180 und 181.

Schaunotizen

[00:01:49] Die Cookie Store API

Die Cookie Store API erhält nun auch in Safari Einzug und verbessert die Developer Experience in einem lange vernachlässigten Bereich: Dem Umgang mit Cookies. Zuvor gab es ja nur document.cookie für den Zugriff auf selbige, wobei das Setzen von Cookies darüber noch gerade so okay war, aber beim Auslesen alle Cookies zusammen in einem großen zusammengemantschten String herauskamen, den man im Anschluss selber parsen musste. Fehlt nun noch Firefox, auf dass alle Browser die neue API unterstützen. Peter verweist auf einen Edgecase, bei dem Chrome in der alten „API“ document.cookie jegliche Daten, die nicht UTF-8-formatiert sind stillschweigend fallen lässt. Hier herrscht(e) wohl beim neuen Standard noch Unklarheit, ob man Dinge hier ebenso handhaben möchte, oder nicht. Peter kommt in dme Zuge auf das Intl.Segmenter-Objekt zu sprechen, das für das Arbeiten mit erweiterten Zeichensätzen und auch Emojis gedacht ist, aber leider nicht vom Firefox unterstützt wird.

[00:10:24] Das <search>-Element

Das neue <search>-Element dient wie damals das <main>-Element als syntaktischer Zucker, um eine passende Landmark/ARIA-Role implizit ins Element einzubacken. Dass das sinnvoll ist, belegt eindrucksvoll der Web Almanac 2022, der zeigt, dass passende Elemente viel öfter genutzt werden als die dazugehörigen role-Attribute.

[00:25:00] Popover API

Hinsichtlich der nun auch in Safari eingebauten Popover API verweisen wir auf die Revision 585.

[00:26:30] <hr>s in <select>s

Für eine übersichtlichere Strukturierung von <select>s erlauben es Safari und Chrome nun, <hr>s unter die <option>– und <optgroup>-Elemente zu mischen. Peter und Schepp testen in dem Zuge, was Browser mit unzulässigen HTML-Elementen in <select>s machen.

[00:33:48] font-size-adjust: from-font

Anders als von Schepp vermutet, dient dieser Wert dazu, ein Verrutschen von Inhalt zu verhindern, wenn eine Schrift aus dem Font-Stack nicht geladen werden kann und dann eine Fallback-Schrift mit ganz anderen Metriken genutzt wird. Mit code>font-size-adjust: from-font werden diese Werte aus der ersten verfügbaren Schrift abgeleitet.

[00:37:46] hyphenate-character

Ab jetzt könnt Ihr angeben, mit Hilfe welchen Zeichens Worttrennungen stattfinden mögen. Da uns der Usecase nicht so ganz klar ist, forschen wir live ein wenig dazu und lernen, dass es das Canadian Syllabics gibt, das wie ein Gleichzeichen aussieht.

[00:40:20] @counter-style

Mit der @counter-style-Rule lässt sich eine Art visuelles Template für Aufzählungen anlegen, das man anschließend per list-style-Angabe referenzieren kann. Darüber kommen wir auch auf die ähnlich heißenden CSS Counter zu sprechen, mit denen man in CSS hochzählen und die aktuelle Zahl jeweils ausgeben kann. Wir kommen darauf zu sprechen, dass man CSS Counters und deren counter-reset-Eigenschaft zusammen mit content als eine Art Steigbügelhalter zur Ausgabe von numerischen Custom Properties verwenden kann. Außerdem erzählt Schepp von seinem irritierenden Erlebnis bei der Kombination von CSS Countern und contain: style – jedoch alles Spec-konform! Oder dass es (noch) keine gute Idee ist, ein contain: size oder contain: strict mit aspect-ratio zu kombinieren. Stattdessen nutzt Schepp nun lieber geinlinedte SVG-Platzhalter als eine Art Spacer-GIF 2.0.

[00:46:10] display: contents

Wir freuen uns darüber, dass mit Safari alle (und bekannten) verbliebenen Accessibility-Probleme von display: contents behoben sind! Peter findet, dass dieses Feature gut zeigt, wie irgendwas konzeptionell super einfach sein kann, aber in der Implementierung dann das genaue Gegenteil ist. Ein Beispiel ist, was passiert, wenn man display: contents auf ein sogenanntes „Replaced Element“, also ein Bild oder ein Select anwendet. Die CSS Spezifikation hat deshalb eigenen Block mit Sonderregeln für alle möglichen Elemente, die dort als „Unusual Elements“ geführt werden.

[00:51:07] Das scripting CSS media feature

Nun lassen sich auch Media Queries und media-Attribute für den Fall verdrahten, dass ein Endgerät keine Scripte versteht oder ausführen kann, via scripting: none. Neben scripting: enabled gäbe es darüberhinaus laut Spec noch die Variante scripting: initial-only, für den Fall dass ein Client nur zu Beginn einmal Scripte ausführt und dann nicht mehr. Allerdings ist diese Definition reichlich unscharf und wird daher noch von keinem Browser unterstützt.

[01:02:55] image-set() aktualisiert und Präfix-frei

Die gepräfixte CSS -webkit-image-set()-Funktion schlummert in WebKit (und auch Chrome) seit mit dem iPhone 4 Retina-Bildschirme das Licht der Welt erblickt haben. Diese ehemals Apple-eigene Erfindung wurde derweil in den CSS-Standard überführt und dabei um einige weitere Fähigkeiten wie File-Format-Angaben erweitert. Safaris Implementation wurde nun entsprechend aktualisiert und in dem Zuge auch gleich von seinem Präfix befreit. Über den Bug-Tracker von Firefox stößt Peter darauf, dass man sich eigene cursor mit Gradienten bauen kann.

[01:05:03] JPEG XL

Als erster Browser hat Safari nun standardmäßig auf den neusten Apple-Betriebssystemen JPEG XL aktiviert (und AV1). Schepp findet es bedauerlich, dass Chrome JPEG XL bis vor ein paar Monaten zumindest hinter Flags eingebaut hatte, man dort aber aus fadenscheinigen Gründen entschied, es wieder herauszuwerfen. Von Jason Grigsby gab es vor ein paar Monaten einen spannenden Artikel dazu, wie JPEG XL mit seinen einzigartigen Eigenschaften das Dilemma mit der Kombination von responsiven Bildern und Container Queries lösen könnte. Etwas abgemildert wird das Problem dadurch dass zumindest lazy ladende Bilder zukünftig mit einem sizes="auto" ausgerüstet werden können.

[01:21:55] „Add to Dock“-Funktion auf Desktop

Nun bietet auch der Desktop-Safari die Möglichkeit, WebApps wie normale Apps ins Dock zu installieren. Schepp zweifelt allerdings an der Durchsetzungsfähigkeit installierbarer WebApps sofern diese nicht aus einem AppStore kommen. Peter hingegen weiß aus seinem Umfeld zu berichten, dass WebApps durchaus von nicht-technischen Anwender*innen verstanden und genutzt werden. Durch seine Reisetätigkeit ist Peter zudem ein großer Fan von WebApps. Schepp weist auf die juristischen Auseinandersetzungen von Epic mit Apple und Google hinsichtlich des Payment-Plattform-Zwangs hin, die es mit einer WebApp so nie geben würde.

[01:29:26] RegExp: v-Flag

Analog zum Wacken-V meint das v-Flag eigentlich ein u für *U*nicode-Support.

[01:34:50] EcmaScript Set-Operationen

Endlich können wir zwei Sets miteinander vergleichen und zum Beispiel die Überschneidungen oder auch die Unterschiede beider herausarbeiten, in Form von Intersection, Union und Difference. Ein bisschen so wie Schepp das von Vektorzeichenprogrammen und deren Shapes kennt. Peter hätte jetzt gerne noch die derzeit im Entwurf befindlichen Records und Tuples, mit Hilfe derer er die Möglichkeit erhält, zwei verschiedene Objekte auf Inhaltsgleichheit zu prüfen. Schepp weiß zu berichten, dass es so etwas zumindest für den Vergleich zweier DOM-Nodes gibt, in Form der Node.isEqualNode()-Methode. Wie diese bei dem Vergleich vorgeht, erfährt man in der HTML-Spec. Schepps Idee, DOM-Nodes für sein Vorhaben zweckzuentfremden bezeichnet er als „kriminell“ 😃

[01:41:35] iOS-Simulatorenin den Safari Devtools

Safari bietet nun ganz neu die Möglichkeit, eine Webseite aus den Devtools heraus in einem echten iOS-Simulator zu testen. Allerdings muss man dafür einen solchen Arsch voll Zusatzsoftware wie z.B. Xcode installieren, dass dafür die SSD von Schepps Mac Mini nicht mehr ausreicht. Und so endet diese Revision denn auch damit, dass Peter und Schepp noch eine Weile über Software, Betriebssysteme und Hardware diskutieren.

Anmeldung zur Revision 600 im Online Format

Hier geht’s zur Anmeldung auf MeetUp

Feiert am 07.01. von 15 bis 18 Uhr mit uns die 600. Podcast-Episode bei einem einzigartigen Online-Event! Wir veranstalten eine Fishbowl-Diskussion, bei der einige Teilnehmer im ‘inneren Kreis’ diskutieren, während andere im ‘äußeren Kreis’ zuhören und dann einsteigen können. Es ist eine interaktive und dynamische Form des Austauschs, perfekt, um tief in das Thema Webentwicklung einzutauchen. Wir freuen uns auf euch!

Diverse Release-Ankündigungen des Apple-Teams stellten für Peter und Schepp den Anlass, zu schauen, was sich bei Team WebKit so tut. Und das ist eine ganze Menge! Deshalb haben wir es auch nicht in eine Revision quetschen können, sondern sie benötigten derer zwei. Wir stützen uns dabei auf die Release-Notes von Safari 17 und 17.2 Beta sowie den Safari Technology Previews 178, 180 und 181.

Schaunotizen

[00:01:40] Import Attributes

Auch Safari unterstützt nun Import Attributes, mit Hilfe derer sich etwa JSON oder CSS nativ in JavaScript importieren lässt. Wir sprechen über das dazu genutzte Keyword with, das innerhalb von ES Modules eine Umwidmung erfahren hat. Chrome muss neben with wohl für alle Ewigkeit auch das Alias assert unterstützen, weil man etwas voreilig mit dem Zurverfügungstellen des Features war. Aus Gründen kommen wir auf das Hochstift Osnabrück – fragt nicht.

[00:17:26] Priority Hints

Safari unterstützt nun das fetchpriority-Attribut, das mit den Werten low, high und auto befüttert werden kann. Und das bedeutet, auch in Safari kann man sich mit falsch gewichteten Priority Hints in den Zeh schießen!

[00:23:41] window.requestIdleCallback()

Halleluja, ganze acht Jahre nach dem ersten Auftauchen dieser API in Chrome können wir window.requestIdleCallback() endlich auch in Safari nutzen! Wir reden darüber, wie sich damit und mit weiteren APIs wie das von Facebook ersonnene navigator.scheduling.isInputPending() und dem noch hinter Flags und in einem Origin Trial befindlichen scheduler.yield() der Main-Thread vor Überlastung schützen lässt. Auch kommen wir auf den Compute Pressure Observer, mit dem sich CPU-Auslastung zukünftig messen lässt.

[00:38:19] Preload Hints für responsive Bilder und ES Modules

Safari unterstützt zukünftig das Preloaden von responsiven Bildern mit der für diesen Zweck ausgeweiteten Syntax. Das hilft, den LCP-Wert der Core Web Vitals zu senken. Auch wird das Preloaden von ES Modules unterstützt. Hier dreht sich Schepps und Peters Diskussion um die Frage, weshalb man das ES-Modules-Preloaden nicht in das normale Preload integrieren konnte und ein extra Wert namens modulepreload ersinnen musste. Der Grund liegt an den sogenannten „Reauest Destinations“.

[00:49:16] HTTP Early Hints

HTTP Early Hints sind ein Mittel für Server, die beim Bauen des HTML ausgebremst werden, zumindest Preload- und Preconnect-Hints vor der eigentlich Antwort vorab an den Client zur Verarbeitung zu senden. So wird die Wartezeit besser genutzt! Übrigens, bei Preconnect Hints ist es essentiell, nicht nur den Host, sondern auch das Verbindungsprotokoll anzugeben (meist https://). Sonst klappt der Preconnect nicht!

Anmeldung zur Revision 600 im Online Format

Hier geht’s zur Anmeldung auf MeetUp

Feiert am 07.01. von 15 bis 18 Uhr mit uns die 600. Podcast-Episode bei einem einzigartigen Online-Event! Wir veranstalten eine Fishbowl-Diskussion, bei der einige Teilnehmer im ‘inneren Kreis’ diskutieren, während andere im ‘äußeren Kreis’ zuhören und dann einsteigen können. Es ist eine interaktive und dynamische Form des Austauschs, perfekt, um tief in das Thema Webentwicklung einzutauchen. Wir freuen uns auf euch!

In dieser Revision hat Schepp Henning Koch (Web / Twitter / LinkedIn) aus Augsburg zu Gast, der Mitgründer von Makandra ist, einem Team aus Ruby- und JavaScript-Entwicklern, UI-Designern und Ops-Leuten, die maßgeschneiderte Lösungen für ihre Kunden entwickeln. Thema des Gesprächs ist „HTML over the Wire“. Henning ist zudem der Maintainer von Unpoly, einem Open-Source-Tool, das genau diesen Ansatz verfolgt.

Schaunotizen

[00:01:52] HTML over the Wire

Wir starten mit der Feststellung, dass „HTML over the Wire“ erst in letzter Zeit stark an Popularität und Momentum gewonnen hat, obwohl das Konzept bereits seit langer Zeit existiert. So gab es schon früher Ansätze, wie z.B. „Laravel Livewire“, über das wir auch schon in Revision 499 mit Christoph Rumpel sprachen.

Sodann geht es zu den Vorteilen von „HTML over the Wire“, wie z.B. die Möglichkeit, kleine Fragmente einer Seite auszutauschen, ohne die gesamte Seite neu laden zu müssen, sowie die Möglichkeit, Animationen und non-disruptive Navigationen zu haben, ohne den ganzen heutzutage üblichen clientseitigen Aufwand. Teil des Konzepts ist die Tatsache, dass viel Logik und Datenverarbeitung wieder vom Frontend zum Server zurück wandert, und Frontend-Entwickler*innen sich wieder auf das klassische Frontend und User-Interface konzentrieren können. Es sind keine JSON-API-Endpoints und auch keine clientseitigen Renderer mehr erforderlich, um Daten hin und her zu schicken und in HTML umzuwandeln, was die Last auf den Clients deutlich reduziert. Frontend-Entwickler*innen können zwar weiterhin eigenes Scripting verwenden, wo es sinnvoll ist, aber das Heavy-Lifting wird vom Server übernommen.

Schließlich sprechen wir über die Entstehung von Unpoly und wie es im Rahmen von Hennings Tätigkeit bei Makranda entstanden ist. Bei Makranda machen sie vor allem Greenfield-Projekte und hatten in der Vergangenheit schlechte Erfahrungen mit jQuery-Spaghetti-Haufen und AngularJS gemacht. Das Team wollte eine Lösung, die weniger Code erfordert und die Logik nicht so stark verteilt. Dies führte schließlich zur Entwicklung von Unpoly. Das Framework setzt von seiner Philosophie her stark auf Progressive Enhancement und unterstützt Entwickler*innen dabei, barrierearme Produkte damit umzusetzen. Spannend ist auch das Konzept der „Layers“, mit denen Dinge wie Offcanvas-Menüs, Overlays und Popovers orchestriert werden.

Keine Schaunotizen

Der Unpoly Elevator Pitch

Ein Präsentationsdeck, das die Motivation hinter Unpoly und seine Vorzüge und Features abhandelt.

Anmeldung zur Revision 600 im Online Format

Hier geht’s zur Anmeldung auf MeetUp

Feiert am 07.01. von 15 bis 18 Uhr mit uns die 600. Podcast-Episode bei einem einzigartigen Online-Event! Wir veranstalten eine Fishbowl-Diskussion, bei der einige Teilnehmer im ‘inneren Kreis’ diskutieren, während andere im ‘äußeren Kreis’ zuhören und dann einsteigen können. Es ist eine interaktive und dynamische Form des Austauschs, perfekt, um tief in das Thema Webentwicklung einzutauchen. Wir freuen uns auf euch!

In dieser Revision haben wir Martin Dilger zu Gast, der als selbstständiger Entwickler, Berater und Trainer tätig ist. Mit ihm sprechen wir darüber, wie Entwickler*innen ihre Arbeit effizienter strukturieren und sich kontinuierlich verbessern können.

Schaunotizen

Vom Chaos zum Code – wie Developer ihre Arbeit effizient strukturieren

Wir kennen alle das Gefühl, wenn die Woche vor uns liegt und wir keinen Plan haben, wie wir alles unter einen Hut bekommen sollen. Martin hat da einen Trick: Er teilt seine Woche in Arbeitszeit, Familienzeit und – ganz wichtig – „me“-Zeit auf.

Und um den Überblick zu behalten, hat er eine Wissensdatenbank in Notion erstellt, in der er sein ganzes Know-how der letzten zehn Jahre gespeichert hat. Über 100.000 Einträge! So hat er beim nächsten Mal oft gleich eine Anleitung, wie es besser geht. Zudem sind da nicht nur seine Aufgaben und Projekte drin, sondern auch interessante Dinge, die er im Netz findet. Eine wahre Goldgrube!

Ein Prozent besser – jede Woche: Die „Ein-Prozent-Methode“ bedeutet, dass wir versuchen, uns jede Woche um ein kleines bisschen zu verbessern. Es ist zwar Arbeit, sich ständig zu fragen: „Was kann ich besser machen?“. Aber es lohnt sich!

Deep Work: Wir alle kennen das – wir versuchen uns auf eine Aufgabe zu konzentrieren und dann… PLING! Eine neue E-Mail. PLING! Ein neues Slack-Nachricht. PLING! Mama ruft an. Martins Lösung? Konzentrieren wir uns auf „Deep Work“. Wir schalten alles aus und tauchen wir tief in unsere Arbeit ein. Und wenn jemand fragt, warum wir nicht sofort antworten? Wir sind einfach zu beschäftigt damit, genial zu sein! :D

Empathie ist für Martin ein super wichtiger Bestandteil erfolgreicher Entwicklerarbeit. Ein guter Softwareentwickler sollte sich in die Lage anderer versetzen können. Und Transparenz? Genau so wichtig! Damit alle im Team und die Kunden immer genau wissen, was los ist. Und natürlich darf auch die Kommunikation nicht zu kurz kommen. Transparente Kommunikation zwischen Teammitgliedern und Entwicklern ist das A und O.

Anmeldung zur Revision 600 im Online Format

Hier geht’s zur Anmeldung auf MeetUp

Feiert am 07.01. von 15 bis 18 Uhr mit uns die 600. Podcast-Episode bei einem einzigartigen Online-Event! Wir veranstalten eine Fishbowl-Diskussion, bei der einige Teilnehmer im ‘inneren Kreis’ diskutieren, während andere im ‘äußeren Kreis’ zuhören und dann einsteigen können. Es ist eine interaktive und dynamische Form des Austauschs, perfekt, um tief in das Thema Webentwicklung einzutauchen. Wir freuen uns auf euch!

In dieser Revision tauchen wir mit Hans und Vanessa in die spannende Welt des Recruitings ein. Sie teilen ihre Expertise und Erfahrungen über den Prozess des Einstellens von Webentwickler:innen und geben wertvolle Einblicke in die Herausforderungen und Lösungsansätze in diesem Bereich.

Schaunotizen

[00:02:54] Webentwickler:innen erfolgreich einstellen – Einblicke mit Hans & Vanessa

Hans und Vanessa sprechen über die komplexen und dynamischen Aspekte des Einstellungsprozesses für Webentwickler:innen. Sie beginnen mit einer Diskussion über die wichtigen Qualifikationen und Fähigkeiten, die in der heutigen schnelllebigen Technologiewelt von Webentwickler:innen erwartet werden, und gehen dabei insbesondere auf gefragte Programmiersprachen, Frameworks und Tools ein.

Das Gespräch führt weiter zu den Feinheiten des Bewerbungsprozesses und den Interviewfragen, die darauf abzielen, sowohl die technischen Fähigkeiten als auch die kulturelle Eignung eines Kandidaten zu bewerten. Sie betonen dabei die Wichtigkeit von Soft Skills und deren Bewertung im Einstellungsprozess, und heben die Rolle von UX/UI-Kenntnissen und anderen Frontend-Aufgaben hevor.

Die Diskussion nimmt eine interessante Wendung, als die Vor- und Nachteile der Einstellung von Remote-Entwicklern sowie die Herausforderungen und Chancen der globalen Talentmärkte beleuchtet werden. Das Thema Onboarding und Weiterbildung wird ebenfalls angeschnitten, wobei Strategien erörtert werden, wie Unternehmen neue Webentwickler erfolgreich in ihre Teams integrieren und deren kontinuierliche Entwicklung fördern können.

Ein weiterer kritischer Punkt ist das Erkennen des Bedarfs an neuen Stellen und worauf man bei der Analyse von Lebensläufen achten sollte. Hans und Vanessa teilen ihre Ansichten über den Stellenwert von Cultural Fit im Vergleich zu Technical Fit und diskutieren die unterschiedlichen Ansätze zur technischen Bewertung von Kandidaten, darunter technische Tests, Coding Challenges und Live Coding.

Abschließend beleuchten sie die Wichtigkeit von Diversität und Inklusion in Tech-Teams und besprechen, wie Unternehmen durch gezielte Maßnahmen Inklusion fördern können. Sie schließen mit einer Betrachtung von Probezeiten und der Frage, ob und wie Bezahlung in diesem Kontext gehandhabt werden sollte.

Dieses Jahr wird ein besonderes Jubiläum gefeiert: 10 Jahre Kirby CMS! Gratulation hierzu von unserer Seite 🎉 🎂

Mit unserem Gast und einem der Köpfe hinter Kirby, Bastian Allgeier, werfen wir einen Blick zurück und natürlich auch nach vorne.

[00:02:25] Keine Schaunotizen

10 Jahre Kirby CMS

Bastian teilt persönliche Einblicke und wertvolle Lektionen aus einem Jahrzehnt der Entwicklung und Gestaltung des Content Management Systems. Wir reden über die Meilen- und Stolpersteine, die Bastian und sein Team auf ihrem Weg erlebt haben.

Als er über den großen Sprung von Version 2 zu Version 3 spricht, reflektiert Bastian offen über das, was er als den größten Fehler in der Geschichte von Kirby bezeichnet – einen kompletten Rewrite. Dieser ehrgeizige Schritt brachte zwar immense Herausforderungen mit sich, doch gleichzeitig war es eine Erfahrung, die das Team zusammenbrachte und die zukünftige Entwicklung maßgeblich prägte. Mit den daraus gewonnenen Erkenntnissen und dem Feedback der engagierten Kirby-Gemeinschaft verlagerte sich der Fokus weg von revolutionären Updates hin zu einem vorsichtigeren, evolutionären Entwicklungsprozess.

Dem Team spielte in die Karten, dass es nach Version 3 keinen dringenden Bedarf für einen schnellen Release einer weiteren Version gab, weder vonseiten der Entwickler- noch der Nutzerschaft. Diese Freiheit, ohne Druck arbeiten zu können, ermöglichte es dem Team, in aller Ruhe an Features zu arbeiten, die sie und ihre Kunden gleichermaßen begeisterten.

Statt auf Größe und Spektakel zu setzen, strebt das Team nach kontinuierlicher Verbesserung und der Verfeinerung von Kirby, sodass jede Version auf der vorherigen aufbaut und den Nutzern einen echten Mehrwert bietet.

Mit Vorfreude blickt Bastian auf das anstehende zehnjährige Jubiläum von Kirby. Dieser Meilenstein ist nicht nur eine Feier der Vergangenheit, sondern auch eine Gelegenheit, auf eine Zukunft zu blicken, in der Kirby weiterhin die Balance zwischen Benutzerfreundlichkeit und technischer Exzellenz hält.

In der heutigen Folge beschäftigen wir uns mit Tiptap, einem Editor-Framework, das als Open-Source-Software unter der MIT-Lizenz verfügbar ist. Zu Gast haben wir dafür Philip Isik (Web / X (ehemals Twitter)), Miterfinder und Co-Geschäftsführer von Tiptap.

Schaunotizen

[00:02:24] Tiptap

Tiptap hat sich aus einem Agenturgeschäft entwickelt, bei dem die Macher nach drei Jahren feststellten, dass sie mehr als nur Agenturarbeit waren und den Wunsch hatten, eigene Produkte zu entwickeln. Aus einem Agenturgeschäft wurde ein Produktgeschäft. Dieser Übergang ist nicht immer einfach, und es gibt viele Dinge zu beachten, wenn man diesen Schritt wagt.

Ein weiteres spannendes Thema in dieser Folge ist das Bezahlmodell von Tiptap. Wir diskutieren, wie man ein Produkt entwickelt, das sowohl kostenfrei als auch kostenpflichtig ist, und wie man die richtige Balance zwischen kostenlosen und kostenpflichtigen Features findet. Es wird erörtert, wie man mit Nice-to-have-Features umgeht und wie man diese in ein Bezahlmodell integrieren kann.

Als Besonderes Extra für unsere Hörer:innen versprechen wir eine Folge-Episode mit tiefgehenden technischen Details. Schreibt‘ uns all deine Fragen an [email protected] oder im Working Draft Community Slack. Wir freuen uns auf deine Fragen!

Die alljährliche CSS-Umfrage „State of CSS“ hat ihre 2023er-Ergebnisse veröffentlicht, und wie es sich für einen anständigen Frontend-Podcast gehört, tun auch wir unsere Gedanken dazu kund. Schepp und Peter führen in diesem zweiten Teil zu Ende, was sie zwei Wochen zuvor mit Vanessa begonnen haben.

Schaunotizen

[00:03:36] Die color()-Function

Die color()-Function soll in Zukunft all die einzelnen Farbräumen und Farbraummodellen gewidmeten CSS-Funktionen wie rgb() oder hsl() ersetzen. Denn es drängen immer mehr Farbräume, und in deren Windschatten auch immer mehr Farbraummodelle für den Zugriff darauf in unsere Browser: Display p3, LAB, LCH, okLAB und okLCH.

[00:09:44] Interpolation Colorspaces

Auch für das Aussehen von Farbverläufen spielt die Wahl des Farbmodells eine große Rolle. Wir reden darüber, dass okLAB und okLCH verbesserte Versionen der nicht-„ok“-Versionen sind, bei denen verschiedene Parameter für die menschliche Wahrnehmung von Farben angepasst sind, wodurch verschiedene Farben mit gleicher im Programmcode eingestellter Sättigung und Helligkeit auch in der Praxis eine vergleichbare Sättigung und Helligkeit aufweisen.

[00:14:22] Relative Colors

Die CSS Color Spec führt in Level 5 mit Hilfe der Relative Color Syntax die Möglichkeit ein, Farben im Grunde genommen zu destrukturieren und neu zusammenzusetzen. Sehr praktisch für Design-Systeme!

[00:15:58] Ist CSS eine Programmiersprache?

Weil wir sind, wie wir sind, schweifen wir an dieser Stelle ab und befassen uns mit der Frage, ob CSS denn nun eine Programmiersprache ist, oder nicht. Dafür spricht, dass es in CSS zunehmend Features gibt, die man eher von einer Programmiersprache erwarten würde, wie ineinander schachtelbare Funktionen, Trigonometrische Funktionen, gehackte oder echte toggle()-Funktionen. Sicher sind wir uns darin, dass CSS nicht trivial zu beherrschen ist und dass auch ein ganz eigenes Gedankenmodell erfordert.

[00:33:40] accent-color

accent-color ist ein sehr billiges und nicht störendes Werkzeug, um analog zu typografischen Anpassungen Interfaces gleich ein bisschen netter zu machen. Es scheinen nur nicht ganz so viele Umfrageteilnehmer zu kennen.

[00:35:44] Interactions

In der Umfrage haben Themen wie Scrollen, Swipen und Pinchen ein eigenes Kapitel namens „Interactions“ spendiert bekommen. Wir sind große Fans von CSS Scroll Snapping und wissen zu berichten, dass eine weitere Ausbaustufe mit so Dingen, wie der :snapped-Pseudoklasse oder neuen Snap-Events ansteht. Adam Argyle, der daran federführend arbeitet, hat auf dem CSS Day 2022 einen tollen Vortrag mit sehr beeindruckenden Demos über den Themenkomplex gehalten.

Wir erwähnen außerdem lobend die Eigenschaft overscroll-behavior, die sogenanntes „Scroll-Chaining“ verhindert, also dass wenn man z.B. ein Overlay bis zum Schluss gescrollt hat und man dann weiterscrollt, das Dokument dahinter auf einmal anfängt zu scrollen. Außerdem lässt sich damit verhindern, dass beim Scrollen ungewollt ein Gesten-Shortcut des Browsers aufgelöst wird.

[00:50:51] scrollbar-gutter

Mit scrollbar-gutter könnt Ihr bei fehlenden Scrollbars Platz für ein späteres Erscheinen dieser freihalten. Sinnvoll ist das bei SPA und MPAs, bei denen man zwischen Ansichten hin und her navigiert, die mal viel Inhalt und mal wenig Inhalt haben. Das Auftauchen und Verschwinden der Scrollbars führt dann zu einem Springen der Inhalte, was ihr eben mit scrollbar-gutter verhindern könnt.

[00:55:11] Variable Fonts

Wir sind uns darin einig, dass wir die Möglichkeiten moderner Schriftformate toll finden. Schepp empfiehlt zu dem Thema einen super Vortrag von Ulrike Rausch auf der beyond tellerrand. Peter wiederum berichtet von seiner Entdeckung der CSS-Eigenschaft font-variant-numeric. Um herauszufinden, welche Features ein spezifischer Font unterstützt, empfehlen wie die Online-Tools FontDrop! und Wakamai Fondue. Bei Einbinden von Fonts gibt es zukünftig noch eine Reihe mehr Möglichkeiten, an die Fähigkeiten des Browsers angepasste Schriftformate einzubinden, z.B. für Color Fonts.

[01:05:20] text-wrap

Mit text-wrap: balance lässt sich festlegen, dass wenn Text umgebrochen wird, er gleich so umgebrochen wird, dass sich zwischen beiden Zeilen eine ausgewogene Zeilenlänge ergibt. Es werden also mehrere Wörter in die nächste Zeile genommen und nicht nur das eine, das die Zeilenlänge gesprengt hat. Dieses Setting ist gut für Überschriften geeignet, auch weil es aus Performancegründen nur bis zu einer Zeilenzahl von drei Zeilen unterstützt wird. Neu hinzu kommt text-wrap: pretty, das in Fließtexten verhindert, dass ein einzelnes Wort alleine in der letzten Zeile steht („orphan“). Weil Text-Layout so unglaublich Komplex ist, verweisen wir nochmal auf die unglaublich interessante Igalia Chats Episode „First Person Scrollers“.

[01:12:02] :focus-visible

Und weil wir gerade dabei sind und es passt, verweisen wir in Sachen :focus-visible und dessen Komplexität bei der Umsetzung auf die Igalia Chats Episode „The history of :focus-visible and inert“. Die :focus-visible-Pseudoklasse bietet Euch dei Möglichkeit, Fokus-Outlines, auch Focus-Rings genannt, nur dann sichtbar werden zu lassen, wenn jemand die Seite mit einem Eingabegerät bedient, das diese erforderlich macht. Anders als die meisten Steak-Halter von Webprojekten draußen in der Welt, findet Peter diese Fokus-Anzeige super hilfreich.

[01:16:07] Other

Das Kapitel namens „Other“ lässt uns auf CSS Houdini und seine vielen großen Pläne kommen, die sich aber bislang nicht manifestiert haben, wie z.B. die CSS Parser API oder Custom Selectors, mit denen Peter einige seiner Probleme im Zusammenspiel mit Custom Elements lösen könnte. Immerhin gibt es @property und das finden wir sehr praktisch, auch wenn Peter sich daran stört, dass Firefox es immer noch nicht freigeschaltet hat. Da es aber Teil des InterOp 2023 Projektes ist, müsste es eigentlich bis Ende diesen Jahres shippen.

[01:23:08] Tools: Pre- & Post-Processors

Peter erzählt, dass er sein CSS durch keinerlei Mangel mehr dreht, seien es Pre- oder Post-Prozessoren. Allerdings nutzt er gerne Parcel als Bundler und so wäre es möglich, dass das noch irgendeine Form der Magie betreibt, die ihm entgeht. Irgendwie kommen wir dadurch auf @scope zu sprechen, das es möglich macht/machen wird, dass CSS Selektoren nur noch auf bestimmte Teilbereiche des DOM Baums einwirken. Damit wird man in Zukunft Style-Encapsulation lösen und alle anderen Krücken werden hinfällig.

[01:27:00] @layer

Von @scope geht es zu @layer. Allerdings nicht ohne einen erneuten Abschweifer, diesmal über SASS‘ @extend– und CSS-Kompressoren-Fallstricke. Beide haben mit @layer allerdings wenig am Hut. Mit @layer lässt das eigene CSS in verschieden „Starke“ Gruppen einteilen, was es ermöglicht, einer Library Default-Styles mitzugeben, die dessen Anwender ohne Spezifitätsverrenkungen verändern können. Peter sieht es auch als hilfreiches Werkzeug, um Legacy-CSS nach und nach auf einen modernen Stand zu bringen. Allerdings würden wir beide von einem breiten Einsatz eher abraten, denn anders als bei manch anderer Neuerung in CSS, lässt ein Einsatz von @layer alte Browser Schiffbruch erleiden. Ähnlich wie es beim CSS Nesting auch der Fall ist.

[01:37:12] CSS Usage

Als vorletztes werfen wir einen Blick auf die Auswertungen zum Thema „CSS Usage“. Hier zeigt sich, dass die meisten Antwortenden CSS im Kontext von Web Apps / SPAs einsetzen. Aber es werden auch sehr viele Design-Systeme damit konstruiert. Am wenigsten wird CSS im Bereich „Art and Illustration“ eingesetzt, was Peter zumindest in Sachen computergenerierter Kunst gut nachvollziehen kann. Denn es fehlt einfach an einer guten programmatischen API für CSS. Das CSS Object Model sollte diese Rolle ja ursprünglich mal ausfüllen, kann die Erwartungen aber auch nicht erfüllen. Aber auch die Alternative SVG hat ihre Macken, und so stehen wir im Grunde mit eher leeren Händen da.

[01:40:10] Browser Incompatibilities

Abschließend schauen wir noch auf die Liste an Features, die die Antwortenden sich noch nicht trauen zu verwenden. Ganz vorne dabei sind :has() und Container Queries, was zusammen mit dem in der Liste auftauchenden @property auf eine gewisse Problembärigkeit des Firefox‘ hinweist.

Insgesamt kommen wir aber beide zu dem Schluss, dass wir mit den aktuellen Möglichkeiten von CSS und den Browsern sehr sehr sehr zufrieden sind! Und oftmals ist es ja auch so, dass man manches Vorhaben vielleicht auch ohne direkten Weg durch Missbrauch anderer, schon vorhandener CSS Features erreichen kann. Schepp fällt da zum Beispiel Roman Komarov ein, der mit CSS Scroll Driven Animations als Steigbügelhalter zahlreiche seiner CSS-Wünsche erfüllen konnte. Wir loben außerdem die tolle Spec-Arbeit der CSS Working Group und auch die große Menge Tests, die in den letzten 10 Jahren für all diese Features geschrieben wurden. Und weil guter Dinge drei sind, empfiehlt Schepp nochmal eine Igalia Chats Episode, nämlich die Folge „The Novel Engines: Ladybird„, in der Andreas Kling darüber berichtet wie er eine komplett neue Browser-Engine geschrieben hat und die Specs und Tests als Grund nennt, wie er das geschafft hat.

Good times ahead!

Die Rückkehr der HTML-Ritter sieht Luke Scheppwalker und seinen Ewok Peter die letzten interessanten Teile der State of HTML Pre-Umfrage besprechen.

Schaunotizen

[00:01:40] Resource Hints

Wir besprechen den wechselhaften Werdegang von rel="prerender" und anderen Resource Hints, Speculation Rules, Fetch Priority und wann wir als Entwickler:innen überhaupt diese Mittel der Performanceoptimierung zücken sollten.

[00:14:41] HTML-Module

Die besprochene Syntax inkl. nicht unerheblichem Browser-Buy-In irritiert uns sehr, denn es gibt schließlich schon ein gut abgehangenes Proposal für Import-Attribute. Ebenso wagen wir es, dezent das „Feature“ Server-Side-Rendering in der heutzutage besprochenen Form in Zweifel zu ziehen.

[00:28:28] <track>-Element

Wir denken Use Cases für <track> herum, die nichts mit WebVTT zu tun haben. Schepp bemängelt, dass das Element nicht zum Darstellen von Podcast-Transkriptionen taugt, da <audio> zu den permanent komplett unsichtbaren Elementen zählt.

[00:36:41] MathML

Keine weiteren Kommentare zu MathML an sich, aber eure Firma sollte Igalia bezahlen, um neue Features in die Browser-Engines zu bringen!

[00:40:30] Focusgroup

Es stellt sich heraus, dass Features es auch in Abwesenheit einer Spezifikation in die Browser schaffen können!

[00:42:27] Exclusive Accordion

Im Rahmen eines Brainstormings für ein Accordion-Element überzeugt Schepp Peter von seinen Ideen für ein <detailsgroup>-Element. Das Original-Proposal mit Verhalten wie Radio Buttons hat es auch beim HTML-Standard schwer.

[00:51:52] Model-Element und Ausklang

Die von Apple ausgebrütete Web-API für ihr VR/AR-Gadget ist für weder interessant, noch besonders überraschend. Zum Thema VR/AR an sich äußern wir uns dezent skeptisch. Am Ende streifen wir noch kurz Konzepte und Alternativen zu Seamless Iframes, bevor wir die Umfragethemen für ausreichend bearbeitet erklären.

Die alljährliche CSS-Umfrage „State of CSS“ hat ihre 2023er-Ergebnisse veröffentlicht! Vanessa, Schepp und Peter freuen sich nicht nur darüber, dass Working Draft erneut an der Abstimmung über den besten CSS-Podcast der Milchstraße teilnehmen durfte, sondern auch darüber, dass die Umfrage Anlass bietet, mal wieder ausgiebig über diverse CSS-Themen zu plaudern.

Schaunotizen

[00:04:13] Subgrid

Wir begrüßen die Einführung von Subgrid, einem der Hauptfokus-Gebiete der Interop-2023-Initiative, rundheraus und sinnieren ein wenig über die Adaption von Grid und Flexbox.

[00:08:25] Logical Properties

Dass niemand von uns wirklich ernsthaft Logical Properties benutzt hat, hält uns nicht davon ab, wild über mögliche Use Cases zu spekulieren. Möglicherweise sind Logical Properties aber auch einfach eine inkrementelle Verbesserung ohne Killer-Anwendungsfall.

[00:15:03] Content-Visibility

Über das Pro und Contra von content-visibility und seinem Event-Kollegen contentvisibilityautostatechange kommen wir auf CSS-Footguns und -Entäuschungen wie will-change (ist doof), vertical-align (ist eine Tabellenzellen-Only-Diva) und andere Fehlgriffe wie das Casing von currentColor zu sprechen.

[00:23:35] Container Queries

Wir geben zu Protokoll, viele der performancekritischen CSS-Hammerfeatures wie den :has()-Selektor und eben Container Queries eher sparsam zu verwenden. Schepp berichtet außerdem von der Mootoolisierung eines Teil-Aspekts von :has(), was ein Nachjustieren der Spezifikationen nötig machte.

[00:33:39] Neue Viewport Units

Wir berichten von unseren Erfahrungen mit Viewport-Units im Allgemeinen und den neuen Viewport-Units, die die diversen Mobile-Browser-Chromes mitbedenken im Besonderen. Die Frage „was zählt eigentlich als Viewport“ führt uns auf direkten Wege zu Themen wie Scrollbars, env() und dem im Orkus verschwundenen overflow: overlay.

[00:40:11] Intrinsic Sizing Keywords

Dass wir alle nur ein grobes, intuitives Verständnis von Maßangaben wie min-content haben, wird schnell ersichtlich.

[00:45:39] linear() Easing Function

Lineares Transition Timing ist nun so parametrisierbar, dass wir damit beliebige Beschleunigungskurven beschreiben können … jedenfalls, wenn wir gewillt sind, sehr viele Koordinaten anzugeben. Aber das ist unserer Auffassung nach kein Non-Starter!

[00:48:57] View Transition API

Schepp rekapituliert seine Probleme mit mehreren prallel stattfindenden View Transitions und wir überlegen, ob es nicht sinnvoll gewesen wäre, MPA-Transitions zuerst einzuführen.

Professionell wie eh und je kamen Schepp und Peter nicht mal in die Nähe des eigentlich vorgesehenen Themas, und quasselten stattdessen über etwas ganz anderes.

Schaunotizen

[00:02:27] Geplauder zu Events und Shadow DOM

Wir sprechen über Events und Shadow DOM! Zunächst geht es um verschiedene Arten von Event-Handling (Handler vs. Listener, bubbling vs. capturing, passive vs. non-passive), Ideen für nachträgliches Event-Reordering und Einschränkungen von Event-Objekten (die z.B. keine Proxies sein dürfen). Zum Ende hin formulieren wir Kritik an Shadow DOM und blicken auf kommende andere Abschott-Techniken wie CSS-Scoping und Shadow Realms.

Das HTML-Imperium in Person von Darth Peter und Imperator Scheppertine schlägt zurück und bespricht weiter die Themen-Sammlung zum nun erschienenen State of HTML.

Schaunotizen

[00:02:19] tabindex-Attribut

Das tabindex-Attribut zu benutzen ist riskant, was uns bessere Alternativen erbrainstormen und Details der Funktionsweise der Tab-Reihenfolge (inkl. dem episch benannten Focus Navigation Scope Owner) ergooglen lässt. Vielleicht kann das tabindex-Attribut ja durch Declarative Shadow DOM wieder zum Leben erweckt werden?

[00:12:38] Structured Data

Wie Working Draft in Revision 526 berichtete, ist JSON-LD der King und alle anderen Formate dürfen sich gern in den Staub werfen.

[00:17:26] part-Attribut

Wir rekapitulieren kurz, wie Parts, Shadow DOM und Slots zusammenarbeiten, um eine rundherum mittelgute Developer Experience zu ermöglichen.

[00:31:16] DOM Parts

Eine sehr hypothetische API für zukünftig besseres DOM-Diffing. Zu dem Papiertiger selbst fällt uns nicht viel ein, aber Peter weiß zu berichten, warum Custom Elements keine Proxies sein können.

[00:40:44] plaintext-Wert für contenteditable

Wir schwelgen in Erinnerungen an heroische Gefechte gegen diverse Browser-Bugs (z. B. Peters Canvas-Hack) und gegen Performance-Abstürze (z. B. beim Scrollen) und kommen am Ende doch zum Ergebnis, dass Programmieren saugt.

[00:41:24] is-Attribut

Kurzer Rant von Peter darüber, wie Alternativen zum ach so verabscheuten is-Attribut eigentlich aussehen würden (nicht gut).

[00:46:00] crossorigin-Attribut

Schepp erklärt kurz, wann und wo wir crossorigin und rel=preload brauchen.

[00:52:31] Client Hints und Resource Hints

Wir sinnieren über Client Hints, User Agent Sniffing und Alternativen, sowie die Unmöglichkeit der Feature-Detection für die gap-Property mit @supports.

Es gibt nun ein State of HTML 2023 (passend zu State of JS und State of CSS, bitte mitmachen), für den zuvor auf GitHub Input gesammelt wurde. Schepp und Peter haben sich die Mitte August für die Umfrage zur Diskussion stehenden HTML-Features reingezogen und vergessen, dabei die Mikrofone auszuschalten.

Schaunotizen

[00:02:23] <dialog>

Im Rahmen des Bequatschens von <dialog> kommen wir auf den Uber-Stacking-Context namens Top Layer zu sprechen, sowie darauf, dass bei ::background keine CSS-Variablen funktionieren.

[00:09:45] inert-Attribut

Wir vergleichen die Features und Fähigkeiten von inert mit dem vergleichbaren, aber flexibleren CSS-Feature visibility.

[00:13:17] Popover-API

Wir nehmen mit Wohlwollen zur Kenntnis, dass die Popover API Libraries wie Popper überflüssig macht und schweifen ein wenig in Richtung htmx und CSS Anchor Positioning ab.

[00:20:50] Selectlist

An Fancy Selects im Speziellen und HTML-Maximalismus im Allgemeinen entzündet sich wie immer die Frage: sollte das auch ein eigenes HTML-Element sein? Peter rechtfertigt seine Ablehnung mit Verweis auf die Komplexität (die „Specs“ von Open UI sind keine Specs) und das weitgehende Scheitern der HTML5-Formularfeatures.

[00:29:11] <breadcrumb>

Warum kein nav-Element, rätseln wir ergebnislos.

[00:34:32] Lazy Loading

Der Performance-Papst legt eine Blitzpredigt zu Lazy Loading hin und berichtet vom Umgang mit AVIF.

[00:44:00] <template>

Wir versuchen zu ergründen, warum (unserer Erfahrung nach) kaum jemand das Template-Element in freier Wildbahn nutzt, wie eine Rettung aussehen könnte … und ob sie Erfolg versprechend sein kann.

[00:48:34] Custom Elements

Schepp legt dar, warum in seiner Realität Web Components (noch) keine Rolle spielen, obwohl wir mittlerweile mit attachInternals Custom Form-Elemente entwickeln könnten!

[01:05:25] Schlussrunde

Zum Abschluss steifen wir extrem kurz die Themen showPicker(), <portal>, View Transitions, blocking="render" und Mozilla allgemein.

Links

State of HTML 2023

Die Macher der Befragung würden sich sehr freuen, wenn auch Ihr mitmachen würdet!

In dieser Revision erzählt Bernd Kaiser (LinkedIn), Software Developer bei inovex, über Solid.js und dessen Meta-Framework SolidStart.

Schaunotizen

[00:02:31] Solid.js & SolidStart

Nachdem Bernd auf die Geschichte hinter Solid.js eingegangen ist, erläutert er die Basics des Frontend-Frameworks. Wir verweisen hierbei auf auf die Revision 572: Signals, bei der Bernhard Mayr, Stefan und Peter bereits über Signals gesprochen haben. Denn diese sind ein grundlegender Bestandteil von Solid.js/Signals. Weiterhin bespricht er mit uns den Control Flow, Component Properties, und Stores. Dabei kommt auch ein Vergleich zwischen Solid.js und React nicht zu kurz. Das Meta-Framework SolidStart, das in den Startlöchern steht – aber aktuell noch eine Beta-Version ist. Solid.js hat übrigens den OSAward für „2022 Breakthrough of the Year“ erhalten.

Links

• Official results for js web frameworks benchmark
• Solid.js Basics
• Solid.js Playground
• What is SolidStart?

In dieser Podcast-Folge drehte sich alles um das Thema Cross-Plattform Frontend-Entwicklung mit Rust. Unser Gast, Benedikt Terhechte (Mastodon, Twitter, und seine Webseite) teilte seine Erfahrungen und Erkenntnisse zu diesem Thema.

[00:01:26]

Benedikt teilte seine Erfahrungen mit der Entwicklung einer Web-Extension in TypeScript und sprach über seine Arbeit mit Rust in der Frontend-Entwicklung. Er erörterte die Unterschiede zwischen verschiedenen Rust UI-Frameworks und gab Einblicke in die Entwicklung einer komplexen Rust-Desktop- und Webanwendung.

Auch haben wir über die Definition einer „nativen“ App diskutiert

Ein interessanter Punkt war die Erwähnung von Tauri, einer Electron-Alternative, die den WebView des Systems verwendet und daher auch die Unterstützung von Android und iOS in der Version 2.0 plant. Ein weiteres Thema war Dioxus, eine React-ähnliche Bibliothek für Rust.

Benedikt erklärte, dass es eine Vielzahl von WASM-Frontend-Bibliotheken für Rust gibt, die sich an verschiedenen Frameworks wie React, Solid JS und anderen orientieren. Er nannte Beispiele wie Yew (ähnlich React), Leptos (ähnlich SolidJS), Perseus und Sycamore (SvelteKit). Zusätzlich gibt es Bibliotheken wie Xilem, Egui und Iced, die darauf abzielen, plattformübergreifende UI-Bibliotheken für mobile, Desktop- und Webanwendungen zu entwickeln.

Links

Perseus

Eine WASM-Frontend-Bibliothek für Rust.

MoonZoon

Eine weitere Rust-Frontend-Bibliothek für Webanwendungen.

Sycamore

Ein Framework für die Entwicklung von Webanwendungen in Rust.

Yew

Eine Rust-Frontend-Bibliothek, die sich an React orientiert.

Leptos

Eine Rust-Bibliothek, die SolidJS ähnelt.

Xilem

Ein Projekt, das sich auf plattformübergreifende UI-Bibliotheken in Rust konzentriert.

Iced

Eine weitere Rust-Frontend-Bibliothek für die Entwicklung von UIs.

Und es geht weiter in unserer host-context()-Reihe und diesmal steht Stefan im Fokus! Und in die Interviewer-Rolle schlüpft erneut Vanessa.

Schaunotizen

[00:02:17] host-context(Stefan)

Im Einstieg geht es um Stefans Job als Senior Product Architect, seinen Werdegang dorthin, seine Erfahrung mit Technologien und um die Herkunft seiner Online-Pseudonyme.

Stefan erzählt von seiner Rolle als Co-Moderator bei Working Draft und wie er vor zehn Jahren Teil des Teams wurde. Die beiden diskutieren über Filme und Bücher, wobei Stefan Sergio Leone als einen seiner Lieblingsregisseure nennt und „Once Upon a Time in America“ sowie „Spiel mir das Lied vom Tod“ empfiehlt. In Bezug auf Bücher erwähnt er „TypeScript in 50 Lessons„. Wer das wohl geschrieben hat? Trotz dieses kleinen Scherzes am Rande, lernen wir Stefan nochmal von seiner sehr bescheidenen Art kennen, wenn es um die Beleuchtung seiner Arbeit gerade im Bereich Bücher, Konferenzen und generelles Expertenwissen geht.

Das Gespräch dreht sich auch um persönliche Vorlieben. Stefan erklärt, dass er keine Haustiere hat und sich lieber in den Bergen als am Strand aufhält. Er bevorzugt das Bergwandern und hat in der Vergangenheit schon richtig lange Wanderungen unternommen. Stefan ist leidenschaftlicher Koch, ist ein Bier-Aficionado und kann auch auf zwei Jahre Taekwondo-Erfahrung zurückblicken.

Wie immer dient die neue TypeScript-Version den Herren Baumgartner und Kröner als billige Ausrede, um über Gott und die Welt zu quasseln

Schaunotizen

[00:01:32] using Declarations and Explicit Resource Management

TS 5.2 unterstützt ein kommendes ECMAScript-Feature (z.Z. Stage 3), das an diversen Stellen ein besseres try-catch-finally sein will. Wir grenzen das Explicit Resource Management von JS gegen die FinalizationRegistry ab und vergleichen das geplante neue Ressourcen-Management-Feature mit dem, was uns Rust und C++ bieten.

[00:00:00] Decorator Metadata

Ein weiteres neues ES-Feature (ebenfalls z.Z. Stage 3) führt uns zu einer Debatte rund um Web Components im Allgemeinen und Lit im Speziellen.

[00:00:00] Named and Anonymous Tuple Elements und Easier Method Usage for Unions of Arrays

Zwei neue Kleinigkeiten, die wir wohlwollend zur Kenntnis nehmen.,

In dieser Revision geht es zur Abwechselung Mal wieder um ein „softes“ Thema, nämlich um gewaltfreie Kommunikation (GfK). Dazu begrüßen wir unseren Gast Gabriel Birke, der bei der Wikimedia Deutschland arbeitet und der über die Idee hinter, und seine Erfahrungen mit GFK spricht.

Schaunotizen

[00:01:42] Gewaltfreie Kommunikation

Von Marshall Rosenberg entwickelt, geht es um eine bestimmte Denkweise, Haltung und Art des Sprechens, die darauf abzielt, Konflikte zu lösen und Beziehungen zu stärken. GfK zielt darauf ab, Bedürfnisse zu erkennen und Konflikte ohne Gewalt zu lösen. „Gewalt“ meint in dem Zusammenhang keine körperliche Gewalt, sondern eher das Durchsetzen eigener Interessen auf Kosten anderer. Stattdessen geht es darum, eigene Bedürfnisse zu kommunizieren, ohne Vorwürfe zu machen. Ein Debugger für Interaktionen, sozusagen! Wie das genau funktioniert, erfahrt Ihr in dieser Folge.

Links

Softwerkskammer

Zusammenschluss lokaler Communities zum Thema Software Craft. Organisatoren der SoCraTes-Unkonferenz.

Empathy in Tech

Veranstaltungen, Vorträge und demnächst das Buch „Empathy-Driven-Development“

Nonviolent Agile Retrospectives

Einführung in Retrospektiven, GFK und wie Teilnehmer und Facilitator GFK einbringen können.

Fachverband GfK

Deutscher Fachverband mit Trainer-Suche

The Center for Nonviolent Communication

Ressourcensammlung zu Gewaltfreier Kommunikation.

Al Weckert

Autor des Buches „GfK für Dummies“

Engineering Management for the Rest of Us von Sarah Drasner

Dinge, die Dir niemand vor Deinem neuen Job als Engineering Manager verraten hat.

Weiter geht es mit der Reihe host-context()! In dieser Revision gibt uns Hans (Webseite), langjähriges Mitglied des Working Draft Podcasts, einen Einblick in seinen Arbeitsalltag und erzählt uns, welchen Sport er am liebsten anschaut.

Schaunotizen

[00:01:31] Host Context: Hans

Hans, online auch bekannt als Drublic erzählt, uns wie es zu dem Namen Drublic kam, und ob er nun eigentlich Hans, Christian, oder Hans-Christian heißt. Er ist nun seit unfassbaren 11 Jahren beim Working Draft! Angefangen hat es mit Revision 45: H.264 in JS, jQuery Standards Team & OccupyHTML5.

Fußball-Fans aufgepasst! Wusstest ihr, dass Hans großer Fan ist? Könnt ihr erraten, wer sein Lieblingsclub ist?

Viel zu erzählen hat Hans über seinen aktuellen Job und den damit verbundenen Aufgaben. Er berichtet darüber, welche Techniken er einsetzt, um mit Problemen umzugehen und wie man Entscheidungen bestmöglich vertreten kann.

Weiter geht es mit unserer Reihe host-context()! In dieser Ausgabe rückt Schepp in den Fokus und Vanessa fragt ihn aus.

Schaunotizen

[00:02:20] host-context(Schepp)

Natürlich reden wir zu Beginn über Scheps Spitznamen und dessen Entstehung und warum seine E-Mail-Adressen und Social-Media-Handles alle gar nicht so heißen. Es geht um Lieblingsfächer in der Schule, Schepps Vorliebe für Windows (und darum, wie die zu bröckeln beginnt). Schepp genießt nach all der Zeit immer noch die Arbeit als Frontend-Engineer und feiert das Bauen gut abgestimmter Komponenten. Es geht um seine Selbstständigkeit und seine Aktivitäten neben Job und Podcast, als da wären: die Webworker NRW und CSS Café Meetups, die Fronteers Konferenz und eine neu begonnene Tätigkeit als Gastdozent bei der Hochschule Düsseldorf. Schepp ist kein Fan von Visual Regression Testing, eher von End-to-End-Tests. Tickets würde er immer in Stunden, nicht in Komplexität schätzen, und TypeScript benutzt er genau nie. Sprachnachrichten sind für ihn „the worst“. Wenn er Zeit hätte, würde er die Programmiersprache Rust lernen und mehr Serien schauen. Stattdessen liest er viel Artikel, Blogposts und taucht in die spannenden Twitter- bzw. X-Threads folgender Accounts ein:

• Science Girl
• The Cultural Tutor
• Verrückte Geschichten
• Historic Vids
• Massimo
• Fascinating

Wir starten in die neue Reihe des host-context()! Den Start macht Hans, der Vanessa Fragen zu Arbeit und Alltag stellt. Viel Spaß mit host-context(„Vanessa“);

Schaunotizen

[00:02:36] Host Context: Vanessa

In dieser Revision starten wir, unseren Hosts hinter die Kulissen zu sehen. Hans stellt Vanessa Fragen, die sie vorher nicht kannte – was zu unterhaltsamen Antworten führte. Gesprochen wird über alles Mögliche. Von Formel 1 über Spielekonsolen bis hin zu natürlich Technischem. Vanessa berichtet über negative und positive Erfahrungen in der Arbeitswelt. Sie erzählt, warum sie keine konkreten Vorbilder nennen kann, da sie sich Inspiration vielen verschiedenen Personen holt. Das wären zu viele, um sie alle auf einmal zu nennen. Am Ende gibt es als i-Tüpfelchen noch eine ganz typische Interviewfrage, die Vanessa so unvorbereitet trifft, dass sie befürchtet, dass sie das Interview ganz sicher nicht bestanden hat. Aber geschnitten wird beim Working Draft nicht! ;)

In dieser Episode diskutieren Vanessa und Stefan mit ihrem Gast Bernhard Mayr (Twitter) über das Thema Qwik.

Schaunotizen

[00:02:40] Qwik

Vanessa gibt zu, dass er das Thema bisher ignoriert hat, aber nachdem er einen Qwik-Kurs bei Frontend Masters belegt hat, hat sie daran Interesse gewonnen. Auch die anderen beachteten das Frameworks anfangs noch nicht. Aber durch ein Treffen mit Miško Hevery, CTO von builder.io und Erfinder von Angular, auf Qwik wurden sie aufmerksam. Zu dritt diskutieren über die Funktionsweise von Qwik und die Richtung, in die sich das Web entwickelt. Dabei gehen die Hosts auf Begriffe wie „Resumability“ ein, und diskutieren über die Geschwindigkeitsvorteile von Qwik. Alle versuchen, den Unterschied zwischen Resumability und Hydration zu erklären, stellen jedoch fest, dass es schwierig ist, es genau zu beschreiben.

In dieser Episode diskutieren die Gastgeber Vanessa, Schepp und ihre Gästin Franziska Gerz (LinkedIn) über die Verbindung zwischen Frontend-Entwicklung und Design. Franziska ist Softwareentwicklerin bei Whiskey Tango Foxtrot GmbH und teilt ihre Erfahrungen als ehemalige Mediengestalterin, die sich zur Webentwicklerin weiterentwickelt hat und nun auch Führungsaufgaben übernimmt.

Schaunotizen

[00:01:34] Code meets Design: Frontend-Entwicklung

Die Idee zu dieser Folge entstand, nach ein vormaliger Gast nach Tipps zur Gestaltung seines Projekts fragte. Vanessa hatte die Idee, über die Schnittstellen zwischen Frontend-Entwicklung und Design zu sprechen. Dabei stellt sie fest, dass sie normalerweise zwar mit Designern zusammenarbeitet, aber manchmal auch selbst gestalterische Aufgaben selbst übernimmt. Vanessa und Franziska diskutieren die Herausforderungen beim eigenständigen Designen und fragen sich, ob der Beruf des Webdesigners in seiner alten Form noch existiert. Sie teilen ihre persönlichen Erfahrungen und reflektieren über ihre Herangehensweise in Designfragen. Die Episode bietet einen interessanten Einblick in die Verbindung von Frontend-Entwicklung und Design und beleuchtet die verschiedenen Perspektiven der Hosts und ihrer Gästin.

Links

• Steve Schoger – The Little Details of UI Design- Link zu YouTube

Schepp, Hans, und Peter ließen mal wieder das Glücksrad kreisen!

Schaunotizen

[00:03:15] Applet-Element

Passend zum (zum Zeitpunkt der Aufnahme) kürzlich veröffentlichten CheerpJ 3.0 überlegen wir, wie wir in heutigen Browsern Java zum Laufen bringen würden und entdecken hotscripts.com wieder.

[00:14:28] Heading-Elemente

Wir verweisen auf die Revision 559, in der wir das Thema bereits erschöpfend beleuchtet hatten.

[00:15:29] slot-Attribut

Peter erklärbärt in Kürze das Slot-Element, woraufhin wir in eine Diskussion über das slotchange-Event und seine Beziehung zu Mutation-, Intersection- und ResizeObserver geraten.

[00:22:59] SVGRadialGradientElement

Peter berichtet von seinen frustrierenden SVG-Erfahrungen mit code.movie und singt ein Loblied auf Inkscape.

[00:32:17] Spellcheck-Attribut

Ihr könnt hören, wie wir uns die diversen Aspekte des Attributs live aus den Specs erarbeiten.

[00:38:50] Screen-API

Die API ist für uns neu, weswegen wir spekulieren müssen, inwiefern sie vielleicht etwas für Fold-Telefone wie das Pixel Fold sein könnte.

[00:45:13] border-image-repeat

Wir grenzen Border Images von den in Revision 574 bereits besprochenen Border Masks ab und sprechen darüber, wie CSS-Standards die den Design-Tends hinterherhecheln (z.B. border-radius).

[00:52:47] IDBRequest/result

Wir verdammen nicht nur IndexedDB in Bausch und Bogen, sondern erklären auch, warum Web SQL als Webstandard nicht funktioniert (wie auch in Browser eingebaute JS-Libraries und Custom Elements). Unsere Meinung: entweder SQLite in die Webapp einbetten oder IndexedDB-Libraries wie localForage und PouchDB verwenden!

Traditionelles Glücksrad mit Schepp und Peter!

Schaunotizen

[00:03:19] Event/type

Event-Types mögen banale Strings sein, aber über Events im Allgemeinen gibt es viel zu sagen. So erklärt Peter CustomEvent für überholt, Schepp spricht sich für die ausschließliche Verwendung von Event Capturing aus. Desweiteren fragen wir uns nach den Begründungen für die Unterschiedlichen Bubble- und Compose-Verhaltensweisen unterschiedlicher Events und erinnern an jQuerys delegate().

[00:17:49] BluetoothDevice/name

Ob der sparsame Spezifikationstext darin begründet ist, dass Web Bluetooth nur ein dünner JS-Wrapper über normale Bluetooth-APIs ist? Wir spekulieren.

[00:19:54] Form-Element

Peters Galaxy-Brain-Hot-Take des Tages: Formulare in Single Page Apps sind ein Antipattern! Was brauchts ein absendbares Formular, wenn alle Features des Formulars in JS re-implementiert werden, wie etwa in der React-Variante von Todo MVC?

[00:34:03] Title-Element

Wir haben überraschend viele Meinungen und Fragen zum einfachsten Element aller Zeiten, speziell rund um JS-APIs und die Lokalisierung von Title-Content.

[00:46:01] mask-border-slice

Wir erfahren von der Existenz von mask-border und grenzen es im Ad-hoc-Verfahren von border-image ab.

[00:51:00] attr()

Das nicht realisierte Potenzial (v.A. bzgl. Typisierung wie bei @property) von attr() erfährt eine ausgiebige Würdigung. Spekulationen über bei CSS zusammenarbeitende Browser-Interna führen dazu, dass Peter noch eine Runde über seinen liebsten Firefox-Bug weint.

Mit Verstärkung in Form von Bernhard Mayr (Mastodon, Twitter) versuchen Stefan und Peter zu ergründen, was es mit dem Signals-Hype auf sich hat.

Schaunotizen

[00:01:32] Signals

Nachdem Peter mit seinem React-Projekt dem Signals-Hype bereits auf den Leim gegangen ist und Stefan und Bernhard auf der ng-be diversen Signals-Talks ausgesetzt wurden, probieren wir das Thema genauer auseinanderzunehmen. Wir vergleichen Reaktivitäts-Ansätze von React, Vue, Solid.js, Knockout.js und mobX mit Signals und rollen die Geschichte von Signals auf. Ein Vergleich der Signals-Implementierung in Angular mit der von Preact bringt hervor, dass Signals nicht direkt Magie sind, aber schon ein bisschen implizite Hexerei veranstalten. Am Ende kommen wir noch kurz auf AI (und wie Programming as Theory Building in eine Welt mit Copilot passt), Web Components und TypeScript zu sprechen.

Neue TypeScript-Version, Stefan und Peter, Abschweifen. Ihr kennt das Spiel.

Schaunotizen

[00:01:27] TypeScript 5.1

Bevor wir uns in die neuen Features von TS5.1 stürzen, blicken wir zurück auf die in Revision 560 besprochene Version 5.0 und überlegen, warum sich bisher (die nun ja auch in ECMAScript standardisierten) Decorators nicht weiter durchgesetzt haben – Schwenks zu Yehuda Katz und Ember bzw. Glimmer inklusive. An der Feature-Front beginnt der Abbau der Unterschiede zwischen void (nicht zu verwechseln mit void, siehe Stefans Artikel zum Thema) und undefined, was wir begrüßen. Ebenfalls aufgeweicht werden die Anforderungen an die Typen von Getter and Setter-Signaturen, v.a. um Legacy-Use-Cases rund um Stylesheets (jenseits von Constructable Stylesheets) zu bedienen. Anlässlich diverser Anpassungen der JSX-Typen (u.a. für mögliche zukünftige Promise-Komponenten in React) waschen wir ein wenig React-Schmutzwäsche und feiern und besprechen die Genese des Dynatrace App Toolkit. Da uns zu den weiteren Kleinigkeiten nicht ganz so viel einfällt, verlegen wir uns zum Ende hin auf Werbung! Peter empfiehlt eine VS-Code-Extension für schönere TypeScript-Fehlermeldungen und hat einen Text zu unknown-Overloads geschrieben, wohingegen Stefan gleich ein ganzes zweites Buch zu TypeScript zur Papier gebracht hat.

In dieser Revision sprechen Hans und Vanessa (Working Draft Host | Frontend Lead bei zavvy.io) über dein Einbau von KI in die Website. Es werden verschiedene Aspekte der Integration von künstlicher Intelligenz (KI) diskutiert, insbesondere im Hinblick auf die Herausforderungen und Lösungen, die bei diesem Prozess auftreten können.

Schaunotizen

[00:02:20] KI: Integration leicht gemacht

Vanessa hat im Vorfeld eine umfassende Evaluierung verschiedener Editoren durchgeführt und sich schließlich für Tiptap entschieden. Alternativen waren Editor.js, CKEditor, Tiny MCE, und noch viele mehr. Die Hauptkriterien für ihre Entscheidung waren die Flexibilität und die Möglichkeit zur Erweiterung um eigene Blöcke und Knoten. Der Editor Tiptap ermöglicht es, dass eine KI-Komponente integriert wird, die mittels einer eigenen Backend-Kommunikation und der OpenAI Completion API betrieben wird.

Während des Integrationsprozesses stellte sich das sogenannte Prompt Engineering als eine neue Herausforderung dar. Vanessa konzentrierte sich hierbei hauptsächlich auf das Frontend, um die richtigen Endpunkte im Backend aufzurufen und die nachfolgenden Aktionen wie das Auswechseln oder Hinzufügen von Texten zu verbinden. Eine wichtige Überlegung war dabei, dass bei manchen Anfragen Texte komplett ausgetauscht werden mussten, während sie bei anderen Anfragen an den bestehenden Text angehängt werden mussten.

Ein großer Bestandteil des Integrationsprozesses war auch das Feedback-Management, welches einen wichtigen Beitrag zur kontinuierlichen Verbesserung des Modells geleistet hat. Durch das Feedback konnte das Modell regelmäßig trainiert und optimiert werden, was zu einer verbesserten Genauigkeit und Effektivität der KI-Komponente führte.

In dieser Revision des Working Draft Podcasts dürfen wir Matthias Endler (Web / GitHub / Twitter / Mastodon) als Gast begrüßen, der sich als selbständiger Softwareentwickler und Consultant, hauptsächlich in der Programmiersprache Rust verdingt. Ursprünglich aus Bayern, hat Matthias Informatik in Bayreuth studiert und arbeitete ab 2014 für Trivago in Düsseldorf. Er hat viele Erfahrungen mit Backend-Entwicklung, insbesondere mit Elastic Search, Containern und Cloud-Technologien. Er ist Mitbetreiber der Plattform „Open Podcast„, Autor einer Video-Serie namens „Hello, Rust!“ und Erfinder der GitHub „codeprints„.

Schaunotizen

[00:02:23] Von Link-Checkern und Rabbit Holes

Matthias ist unter anderem Autor des URL-Crawlers/Link-Checkers lychee und wir wollen heute über die vielen Aspekte eines solchen Unterfangens sprechen, die man gemeinhin nicht sieht oder bedenkt. Matthias entwickelte den Crawler als Tool, um eine wachsende Liste von Code-Analyse-Tools für PHP zu verwalten. Die Liste begann als einfache Markdown-Datei und wuchs schließlich auf über 700 Tools und zog auf GitHub 11.000 Sterne an. Matthias fand jedoch heraus, dass die Wartung der Liste mit all ihren Links eine zeitaufwendige und frustrierende Aufgabe war. Aus diesem Grund entschied er sich, einen Link-Checker zu verwenden. Er testete verschiedene vorhandene Link-Checker, fand aber kein Tool, das seinen Anforderungen entsprach. Daher entschied er sich, sein eigenes Tool zu entwickeln. Was zunächst wie eine einfache Aufgabe klang, entpuppte sich als eine Herausforderung mit vielen Hürden und Lernmöglichkeiten. Und was als Wochenendprojekt begann, entwickelte sich zu einem größeren Projekt, als andere Entwickler auf sein Tool aufmerksam wurden und es nutzen wollten.

Anlässlich des Abschlusses seiner Blogpost-Serie „100 Days Of More Or Less Modern CSS„, luden wir Manuel Matuzović, Frontend-Entwickler und Accessibility-Experte aus Graz (Web / Mastodon), in unseren Podcast ein, um zunächst über seine Motivation zu dieser Serie und schließlich auch über die spannendsten seiner gewonnenen Erkenntnisse in Sachen CSS zu sprechen. Manuel war zuvor schon einmal zum Thema HTML-Crafting bei uns zu Gast.

Schaunotizen

[00:02:12] 100 Days Of More Or Less Modern CSS

• Day 1: custom properties and fallbacks
• Lea Verou – Custom Variables Secrets
• Day 93: the lch() color function
• Day 98: oklab() and oklch()
• Björn Ottosson: A perceptual color space for image processing (OKLAB)
• Day 95: the color-mix() function
• Chris Lilley – Escaping the sRBG Prison
• Day 92: relative color syntax
• Day 75: font palettes
• Day 76: overwriting colors in font palettes
• Day 22: the ::backdrop pseudo-element
• Kilian Valhof – ::backdrop doesn’t inherit from anywhere
• Day 36: :has() and pseudo-elements
• Day 50: :has(:not()) vs. :not(:has())
• Day 91: a previous sibling selector with :has()
• Der „Max Böck Offset“
• Microsoft Edge / Patrick Brosset – The truth about CSS selector performance
• Day 99: native nesting
• Dart Sass
• Day 2: logical properties
• Day 3: logical property shorthands
• Day 9: the inset shorthand property
• Day 31: logical border properties
• Day 44: logical floating and clearing
• Day 77: block-size, inline-size, vi, and vb
• Ahmad Shadeed – RTL Styling 101
• Day 96: the margin-trim property
• Heydon Pickering – Axiomatic CSS and Lobotomized Owls
• Day 82: value processing
• Day 63: explicit defaulting with inherit, initial, unset, and revert
• Day 74: using !important in cascade layers
• Una Kravets – How does !important actually work? (It’s not what you think!)
• Bramus Van Damme – The CSS Cascade, a deep dive
• Day 48: inset 0
• Day 84: the @property at-rule

Ein harmloser Trollversuch auf Mastodon endet in einer stundenlangen Grundsatzdebatte zwischen Stefan und Peter.

Schaunotizen

[00:02:11] Design Patterns in der Webentwicklung

Inspiriert durch die zweifelhafte Aufstellung von Design Patterns durch den selbsterklärten Refactoring-Guru sprechen wir über Design Patterns! Ausgehend vom Buch-Klassiker „Design Patterns“ besprechen wir, was in JS/TS anders, und speziell beim Refactoring-Guru falsch läuft. Vor allem das Singleton und die Decorators bringen uns in Wallung. Wir eruieren, was die Programmiersprachen dieser Welt wirklich unterscheidet, debattieren Sinn und Unsinn von Klassen (sowie Legacy-Patterns wie das Revealing Module Pattern) und stellen die Frage, ob das Builder-Pattern ein OOP Design Pattern ist … und ob nicht vielleicht eher React ein Design Pattern ist. Nachdem wir auf Patterns.dev auch das Singleton wiederfinden, beenden wir entsetzt die Sendung.

Gast Nils Röhrig berichtet über seine Erfahrungen mit Edge Computing mit SvelteKit und Cloudflare Pages. Er spricht über Edge Computing und seine Auswirkungen auf die Webentwicklung. Im Detail wird er sich zusammen mit Vanessa mit SvelteKit und Cloudflare Pages befassen.

In dieser Revision hatten wir das Vergnügen, mit Marvin Hagemeister (Web / Twitter / Mastodon) über JavaScript-Tooling und seine Erfahrungen auf diesem Gebiet zu sprechen. Marvin ist Entwickler bei Shopify vor allem durch seine Arbeit im Open-Source-Bereich bekannt, insbesondere bei Preact, einem React-ähnlichen Framework. Er erzählte uns, dass er sich immer mehr für das gesamte JavaScript-Ökosystem und Tooling interessiert, was ihn entsprechend dazu gebracht hat, eine Blogpost-Serie zu dem Thema zu schreiben. Und genau darüber wollten auch wir mit ihm sprechen.

Schaunotizen

[00:02:04] Quo vadis Frontend-Tooling?

Anlass für Marvins Forschungen war die suboptimale Performance von JavaScript-Tools, insbesondere bei größeren Projekten, bei denen das Bauen und Testen von Code länger dauern kann – wie es z.B. bei Shopify der Fall ist.

Aktuell gibt es viele neue Tools, die in schnelleren Programmiersprachen wie Rust oder Go entwickelt werden, um die Leistung zu verbessern. Schnelle Tools halten wir für essenziell, da Langsamkeit den Arbeitsfluss und die Produktivität beeinträchtigen kann. Marvin sprach auch über seine persönlichen Erfahrungen mit schnellen Testframeworks und das er sich fragte, warum bestehende Tools nicht genau so schnell sind. Wir diskutierten die Größe von Projekten und wie viel die Programmiersprache zur Leistung beiträgt.

Ein weiterer Schwerpunkt unseres Gesprächs war der Wandel im JavaScript-Tooling-Universum. Bestehende Tools werden neu gedacht und oft in anderen Programmiersprachen als JavaScript entwickelt. Beispiele dafür sind der Nachfolger von Webpack, TurboPack, und ES-Build, die in Rust bzw. Go geschrieben sind. Zusammen mit Marvin haben wir über die Auswirkungen dieser Entwicklungen auf das gesamte JavaScript-Ökosystem und die Industrie gesprochen und sinniert.

Keine Schaunotizen

speedscope

Ein interaktiver Flamegraph-Visualisierer

patch-package

Mit patch-package könnt Ihr nach dem Installieren lokale Korrekturen an npm-Paketen vornehmen.

Diese Woche war Marc Thiele mal wieder bei uns zu Gast und wir sprechen über Konferenzorganisation.

Schaunotizen

[00:02:15] Konferenzorganisation

Diesmal schauen wir mal etwas genauer hinter die Kulissen der Organisation von Konferenzen. Marc Thiele ist als Organisator der Beyond Tellerrand prädestiniert dafür. Die Konferenz findet bereits nächste Woche in Düsseldorf statt, aber auch am 11. und 12. September in Berlin.
Natürlich sprechen wir über die Konferenz selbst, aber auch darüber, wie die Pandemie die Konferenz verändert hat, wie Marc seine Gäste findet und wie er die Zielgruppe der Konferenz anspricht.
Darüber hinaus gibt’s einige Insights zu Marcs Podcast „neu•gierig“.

Peter und Schepp durften Thomas Steiner (DevRel bei Google, online zu finden im Web, auf Github, auf Twitter und im Fediverse) zu den neusten Neuheiten aus dem Wirkungskreis von Project Fugu ausquetschen, nachdem Working Draft zuletzt in der Revision 399 darüber berichtete. Es hat sich einiges getan!

Schaunotizen

[00:02:08] Neues von Projekt Fugu

Projekt Fugu ist ein laufendes Chrome-Großprojekt zum Schließen des „App Gap“, was sich in vielen neue Browser-APIs widerspiegelt. Zu diesen APIs gehören die File System Access API, konsolidierte Sensoren-APIs, die Badging API, eine Shape Detection API und die Web Serial API. Neben den APIs an sich geht es auch ums weitere API-Umfeld wie Permission-Handling, die Möglichkeiten von Isolated Web Apps (z.B. die vorgeschlagene Direct Sockets API), inwiefern andere Browser mit an Bord sind (lokal nachzutesten mit howfuguismybrowser.dev) und wie sich das Discoverability-Problem lösen lässt.

Und wieder haben wir eine Gästin zu Besuch – diesmal ist es Svenja aus Marburg. Svenja ist Webentwicklerin mit Schwerpunkt Accessibility bei Accenture Song, Bloggerin, und Ihr findet Sie als @SvenjaDev auf Twitter und als @[email protected] auf Mastodon.

Schaunotizen

[00:02:06] Interview mit Entwicklerin Svenja zu Barrierefreiheit

Vor ein paar Jahren ist Svenja auf Social Media in der Webentwickler-Bubble aufgetaucht. Ihre Spezialisierung ist Accessibility, was nicht von ungefähr kommt, denn Svenja ist blind.

In unserem Interview mit ihr sprachen wir über ihren Weg in den Beruf. Wir wollen von ihr wissen, wie sie das Programmieren angeht und welche Coding-Umgebung dafür aus ihrer Sicht gut geeignet ist. Es stellt sich heraus, dass dies Microsofts Visual Studio Code ist.

Natürlich wollen wir auch wissen, was aus ihrer Sicht ein gute gecodete Webseite ausmacht und welche Dinge vielleicht gar nicht so wichtig sind, die wir Sehende möglicherweise überbewerten.

Wir fragen sie, ob eine Webseite möglicherweise auch zu semantisch sein kann, wie es einmal in einem Vortrag von Vasilis van Gemert durchklang.

Schließlich lenken unser Augenmerk auch auf die Barrierefreiheit von Single-Page-Applications. Hier schlagen wir den Bogen zurück zu Visual Studio Code, das ein Paradebeispiel einer mit Webtechnologie umgesetzten App darstellt. In der Regel sind native Apps den Web-basierten Apps aber überlegen.

Links

Der Grubenlampe Podcast – Interview mit Svenja, einer blinden Programmiererin

Unser Podcast war nicht ihr erster Podcast. Auch dieser hier ist sehr hörenswert!

Svenjas Blog

Hier bloggt Svenja von Zeit zu Zeit zu ihren Liebslingsthemen

Svenjas Twitch

Svenja spielt gerne Heartstone und streamt das ganze dann hier.

In dieser Revision besprechen wir Organisationsstrukturen. Dabei haben wir einen Fokus auf UnFIX, ein Organisationsdesign, worüber uns Milan Matull, Managing Partner bei Factorial, viel zu erzählen hat. Milan war bereits Gast beim Working Draft in Revision 464 zum Thema TailwindCSS 2.0 und in Revision 516 zum Thema TailwindCSS 3.0.

Schaunotizen

[00:02:11] Organisationstruktur „UNFIX“

Unterschiedliche Unternehmensgrößen benötigen unterschiedliche Modelle, um Teams und Arbeit zu strukturieren. Milan und seine Kolleg:innen setzten in der Vergangenheit auf das „Viable System Model“ (VSM). Das Spotify-Model ist seit Jahren ein fester Bestandteil in Diskussion, wie man Teams am besten aufstellen könnte. Für größere Strukturen gibt es Modelle, die auf Scrum aufbauen, wie SAFe und leSS. Sind flache Hierarchien gewünscht eignen sich Holacracy, allerdings ebenfalls VSM und UnFIX. Denn gefragt sind Modelle, die sich ständig an das Unternehmen anpassen können, wie auch Management 3.0 und Team Topologies. Milan erzählt, worum genau es im UnFIX Modell geht. Es unterscheidet sich v.a. darin, dass es kein starres Framework ist. Das mag den Einstieg etwas erschweren, aber sorgt für viel Flexibilität, sobald es notwendig wird.

Nach einer Pause nehmen Stefan und Peter wieder das allquartalige Besprechen der neuesten TypeScript-Version auf. Und möglicherweise gibt es noch andere semi-relevante Themen wie React-Beef, Klassenkampf und PHP.

Schaunotizen

[00:01:01] TypeScript 5.0

Wie gewohnt rekapitulieren für anlässlich der Beta einer neuen TypeScript-Version das TypeScript-Versionierungs-Schema und tauchen danach tief in die spannenderen neuen Features ein. An erster Stelle stehen die neuen, dem ECMAScript-Standard entsprechenden Decorators. Diese ergänzen in TypeScript die weiterhin verfügbaren Legacy Decorators, deren Unterschiede zum Standard und Herkunft aus den Ruinen von AtScript wir besprechen. const Type Parameters halten wir für eine sinnvolle Ergänzung, ebenso die Änderungen am Config-File-Format und die neue Unterstützung export type *. Die in 5.0 anstehenden Änderungen an Enums sind auch nicht schlecht, Enums selbst hingegen schon.

[00:42:27] Hidden Bonus Track/dt>

In einer etwas außer Kontrolle geratenen Vorbesprechung sprechen wir über den aktuellen React-Beef in der Frontend-Welt, Peters jüngste Erfahrungen
mit PHP und Laravel sowie die Beziehung zwischen (und die Qualität von) React, Next.js und Vercel.

Hans, Schepp und Peter spielen Glücksrad!

Schaunotizen

[00:04:15] Selection.prototype.isCollapsed

Auf der Suche nach Use Cases fällt uns erst auf, wie vergleichsweise mühsam Copy/Paste per JS via execCommand war, was heutzutage mit der Clipboard API sehr viel besser geht.

[00:09:00] <b>

Hans referiert perfekt über Sinn und Unsinn des ehemaligen Bold-Elements inkl. Abgrenzung vom Kollegen <i>. Wir philosophieren darüber, welche Elemente die Bold- und Italic-Buttons in einem WYSIWYG-Editor ins Dokument setzen wollen und streifen dabei Use Cases für<dl>, <mark>, <kbd> und <xmp>. Für letzteres ermittelt Peter sogar per Live-Recherche die Namensherkunft (xmp für „Example“ laut HTML 2.0).

[00:25:37] StereoPannerNode

Ein Bestandteil der Web Audio API, zu dem uns nicht besonders viel einfällt.

[00:28:50] <meta>

Wir diskutieren über Sinn und Unsinn von per Meta-Tag eingebauten Microdata-Informationen, v.a. in den Geschmacksrichtungen OpenGraph (mit verfügbarem Validator) und Twitler (ohne Validator). Am Ende kommen wir noch auf Charsets (auch via Meta-Tag setzbar, unter anderem auch in einer Langfassung) und die Kollegen von Wo wir sind ist vorne zu sprechen.

[00:38:17] MediaError.message

Zu Media-Error-Codes selbst haben wir nicht besonders viel beizutragen, aber Peter nutzt die Gelegenheit, um für DIY-Error-Klassen zu argumentieren.

[00:46:54] ElementInternals.ariaColSpan

Eine API, mit der sich per ElementInternals (von uns kürzlich in der Revision 557 ausführlicher besprochen) der Defaultwert für aria-colspan setzen lässt.

[00:51:27] <h1> – <h6>

Und täglich grüßt der Outline-Algorithmus! Wir kauen das altbekannte Problem der Überschriften in user-generated Content durch und diskutieren, unter welchen Umständen wir <hgroup>, <header> oder etwas ganz anderes einsetzen.

Nachdem Vanessa und Hans sich vor zwölf Wochen in der Revision 546 über Ihre Wege in den Beruf ausgetauscht haben, nämlich einerseits das Studium, andererseits das „zufällige Hineinschlittern“ nach dem Abitur, meldeten sich Stefan Macke (Twitter / IT-Berufe-Podcast) und Marcel Koch (Twitter / Mastodon / Web) bei uns, weil wir weder Ausbildung, noch duales Studium als mögliche Wege in den Beruf beleuchtet haben. Das lag aber schlicht daran, dass wir von beidem keine Ahnung haben, und so haben wir die beiden als Experten eingeladen und das Ganze nachgeholt.

Schaunotizen

[00:02:05] Per dualer Ausbildung oder dualem Studium in den IT-Beruf

Zunächst lernen wir den Unterschied zwischen dualem Studium, dualer Ausbildung und der rein schulische Ausbildung. Über die ersten beiden wollen wir reden.

In den dualen Ausbildungen lernt man praktisch und gegen Bezahlung in einem Betrieb und flankiert wird das durch eine schulische Ausbildung entweder in einer Hoch- oder Berufsschule. Letzteres wäre das, was man unter einer dualen Ausbildung versteht. Insgesamt führt die Ausbildung seit 2020 zu sieben möglichen Ausbildungsberufen:

• Fachinformatiker*in Anwendungsentwicklung, für alle die später gerne programmiern möchten
• Fachinformatiker*in Systemintegration, für alle die später als Administrator*in tätig sein möchten
• Fachinformatiker*in Prozessanalyse, mit der man später KI programmiert oder SAP implementiert
• Fachinformatiker*in digitale Vernetzung, mit der man später z.B. IoT-Produkte entwickeln kann.
• IT-Systemelektroniker*in, für alle, die Lust auf Hardwarebauen haben
• Kauffrau/-mann für Digitalisierungsmanagement, mit der man später digitale Prozesse in Betrieben optmiert, und
• Kauffrau/-mann für IT-Systemmanagement, für alle, die später IT verkaufen möchten.

Die IT-Ausbildungsberufe sind unter Männern die zweibeliebteste Gattung, unter Frauen sehen sie allerdings erst an Platz zehn.

Diese duale Ausbildung dauert üblicherweise 3 Jahre, wird meist auf 2,5 Jahre verkürzt, kann im Extremfall aber auch auf 1,5 Jahre halbiert werden. Eine Abschlussprüfung findet anders als man denken würde nicht erst am Ende der Ausbildung statt. Stattdessen gibt es eine über die Gesamtzeit „gestreckte Abschlussprüfung“, deren erster Teil nach 18 Monaten für alle sieben Ausbildungsberufe identisch abgelegt wird. Die Ausbildung beginnt damit breit gefächert und erst danach geht es tief in die Spezialisierung. Ganz zum Schluss der Ausbildung kommt das Abschlussprojekt, eine Art „Gesellenstück“ an dem man zwischen 40 und 80 Stunden arbeitet, sowie die Präsentation desselben, einem 15 minütigen Fachgespräch darüber und einer schriftliche Dokumentation, die zwischen 30 und 60 Seiten zählt.

Ausbildungen bringen einem aus Stefans Sicht mehr Praxiswissen und sie sind anerkannt und sehr gefragt.

Entscheidend für den Erfolg ist, dass man einen Betrieb findet, der einen anständig an die Hand nimmt und ausbildet und für den man nicht nur eine billige Arbeitskraft ist. Hier muss man ganz zu Beginn gut drauf schauen, wo man gelandet ist und ob es eine gute Idee ist, die gesamte Ausbildung im Betrieb zu bleiben.

Ein Studium ist dahingehend akademischer angelegt. Im dualen Studium arbeitet man aber ebenso praktisch in einem Betrieb, welcher nicht nur die Studiengebühren von 25.000 EUR übernimmt, sondern einem auch ein Gehalt von 1.200 EUR brutto zahlt. Im Gegenzug bindet man sich nach Abschluss des Studiums für anderthalb bis zwei Jahre an den Betrieb – oft will man tatsächlich aber auch gar nicht weg.

Insgesamt können wir festhalten, dass sowohl Marcel als auch Stefan den Weg einer Ausbildung oder eines dualen Studiums sehr empfehlen können.

Keine Schaunotizen

Duales Studium mit Gerda Feldhaus, Elena Hollen und Markus Amshove – Anwendungsentwickler-Podcast #110

In dieser Episode seines Anwendungsentwickler-Podcasts diskutiert Stefan mit Gerda Feldhaus, Elena Hollen und Markus Amshove die Vor- und Nachteile eines dualen Studium.

Der IT-Berufe-Podcast

Stefans IT-Berufe-Podcast bringt seit 2015 Inhalte rund um die Ausbildung in den verschiedenen IT-Berufen.

Fachinformatiker.de

Fachinformatiker.de ist laut eigener Aussage die größte IT-Community rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Schepp und Peter nahmen die Veröffentlichung der Safari Technology Previews 161 und 162 zum Anlass, die dort frisch implementierten Features zu diskutieren und zu kommentieren.

Schaunotizen

[00:01:25] Best of Safari Technology Preview

Los geht es mit neuen Media-Query-Features, speziell prefers-reduced-motion und prefers-contrast (die in den Previews nicht neu sind, aber jetzt besser debugged werden können). Wir diskutieren die Hürden im praktischen Einsatz dieser Features (sowie von prefers-color-scheme) und erinnern an Hotdog Stand. Die Unterstützung von @property fehlt nach den neuesten Safari-Updates nun nur noch in Firefox, aber insgesamt sieht es für das CSS Typed OM und das Houdini-Projekt eher nicht so glänzend aus (Working Draft berichtete bereits). Über Fragen des Umgangs mit immer komplexerem CSS kommen wir zum Thema Selektor-Performance von :has(), die sich mit dem Profi-Profiling-Tool von Chrome messen lässt. Die Unterstützung von :user-invalid und :user-valid feiern wir marginal enthusiastischer als die von Lookbehind Assertions in Regulären Ausdrücken und wir nehmen die (beinahe) bestehende Existenz des ResizableArrayBuffer zur Kenntnis. Safari wird nun als letzter fehlender Browser Unterstützung für OffscreenCanvas bekommen, was Peter dazu bringt, seine jüngsten Abenteuer rund um willReadFrequently nochmal wiederzugeben. Zum Ende hin quatschen wir noch über margin-trim, CSS Subgrids, Declarative Shadow DOM, E4X, HTMLElement.attachInternals() bzw. Form-associated custom elements, globale Event Handler und die Zukunft von Safari und der ganzen weiten Browserwelt.

Über Domain-Driven Design (DDD) sprechen Hans und Vanessa mit dem Gast Florian Benz, VP of Engineering bei Scalable Capital. Florian beleuchtet dabei vor Allem dir Umsetzung samt Stolpersteinen in der Realität.

Schaunotizen

[02:14:00] Domain-Driven Design

Florian begann die ersten Schritte mit Domain-Driven Design (im Folgenden mit „DDD“ abgekürzt) in Teams bei Scalable Capital im Jahr 2019. Zu den größten Herausforderungen zählte, wie man das theoretische Wissen über DDD konkret umsetzen. Bei der Theorie geht Florian speziell auf folgende Teile von DDD ein: Explorativ, strategisch und taktisch. Genauer erläutert er die folgenden Komponenten von taktischem Design: Value Objects, Entities, Aggregrates, Repositories, Services und Factories.

Ein Hauptbestandteil von DDD ist es, eine gemeinsame Sprache zu entwickeln. Das ist jedoch gar nicht so einfach. Vor allem, wenn die allgemeine Code-Sprache bei Projekten oft Englisch ist, aber die Dokumentationssprache z.B. Deutsch. Doch wenn das Team einmal so weit ist, macht es die gemeinsame Sprache für alle einfacher. Für Entwickler:innen im Speziellen, den Code zu strukturieren und eine sehr wichtige Frage zu beantworten: Wo gehört dieser Code überhaupt hin?

Links

• Patterns, Principles, and Practices of Domain-Driven Design
  Scott Millett, Nick Tune
• „The Big Blue Book“
  Domain-Driven Design: Tackling Complexity in the Heart of Software —Eric Evans
• Domain Modeling Made Functional —Scott Wlaschin, KanDDDinsky 2019
• Making Impossible States Impossible—Richard Feldman, elm-conf 2016
• Kotlin and Domain-Driven Design-Value Objects—Florian Benz 2020
• DDD Crew – Welcome to Domain-Driven Design (DDD)
  „This project contains definitions of DDD and fundamental concepts to reduce the learning curve and confusion.“

Verwandte Revisionen

• Revision 314: DDD, CQRS und WTF

Chat GPT ist in aller Munde, was Vanessa und (besonders) Hans und Peter zu einer lebhaften Diskussion rund um AI und ML speziell im Webdev-Kontext verleitet.

Schaunotizen

[00:02:18] Chat GPT & Co

Nach einem kurzen Begriffsklärungsversuch debattieren wir um ChatGPG und Co (v.a. Githubs Copilot, Adobes Enhance Speech, und Descripts textbasiertem Videoeditor). Wir versuchen Use Cases für die Tools zu kategorisieren, die darin inhärenten Chancen und Risiken abzuwägen und überlegen, inwiefern Quellennachverfolgung und Explainable AI denkbar und glaubwürdig sind. Am Ende stellt sich die Frage, ob in Zukunft ganze hochwertige Webseiten automatisch generiert werden können oder ob AI auch weiterhin daran scheitert, Algorithmen für sortierte Arrays nicht nur auszuspucken, sondern auch zu bewerten.

Diese Revision traf eine rekordverdächtigen Anzahl Gäste und Hosts aufeinander: Vanessa, Stefan und Schepp begrüßten Joe Ray Gregory, David Müllerchen und Robin Böhm an ihrem virtuellen Kaminfeuer.

Joe aus Hamburg kennt Ihr aus den Revisionen Revision 520: Unit-Testing / Testing Library und Revision 552: Frontend Development im Jahr 2023.

Robin aus Berlin (Twitter / Web) wird nur langjährigen Hörer*innen von seinem Besuch vor 10 Jahren aus Revision 130: AngularJS – Superheroic JavaScript MVW Framework ein Begriff sein.

David Müllerchen (Twitter / Web), ebenfalls aus Hamburg, bildete den Dritten im Bunde.

Alle unsere Gäste sind Webentwickler, Berater, Trainer, Meetup-Organisatoren und David sogar Twitcher. Die einen präferieren Angular, der andere eher Vue.js. Aber vor allem haben sie alle drei Vorerfahrung im Konferenzorganisieren und haben sich zuletzt für eine große Community-Konferenz zusammengetan. Wie das kam und welchen Hürden die drei und ihr Team auf dem Weg dahin zu überwinden hatten, darüber reden wir in dieser Ausgabe!

Schaunotizen

[00:00:59] Konferenzorganisation in Zeiten einer Pandemie

Den Anfang nahm alles mit der Angular-Konferenz NG-DE 2019, die sehr viel Aufwand, aber auch ein großer Erfolg war und die sich für eine Wiederholung empfahl. Trotz Ausstiegs seiner Co-Organisatoren aufgrund von Erschöpfung, buchte Robin die Location erneut für das darauffolgende Jahr. Wir wissen alle, was dann geschah: 1 Pandemie. Von nun an wurde es eine Zitterpartie, ob eine Konferenz in 2020 überhaupt noch möglich werden würde, und wenn nicht, wie sich die Location bei all verhalten würde. Zum Glück hat sie mitgezogen. In 2020 wurde aus der geplanten Konferenz nichts mehr und alle Bemühungen um das Event wurden auf Eis gelegt. Das änderte sich in 2021, als sich nicht nur die pandemische Situation verbesserte, sondern Robin in David und Joe auch neue Mitstreiter fand. Joes Hinzustoßen mündete in einem zusätzlichen Konferenztag, welcher dem Framework Vue.js gewidmet werden sollte.

Die eigentliche Konferenz-Organisation und die Sprecherauswahl baute auf lange erarbeitete Blaupausen der JSConf.EU, ergänzt um Tipps anderer Organisatoren wie denjenigen der JSUnconf, der RuhrJS oder des JSKongress‘. Für die Auswahl der Vorträge hieß das, dass man einen „Call for Papers“ ausgerufen hatte und die eintrudelnden Vorträge anonymisiert und in einen „Blind-Voting“-Prozess überführt wurden.

Neben der aufwendigen Sprecher*innen-Auswahl musste natürlich ein Budget geplant und Ticketpreise davon abgeleitet werden. Es mussten Sprecherreisen und -unterkünfte organisiert und gebucht werden. Es galt, eine Location für die Abendveranstaltung zu finden, Webseiten zu bauen, Promomaterial herzustellen, Werbung zu machen.

Und das Team legte auch viel Wert darauf, verantwortungsvoll auf die Situation mit der Pandemie einzugehen und Masken und Tests anzubieten, Systeme zu entwickeln wie Menschenansammlungen vermieden werden konnten, und Besucher*innen die Möglichkeit zu geben, zu signalisieren wenn Sie lieber mit Maskentragenden Gespräche führen wollten.

Nachdem all das auf Spur war, wurde es auf den letzten Metern doch noch „spannend“, denn es stellte sich heraus, dass zeitgleich eine große Messe in Berlin angesetzt war, die die Preise der Unterkünfte hat in die Höhe schnellen lassen, bis hin zu dem Punkt wo Teilnehmende es sich nicht mehr hätten leisten können. Auch hier zog die Location, aber auch die Community mit und das Event wurde kurzerhand um wenige Tage verlegt.

Am Ende wurden NG DE 2022 und vuejs.de Conf Gott sei Dank erneut ein großer Erfolg und hat sich all die Mühe und das Zittern gelohnt. 🥳

Nachdem sich Vanessa und Peter in ihrem ersten Anlauf noch um ein strukturiertes Abarbeiten des Fragenkatalogs der 2022er State of JS-Umfrage bemüht hatten, ergehen wir uns dieses Mal in eher freier Assoziation, schaffen es dabei aber auch, die verbleibenden 98% der Umfrage in einer Revision abzufertigen.

Schaunotizen

[00:00:58] State of JS

Die zweite Hälfte des State of JS befasst sich mit Tools und Frameworks, die wir eher abstrakt diskutieren. Zu den relevanten Fragen zählt die von State of JS getroffene Unterscheidung zwischen Frontend- und „Render-Frameworks“ (Next, Nuxt, Gatsby etc.), die Frage inwiefern Frontend-Frameworks eher ein Management als ein Entwickler-Tool sind und wie Web Components dazu passen. Ob wir jemals weniger Frameworks haben (oder werden haben wollen) und ob uns der framework-industrielle Komplex überhaupt lässt, bleibt trotz des kreativen Einsatzes von Auto-Analogien (u.A. zur Pistolenschaltung) ungeklärt. Zu Sinn und Zweck von Mobile Frameworks haben wir eher wenig beizutragen, feiern aber Browser-Devtools wie DOM-Breakpoints (Chrome, Firefox), Hover-State-Enforcing (Chrome, Firefox), Resource Overrides (Chrome-Extension) und In-Devtools-Suchfunktionen gründlich ab (und anwesende Performance-Päpste finden darüber hinaus an an Chromes Trace-Tools gefallen). Weitere ehrenswerte Nennungen erfahren Sentry, die (einigermaßen) gute alte Formularvalidierung, <dialog> und <details>, die View Transition API und generell alles aus der Revision 552 zu Frontend Development im Jahr 2023.

Zum Jahreswechsel haben wir uns mit Joe Ray Gregory (@joyraygregory) hingesetzt und zusammen darüber orakelt, welche neuen Tools und Paradigmen die Frontend Entwicklung im Jahr 2023 prägen könnten. Joe ist Frontend-Entwickler und Trainer aus Hamburg und Ihr kennt ihn vielleicht aus der Revision 520 über Unit-Testing.

Schaunotizen

[00:01:45] Frontend Development im Jahr 2023

Wir reden natürlich über Frontend-Frameworks und denken, dass der Schwenk hin zu Frameworks fortsetzen wird, bei denen Server-Side-Rendering und so wenig JaVaScript im Client der Standard ist. Prominentestes Beispiel hierfür ist Astro, aber auch NextJS und NuxtJS entwickeln sich in diese Richtung.

Außerdem werden sich Web Components als Auslieferungsform weiter etablieren.

Für eine bessere Performance wird alles weiter in Richtung „Actor Model“ entwickelt, also dass ein Main-Thread möglichst viel Arbeit in separate Threads auslagert (höre auch Revision 329 zum Actor Model). Eine Schlüsselrolle wird das Tool Partytown spielen.

Als Unterstützung bei der Entwicklung werden Mikro-Bibliotheken aus dem UnJS-Pool große gebräuchliche Bibliotheken wie Axios oder auch Lodash ersetzen.

Im Testing wird Playwright seinen Marktanteil weiterausbauen.

Für die Komponenten-basierte Entwicklung wird Storybook zwar das Goto-Werkzeug bleiben, aber daneben wird sich Histoire aus dem Vue-Umfeld ähnlich etablieren können wie zuvor auch schon Vite.

In Sachen Bundler und Build-Tools kommt allerlei Neues auf uns zu: Turbopack wird der Nachfolger von Webpack und dann gibt es vom Erfinder von Babel noch eine ganze Build-Suite namens Rome, die Code-Formattier, Code-Linter, Com- & Transpiler, Bundler, sowie das Testing-Tool aus einer Hand sein will. Beiden ist gemeinsam, dass sie aus Performance-Gründen auf Rust bauen, was derzeit auch im Trend zu sein scheint und von SWC, Parcels Lightning CSS und esbuild (allerdings in Go) vorexerziert wurde. Darüber, ob das immer nötig ist oder ob ein wenig Nacharbeit an JavaScript-Code nicht der erste Zwischenstopp sein müsste, fragt sich da Marvin Hagemeister.

Aus dem CSS-Bereich kommend werden die Container Queries ganz viel neue Möglichkeiten eröffnen, sobald diese in allen Browsern freigeschaltet sind.

Monorepos werden ein Thema werden, dank exzellentem Tool-Support durch pnpm, Turborepo oder Lerna (das allerdings nicht mehr maintained wird).

Und schließlich schauen wir auch gespannt darauf, was der NodeJS- und Deno-Konkurrent Bun, dessen JavaScript-Engine nicht auf Googles V8, sondern auf Apple JavaScriptCore bsisert, zukünftig in die Waagschalde werfen wird.

[00:00:00] Keine Schaunotizen

Console Ninja

VSCode-Erweiterung, um Consolen-Output direkt in der IDE zu haben.

Mit Gast Alexander Neumann (Github), seines Zeichens Entwickler der FOSS-Backup-Software Restic quatschen wir über Backups, Backup-Strategien und Backup-Fails.

Schaunotizen

[00:00:58] Backups!

Unsere Einstiegsfrage ist: Was ist überhaupt ein Backup? Ist Backup gleich Backup? Wir beleuchten unterschiedliche Backup-Strategien (für den Alltag und für Spezialfälle wie Datenbanken) und kommen über den Vergleich von Restic mit der Konkurrenz vom morschen Obstbaum zu technischen Praxisfragen rund ums Backup. Über Fragen des Wie und Warum von inkrementellen Backups kommen wir zu Themen rund ums Backup-Rückgrat – Content Defined Chunking (im Falle von Restic via chunker), den Volume Shadow Copy Service, ZFS, etc. Jenseits der schieren Technik ist bei Backups aber auch der Faktor Mensch relevant und wir kommen nicht umhin, Restore-Complacency und Backup-auch-wirklich-machen-Strategien zu besprechen. Konkret am Beispiel von Restic sprechen für über Überlegungen zu Verschlüsselung und Sicherheit, Redundanz, Forward Error Correction, Kompression und Multi-Device-Backups. Zum Schluss geht’s natürlich auch ein wenig um OSS-Themen wie die Zukunftsplanung von Restic und das Community-Management.

Diese Folge haben wir Principal Frontend Architect Lisi Linhardt, welche schon einmal bei uns zu Gast war, damals jedoch in einer anderen Rolle. Mittlerweile arbeitet Lisi schon seit zwei Jahren beim Österreichischen Startup und Headless CMS Anbieter Storyblok, über das wir auch mal eine Revision aufgenommen haben.

Schaunotizen

Mit Lisi reden wir diese Revision über allerlei verschiedene Dinge. Die Klammer drumherum lautet jedoch…

[00:00:59] Lead Developers & Remote Work

Angefangen hat Lisi bei Storyblok als Frontend-Lead, heutzutage ist sie aber eher Team-Lead. Das heißt, während sie früher die Architektur geprägt hat, ist sie heute mehr ein Bindeglied zwischen verschiedenen Gewerken, hat ein Auge auf Dokumentation, aber auch das Onboarding neuer Mitarbeiter.

Vanessa kann sich derzeit noch mehr auf Architektur und Technik konzentrieren, was der geringeren Größe des Startups (Zavvy) geschuldet ist, in dem sie als Frontend-Lead beschäftigt ist. Dennoch gibt es auch Phasen, in denen sie nicht zum Coden kommt und mehr Manager-Aufgaben zu erledigen hat. Das frustriert sie dann manchmal etwas, weil sie den Eindruck hat, dass sie „nichts schafft“.

Lustigerweise geht das Onboarding bei Storyblok auch mit der Zavvy-App vonstatten. Es gibt für die verschiedenen Mitarbeiter verschiedene Onboarding-Jouneys und auch Team-Buddys.

Dokumentation verfasste Lisi früher gerne mal in Notion – die Dokumentation, die sie heutzutage verfasst, liegt aber in der Regel mit im Repository. Vanessa nutzt dafür gerne mermaid.js.

Wir schweifen dann ab in Richtung Benennung von Dingen in Code und wer da welche Präferenzen hat.

Anschließend kommen wir zum Thema „Remote“. Denn Storyblok ist eine der wenigen Remote-only-Firmen, die es so gibt. Gekommen ist das durch das Wachstum während der Pandemie (auch hier nochmal der Verweis auf die Revision 495: Storyblok – Einblicke in ein Startup). Wir sind uns einig, dass Remote dann doof ist, wenn nur einzelne Personen remote sitzen, während der Großteil des Teams physisch beieinander sitzt. Die Einzelpersonen werden da schnell mal aus dem Kommunikationsfluss ausgeklinkt.

Wichtig ist, regelmäßig physische Team-Meetings zu veranstalten. So gibt es bei Storyblok einmal im Jahr ein sogenanntes „Offsite“, wo die gesamte Firma aufeinander trifft.

Vanessa vermisst bei der Remote-Arbeit manchmal den Flurfunk.

Als die größte Herausforderung sieht Lisi das Arbeiten über verschiedene Zeitzonen hinweg an. Eine Lösung besteht darin, möglichst viel Kommunikation asynchron ablaufen zu lassen. Das meiste an Kommunikation entfällt aber meist auf das eigene Team und wird mit zunehmender Gewerk-Entfernung rapide weniger. Das heißt, die Herausforderung stellt sich am ehesten für das eigene Team.

Wir debattieren darüber, ob es wichtig ist, dass alle in Calls ihre Videokameras anhaben oder nicht, welche Arbeitszeiten man in einem weltweiten Remote-Setting hat, inwiefern Fokuszeiten helfen und wann Feierabend ist. Schepp ist hier der Meinung, dass man Kommunikation als empfangende Instanz steuern sollte, also zum Beispiel durch Abschalten von Benachrichtigungen zu bestimmten Zeiten.

Was im Remote-Setting auch schwieriger wird, ist bei Kollegen festzustellen, wenn es ihnen nicht so gut geht. Retros aber ein Werkzeug, um zu sehen, wie alle so drauf sind.

Keine Schaunotizen

The Culture Map: Decoding How People Think, Lead, and Get Things Done Across Cultures

Für Menschen, die in internationalen Teams arbeiten, mag Lisi gerne dieses Buch hier zur Lektüre empfehlen.

In einem hochexzentrischen Orbit kreisen Vanessa und Peter um den diesjährigen Fragenkatalog zum State of JS herum. Bedingt durch zahllose Exkursionen schaffen sie es so gerade durch ersten ca. 20 % der Umfrage.

Schaunotizen

[00:01:50] State of JS 2022

Wir starten mit dem Proxy, von dessen Use Cases wir in unser beider Realitäten zu berichten haben. Promise.allSettled() ist weniger spannend, erlaubt uns aber einen Schwenk zum breiteren Konzept der Iterables. Fragen rund um Dynamic Import werden im Bundle mit Stilfragen rund um Skinny Jeans abgefühstückt, wonach Peter Nullish Coalescing und Vanessa Logical Assignment lobpreisen. Die Schockfrostung der Hölle erfolgt, also Peter (!) von seinen Vue-Abenteuern in Verbindung mit privaten Klassenfeldern berichtet und mit Vanessa diverse Fallen rund um String-Replacement (replace() ist eine Falle, matchAll und replaceAllsind viel besser) durchkaut. Beide Parteien scheitern in Folge daran, ihre Gegenüber von der Großartigkeit von Promise.any() und Array.prototype.at()zu überzeugen. Des Weiteren fallen uns zunehmend kürzer werdende Fun Facts zu Features wie Top-Level await, Temporal, Array.prototype.findLast(), Error.prototype.cause und Object.hasOwn() ein. Spätestens im zweiten Fragebogen, in dem es um Browser-APIS geht, verlässt uns ein wenig der Elan. Service Workers und Custom Elements sind alte Hüte, Shadow DOM darüber hinaus ohne Custom Elements nur bedingt interessant. Angesichts von Web Animations rafft sich Peter nochmal zu einem Rant wider die Frameworks auf, bei WebGL, WebRTC, WebSockets und WebSpeech müssen wir hingegen schlicht die etablierte Existenz der APIs anerkennen. Mit ein paar letzten Spekulationen zur Broadcast Channel API lassen wir die Folge ausklingen.

Die Idee zu dieser Folge entstammt einem Hörerwunsch. Florian Geierstanger schrieb uns vor rund 6 Monaten an, ob wir nicht eine Revision zu diesem Thema machen könnten:

Themenvorschlag für eine @workingdraft Episode: Wie können wir eine lern-freundliche Umgebung schaffen (in einem Team, in einer Firma)?

— Florian Geierstanger (@kino_auge) June 16, 2022

Passende Gesprächspartner dafür waren schnell gefunden, aber leider scheiterten diverse unserer Anläufe bis dato. Eigentlich sollte auch Florian mit von der Partie sein, aber zuletzt war dann er selbst krank. Bevor wir noch einmal verschieben, haben wir uns dazu entschieden, die Aufnahme dennoch endlich einzutüten!

Schaunotizen

[00:01:56] Lernfreundliche Organisationen

Als Expert*innen für lernfreundliche Umfelder hatten wir Corinna Baldauf und Dawit Hasenbeck von der (sehr lernfreudigen) Firma sipgate zu Gast.

Die Firma sipgate gibt es schon eine ganze Weile, aber das Jahr 2010 war in der Firmenhistorie ein einschneidendes: In diesem Jahr beschloss man, sich in eine agile Firma zu transformieren, was nicht nur mit neuen Arbeitsprozessen einherging, sondern auch mit einer neuen Einstellung zum Thema Fortbildung. Die Firmenleitung gab die Devise aus, dass Fortbildung explizit gewünscht sei und es wurden entsprechende Rahmenbedingungen geschaffen und Budget bereitgestellt. Seitdem existiert bei sipgate das „Fortbildungsboard“ mit dem Claim „Es gibt nichts Teureres als Mitarbeiter*innen, die sich nicht fortbilden“:

Auf diesem Board tut man durch Platzieren von Post-its und Gesichtern kund, wer wann welche Fortbildung besuchen möchte, und man sucht sich Kollegen, die mitmachen möchten. Dabei wird geschaut, dass die Firma auch während Fortbildungen einzelner arbeitsfähig bleibt und die Fortgebildeten berichten den anderen hinterher von ihren Learnings – entweder in Vortragsform oder als Zusammenfassung im internen Slack oder als Podcast. Wofür man sich auch entscheidet, seien es Konferenzen, Bücher oder Workshops: man bucht es sich selbst.

Dann gibt es noch alle zwei Wochen die sogenannten „Open Fridays„, firmeninterne Barcamps in denen alle Arten von Themen vorgestellt werden. Gleichzeitig wird der „Open Friday“ auch genutzt um zu zeigen, was Teams geshipped haben und um größere Themenkomplexe zu besprechen. Das klappt sogar remote.

Im Rahmen der agilen Prozesse und Clean Codings findet Lernen auch in Form von Pairing über die Disziplinen hinweg statt, und natürlich werden auch die Retros als Lernwerkzeuge verstanden.

Zu guter Letzt veranstaltet sipgate auch Talk-Reihen mit prominenten Gästen bei sich im Haus, die in diesem Fall auch Besuchern von außerhalb offen stehen.

Keine Schaunotizen

Corinnas Retromat

Retro-Blaupausen zum Losstarten!

Die alljährliche Umfrage zum State of CSS haben Vanessa und Schepp herangezogen, um über die dort aufgeführten brandneuen oder auch nicht mehr so neuen, aber dennoch interessanten CSS Features zu sprechen. Dies ist Teil zwei von zwei Teilen. Teil eins könnt Ihr hier nachhören.

[00:01:00] Schaunotizen

[00:02:03] Das prefers-reduced-data Media Feature

Das prefers-reduced-data Media Feature (HTML), bzw. die prefers-reduced-data Media Query (CSS) wird derzeit nur von den Chromium-Browsern unterstützt, und das auch nur hinter Flags. Hiermit könnt Ihr (teilweise) steuern, was an Daten zusätzlich geladen werden soll, je nachdem ob der Wert auf no-preference oder reduce steht.

Wir sprechen in dem Zusammenhang auch über sogenannte „Browser Interventions„, die Simon Pieters in diesem Twitter-Thread genauer ausführt.

Außerdem findet der Poor Man’s Dark Mode Erwähnung.

[00:18:37] :focus-visible

Die Kurzfassung der Funktionsweise der :focus-visible-Pseudoklasse ist, dass diese nur dann zum Tragen kommt, wenn der Browser ein Interaktionsmuster feststellt, bei dem die benutzende Person einen visuellen Fokus-Indicator benötigt. Damit kann man die von Designern und Chefs verhassten Fokus-Outlines wegstylen, um sie im Falle eines aktivierten :focus-visible wieder zurück zu bringen.

Die Langfassung dessen, was hinter :focus-visible (und inert) steht, könnt Ihr in dieser Folge der Igalia Chats Podcastreihe nachhören.

[00:21:15] Color Schemes

Dieser von Vanessa erwähnte Artikel beinhaltet alle Infos zu den verschiedenen Color Schemes, die man benötigt.

[00:22:00] Das ::marker-Pseudoelement

Mit Hilfe von ::marker lässt sich nun endlich(?) das Aufzählungszeichen von Listen greifen und stylen. Wir sind uns allerdings nicht sicher, wie sehr uns das tangiert.

Wichtig zu wissen ist nämlich, dass man bei ::marker nur ein Subset an CSS-Eigenschaften zum Stylen zur Verfügung hat.

[00:24:45] :has()

Dank der Ideen eines brillanten WebKit-Ingenieurs zur Umgehung der drohenden Performance-Probleme, ist Ende 2021 naben Container Queries auch der zweite Traum aller Frontend-Enwickler*innen, der Parent-Selector Wirklichkeit geworden!

Wir erwähnen kurz die Tatsache, dass es auch beim :last-child-Selektor aus Performancegründen länger gedauert hat, bis dieser in allen Browsern verfügbar war.

[00:28:46] :where()

Mit :where() kann man einerseits stellvertretend mögliche Selektoren auflisten, um sich nicht per Selektoraufzählung wiederholen zu müssen. Das kann :is() allerdings auch. Der Unterschied von :is() zu :where() ist jedoch, dass :is() die Spezifität des  Selektors in der Auflistung mit der höchsten Spezifität übernimmt, während die Spezifität von :where() bei 0 (null) verbleibt, ähnlich wie beim Universalselektor *.

Und das wiederum ermöglicht zusammen mit anderen Neuerungen wie den globalen Eigenschaftswerten unset und revert gänzliche neue Arten von CSS-Resets.

[00:30:39] Warum heißt es manchmal CSS Variablen und manchmal Custom Properties?

Wir klären die Frage, ob beides vielleicht unterschiedliche Dinge sind (Spoiler: sind sie nicht), und warum das Ganze offiziell nicht „CSS Variablen“ heißt.

Dann erwähnen wir Lea Verous Talk über Custom Properties vom letzten CSS Day, der sehr weit in die Tiefe geht und Dinge wie Toggle-Switches und mehrere Ebenen von verschachtelten Custom Properties zeigt.

[00:37:56] @property

Über @property ging es vor nicht all zu langer Zeit in der Folge Revision 534: CSS Houdini, gescheitert?. Dank @property kann man CSS Custom Properties typisieren, so dass der Browser im Anschluss weiß, wie er den Wert im Rahmen einer Animation interpolieren kann. Oder man definiert, ob eine Custom Property sich vererbt, oder eben nicht. Und zu guter Letzt kann man einen initialen Wert festlegen, den die Custom Property hat, wenn Ihr kein Wert zugewiesen wurde.

@property --property-name {
  syntax: "";
  inherits: false;
  initial-value: #c0ffee;
}

Ein schöner Nebeneffekt von „dummen“, also nicht-typisierten Custom Properties ist die Tatsache, dass man von diesen z.B. Farben mit verschiedenen Transparenzen oder Farben mit ähnlichen HSL-Werten ableiten kann.

[00:41:58] @supports()

@supports() ist eine im Browser eingebaute Feature Detection für CSS Eigenschaften und/oder bestimmte Eigenschaftswerte. Verwenden wir beide gerne und viel.

Neuerdings lässt sich mit Hilfe der selector()-Funktion in einem @supports auch herausfinden, ob CSS Selektoren vom Browser unterstützt werden.

[00:43:46] min(), max() und clamp()

Alle drei Funktionen sind aus unserer Sicht sehr nützliche Ergänzungen von CSS. Bei min() und max() haben wir allerdings wie die meisten anderen Entwickler*innen das Problem, dass wir zunächst zum falschen greifen wollen, weil wir das Gegenteil des Funktionsnamens erreichen wollen.

clamp() wiederum findet meist im Rahmen von Fluid Typography Anwendung.

Und schließlich erwähnen wir noch die Tatsache, dass man innerhalb von min(), max() und clamp() kein calc() benutzen muss, weil die schon von Haus aus Mathematische Ausdrücke als Werte unterstützen.

[00:47:14] Dies und das

Wir rauschen als nächstes schnell noch über ein paar CSS Features drüber:

• will-change finden nicht nur wir sehr problematisch und raten vom Einsatz ab
• Cascade Layers aka @layer sind ein spannendes neues Konzept. Es gibt dazu einen tollen Talk von Bramus van Damme. Use-Case sind vermutlich Design Systeme.
• Mit ::part() kann man von außen Teile eines Shadow DOMs stylen, sofern die Autoren desselben diese Teile mit einem part-Attribut markiert haben.
• Trigonometrisch Funktionen wie sin(), cos() und tan() sind sinnvolle Ergänzungen, um komplexe Transformationen zu berechnen.
• CSS Nesting ist nett, haut uns aber nicht so vom Hocker. Außerdem wird es wohl noch etwas länger dauern, bis man das einsetzen kann.
• Die image-set()-Funktion ist sowas wie srcset, nur in CSS. Wird in einer Vorversion mit -webkit--Prefix schon seit langem von Safari und Chromium unterstützt.
• Die image()-Funktion ist so etwas wie die Nachfolgerin der url()-Funktion. Sie räumt ein paar historische Probleme von url() aus, wie zum Beispiel, dass man darin keine Custom Properties verwenden kann. Darüber hinaus rüstet image() weitere Fähigkeiten nach, wie etwa ein Bild aus einer Farbe zu generieren, so dass man keinen Gradienten mehr dafür missbrauchen muss. Und man kann auch nur Bildausschnitte via Fragment-Notation verwenden. Der Browser-Support ist aber nicht vorhanden.

[00:53:09] CSS Frameworks

Wir gehen kurz die aufgelisteten Frameworks durch und stellen fest, dass wir nur die wenigsten davon kennen. Außerdem werden hier echte CSS Frameworks wild mit Komponentenbibliotheken gemischt. Welche verwendet Ihr denn und was gefällt Euch an denen gut? Joined uns im Community Draft und sagt es uns!

[00:58:53] CSS in JS

Noch viel weniger Plan als von Frameworks haben wir von den verschiedenen CSS-in-JS-Bibliotheken 🥴

Vanessa erinnert sich jedoch an eine alte Folge, in der Hans und Schepp ausschließlich über CSS in JS diskutiert haben: Revision 468: CSS in JS.

[01:07:08] Other Tools

Schepp nutzt weiterhin sehr gerne SCSS, weil es sehr angenehm ist, damit zu arbeiten und sein CSS zu organiseren. Bei Vanessa kommt es ein wenig von den in Projekten eingesetzten Scaffolding-Tools und deren „Serviervorschlägen“ an, welche Art Pre- und Postprozessoren am Werk sind.

An weiteren Tools nutzt Vanessa noch Stylelint, Purge CSS, Prettier, Autoprefixer und CSS Nano. Dadurch dass diese Dinge aber eben oft automagisch von Scaffolding-Tools gesetupped werden, steht man auch schonmal wie der Ochs vor dem Berge, wenn etwas nicht geht, weil man nicht weiß, was denn genau alles in einem Projekt am Werk ist. Schepp hingegen ist mehr so der Typ, der alles selbst aufsetzt und konfiguriert, der damit am Anfang zwar langsamer ist, er aber immer weiß, was passiert. Von CSS Nano rät Schepp hingegen ab. Aus CSS lässt sich einfach nicht so viel an Minifizierung herausholen, als dass es sich lohnne würde die Risiken einzugehen, die mit CSS Nano daherkommen.

Als Entwicklungsbrowser nutzt Vanessa den Microsoft Edge, während Schepp weiterhin auf Chrome setzt. Beide schwärmen wir aber auch von extra für Entwickler*innen gebaute Browser wie dem Sizzy-Browser oder Polypane.

Zu guter Letzt gehen wir noch auf eine Art K.O.-Umfrage ein, in der man sich in mehreren Duellen für eines von zwei Kriterien entscheiden soll, die einem bei der Auswahl eines Tools wichtiger ist. Am Ende der Duell-Reihe bleibt dann das wichtigste Kriterium übrig. Die Duelle sind unserer Meinung nach aber seltsam gegeneinander aufgestellt.

[01:31:45] Resources

Im Kapitel über die Learning Resources freuen wir uns schließlich sehr darüber, dass unser Podcast es hineingeschafft hat. Mega!

Hans und Vanessa besprechen verschiedene Ausbildungspfade in der IT. Sie versuchen die Frage zu klären, ob man in der IT Branche eigentlich eine Ausbildung oder einen akademischen Titel braucht. Dabei gehen sie vor allem auf Selbststudium vs. Studium an einer Hochschule ein.

Schaunotizen

[00:01:52] Ausbildungspfade im Web

Zu Beginn erzählen sie von ihren eigenen Erfahrungen: Hans hat sich sein Wissen selbst angeeignet und seine Ziele stets verfolgt und ist arbeitet aktuell als Vice President Engineering. Vanessa nahm den „klassischen“ Weg über Bachelor- und Master Studium und ist momentan als Frontend Lead tätig. Man kann sich daher wohl über beide Wege Jobangebote angeln. Doch welche Vor- und Nachteile haben die jeweiligen Wege? Vanessa wiegt ab, wie viel von der gelernten Theorie sie im Beruf tatsächlich benötigt. Hans erinnert sich, bei welchen Gelegenheiten er nicht nur programmieren musste, sondern auch Tools wie Git benutzt, um zusammen in einem Team zu arbeiten. Sowohl für Berufseinsteiger, als auch für Personalverantwortliche in Firmen ist es wichtig, sich über Erwartungen bewusst zu sein. Zudem versuchen Hans und Vanessa vorurteilsfrei zu sein.

Die alljährliche Umfrage zum State of CSS haben Vanessa und Schepp herangezogen, um über die dort aufgeführten brandneuen oder auch nicht mehr so neuen, aber dennoch interessanten CSS Features zu sprechen. Dies ist Teil eins von zwei Teilen.

Schaunotizen

[00:01:52] State of CSS

Vanessa und Schepp beginnen mit der Feststellung, dass sich der Nutzen vieler neuer CSS Features nicht immer direkt erschließt, oder auch, dass einem der Umfang der Möglichkeiten, die sich aus neuen Features ergibt, nicht immer sofort klar ist.

[00:07:15] CSS Writing Modes

Beide haben wir nie Interfaces bauen müssen, die für andere Sprachen als von links nach rechts und von oben nach unten gelesene angepasst werden mussten. Wir haben die CSS Writing Modes aber durchaus genutzt, um Schrift auf engem Raum vertikal anzuzeigen. Irgendwie kommen wir auf die These, dass es bestimmt so etwas wie „Unter-Internets“ gibt, in der sich Konsumenten anders geschriebener Sprachen tummeln, dort die tollsten Web Dev Tricks gepostet werden, und wir davon aufgrund der Sprachbarriere überhaupt nichts wissen.

[00:15:30] gap Property for Flexbox

Wir sind uns einig, dass gap, welches neben CSS Flexbox auch von CSS Grid und (außer in Safari) CSS Multicolumn unterstützt wird, super praktisch ist.

[00:21:43] Subgrid

Subgrid betrachten wir noch als nicht einsetzbar, weil der Browser-Support noch nicht breit genug ist und es auch keine guten Fallbacks gibt.

[00:22:21] content-visibility

Bei content-visibility ist das anders. Das lässt sich trotz geringem Browser-Support super in Form von „Progressive Enhancement“ einbauen. Letztlich ist das nichts anderes als Lazy Rendering von Elementen.

[00:22:40] @container

Und auch Container Queries beginnen wir mittlerweile so einzusetzen, dass Dinge „graceful degraden“, wenn die Technik noch nicht zur Verfügung steht, was man mit @supports ja gut herausbekommen kann.

[00:24:21] Media Queries Range Contexts

Die neue Schreibweise von Media Queries in Form von Wertebereichen zwischen einem Minimum und Maximum, mit Hilfe von mathematischen Gräßer- und Kleinerzeichen finden wir gut lesbar und sie hilft auch ein paar Edge Cases zu vermeiden, auf die wir mit der derzeitigen Schreibeweise stoßen. Anders als von uns in der Aufnahme behauptet, werden die nicht nur von Firefox, sondern auch von Chromium unterstützt. Es dauert also noch eine Weil, bis wir die einsetzen können.

[00:30:49] Logical Properties

Logische Eigenschaften benutzen wir aus den gleichen Gründen nicht, wie im Zusammenhang mit den CSS Writing Modes genannt. Allerdings sehen wir durch unser Verhalten Zugänglichkeitsprobleme für Benutzer*innen, die mit Browser-Plugins eine Seite in ihre Sprache übersetzen lassen. Die könnten von Logical Properties profitieren.

[00:32:07] Viewport-Percentage Length Units

Die neuen Viewport Units sind eine praktische und willkommene Ergänzung zu den etablierten und lösen Probleme, die man speziell auf mobilen Geräten und ihren dynamischen Viewports hat.

[00:32:53] backdrop-filter

Der Backdrop-Filter hat es Vanessa besonders angetan. Der Backdrop-Filter macht für Dinge, die hinter einem Element durchscheinen das, was der normale Filter für Elemente tut. Wir stellen fest, dass man mit Filtern, egal ob Backdrop-Filter oder normalem Filter, schnell zu dick auftragen kann. Weniger ist hier also wieder einmal mehr. Irgendwie kommen wir dann auf die Serie She-Hulk, die Vanessa sehr empfehlen kann.

[00:38:37] Intrinsic Sizing

Als nächstes sprechen wir über die Keywords fit-content, min-content und max-content, die man in width und height einsetzen kann und die ein Element abhängig von seinem Inhalt dimensionieren, ähnlich wie CSS Flexbox‘ flex-basis oder CSS Grids fit-content()-Funktion. Use-Cases gibt es aber eher wenige.

[00:44:12] accent-color

Vanessa liebt accent-color, das zum unkomplizierten „Themen“ von Browser-GUI aka „Replaced Elements“ genutzt werden kann. In manch einem Projekt reicht das schon, um die beteiligten Designer*innen glücklich zu machen, ohne dass man gleich Inputs & Co alle in neu (und barrierevoll) nachbauen muss.

[00:48:17] currentcolor

Zitat aus der „Incomplete List of Mistakes in the Design of CSS“ der CSS Working Group:

The currentColor keyword should have retained the dash, current-color, as originally specified. Likewise all other color multi-word keyword names.

Tatsächlich wird der Fehler des Camelcasens dieses Keywords nun in 2022 endlich korrigiert, allerdings nicht mit einem Bindestrich, sondern durch komplettes Lowercasen des Wortes. Das hat den Hintergrund, dass CSS größtenteils case-insensitive ist und die Änderung so rückwärtskompatibel bleibt.

[00:53:36] (Gradient) Color Spaces

Auf die neuen Farbräume in CSS freuen wir uns schon. Die decken nicht nur mehr Farbraum ab, als das derzeit verwendete sRGB, sondern sind auch nach einem psychovisuellen Modell entwickelt. Und aufgrund ihrer Form ermöglichen die neuen Farbräume auch deutlich schönere Farbverläufe.

[00:58:14] CSS Scroll Snapping

Nun geht es endlich um das eingangs schon angesprochene CSS Scroll Snapping und Scrollen und Touchen und wir verweisen auf Adam Argyles irren CSS Café Talk zu dem Thema.

[01:03:09] Variable Fonts

Obwohl wir schon einige Vorträge zu dem Thema gesehen haben, haben wir der Praxis noch nicht einen variablen Font zum Einsatz gebracht. Das lohnt sich aber eigentlich auch erst, wenn man mehr als zwei bis drei Schriftschnitte benötigt. Zudem stellen die variablen Fonts manches Schriften-verarbeitende Tool vor Probleme.

[01:08:47] line-clamp

Wir sehen line-clamp, mit dem man Texte nach so und so viel Zeilen abschneiden kann, mit gemischten Gefühlen. Einerseits erscheint es uns wie etwas unbeholfenes Interface-Design, bei dem störender Inhalt weichen soll. Andererseits finden wir schade, dass wir vom Browser keine Rückmeldung, z.B. in Form einer Pseudoklasse haben, wenn Text tatsächlich abgeschnitten wurde. So können wir gestalterisch nicht darauf eingehen und einen Hinweis auf mehr Text einblenden.

[01:13:25] font-display

font-display stammt aus dem Bemühen, die verschiedenen Verhalten von Browsern beim Anzeigen von Schriften zu vereinheitlichen bzw. einstellbar zu machen. font-display: swap ist hier meist die Einstellung, die man haben möchte.

Diese Revision war eigentlich mit Thema geplant, aber ein spontaner familiärer Notfall hat unser Programm kurzfristig geändert. Mit dem einen verbliebenen der drei geplanten Gäste, nämlich Florian Geierstanger (Web / Twitter), sind Hans und Schepp daher auf eine weitere Runde Glücksrad umgeschwenkt.

Glücksrad

[00:03:40] <spacer>

Direkt als erstes schickt uns das Glücksrad auf eine Zeitreise weit in die Vergangenheit, zu dem uns bislang unbekannten <spacer>-Element. Dieses Netscape-spezifische Element schien zu formalisieren, was Entwickler*innen damals mit dem sogenannten Spacer-GIF bewerkstelligt haben. Wie so oft, wenn etwas in die Browser eingebacken wird, gab es eine Extra-Fähigkeit obendrauf: So konnte man mit Hilfe des type-Attributs Abstände auch nur in einer Achse erzeugen, was bei Bildern so nicht ging. 2010 schrieb der damalige Mozilla-Entwickler Henri Sivonen anlässlich der Entfernung des dazugehörigen Codes aus Gecko auch etwas über das Element. Schepp denkt an den HTML Tags Memory Test und überlegt, ob es dort wohl akzeptiert wird (wird es nicht).

[00:12:35] <audio>

Als nächstes geht es wieder leicht zurück in die Zukunft, und um das im Rahmen von HTML5 eingeführte <audio>-Element. Hans erinnert sich, dass man es analog zu den <video>– und <picture>-Elementen mit alternativen Dateiformaten füttern kann und der Browser pickt sich das heraus, was er abspielen kann.

Florian findet an dem Element doof, dass sich der Audioplayer beim Navigieren zu einer anderen Seite schließt. Schepp fällt zu dem Thema ein, dass es die Media Session API gibt, die u.a. dieses Problem ausräumen soll. Und Hans wiederum erinnert sich daran, wie er diese API im nie zum Einsatz gekommenen Working Draft Audio Player verwendet hat. Die Macher des Podcasts Wo wir sind ist vorne haben das Problem (für Navigationen innerhalb der Seite) mit turbolinks gelöst.

Desweiteren kommen wir auf Audio-Transkription und mögliche Wege zur Darreichung selbiger zu sprechen.Zwar gibt es den WebVTT-Standard und die dazugehörigen, speziell formatierten .vtt-Dateien für Untertitel und Transkripte, aber leider kann sie das <audio>-Element nicht darstellen. Das macht in sofern Sinn, als dass die Abkürzung „WebVTT“ für „Web Video Text Tracks Format“ steht. Bleibt in so einem Fall also nur, auf ein <video>-Element umzuschwenken. Verrückterweise kann aber auch ein <audio>-Element Video abspielen!

Wir sprechen darüber, dass wir hier im Podcast keine Transskripte haben, was daran liegt, dass die uns bekannten maschinellen Tools große Probleme mit unseren Inhalten haben. Eine manuelle Transkription haben wir bislang nur einmal machen lassen. Die war zwar exzellent, doch stören wir uns an den Arbeitsbedingungen in der Branche (über die wir erst im Anschluss daran erfuhren). Florian bringt eine neue AI-basierte Lösung namens „Whisper“ ins Spiel, die sehr gut funktionieren soll und die wir uns als Hausaufgabe mitnehmen.

Hans fragt, welchen möglichst einfach gehaltenen Audioplayer wir empfehlen können, worauf uns eigentlich nur MediaElement.js einfällt.

Schepp weist auf ein Learning hin, das er vor einiger Zeit hatte, nämlich dass die HTMLMediaElement.play()-Methode im Standard und entsprechend auch in den Browsern 2016 nachträglich auf Promises umgestellt wurde.

Abschließend preisen wir die Tatsache, das man die Abspielgeschwindigkeit von Medien via JavaScript mit dem playbackRate-Attribut beeinflussen kann. Florian empfiehlt dafür ein Browser-Plugin namens „Video Speed Controller“, das dafür auf Seiten die etwas abspielen ein Interface einblendet.

[00:33:07] XMLHttpRequest.status

Gibt bei AJAX-Requests den HTTP-Antwortcode zurück. Ist der Request noch nicht durchgegangen, steht der Wert auf 0 (Null).

Das spannendste an der XMLHttpRequest-API ist seine Entstehungsgeschichte: Das damalige Outlook Web Access Team (was Gmail, nur eben 10 Jahre früher war) benötigte die API, um Inhalte dynamisch nachladen zu können. Weil damals XML allerorten gehyped wurde, und alles mit „XML“ im Namen große Chancen hatte, in den Internet Explorer eingebaut zu werden, kam man auf die Idee, die API mit „XML“ zu prefixen und so in den IE einzuschmuggeln.

Außerdem erinnern wir uns an das Konzept von JSONP, das aber eigentlich überhaupt gar nichts mit der XMLHttpRequest-API zu tun hat, und mit dem man Cross-Origin-Datentransfers vor CORS realisiert hat.

[00:46:13] Das itemtype-Attribut

Dieses HTML-Attribut stammt aus dem schema.org-Vokabular, welches Markup um strukturierte Daten anreichert. Je nachdem, was für eine Art Inhalt man damit auszeichnet, stellt Google diesen in seinen Suchergebnissen angepasst dar. Wie das aussieht, kann man sich in Googles Such-Galerie anschauen.

Schepp empfiehlt, heutzutage statt auf HTML-Attribute besser auf JSON-LD zu setzen, weil man mittlerweile ja eher in Baukästen denn in Seiten denkt und dann ein zentraler Ansatz förderlicher ist.

[00:54:43] Die @font-face-At-Rule

Wir alle kennen diese At-Rule, um den Browser mit Schriften bekannt zu machen, und um diese dort einzustellen. Aber wusstet Ihr auch, dass das, was Ihr dort hinein schreibt, keine Properties, sondern Descriptoren sind? Hierzu fällt uns Tab Atkins-Bittners CSS-Begriffe-Lexikon ein (in welchem Descriptoren allerdings nicht erwähnt werden).

Schepp weist auf die recht neuen Descriptoren ascent-override, descent-override, size-adjust und line-gap-override hin, die dem Finetuning der vertikalen Positionierung innerhalb einer Text-Zeile und des „Durchschusses“ von Schriften dienen, aber vor allem Layout-Shifts beim Austauschen von Schriften per font-display: swap verhindern sollen. Leider ein stark unterdokumentiertes Feature, von dem Schepp nur im Rahmen eines Talks von Jake Archibald gelernt hat. Florian kennt ein gutes Tool, um das einzustellen, nämlich den Fallback-Font-Generator.

In Sachen Performance empfiehlt Schepp, @font-face direkt in das HTML zu packen, um dem Browser frühzeitig die entsprechenden Infos bereitzustellen und ihn die Schriften nicht erst in einem extern liegenden Stylesheet entdecken zu lassen. Von Zach Leatherman gibt es darüberhinaus auch einen spannenden Talk zum Thema „Schriften schnell laden“. Nach seinem Talk haben wir noch ein paar Extrainfos im Rahmen eines Interviews aus ihm herausgequetscht.

Florian bringt das Thema „lokale Schriften“ ins Spiel. Neben der altbekannten local()-Funktion gibt es neuerdings auch die Local Font Access API, mit der man auch schon in gewissen Browsern herumspielen kann. Schepp meint sich daran zu erinnern, dass Figma diese API schon nutzt – aber das stellt sich wohl als Irrtum heraus.

Diese Revision haben wir Nico Brünjes (Twitter / Web) und Hennes Römmer (Twitter / Web) von ZEIT ONLINE zu Gast und die beiden erzählen Schepp von den Herausforderungen und Schwierigkeiten der Mitarbeiter-Gewinnung im Tech-Sektor (bezogen auf ZEIT ONLINE).

Schaunotizen

[00:01:00] Tech Recruiting

Ausgangslage ist dass wir es mit einem Bewerbermarkt zu tun haben, also einem großen Angebot an Arbeit und Jobs und nicht genügend Programmierer* und Bewerber*innen. Also muss sich eine potentielle Arbeitgeberin wie ZEIT ONLINE reinhängen:

• Man braucht eine attraktive Außendarstellung des Teams, was bei ZEIT ONLINE in Form eines Tech-Blogs nicht so gut geklappt hat und nun über eine Steckbrief-Microsite gelöst wird. Sind Meetups im eigenen Haus auch ein Weg?
• Dann gilt es, die perfekte Stellenanzeige zu schreiben. Allerdings gilt auch hier: it depends. Und zwar von der anzusprechenden Person. Die eine mag es detailliert, die andere nicht. Und sollte man Anforderungen zu klar formulieren und Gefahr gehen, mögliche Bewerber*innen zu früh abzuschrecken?
• Jetzt muss die Stellenanzeige noch zu den richtigen Personen gelangen. Welche Ausspielungswege haben sich da bei ZEIT ONLINE als hilfreich erwiesen? Stepstone? Indeed? Oder Stack Overflow?

Dankenswerterweise bekommt ZEIT ONLINE viele Bewerbungen, aber oft sind es nicht die passenden. Es bewerben sich z.B. Junioren auf Senioren-Posten, Backend-Entwickelnde auf Frontend-Stellenausschreibungen und alle sind sie „Fullstack“. Sind die Stellenanzeigen doch zu unklar formuliert? Oder versuchen die Bewerber*innen einfach Ihr Glück?

Ist eine Bewerberin oder ein Bewerber einmal im Rennen, gilt es sich in Interviews kennenzulernen und über eine Coding Challenge einen Einblick in die Arbeitsweisen beider Seiten zu bekommen.

Hat eine Bewerberin oder ein Bewerber das Team von ZEIT ONLINE überzeugt, gilt es, die Person gut zu onboarden. Hierzu wird der neuen Person eine Partnerperson aus dem Team zur Seite gestellt, die mit Rat und Tat hilft. Auch pflegt man bei ZEIT ONLINE pair zu programmieren und über Pull-Requests zu debattieren, so dass jemand neues gut in die bestehenden Strukturen hineinkommt.

Zu guter Letzt besteht gute HR-Arbeit natürlich auch darin, einmal akquiriertes Personal im Unternehmen zu halten. Bei ZEIT ONLINE passiert das über „Perks“, regelmäßige Gespräche und interne Mitarbeiteraktionen.

Endlich spielen wir wieder Glücksrad! Der aus unserer „Mit Gast“-Premiere bekannte Stefan Judis (Twitter, Web), mittlerweile DevRel bei Checkly und Autor des Web Weekly Newsletters, setzte sich zusammen mit Schepp an unser neues MDN-gespeistes und Svelte + WebSockets gepowerte Webtechnologie Glücksrad. Folgendes sprang dabei heraus:

[00:01:00] Glücksrad

[00:03:28] HTML | global_attributes | spellcheck

Ein boolsches Attribut, mit dem sich eine Rechtschreibprüfung auf editierbaren Elementen aktivieren oder deaktivieren lässt. Entdeckte Rechtschreibfehler lassen sich per ::spelling-error-Pseudoelement herausgreifen und mit „Squiggly Lines“ aka text-decoration: wavy red; markieren. Grammatikfehler wiederum kriegt man mit ::grammar-error zu fassen. Was insofern nicht stimmt, als dass der Browser-Support für diese Pseudo-Elemente non-existent ist 😬
Ach so, und für eine brauchbare Rechtschreibhilfe dürft Ihr nicht vergessen, das korrekte lang-Attribut auf dem Root-Element zu setzen!

[00:09:20] API | HTMLElement | .outerText

Der .outerText-Getter und -Setter unterscheidet sich beim Lesen genau gar nicht von .innerText. Erst beim Schreiben unterscheidet sich sein Verhalten. Dann nämlich wird das betroffene HTML-Element inklusive seinem enthaltenen Text durch den zugewiesenen Text ersetzt. Der Text steht also im Anschluss im Elternelement des eben noch angesteuerten Elements – an dessen bisheriger Position im DOM.
Wir sprechen kurz den Fakt an, dass eine Leseoperation per .innerText im Gegensatz zu .textContent zu Reflows führt, weil der Browser nur denjenigen Text ausgeben soll, der auch tatsächlich sichtbar ist – was er nur durch ein kurzfristig anberaumtes Neurendern herausfinden kann.

[00:16:18] CSS | properties | text-overflow

Pah, einfach! Oder etwa nicht? Zu text-overflow können wir schnell alles Wissenswerte zusammentragen: Sie dient dem Auspunkten von überschüssigem Text. Dazu setzt Ihr die Property im Grunde immer auf ellipsis, und funktionieren tut das nur, wenn Ihr gleichzeitig auch overflow: hidden und white-space: nowrap setzt. Aber was ist eigentlich der initialer Wert? Na clip! Das bringt uns kurz auf overflow: clip. Außerdem lernen wir, dass text-overflow ähnlich wie content beliebige Strings unterstützt und auch das fade-Keyword oder eine fade()-Funktion für weiches Ausblenden. Zu guter Letzt lassen sich sogar zwei Werte setzen: Einer für das gewünschte Auspunkten zu Text-Beginn und eines zu Text-Ende. Leider ist der Browser-Support auch hier unterirdisch 😭

[00:24:21] CSS | selectors | :read-only

Mit der :read-only-Pseudoklasse könnt Ihr Eingabeelemente herausgreifen und stylen, die auf einem reinen Lesemodus stehen. Bei Inputs bewerkstelligt Ihr das mit einem gesetzten readonly-Attribut. So weit, so klar. Aber wusstet Ihr, dass :read-only jedes HTML-Element mit Ausnahme von input, textarea und contenteditable erfasst, weil die ja alle „Read only“ sind? 🤯
Umgekehrt könnt Ihr alle input, textarea und contenteditable, auf denen kein readonly-Attribut gesetzt ist mit der Pseudoklasse :read-write ansteuern.

[00:33:37] HTML | elements | <marquee>

Wir erinnern uns, dass <marquee> eines dieser Elemente aus grauer Vorzeit sind, als es weder CSS noch Flash oder Java Applets gab, um Texte zu animieren. Meist wurde es für Nachrichten-Ticker eingesetzt. Was wir nicht auf dem Schirm hatten war, wie viele Attribute (oder Neudeutsch: „props“) bereitstehen, um Art der Animation, Richtung, Bouncen, Loopen, Scrolldistanz oder Scrollschritte festzulegen. Es stehen zudem die Methoden .stop() und .start() bereit, um die Animation anzuhalten und wieder zu starten. Rund wird die Sache durch die drei Events start, bounce und finish.

[00:38:59] CSS | types | <time-percentage>

Bei <time-percentage> handelt es sich um eine alternative Spezifikations-Notation von [ <time> | <percentage> ] und bedeutet, dass als Wert wahlweise ein ⌚Zeit- oder ein Prozentwert angegeben werden kann. Allerdings nur dann, wenn sich der Prozentwert eindeutig in einen Zeitwert umwandeln lässt, so wie sich Prozentwerte bei Höhen- und Breitenangaben auch in Längen umwandeln lassen. Damit wissen wir schonmal mehr als in unserem zweiten Glücksrad mit Gast im Dezember, wo das auch schon einmal aufkam. Die wichtigste Frage können wir aber weiterhin nicht beantworten: Wo in CSS ist es möglich, einen Zeitwert in Prozent auszudrücken? MDN weiß es leider auch nicht. 🤔 Wisst Ihr es? 👀

[00:44:36] HTML | global_attributes | class

Naja, naja, hier gibt es nicht viel zu sagen. Stefan und Schepp sprechen ein wenig über Wege, HTML mit CSS zu verdrahten: Die einen mögen lieber BEM, die anderen setzen auf Utility-Klassen, und Dritte wie Harry Roberts mischen beides munter. Schepp mag es zudem, so viel wie möglich mit HTML-Attributen à la aria-hidden / hidden, aria-current & Co zu arbeiten, weil man Accessibility obendrauf bekommt. Beide freuen sich sehr auf all die neuen Möglichkeiten, mit dem :has()-Selektor CSS zu strukturieren 🤩

[00:58:25] CSS | selectors | ::-moz-color-swatch

Das Pseudo-Element ::-moz-color-swatch stellt in Firefox beim Farb-Input den Bereich dar, in dem die aktuell gewählte Farbe angezeigt wird. In Safari und Chromium gibt es analog dazu das Pseudo-Element ::-webkit-color-swatch. In dem Zusammenhang kommen wir auf das Open UI Projekt zu sprechen, das sich zum Ziel gesetzt hat, all diese Browser-Sonderlocken zu vereinheitlichen und gestaltbar zu machen. Stefan weist außerdem darauf hin, dass Ihr bei Input-Elementen mit Pickern ebendiesen neuerdings per .showPicker() sich programmatisch öffnen lassen könnt.

Anlässlich der Veröffentlichung Ihres neuen Buchs über die Sprache Rust, luden wir zwei der Autoren, nämlich Marco Amann (Twitter) und Marcel Koch (Twitter), sowie den hausinternen Rust-Experten Stefan zu uns in den Podcast ein, um über die Raison d’Être dieser Programmiersprache zu sprechen.

Schaunotizen

[00:01:46] Rust

Zur Einführung in Rust klären wir die wichtigste Frage zuerst, nämlich inwiefern Entwickler*innen wie unsere Hörerschaft sich Rust zunutze machen können. Danach erklären wir, inwiefern sich Rust von anderen Sprachen unterscheidet und inwiefern das von Vorteil ist. Spoiler: Es ist sein semiautomatisches Speichermanagement dank Ownership-System und Borrow Checker. Anschließend beschäftigen wir uns mit möglichen Anwendungen der Sprache und namedroppen Tools und Frameworks aus dem Rust-Universum als wenn es kein Morgen gäbe:

• Die Rust Foundation
• Cargo und crates.io – das npm von Rust
• Cargo.toml – die package.json von Rust
• rustup – das nvm von Rust
• wasm-pack – das WebPack von Rust
• Wasmtime – CLI Tools in Rust bauen
• neon – Rust in Node.js nutzen
• j4rs, aka „Java in Rust“ – Rust in Java nutzen und umgekehrt
• flapigen – Tool, um Rust mit beliebigen anderen Sprachen zu verknüpfen
• Actix – ein Webserver-Framework für Rust
• rocket.rs – ein besonders einsteigerfreundliches Webserver-Framework für Rust
• axum – ein weiteres Webserver-Framework für Rust, das auf der Tokio-Runtime basiert (siehe nächstes)
• Tokio Runtime – Framework, um in Rust asynchronen Code zu schreiben
• Diesel – ein ORM und Query-Builder für Rust
• Serde – Framework zum Serialisieren und Deserialisieren von „Structs“ (aka komplexen Datenstrukturen)
• Learn Rust – die offizielle Doku

Abschließend wollen wir natürlich auch ein Buch unserer Gäste verlosen. Alle Retweeter*innen unseres Ankündigungstweets ebendieser Folge kommen automatisch in den Lostopf!

[00:00:00] Keine Schaunotizen

Das Rust-Buch unserer Gäste

Konzepte und Praxis für die sichere Anwendungsentwicklung, gedruckt und/oder digital

Rust Meetup Linz

Das Rust-Meetup aus Stefans Heimatstadt, auch remote verfügbar per Video-Stream

New Rustacean

Ein Podcast zum Lernen von Rust

Rustacean Station

Ein Community-betriebener Podcast rund um das Thema Rust

Für diese Revision haben Hans und Schepp Accessibility-Guru Eric Eggert (Web / Twitter / YouTube) eingeladen, um über aktuelle und zukünftige Barrierefreiheitsstandards zu sprechen. Eric ist seit langen Jahren Mitbesitzer einer kleinen Agentur namens outline und hat als Freelancer einige Projekte, wie etwa die WAI-ARIA Tutorials und How to Meet WCAG für das W3C umgesetzt und zusammen mit dem Aktion Mensch e.V. an einer Deutschen Übersetzung der WCAG 2.1 gearbeitet.

Schaunotizen

[00:01:37] Die W3C Accessibility Standards

Die W3C Accessibility Standards werden von der Web Accessibility Initiative gemacht und gliedern sich im Wesentlichen in drei Bereiche auf:

• Die Web Content Accessibility Guidelines (WCAG), die in einer ersten Version im Jahr 1999 erschienen sind, und die 2008 von Version 2.0 abgelöst wurden. Auf der basiert auch die Deutsche Barrierefreie-Informationstechnik-Verordnung (BITV) und die 2016 verabschiedete, stattdessen greifende Web Accessibility Directive (Directive (EU) 2016/2102).
• Die Authoring Tool Accessibility Guidelines (ATAG) in Version 1.0 und 2.0, die leider wenig Traktion haben
• Die Accessible Rich Internet Applications (WAI-ARIA), die in Version 1.0 (2014) und in Version 1.1 (2017) veröffentlicht wurden, mit einem anstehenden Release 1.2, sowie…
• Aktuell noch Zukunftsmusik, die W3C Accessibility Guidelines (WCAG 3.0), mit der das W3C nicht mehr nur die Barrierefreiheit von Web Inhalten normieren möchte.

Wir reden mit Eric im Wesentlichen über die Rolle der WCAG, über ihre Evolution und wo sie eine Rolle spielt. So wird der European Accessibility Act spätestens ab 2025 jede an Endkonsumenten gerichtete Webseite dazu verpflichten, barrierefrei nach WCAG zu sein. Damit wird in der EU Stück für Stück die UN-Behindertenrechtskonvention aus 2008 in lokale Gesetzgebung überführt. Wir reden über die Zielrichtung der WCAG, darüber wie sie funktioniert und wie man prüft, ob man ihre Kriterien erfüllt.
Da sehr wahrscheinlich im Dezember Version 2.2 der WCAG veröffentlicht werden wird, sprechen wir natürlich auch über die Neuerungen, die dieses Minor Release bringen wird. Das sind im Wesentlichen:

• Klarere Vorgaben zur Kennzeichnung des aktuell fokussierten Elements auf der Seite
• Neue Vorgaben für eine barrierefreie Authentifizierung
• Vorgaben zur Größe von Elementen bei einer Bedienung per Touch

Zu guter Letzt geht es auch noch kurz über den zukünftigen Standard WCAG 3.0 (Projekt „Silver“ vom lateinischen Argentum (AG), das wiederum eine Anspielung auf „Accessibility Guidelines“ ist). Bei diesem möchte das W3C gänzlich neue Wege gehen. Die Fertigstellung ist für 2026 angepeilt.

Links

W3Cs Digital Accessibility Foundations Free Online Course

Ein kostenloser Online-Kurs für Programmierer und Nicht-Programmierer gleichermaßen, der erklärt, was Barrierefreiheit eigentlich ausmacht.

How People with Disabilities Use the Web

Wie benutzen gehandicapte Menschen eigentlich das Web?

Accessibility Fundamentals

Eure Starthilfe in Sachen barrierefreies Web

Understanding WCAG 2.2

So funktioniert die WCAG

How to Meet WCAG

A customizable quick reference to Web Content Accessibility Guidelines (WCAG) 2 requirements (success criteria) and techniques.

Diesmal haben wir es uns zu zweit lauschig gemacht. Vanessa schlüpfte in die Rolle unserer Gästin und hatte als Thema „Komponentenbibliotheken“ im allgemeinen und Storybook und Histoire im Speziellen im Gepäck.

Schaunotizen

[00:00:00] Komponentenbibliotheken – Why? How? What?

Vanessa und Schepp starten mit einer Definition des Begriffs „Komponenten“ und „Komponentenbibliothek“ und arbeiten sich sodann zum ersten und prominentesten Vertreter dieser Gattung vor: Storybook. Angetreten ist Storybook 2016 als sehr fokussiertes Werkzeug, das im Laufe der Zeit immer mehr zur eierlegenden Wollmilchsau hochgezüchtet wurde. Dies ging aus Vanessas Sicht leider nicht ohne Rückschritte im Handling einher. Speziell als mit Version 5 die „Knobs“ kamen trug es sie, und wohl auch einige andere Benutzer*innen, aus der Kurve. Hinzu kam, dass Storybook zwar allen gerecht werden möchte, man ihm seine auf React und Webpack zielende DNA aber immer noch anmerkt.

Da kam es Vanessa sehr gelegen, dass Vue.js-Core-Team-Mitglied Guillaume Chau neuerdings eine auf Vue.js und Vite spezialisierte Komponentenbibliothek namens „Histoire“ veröffentlicht hat. Und so sprechen wir über das Für und Wider der Nutzung beider Pakete, sehen z.B. die große Community auf der einen Seite, aber eben auch die bestechende Einfachheit bei dennoch umfangreichem Featureset auf der anderen.

Am Ende treten wir schließlich noch ein paar Schritte zurück und sinnieren über die Frage, ob solche Komponentenbibliotheken uns überhaupt nennenswerte Vorteile bringen, oder ob man sich mit ihnen nur ein weiteres zu pflegendes Softwarepaket ans Bein bindet, das einen herunterbremst.

[00:00:00] Keine Schaunotizen

Storybook Component Encyclopedia

Hier kann man sich die Komponentenbibliotheken und damit Entwicklungsansätze diverser großer Player ansehen.

Atomic Design

Das von Brad Frost ersonnene, von uns aber heftigst in die Pfanne gehauene Komponenten-Konzept.

Für diese Folge haben wir uns Jonas Ulrich vom Startup kickstartDS (Blog / Discord / Twitter) eingeladen, um über die praktischen Herausforderungen bei der Entwicklung eines UI Design Systems zu sprechen.

Vor der Gründung ihres Startups arbeiteten Jonas und seinen Mitstreitern 15 Jahre lang als Web-Agentur mit vorwiegend Mittelständlern als Kunden. Vor zwei Jahren entschied man sich dazu, die Erfahrungen des Agenturteams beim Entwickeln von Design Systemen in ein zusätzliches Standbein zu verwandeln und UI-Baukästen als Produkt anzubieten.

Wir wollen darüber reden, wie man an die Entwicklung eines solchen UI Design Systems herangeht und welche Herausforderungen darin stecken.

Schaunotizen

[00:01:39] Wie entwickelt man ein UI Design System?

Bevor es an die Entwicklung eines Design Systems geht, gilt es zunächst die Frage zu klären, wer später die Konsumenten sein werden. Im Falle von kickstartDS sind das ebenjene Sorte Mittelständler, die Jonas‘ Agentur bislang betreut hat, die bei rund 100 Mitarbeitern liegt und die schon über eine gewisse Anzahl Webseiten im Netz verfügt. Ziel ist damit nicht nur einfaches Theming, sondern Multi-Mandanten-Fähigkeit, also der Möglichkeit, das Design System für die Firmenwebseite, das Firmenblog oder eine Marketing-Seite im Charakter unterschiedlich ausfallen zu lassen.

Konzeptuell beginn die Arbeit mit der Entwicklung von Basis-Tokens, wie Fibonacci-Skalen, Farbvarianten, etc. Die müssen einzeln nicht nur gut funktionieren, sondern auch in einem Beziehungsgeflecht mit anderen Basis-Tokens. Das ist schwerer als man denkt. Die Basis-Tokens werden anschließend in semantische Tokens à la „Primary Color“ verpackt. Und die werden innerhalb von Komponenten dann nochmal in Komponenten-Tokens verpackt. Das erleichtert die Konfiguration und eröffnet den Benutzern gleichzeitig an all diesen Schnittstellen, auf Wunsch von der Vorgabe abzuweichen. Sinnvolle Token-Vorbelegungen ermöglichen darüber hinaus einen schnellen Einstieg, ohne Konfigurationsorgien. Insgesamt stellt dieser ganze Entwicklungsprozess eine multidisziplinäre Aufgabe dar.

Vom Workflow hat das Team sich für HTML, CSS und JavaScript als primäres Delivery-Format entschieden, weil das mit jeder Zieltechnologie gleich gut harmoniert. Konsumierende Entwickelnde müssen dann aber das HTML in die von ihnen verwendete Template-Sprache überführen (und bei Änderungen nachziehen). Von Jonas‘ Team werden die Komponenten aber natürlich nicht in diesen Technologien entwickelt, sondern werden am Ende dahin transpiliert. Die eigentliche Entwicklungsumgebung besteht aus JSX, SCSS und ES6. Das ermöglicht es aber, als weiteres Delivery-Format React zzgl. einer Konfigurationsbeschreibung nach JSON Schema anzubieten. Zudem werden die Design-Tokens in Amazons Style Dictionary Format angeboten, so dass sie von dort aus in alle möglichen Zielformate umgewandelt werden können (Claim: „Style once, use everywhere“). Web Components gehören aktuell u.a. aus SEO-Gründen nicht zu den auslieferbaren Formaten.

Wir sprechen außerdem darüber, wie man Design Systeme in Firmen etablieren kann. Jonas sieht am meisten Erfolg in einem Grassroots-Ansatz, also einem Ansatz, bei dem das entwickelnde Team sich ein Design System wünscht. Dann sind die Betroffenen nämlich motiviert an Bord. Weniger gut ist der Ansatz, ein Design System von oben zu verordnen. Zur Einführung empfiehlt er außerdem, sich nicht direkt der Haupt-Webseite zu widmen, sondern erste Erfahrungen in einem Nebenprojekt zu sammeln.

Da ein Design System nicht nur eingeführt, sondern danach am Leben gehalten und weiterentwickelt werden muss, ist es zudem erforderlich, dass man einzelne sogenannte „Champions“ oder gar ein ganzes „Design Ops“-Team benennt, das das UI-System wie ein interner Dienstleister pflegt und andere Teams mit Rat und Tat beim Einbau unterstützt. Hans und Jonas halten es für ideal, das Ganze im Stile eines Open Source Projektes zu führen.

Keine Schaunotizen

Revision 524: Design Systeme

Mit unserem damaligen Gast David Jost besprachen wir im April das Thema Design Systeme eher high-levelig und aus der Brille eines großen Unternehmens

Nathan Curtis: Naming Tokens in Design Systems

Terms, Types, and Taxonomy to Describe Visual Style

Tailwind UI

Beautifully designed, expertly crafted components and templates, built by the makers of Tailwind CSS. The perfect starting point for your next project.

Material UI

MUI offers a comprehensive suite of UI tools to help you ship new features faster. Start with Material UI, our fully-loaded component library, or bring your own design system to our production-ready components.

Chakra UI

Chakra UI is a simple, modular and accessible component library that gives you the building blocks you need to build your React applications.

Nachdem es vor zwei Revisionen um das Zusammenspiel von Cypress mit Vitest ging, wollen wir diese Revision ganz exklusiv Cypress widmen und über neue Features aus den Major-Releases 9 und 10 sprechen. Das letzte Mal haben wir das nämlich vor anderthalb Jahren gemacht. Dafür haben wir uns und die beiden Deutschen Cypress Ambassadore Ramona Schwering von Shopware und (erneut) Tobias Struckmeier von der Adesso eingeladen.

Schaunotizen

[00:00:58] Neues in Cypress 9 und 10

Das erste neue Feature, das wir beleuchten, ist das „Component Testing„, das derzeit noch in Beta ist. Beta unter anderem auch deswegen, weil es derzeit nur im Zusammenspiel mit React richtig gut läuft, mit Vue nur noch gut und mit Angular noch gar nicht so richtig.

Wie der Name schon andeutet, erlaubt es das Durchtesten isolierter UI-Bausteine, aber in echten Browsern anstatt in einer per JSDom simulierten Browser-Umgebung wie sie oft zum Einsatz kommt. Das ist zwar aufwendiger und langsamer, Fehler können damit aber besser debugged werden, weil die entwickelnde Person bei Auftreten eines solchen einfach den Browser übernehmen, die Devtools öffnen und mit der Fehlersuche beginnen kann. Dieses Feature führt aber leider zu einer neuen Projektstruktur, die zwischen E2-E und Component-Testing aufteilt, und die noch ein paar weitere Änderungen mit sich bringt. Wichtig zu wissen für eine Migration von einer älteren Cypress-Version – die allerdings recht schnell von der Hand geht.

Andere Tools zum Entwickeln von Komponenten wie Storybook ersetzt dieses Feature nicht. Andersherum bietet Storybook aber mittlerweile mit „Storybook Play“ ein eigenes Testing-Feature.

Als nächstes sprechen wir über Cypress Studio, welches man derzeit als experimentell einstufen muss, weil dessen Zukunft in Frage gestellt wird. Cypress Studio ermöglicht es, Cypress-Tests WYSIWYG-artig zu erstellen, was Nicht-Entwickelnden einen Zugang zum Erstellen von Tests öffnet. In Frage gestellt deswegen, weil die Chrome Devtools neuerdings mit dem „Recorder“ daherkommt, der User-Flows aufzeichnet, die man mit Hilfe von Browser-Plugins abgreifen und in eigene Tools und Formate exportieren kann.

Wir widmen uns in dem Zusammenhang der Frage, wie robust und dauerhaft rein visuell anstelle von semantisch zusammengestellte Tests sein können und sind uns darin einig, dass sie deutlich fragiler sind. Allerdings sind sie definitiv ein guter Einstieg in die Welt der Test-Erstellung und mit zunehmender Erfahrung wird es immer mehr möglich, diese als Vorlage zu betrachten, die man Anschluss „robust“ macht. Auch lässt sich Cypress vorab ein Stück weit so einstellen, dass es bestimmte HTML-Strukturen bevorzugt als Orientierungspunkte heranzieht als andere (bestimmte Attribute vs. CSS-Selektorkette).

Das dritte neue Feature, über das wir sprechen, ist ebenfalls noch experimentell: Das Multi-Domain-Testing. Multi-Domain-Testing ist traditionell ein blinder Fleck aller Testing-Tools, und zwar weil es technisch aufwändig oder sogar unmöglich ist. Es geht dabei darum, dass Tests auch möglich sind, wenn der User-Flow die primäre Domain zeitweilig verlässt, wie es zum Beispiel bei einem Login via externer Dienste der Fall ist, oder auch bei einer Zahlung über einen externen Zahlungsdienstleister. In Revision 442 sprachen wir dazu auch mit Marvin Hagemeister, der aus diesem Grund zusammen mit Kollegen sein eigenes Testing-Framework gebaut hat, das das kann. Dass sowas jetzt auch mit Cypress möglich ist, ist u.a. in der ebenfalls experimentellen „Session API“ zu begründen. Diese ermöglicht es, Cookies und LocalStorage-Daten über mehrere Tests hinweg zu persistieren. Das macht es auch möglich, bestimmte Arten von Tests zu beschleunigen, indem man die ganze Setup-Arbeit einmal macht, abspeichert und fortan nur noch lädt.

Das führt uns zu dem letzten diskutierten Themenblock, nämlich die Ausführungsgeschwindigkeit von Cypress-Tests und wie man die schnell hält. Ramonas Strategie ist, ein Basis-Set für die schnellen und wichtigsten Tests zu nutzen, um die Pipeline schnell zu halten, und dazu einen „Nightly Build“-Ansatz zu fahren, bei dem jede Nacht alles aufwendig abgetestet wird. Eine weitere Möglichkeit ist die Parallelisierung per Ordner oder Segmentierung via Tags, und das Ganze auf mehreren Maschinen orchestriert via Cypress Dashboard. Am längsten dauert aus ihrer Sicht aber immer das initiale Setup der Testdaten – und da unterscheidet sich Cypress nicht von anderen Tools. Und schließlich sind wir uns auch einig, dass keine 100% Testabdeckung notwendig ist, weil einfach zu teuer.

[00:00:00] Links

An Update on Cypress Studio

Ein Blogpost vom Cypress-Team mit dessen Überlegungen zu Cypress Studio.

Cypress 10.2.0: Run tests up to 2x faster on Apple silicon (M1)

Seit Version 10.2 läuft Cypress nicht mehr in einer Intel-Emulation, sondern nativ mit dem ARM-Befehlssatz.

Storybook Play

Storybook bietet mit Play nun einen eigenen Test-Workflow.

Vitest

Ein auf Vue maßgeschneidertes Testing-Framework. Mehr dazu in Revision 535.

Mit Josefine Schaefer und Manuel Schröder, beide Developer Relations Engineers bei dem Headless CMS Tool Storyblok, bespricht Vanessa das Imposter Syndrom bei Entwickler*innen.

Schaunotizen

[00:01:21] Das Imposter Syndrom bei Entwickler*innen

Vorneweg: Wir haben keine Ausbildung, um als Experten über dieses Thema zu besprechen. Wir tauschen unsere persönlichen und subjektiven Erfahrung aus.

Der Imposter ist ein Hochstapler. Personen können allerdings auch ein Hochstapler-Syndrom haben. Obwohl sie deutliche Beweise für ihre Fähigkeiten bekommen, fühlen sie manchmal, als hätten sie ihren Erfolg, z.B. eine Festanstellung als Software Entwickler:in, erschlichen. Wir besprechen, inwiefern Konferenzen, Social Media und das Arbeitsumfeld Auswirkungen auf Entwickler:innen in Bezug auf das Syndrom haben. Ebenfalls hinterfragen wir uns, welche Personengruppen davon stärker oder weniger betroffen sind. Sind es beispielsweise Selbstlernende oder theoretische Akademiker, die mehr damit zu hadern haben, wie man eigentlich StandUps, Code Reviews, und mehr organisiert. Außerdem sprechen wir über unsere Erfahrungen und weisen auf Artikel hin, mit dem man dem Imposter Syndrom entgegenwirken kann.

Links

• I’m Poster Manifest
• How to Overcome ‚Imposter Syndrome‘
• Tech Imposters

Verwandte Revisionen

• Revision 495: Storyblok – Einblicke in ein StartUp

In den letzten Monaten hat sich eine neue Kombination an Testing-Tools für die Frontend-Entwicklung gebildet, die von vielen Entwickler:innen favorisiert wird. Markus Oberlehner erklärt, wie man Cypress Component Testing und Vitest am besten verbinden kann.

Schaunotizen

[00:00:00] Testing mit Cypress und Vitest

Cypress und Vitest sind Test Runner. Test Runner sind Tools, die von Entwickler:innen geschriebene Tests auszuführen. Dabei kommt Cypress mit einem virtuellen Browser, während Vitest unschlagbar in der Ausführungszeit ist. Vitest kommt aus dem gleichem Universum wie Vue und Vite. Vitest, wie auch Cypress, sind allerdings Framework agnostisch und können mit beliebigen Bibliotheken eingesetzt werden, wie React und Angular. Eine Benutzung von Vitest zusammen mit dem Bundler Vite ist sinnvoll, da beide Tools die gleiche Konfiguration nutzen können. Es ist allerdings keine Voraussetzung.

Markus Geheimtipp ist ein unabhängiger Driver, der Tests sowohl in Cypress, als auch in Vitest ausführen kann.

Im Laufe der Revision geht Markus auf die Begrifflichkeiten von Unit, Integration und System Tests ein. Außerdem erklärt er, in welchen Fällen er es bevorzugt Mocks und Stubs zu benutzen, und in welchen nicht.

Links

• Good Vue Tests von Markus Oberlehner
• Vue.js Conf Berlin, auf der Markus Oberlehner einen Talk geben wird

Verwandte Revisionen

• Revision 458: Cypress
• Revision 520: Unit-Testing / Testing Library
• Revision 473: Vue 3, taugts?

In dieser Ausgabe legt Schepp Vanessa und Hans seine Überlegungen zu CSS Houdini dar.

Schaunotizen

[00:00:59] CSS Houdini, gescheitert?

Nach einem Recap, was CSS Houdini ist und warum es beinahe „WhatTF“ geheißen hätte, stellt Schepp die These auf, dass das Houdini-Projekt gescheitert sei. Es gibt aus seiner Sicht dafür einige Indikatoren, sowohl was den Implementationseifer der Non-Chromium-Browser-Hersteller angeht, also auch Kritik aus der Entwicklerschaft, u.a. die Paint API sei nichts weiter als -webkit-canvas() in neuem Gewand.
So schwarzmalerisch seine Schlussfolgerung ist, so sehr freut er sich über einen Teilfeature von Houdini, nämlich die @property At-Rule. Diese ergänzt CSS um die Möglichkeit zur Typ-Annotation von Custom Properties, so dass der Browser diese fortan nicht mehr nur als dumme Strings betrachtet, sondern als Fließkomma- oder Ganzzahl, als Farbe, Rotation oder Längenmaß. Und das wiederum eröffnet einem in Kombination mit CSS Animationen und calc() eine Welt an Möglichkeiten, die man zuvor nicht hatte, z.B.:

• Animierte Gradienten
• Automatisierte Slideshows
• Objekt-Morphing
• oder sogar mathematische Algebra!

Schepps Wunsch wäre daher, dass sich die Browser-Hersteller auf die kleineren Dinge konzentrierten und dass @property zukünftig auch in Firefox und Safari implementiert würde (eventuell auch per Crowdfunding durch die Firma Igalia):

• Mozilla Bug
• WebKit Bug
• Igalia Open Prioritization

Was ist Eure Meinung zu CSS Houdini? Schickt uns einen Tweet an @workingdraft, oder diskutiert mit in unserem Community Slack!

Es ist mal wieder ein schöner DienstagMittwoch und wir hauen die nächste Folge raus. Diesmal mit von der Partie sind der Schepp und der Hans. Schepp berichtet über die Core Web Vitals – mehr dazu unten.

Schaunotizen

[00:00:59] Core Web Vitals

Wenn man sich die aktuellen Performance-Metriken im Frontend so anschaut, guckt man meistens auf die Web Vitals von Google. Schepp erklärt, warum wir die Web Vitals haben und wie die Core Web Vitals funktionieren. Auf alle Metriken der Web Vitals ist er auch schon mal im Wo Wir Sind Ist Vorne Podcast eingegangen. Außerdem sprechen wir über die kürzlich neu eingeführte Metrik Interaction to Next Paint.
Wer mehr zu den Web Vitals lernen möchte, schaut am besten Mal hier vorbei.

Wir sind wieder mit einer neuen Episode am Start und diesmal geht es um das Thema „Infrastructure as Code“. Hans spricht mit Thomas Eisenbarth über seine Erfahrungen mit dem Thema. Ein richtig interessanter Talk, der die Seite der Development Operations etwas näher beleuchtet.

Schaunotizen

[00:01:33] Infrastructure as Code

Den meisten von euch ist der Begriff Infrastructure as Code bestimmt mal über den Weg gelaufen. Mit der Entwicklung, die Hardware, wie Netzwerk und Server, nicht mehr selbst zu betreiben, sondern alles in die Cloud zu schieben, ist die Reproduzierbarkeit von Infrastruktur relevant geworden.
Wir diskutieren, woher wir kommen, warum wir Infrastruktur in Code beschreiben wollen und welchen Effekt das auf die Zusammensetzung eines Teams haben kann. Außerdem gibt Thomas Tipps, wie man sich selbst dem Thema annähern kann, auch wenn man noch nicht so viel Ahnung davon hat.
Erwähnt haben wir unter anderem:

• Terraform
• Inspec

Ihr wollt über das Thema etwas diskutieren? Dann schaut mal in unserer Community auf Slack vorbei: draft.community.

Diese Ausgabe haben Vanessa und Schepp sich mit Manuel Matuzović (@mmatuzo / Webseite), Frontend-Entwickler und Barrierefreiheitsexperte, zusammengetan und gemeinsam ein Plädoyer für mehr Markup-Eloquenz im Web gehalten.

Schaunotizen

[00:01:00] Mehr Eloquenz im Web!

• Manuels beyond tellerrand Talk „Lost in Translation“
• Accessibility Club Meetup #11
• W3C Markup Validation Service
• HTMLHell
• HTML Tags Memory Test
• The WebAIM Million
• WAVE, das Web Accessibility Evaluation Tool
• Umfrage von Manuel zum Einsatz von HTML-Validatoren auf Twitter und Reddit
• Create React App
• Netlify plugin for post-build validation of HTML
• Google Lighthouse: „Zu viele DOM Knoten“-Fehler
• Eric Bailey – The Intersection of Accessibility and Performance
• Harry Roberts – Get Your „head“ Straight
• Tim Kadlec – The Big Picture
• Das fetchpriority-Attribut, aka Priority Hints
• HTML Validator Bookmarklet
• Webhint.io und dessen Integration in die Edge-Devtools
• axe
• Alpine.js
• Das CSS Café Meetup
• Josh Comeau: CSS for JavaScript Developers

Schepp begrüßte diesmal jemanden, dessen Aktivitäten er schon seit Jahren auf Twitter verfolgt: Wolfram Kriesing aus München (Blog / Twitter).

Schaunotizen

[00:01:00] Von Katas, Craft Camps und Code Retreats

Wolfram ist nicht nur ein Urgestein der IT, sondern war auch Early Adopter der Sprache JavaScript. Zeitgleich mit dem Aufkommen der ersten JavaScript-Just-in-Time-Compiler gründete Wolfram mit einer Handvoll weiterer Visionäre die auf JavaScript spezialisierte Firma uxebu. Dort hantierte man schon frühzeitig mit Enterprise-JavaScript-Frameworks wie dem Dojo Toolkit und entwickelte einen Konverter für Flashs SWF-Dateien namens Pixel Plant und zahlreiche weitere Open Source Lösungen.

Wolframs Passion für die Sprache führte ihn immer tiefer in den Fuchsbau und schließlich zum Konzept des Test-Driven-Developments (TDD). Wir reden darüber, wieso TDD nicht nur ein guter Ansatz zum Entwickeln ist, sondern sich mindestens ebenso gut zum Lernen und Verstehen einer Sache eignet.

Und schließlich reden wir auch über zahlreiche Lernplattformen und Events, die Wolfram zu den zuvor genannten Themen aus der Taufe gehoben hat:

• Das JSCraftCamp – eine Software-Crafting-Unkonferenz, nur eben fokussiert auf die Sprache JavaScript. Das nächste Camp wartet am 17. und 18. Juni 2022 in München auf Euch!
• Die JavaScript Katas – eine Sammlung von Coding-Herausforderungen, genannt Katas, die einem helfen sollen, sich mit der Funktionsweise einzelner JavaScript-Bestandteile vertraut zu machen. Der Clou ist, dass das Ganze natürlich in einen TDD-Unterbau eingebettet ist.
• Die JavaScript Code Retreats – eine weitere Event-Serie, in der Wolfram mit einem Münchener Ableger mitmischt. Diese Ein-Tages-Events finden zeitgleich weltweit statt und auch dort geht es darum, seine Skills mit Hilfe von TDD auf das nächste Level zu hieven.
• Das JavaScript The Language Meetup – hier wird nur aller feinstes JavaScript in Form von TDD-getriebenem Mob-Programming serviert und verköstigt.

In einer offenen Diskussionsrunde bespricht Vanessa mit Nikolaus Rademacher, Senior Product Engineer bei Accenture Song, das Thema Software Schätzungen im Rahmen von Sprints. Zuvor war Nik bereits zu Gast, um über die Rolle und Verantwortung von Entwickler:innen in agilen Teams in Revision 510 und Revision 512 zu sprechen.

Schaunotizen

[00:00:58] Richtig schätzen

Wie schätzt man eigentlich richtig? In dieser Revision widmen wir uns Schätzungen, egal ob Fibonacci, T-Shirt Größen, oder einfach nur Zahlen. Wir besprechen, ob man Bugs schätzen sollte, was Spill-Overs sind und welche Vor- und Nachteile es hat, die Schätzungen von Tickets in Bearbeitung nochmals anzupassen, wenn man as Gefühl hat, dass man daneben lag. Wir klären auch die Antwort auf die Frage: „Was ist besser? Zeit- oder Komplexitätsschätzungen“. Oder wie wäre es mit „Kundenwert“ stattdessen? Sie ist: „es kommt darauf an!“ ;)

Nik stellt das Cynefin Framework vor. Es ist ein nützliches Tool, um Tasks in „komplex“, „kompliziert“, „chaotisch“ und „klar“ zu kategorisieren.

Als Online Scrum Planning Poker Tool empfiehlt Vanessa Planning Poker Online.

Wieder einmal zu Gast ist Jon Uhlmann (@jonnitto), mit dem wir diesmal über Svelte und SvelteKit sprechen.

Schaunotizen

[00:00:58] Svelte und SvelteKit

Bei Svelte hat sich in den letzten Jahren wieder einiges weiterentwickelt. Treu geblieben sind sie sich allerdings, denn wie gewohnt ist die Dokumentation sehr hilfreich, übersichtlich und umfassend. Im Gegensatz zu React ist Svelte tatsächlich „reaktiv“. Dabei kommt es mit einem eigenem Compiler. Seit einiger Zeit gelangt SvelteKit an immer mehr Beliebtheit. Das Framework ist der Nachfolger von Sapper. Wer von Sapper auf SvelteKit migriert, kann sich an den offiziellen Guide halten. Zwei tolle Eigenschaften von Svelte sind der eingebaute Accessibility-Support und die Unterstützung von Transitions und Animations, die an die Transitions von AlpineJS erinnern. Wer sich nun für Svelte interessiert und auf der Suche nach mehr Informationen ist, kann bei der Webseite vom SvelteSummit vorbeischauen. Erst vor Kurzem fand die diesjährige Remote Konferenz statt. Die Videos findet man auf YouTube: Svelte Summit Sprint. Um sich sonst auf dem Laufenden zu halten, empfehlen wir den Svelte Blog mit monatlich erscheinenden Artikeln.

Weitere Revisionen mit Jon Uhlmann

• Revision 504: Analytics- & Tracking-Tools
• Revision 490: Alpine JS & Petit Vue mit Jon Uhlmann
• Revision 496: Tooling rund ums Frontend Tooling.

Weitere Revisionen zum Thema Svelte

• Revision 413: Svelte

Diese Revision ist Vanessa in die Rolle der Gästin geschlüpft und hat Schepp etwas zum Thema „State Management“ in Vue erzählt.

Schaunotizen

[00:00:00] Vue State Management

Wir beginnen mit einem Rückblick auf Vue 1 und 2 und die dort etablierten Global- und Options APIs
Vue 3 hat dann, angelehnt an Reacts Hooks, die Composables und die Composition API eingeführt, sowie die Reactivity API, die einen alle aus der Prop-Drilling-Hölle befreien – wenn man denn weiterhin ohne waschechten Store arbeiten wollte.
Ist die Entscheidung für einen Store gefallen, dann hieß der früher immer Vuex und war der vom Vue-Team mitentwickelte und offiziell empfohlene. Parallel dazu hat sich ein weiterer Store entwickelt, nämlich Pinia, und der ist über die Zeit so gut geworden, dass er nun offiziell zu Vuex 4’s Nachfolger ernannt wurde. Pinia spielt besser mit TypeScript und auch mit Server-Side-Rendering zusammen, und lässt sich ähnlich wie die oben genannte Composition API ansteuern.
Und dann gibt es schließlich noch Harlem.js, das sich auf die Composition- und Reactivity APIs stützt, und somit nur mit Vue 3 arbeitet.

Vanessas Fazit lautet: Benutzt gerne weiter Vuex, wenn Ihr es schon im Einsatz habt, setzt aber auf Pinia, wenn Ihr neue Projekte aufsetzt. Harlem.js hingegen sagt ihr vom Ansatz her spontan nicht so zu.

Schepp und Peter durften Martin Splitt begrüßen (Developer Advocate bei Google, Web, Twitter) um mit ihm über technische Suchmaschinenoptimierung zu plaudern und mit den übelsten SEO-Mythen aufzuräumen.

Schaunotizen

[00:01:00] Technisches SEO in 2022

Seit Martins letztem Besuch in der Revision 351 hat sich einiges getan! Der JS/CSS-Support des Google Bots ist mittlerweile sehr umfassend, nur mit bestimmten Web APIs wie Geolocation und Service Worker weiß der Crawler nichts anzufangen. Martin empfiehlt zur Fehlersuche die Search Console um JS/API-Probleme wie auch versehentliche Ressourcen-Blockaden gegenüber dem Google Bot aufzudecken. Wir quatschen aus diesem Anlass über die robots.txt, den x-robots Tag (aka HTTP-Header), Sitemaps, rel="nofollow" und rel="sponsored" und die im Zuge all dieser Informationen aufkommenden Herausforderungen des Indizierens von Web-Content. Wo der SEO ist, ist aber auch der Schlangenölverkäufer meist nicht fern, und so kommen wir nicht umhin, auch ein wenig über obskure Seo-Magie, Verschwörungstheorien und Cargo-Cult-SEO (und Entwicklung) zu diskutieren. Am Ende des Tages schlägt nichts eine saubere URL-Struktur mit Sitemap, Meta-Informationen (vorzugsweise via JSON-LD) und einem Auge auf den Web Vitals. Zuletzt verweisen wir noch auf den , Schepps Auftritt bei WWSIV und plädieren für einen gesunden und entspannten Umgang mit SEO!

Schepp und Peter durften Marc Thiele (Web, Twitter) als Gast begrüßen, der viel über die Beyond Tellerrand (und seine übrigen Aktivitäten) in der Vergangenheit und der durch Corona verseuchten Gegenwart zu erzählen hatte.

Schaunotizen

[00:01:22] Konferenzen und Corona

Marc rekapituliert zunächst die Geschichte der Beyond Tellerrand und erzählt, was die Konferenz sein soll und was nicht (eine weitere, trockene Techtalk-Tristesse). Unter Corona-Vorzeichen ist’s mit dem Konferenzgeschäft knifflig und weder Konferenzverstalter Marc noch Konferenzcontentgenerator Peter sehen in Online/Hybrid-Formaten einen 1:1-Ersatz. Angepasste Formate wie Marcs Stay Curious sind eine Notlösung, mehr nicht. Da trifft es sich gut, dass es demnächst eine weitere Beyond Tellerrand in Düsseldorf gibt und noch Tickets zu haben sind! Sollte das entweder euren Konferenzhunger nicht stillen oder Düsseldorf für euch zu südlich liegen, hat Marc außerdem die aXbt in Hamburg im Angebot.

Für diese Ausgabe haben wir uns wieder einen Gast eingeladen: David Jost, mit dem wir in über einer Stunde das Thema „Design Systeme“ von all seinen Seiten beleuchten. Und das sind mehr, als man in seiner Naivität gemeinhin glaubt.

Schaunotizen

[00:01:21] Design Systeme

• TED 2005 – Richard St. John – 8 secrets of success
• Frank Chimero – The Web’s Grain
• Stephen Hay – Responsive Design Workflow
• Nathan Curtis
• Una Kravets – The new responsive: Web design in a component-driven world
• Inclusive Components – Cards
• Open UI Project
• UI Engineering Podcast

Die traditionell-quartalsweise erscheinende Podcast-Folge, in der Stefan und Peter das eine Thema planen und 80% der Zeit über das andere Thema sprechen, ist da!

Schaunotizen

[00:01:45] TypeScript 4.6 ist da

TS 4.6 bringt wenig neues, aber da wir in den TypeScript-Folgen eh immer über interessantere Themen sprechen, ist uns das ganz recht. Stefan erzählt etwa davon, wie er im Klassenkampf die Seiten gewechselt hat und ein an das ES-Iterator-Protokoll andockendes Lazy-Iterator-Tool mit ECMAScript-Klassen gebaut hat. Im Rahmen dessen freut er sich sogar darüber, dass das erste kleine TS-Feature, etwas präziser dem ES-Standard folgende Unterstützung für super(), jetzt da ist und postuliert Use Cases rund um Open Telemetry. Peter hat derweil Kunden mit einen Use Case für Static-Blöcken in Klassen, die uns vorletztes Mal noch nicht überzeugen konnten. Allgemein halten wir fest, dass früher (= Java/OOP/POOP), zwar vieles, nicht alles schlecht war und dass auch in Programmierbüchern von 1997 noch Weisheit zu finden ist. Im Verhältnis 20/80 widmen wir uns der weiteren langweiligen und marginalen TypeScript-Updates (dies, das, jenes) sowie den wesentlich spannenderen Themen rund um Typannotationen, Funktionsüberladung, TS-Performance, SWC, Demo, Runtime-Typen und TS-Specs, Language Server Protocol, Rust, Zig, Java und Homepagebaukästen

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.

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.

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!

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.

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.

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.

Dieses Mal hat Schepp Patrick Lipinski aka Lippe aka @dickelippe zu einer Runde Glücksrad zu Gast. Wir kennen Patrick schon sehr lange von dem ganzen Konferenz-Getingele, besser bekannt unter dem Begriff „Klassenfahrt“, und bei der letzten gemeinsamen Konferenz kamen wir darauf, dass er doch einmal Gast bei uns sein könnte. Gesagt, getan!

[00:00:59] Glücksrad

CSS‘ appearance-Property

Los geht es mit der appearance-Property. Patrick und Schepp stellen fest, dass sie diese CSS-Eigenschaft eigentlich immer nur mit dem Wert none verwenden. Gibt es auch andere Use-Cases? Schepp kommt außerdem in den Sinn, dass man im neuesten Edge Canary das vom Open UI Projekt konzipierte, und frei umgestaltbare <selectmenu> ausprobieren kann. Wir debattieren zum Abschluss kurz über Reset vs. Normalize und über die neueste Form des Resets.

Das <applet>-Element

Die Anfangszeiten des Webs grüßen und wir erinnern uns an Java-Applet-getriebene Wellen-Effekte auf Websites. Auch Java-getrieben, aber anders schlimm: Die Log4j-Sicherheitslücke, über die Kristian Köhntopp ein herrliches Meinungsstück geschrieben hat.

Das title-Attribut

Wird leider meist als Tooltip oder von SEOs missbraucht. Wo das title-Attribut sinnvoll eingesetzt werden kann, ist z. B. als Sidekick des <abbr>-Elements.

Der CSS-Datentyp <time-percentage>

Mehr als das, was wir in MDN lesen können, wissen wir in der Folge selbst nicht über diesen Datentyp: Er darf wahlweise ein Zeitwert oder ein Prozentwert (einer Zeit) sein. Anders als Schepp vermutet, hat das Ganze aber nichts mit den neuen Scroll-Linked-Animations zu tun.

Die Gyroscope API

Eine der ersten APIs, die mit HTML5 aus der Taufe gehoben wurden. Schepp erinnert sich, dass Macbooks auch ein eingebautes Gyroskop/Accelerometer haben, auf welches man aus Browsern heraus zugreifen kann.

Die CSS :host-context()-Pseudoklasse

Über diese Pseudoklasse kann eine Webcomponent trotz Shadow-DOM-Barriere herausfinden, in was für einem Light-DOM-Baum ihr Shadow-Dom-Host steckt. Gut, wenn die Komponente sich an verschiedene Kontexte anpassen können soll.

CSS Global Keywords

Globale Keywords in CSS wären Dinge wie auto, none, inherit, revert oder initial, die man in so gut wie jede Eigenschaft stecken kann.

HTMLs inputmode-Attribut

Über das inputmode-Attribut können Web-Entwickelnde auf einem <input>-Element steuern, welche Art von Softkeyboard zur Eingabe angezeigt wird. Praktisch, wenn es etwa in einer Anmeldung ein Feld gibt, in dem man entweder seine E-Mail-Adresse oder seinen Benutzernamen eingeben kann.

Web Animations API Keyframe Effects iterationComposite-Eigenschaft

Diese Eigenschaft, von der wir zuvor noch nicht gehört haben, scheint zu steuern, ob erneute Animationsdurchgänge einen vorherigen Wert ersetzen oder sich aufaddieren. Tja, wieder was gelernt und vielleicht brauchen wir es eines Tages mal? Sowohl Patrick als auch Schepp haben die Web Animations API bislang noch nicht eingesetzt, allerdings kommt Schepp eine bestimmte Folge der „HTTP 203“-Serie in den Sinn, in welcher Jake ein ganz bestimmtes Problem nur mit Hilfe des Web Animations API lösen konnte. Sehenswert!

Der CSS-Datentyp ratio

Wurde der ratio-Datentyp früher ausschließlich in Media Queries genutzt, kommt er neuerdings auch in der CSS-Eigenschaft namens aspect-ratio zum Einsatz.

Die Presentation API

Wir wissen nur eines: Es gibt sie wohl. Wer weiß, wofür sie gut ist: Bitte melden! 😅

CSS‘ @property-Rule

Wir finden diese ist das Beste des ganzen CSS-Houdini-Projekts und verweisen auf Schepps Darlegungen in der 33-ten Folge des „Wo wir sind ist vorne“-Podcasts (ab 00:12:31).

Links

CSS‘ -webkit-text-stroke-Property

Patrick erzählte in der Vorbesprechung von der Möglichkeit, farbige Text-Umrandungen nicht nur in SVG, sondern auch in HTML per CSS zu setzen. 😊

CSS‘ paint-order-Property

Die zweite CSS-Eigenschaft, von der Patrick erzählte, war paint-order, das in Kombination mit -webkit-text-stroke nützlich wäre, um eine Umrandung wirklich nur außen herum gehen zu lassen, indem man den Hintergrund/Fill drüber legt. Leider wird diese noch nicht außerhalb von SVG unterstützt. 🙁

Patrick sucht aktuell eine Position als UX-Engineer!

Ihr fragt, was macht denn ein UX-Engineer eigentlich? Kein Problem, auch hier können wir wieder auf die Kollegen vom „Wo wir sind ist vorne“-Podcast verweisen, die zu dem Thema eine Folge mit Dirk Ginader aufgenommen haben. Wer also jemanden weiß, der jemanden weiß… Immer her mit den Jobangeboten!

Einmal alles andersherum! Diesmal führt unser Gast Ole Michaelis, Software-Entwickler, Konferenzsprecher, Organisator und Jonglierer, ein Interview mit unseren Hosts Hans und Vanessa zum Thema „wie schafft man sich eigentlich neues Wissen drauf“?

Schaunotizen

[00:00:59] Lernen, Weiterbildung und Wissenserweiterung

Ole erzählt uns zu Beginn, dass er mittlerweile lange genug im Bereich der (Web-)Entwicklungen arbeitet, um bei neuen Frameworks und Bibliotheken das Gefühl zu bekommen: das gab’s doch fast genauso vorher schonmal! Im Anschluss wird diskutiert, wie man eigentlich Trends und Hypes erkennt, und von Konzepten unterscheidet, die sich im Endeffekt durchsetzen werden oder durchgesetzt haben.

Auf dieser Grundlage, erörtern sie, we man sich dafür entscheidet, was man sich tatsächlich genauer ansieht und lernt. Für Ole war es zum Beispiel Haskell, worauf sich Vanessa hin an ihre schöne Standard ML (SML) Zeit in der Universität erinnert. Weiterhin werden verschiedene Medien zum Lernen besprochen, wie zum Beispiel Videos auf YouTube, Newsletter (Links siehe unten), Kursplattformen, etc.

Die nächste Frage, wenn man schon einmal angefangen hat zu lernen, ist die, wann man wieder aufhört. Ab welchem Zeitpunkt entscheidet man sich dafür, dass man genug über dieses Thema weiß?

Abschließend, ein sehr wichtiger Aspekt, geben Ole, Hans und Vanessa ihre Meinung zum Thema „Lernen während der Arbeitszeit“ bzw. „Lernen finanziert durch die Firma“ ab. Alle sind sehr interessiert an der Meinung der Hörerrinnen und Hörer!

Links

• Tools
  • Things 3
  • Abyss
• Programmierspiele und Co.
  • Advent of Code
  • Human Resource Machine
  • Langton Ant
  • Game of Life
  • Elevator Saga
• Newsletter
  • Newsletter von Stefan Judis
  • HTMHell
  • Release Notes von Working Draft

Diese Revision nehmen Vanessa und Schepp die Veröffentlichung des diesjährigen Web Almanac zum Anlass, sich ein paar der darin beleuchteten Bereiche heraus zu picken und über die Daten und Erkenntnisse zu reden.

Schaunotizen

[00:01:00] Der Web Almanac 2021

Aufgrund des großen Umfangs und der Detailtiefe entscheiden wir uns, uns auf ein paar wenige Themen aus dem Almanac zu beschränken. Unsere Wahl fällt auf JavaScript, Structured Data, Accessibility, Page Weight und CMS. Wir kommen relativ zu Anfang auf das Thema Security zu sprechen und nennen das Audit-Werkzeug Snyk, verweisen auf eine vergangene Revision zum Thema Mutated XSS erinnern uns an Blogposts, die beschreiben, wie man npm-Pakete theoretisch zum Abgreifen von Daten missbrauchen könnte oder wie es praktisch tatsächlich passiert. Schepp lernt nebenbei, dass es einen SourceMap-HTTP-Header gibt. Hinsichtlich Accessibility verweisen wir auf eine gar nicht so alte Episode von uns, erwähnen Manuel Matuzovićs Experiment, diversen automatisierten Accessibility-Audits trotz völlig unzugänglicher Webseite perfekte Accessibility-Scores abzutrotzen und dass wir beim Accessibility-Club in einem Vortrag von Karl Groves gelernt haben, was sogenannte Accessibility-Overlays doch für ein Schlangenöl sind. Im Abschnitt CMS sind wir positiv davon überrascht, wie gut TYPO3 im Bereich Performance abschneidet und wir erwähnen auch kurz das Headless CMS Storyblok, dessen Macher vor nicht all zu langer Zeit bei uns waren.

Anlässlich Hans‘ Mitwirken an der mittlerweile leider eingestellten Hörbuch- und Podcast-Plattform FYEO, reden wir heute über die Herausforderungen, die der Bau eines 1,6 Millionen Podcasts umfassenden Katalogs mit sich bringt.

Schaunotizen

[00:01:02] Herausforderungen beim Bau eines Podcast-Katalogs

Zu Beginn klären wir, wie Podcasts eigentlich gehostet, veröffentlicht und verteilt werden. Viele Podcasts nutzen zum Hosten ihrer Audio-Dateien spezialisierte Anbieter wie anchor.fm oder Podigee. Andere, wie wir, hosten ihre Audios selbst (und erzeugen damit 2 Terabytes an Traffic im Monat, Chapeau an dieser Stelle an ALL-INKL.COM).

In beiden Fällen benötigt man dann einen speziellen Podcast-Atom/RSS-Feed, der entweder von den Hosting-Plattformen ausgespuckt wird, oder von der eigenen Webseite, z.B. in Form eines WordPress mit Podcasting-Plugin.

Aufgrund dieses dezentralen Hosting-Ansatzes, werden Podcasts von den Podcast-Katalogen dieser Welt erst einmal gar nicht gefunden. Stattdessen musss man selbst tätig werden, und sie bei allen gewünschten Plattformen eintragen, sei es bei Apple, Google oder Spotify. Am Apple-iTunes-Verzeichnis wiederum bedienen sich viele weitere, kleinere Podcasting-Plattformen, um Podcasts zu finden und zu ihrem eigenen Fundus hinzuzufügen. So lief das auch bei Hans‘ ehemaligen Projekt.

Fortan ging anschließend darum, mit klugen Herangehensweisen zu erreichen, dass von den Podcastmacher*innen veröffentlichte Episoden schnell auf der Podcast-Plattform angezeigt werden. Das ist insofern nicht so einfach, als dass die Podcast-Feeds einem Pull- statt einem Push-Prinzip folgen, man Feeds aber auch nicht unendlich häufig anfragen kann.

Für Podcaster ist es jedenfalls wünschenswert, auf so vielen Plattformen wie möglich vertreten zu sein, damit der Umfang der Hörerschaft wächst, und andererseits auch, um von Statistiken zu Abspielverhalten und Demografie zu profitieren, die diese Anbieter im Gegenzug bereitstellen.

Keine Schaunotizen

Unsere Audioproducerin Sabine Piel

Seit Sabine uns unterstützt, schaffen wir es endlich, Episoden regelmäßig zu veröffentlichen 🙏❤

Wo wir sind ist vorne № 33: Web Performance

Schepp war zu Gast im sehr empfehlenswerten Frontend-Podcast von Moritz Gießmann und Constantin Groß namens „Wo wir sind ist vorne“. Dort haben die drei einen 3,5-Stunden-Brecher zum Thema „Web Performance“ aufgenommen, bei dem keine Frage mehr offen bleiben dürfte.

Erneut trafen sich Stefan und Peter unter dem Vorwand einer neuen TypeScript-Version um ihrem Zorn über alle möglichen Gesamtsituationen Luft zu machen.

Schaunotizen

[00:01:55] State of the ECMAScript Module

TypeScript wollte besseren ESM-Support ausrollen und hat’s dann doch nicht getan. Warum? Weil aktuell JS-Module ein einziges Chaos sind! Wir gedenken den Ahnen (RequireJS- und CommonJS-Modulen sowie Browserify) und verfluchen sie für das, zu dem sie den ESM-Standard verleitet haben. Zwischen unserem Geschimpfe sprechen wir auch über modul-relevante Tools der nächsten (Rome, Vite, esbuild, swc, deno) und letzten Generation (Jest, Closure Compiler, Less, Sass), sowie ein wenig über React, die ScriptConf, Rust (und andere Sprachen) als die Zukunft von JS-Infrastruktur und LLVM.

[00:00:00] TypeScript 4.5

So sehr uns das Modul-Chaos ärgert, so gut finden wir dann doch Tail-Recursion Elimination für rekursive Typen (übrigens ein ES6-Feature, das bis heute fast in keiner JS-Engine funktioniert), lib-Upgrades und Use Cases wie den ResizeObserver, Neuerungen für Template String Types, Top-Level-Await, Private Field Presence Checks, Import Asertions, JSDOC, TSDOC und SOAP.

Aller guten Dinge sind drei, und so kam es dass wir Jon Uhlmann (@jonnitto) zum dritten Mal als Gast einladen konnten, um mit ihm über den Themenkomplex „Analytics & Tracking Tools“ zu sprechen. Unsere vorherigen Ausgaben mit ihm findet Ihr unter Revision 490: Alpine JS & Petit Vue mit Jon Uhlmann und Revision 496: Tooling rund ums Frontend Tooling.

Schaunotizen

[00:01:50] Analytics- & Tracking-Tools

Wir beginnen mit einer Aufzählung der verschiedenen Arten an Analytics- & Tracking-Tools: Angefangen hat alles Ende der Neunziger mit Perl-befeuerten Besucherzählern und dem Auswerten von Server Logs – z.B. mit AWStats, das auch wir hier vom Podcast noch heute benutzen, um unsere Downloadzahlen zu tracken. Mitte der Zweitausender kaufte Google die Firma Urchin inklusive Ihres gleichnamigen Analytics-Tools, welches im Anschluss in „Google Analytics“ umbenannt und zur kostenlosen Nutzung freigegeben wurde. Entsprechend explodierte danach der Einsatz dieses Tools. Noch etwas später wurden Werkzeuge populär, die Besuchersessions tracken Besucherverhalten in Heatmaps abbilden, wie z.B. Hotjar. Die neueste Errungenschaft sind sogenannte „Retargeting“-Pixel, mit denen Werbetreibende, aber auch Facebook erkennen, dass man sich für bestimmte Themen interessiert und die einem fortan mit immer wieder dieselbe Werbung schwer auf den Keks gehen können.

Die Vorteile dieser Tools liegen auf der Hand. Gleichzeitig ist Datensparsamkeit ein erstrebenswertes Ziel, weil Daten in falschen Händen auch gegen einen verwendet werden kann. Aus diesem Grund entwickeln sich immer mehr Betriebssysteme und Browser in Richtung Privacy, so dass man entweder ganz vor Tracking geschützt wird oder nur noch dann getrackt wird, wenn man selbst zustimmt (was in diesem Fall wohl nur noch 10% der Nutzer*innen tun):

• Der Brave Browser
• Apples App Tracking Transparency und die Intelligent Tracking Prevention in Safari, oder
• Firefox‘ Enhanced Tracking Protection

Gleichzeitig entwickelt sich ein Markt für alternative, DSGVO-konformere Tools, wahlweise zum Selberhosten oder in der Cloud:

• Matomo
• Plausible.io
• Piwik Pro
• Sentry

Insgesamt 60 Tools listet dieses Blogpost auf.

Wie erwähnen außerdem die Möglichkeiten, ganz ohne eigenes Tracking interessante Erkenntnisse aus der Google Search Console oder dem Chrome User Experience Report (CrUX) zu gewinnen.

Vanessa und Peter tauschen sich in dieser Revision überraschend ausgiebig zu diversen CSS-, HTML- und Accessibility-Problemchen/Features aus.

Schaunotizen

[00:00:00] Kleinkram

Vanessa hat festgestellt, dass Viewport-relative Einheiten und vor allem vh nur bedingt existieren – zumindest in mobilen Browsern. Browser-Heuristiken und bestimmte Verhaltensweisen von (mobilen) Browsern treiben uns in Sachen horizontalem Scrolling, Accessible Dialog-Design und :focus-visible um. Wir quatschen kurz über Safari-Bugs und Selektor-Hacking, agitieren für die Verwendung von input[type=email] sowie die Nicht-Verwendung von autofocus. Über Peters Geheimtipp PostHTML (wie PostCSS, nur für HTML) kommen wir zur Frontend-Gretchenfrage, zur Digital Ocean App Platform, Mobilfunktarifen und G’schichten aus’m Zug. Themenrelevant geht es weiter mit unserer (erfolglosen) Suche nach Use Cases für fit-content und inline-flex (zu finden in Tailwind UI), CSS Debugging, noch mehr Scrolling/Overflow-Problemen Emoji-Bugs in Chrome, Can I Include, Inclusive Card Components und CSS Modules.

Hans, Schepp und Peter ließen mehrfach das so genannte Workingdraft-Glücksrad rotieren, erhielten jedoch bei fast jeder Umdrehung einen kapitalen Wissens-Zonk.

[00:01:48] Glücksrad

Trusted Types API/isScript

Eine Anti-XSS-API, die in den Revisionen 447 und 486 (mit Gast Frederik Braun/@freddyb) schon mal Thema war.

Content Index API

Eine PWA-API für die Definition von Offline-Metadaten. Funktioniert sogar schon in Chrome auf Android!

WebRTC/RTCRtpSender

Mit WebRTC haben wir allesamt keine Erfahrung, Peter kann dafür über Frust mit der verwandten MediaRecorder-API berichten. Statt Browser-Inkompatibilitäten mit Dingen wie adapter auszugleichen würden wir vermutlich, ganz wie Clubhouse, WebRTC als SAAS einkaufen.

:invalid-Pseudoklasse

Der unserer Einschätzung nach mäßig nützliche Indikator für Formularfeld-Gültigkeit wird in Selectors Level&nbp;4 durch :user-invalid ergänzt..

overscroll-behavior-x

Einmal unbekannte, aber nützliche CSS-Features für 500 bitte!.

menuitem-Element

Ein extrem totes, Firefox-only-HTML-Element lässt uns über Contextmenüs und dazugehörige jQuery-Plugins nachdenken.

Keyboard API

Wir suchen mit mäßigem Erfolg nach Use Cases für die Keyboard API.

Cache API

Stellt sich raus: Der Cache kann immer noch nur GET-Requests speichern und funktioniert auch außerhalb vom Service Worker!

Im Rahmen der etablierten Traditionen nehmen Stefan und Peter das Release einer neuen TypeScript-Version zum Anlass, um über alles außer über TypeScript zu sprechen.

Schaunotizen

[00:01:48] TypeScript 4.4

Am Rande sprechen wir über die Features von TS 4.4, doch eigentlich geht es eher um CSS Grid, den typeof-Operator, Template Literal Types, TS-SQL, das commander-Package, Fastify (anstelle von Express), Symbols, Nodes process-Object, @@toStringTag und ES-Proxies. Auf etwas höherem Abstraktionslevel fragen wir uns, ob TypeScript demnächst mal fertig ist (Antwort: nö, es gibt in Sachen Builder Pattern/Fluent Interface noch theoretischen Aufholbedarf), sprechen über, Prototype-Patching, Conditional Types, Exclude<T>, Rust, Haskell, Dependent Types und Performance (mit besonderem Fokus auf Next-Generation Tools wie esbuild, Next.js, SWC, Rome und Deno) … und die Brücke zu Nero Burning ROM schlagen wir auch noch irgendwie. Kurz bevor Stefan aus seinem Konferenzraum geworfen wurde sprechen wie noch kurz über Typen für Try-Catch, any, unknown und unsafe, wundern uns über static blocks in classes, gedenken der Gefallenen (ECMAScript 4, E4X, SOAP, JXON) und blicken kurz auf das, was uns TypeScript 4.5 (z.Z. in der Beta-Phase) in Kürze bringen wird.

Zu Folge 500 haben Schepp, Vanessa, Hans, Peter und Stefan Hörer:innen-Fragen eingesammelt und beantwortet!

Schaunotizen

AMA

Gefragt nach unseren Lieblings-Folgen von Working Draft finden die Revisionen 100 (mit Paul Irish), 446 (zu PHP) und 468 (CSS in JS Super Throwdown Challenge) Erwähnung, ebenso die Live-Events zum SmashingMagazine Meetup #3 und von der beyond tellerrand. In Unkenntnis darüber, wie wenig Zeit wir haben werden, nehmen wie die Frage „Tabs oder Spaces“ halbwegs ernst und schlagen den Bogen von HTML5Boilerplate und CoffeeScript hin zur Twilight-Filmserie (hört’s euch an, es ergibt alles Sinn). Danach geht es um Nazis, andere Krauts (aber gute Krauts) Probleme mit Google Maps Quereinsteiger, Schepps jugendliches Aussehen, Peters Gamer-Vergangenheit, Hans‘ Top 3 NoFX-Picks, Schepps Lieblings-IE-Bugs (doppelter Margin bei float:left) und IE-only-Features (in der Verlosung: Exclusions, HTC-Files, Expressions), die Verbannung des Box-Modells aus dem Standard (ebenfalls auf der Abschussliste: autofocus und Voice-Styling in CSS), das schnelle Verinnerlichen von Webtech-Specs/Techs (gibt’s nicht) Front-End Architektur mit Svelte/SvelteKit (das Workingdraft-Glücksrad ist in Svelte geschrieben!) CSS Cafe und andere Schepp-Meetups, Webtech-Buch-Schreiberei (siehe auch Revision 453), Sport, Lego, Telefonate, Kinder, Teilzeit, Engineering Management, Rust, Go, C++, AssemblyScript, Turbine, die Composition API von Vue, Schepps IMDB-Eintrag und Vergangenheit als 3D-Animator, unsere goldige Audio-Producerin und Präsenz-Podcasting. Im Laufe der Zeit mussten mehr und mehr von uns zu Meetings mit Kindern und/oder Kollegen abreisen, sodass am Ende nur Schepp und Peter verblieben, um etwas über die Zukunft von Working Draft zu philosophieren.

Hans, Stefan und Vanessa hatten nach langer Zeit wieder das Vergnügen mit Backend-Entwickler Christoph Rumpel (@christophrumpel), Autor von Laravel Core Adventures und Mastering PhpStorm, ein Larastreamer und Host des Podcasts Call it a day, sprechen zu dürfen, diesmal über Laravel Livewire.

Schaunotizen

[00:00:59] Laravel Livewire

Laravel Livewire ist ein PHP/Laravel Package von Caleb Poruio, der ebenfalls der Autor von Alpine.js ist. Dieses Package eignet sich v.a. für Fullstack oder stark backend-lastige Developer Teams. Es ermöglichst dynamische Interface Funktionen, ohne tatsächliches JavaScript geschrieben werden muss. Die Grunfunktion basiert auf server-side gerendertem HTML Partials, ähnlich wir PJAX von jQuery. Doch alle Frontend Entwickler:innen wissen: Heutzutage bleibt es selten bei „einfach nur JavaScript“. Bei einem Framework wie Laravel Livewire fällt auch der Aufbau und die Wartung von Bundlern und ähnlichem Tooling weg. Die Idee kommt vom Framework Phoenix von Elixir. Ein ähnliches Framework für C#, um client-side Webapplikationen zu bauen, ist Blazor. Vergleichbar in der Welt von Ruby on Rails ist Hotwire. Als Beispiel nimmt Christoph uns mit in eine server-side geladene Applikation mit den üblichen Page Reloads. Nun landet man auf einer Seite mit einer Tabelle, für die es sich anbieten würde, wenn man diese Daten nun auch sortieren oder filtern könnte – und statt einem Page Reload lieber einen kurzen Loading Spinner anzeigen möchte. Darüberhinaus eignet es sich für Echtzeit-Validierung, Auto-Saving, Suchen, Auto-completes, dynamischen Dropdowns, Datei Uploads und vielem mehr. Auch das Schreiben von Tests mit mit Livewire kein Problem. Es hat sogar noch den Vorteil, dass dadurch, dass die Logik nicht in ein JavaScript Framework ausgelagert wurde, es keine zusätzlichen Integrations- oder Ende-zu-Ende-Test zwischen Frontend und Backend benötigt. Christoph bringt uns zwei Beispiele mit (siehe Links). Abschließend gibt es noch zu beachten, dass Entwickler:innen auf die Performance achten müssen, da ja jede Aktion einen Request erzeugen wird. Anm. der Redaktion: Performance ist aber auch mit einer Single-Page Applikation o.ä. auch nicht einfach, v.a. wenn erst einmal ein 4k Video geladen wird. Darüberhinaus gilt es auch den Überblick über sensitive Daten zu behalten, da durch Livewire eine offene Schnittstelle zum Client entsteht.

Links

ChannelTest1 + ChannelTest2

Zwei Livewire Tests von Christoph Rumpel.

Livewire Deep Dive

How Livewire works (a deep dive) von Autor Caleb Porzio

Inertia.js

Das Pendant zu Livewire – eine server-side Webapplikation

Larastreamers GitHub Repository

Die Codebase von Larastreamers

TALL Stack

Tailwind, Alpine.js, Laravel und Livewire

TEA Stack

Tailwind, Eleventy und Alpine.js

Verwandte Revisionen

Revision 490

Verwandte Revision über Alpine.js and Petite Vue.

Revision 127

Historische Revision über das INIT Boilerplatz und das Laravel PHP-Framework mit Christoph Rumpel aus 2013.

Revision 283

Vue.js und Chatbots mit Christoph Rumpel aus 2016.

Vanessa, Hans und Schepp verwandeln in dieser Revision die Vorbesprechung in die eigentlich Sendung, in der es ausnahmsweise Mal nicht nur um knallharte Fakten und technische Themen geht.

[00:01:45] Schaunotizen

CSS Spec Terms

Tab Atkins-Bittners Glossar der CSS-Termini.

Windi CSS

Ein zu Tailwind CSS kompatibles Framework, das aber bestimmte Dinge besser meint zu lösen.

What Is Web 3.0 & Why It Matters

Ja was ist denn eigentlich dieses Web 3.0? Und war das nicht eigentlich schon HTML5? Und wie passt das zu Industrie 4.0?

Free Guy

Filmempfehlung: eine US-amerikanische Science-Fiction-Action-Komödie mit Ryan Reynolds in der Hauptrolle.

CSS for JavaScript Developers

Ein Lernkurs, der mit einer gänzlich anderen Perspektive an CSS herangeht. Darüberhinaus empfehlen wir die Kurse von Wes Bos.

Podcastempfehlungen

• Syntax.fm
• Software Architektur im Stream
• Techlead.Journal()
• HTTP/203
• Programmierbar
• Wo wir sind ist vorne
• JavaScript Jabber
• JS Party
• alphalist CTO Podcast
• Land of the Giants Podcast

Nach zehn Wochen war es mal wieder an der Zeit, an unserem Webtechnologie-Glücksrad zu drehen!

[00:01:15] Glücksrad

SVGAnimatedEnumeration

Ähm… hä?

Keine Ahnung, wozu das gut ist. Schnell weiter!

Die :root-Pseudoklasse

Stefan nutzt sie gerne, um an sie seine CSS Custom Properties zu hängen, aber sonst fristet die Pseudoklasse in unserem Alltag ein eher tristes Dasein.

Der <image>-Datentyp

In den <image>-Datentyp lassen sich allerlei Dinge stecken:

• Bilder per url()-Funktion (natürlich)
• Gradienten aller Art, also lineare, radiale und konische Gradienten, sowie deren repeating-Pendants.
• ein responsives image-set()
• die endgeile, aber nirgendwo supportete image()-Funktion
• das nur in WebKit und Chromium unterstützte cross-fade()
• sowie das mächtige, aber nur in Firefox implementierte element()

::-webkit-scrollbar und Konsorten

Wir reden über Scrollbar-Styling im alten IE und wie man darauf heutzutage in den verschiedenen Browsern einwirkt, nämlich neben der ::-webkit-scrollbar-Familie für WebKit und Chromium, mit dem per W3C abgesegnetem scrollbar-width und scrollbar-color im Firefox. In neueren IEs und dem davon abgeleiteten Edge ließ sich eine hässliche Scrollbar immerhin noch via -ms-overflow-style: -ms-autohiding-scrollbar; verstecken.

font-variant-east-asian

Eine CSS-Eigenschaft, um offenbar eine Art asiatischer Ligaturen zu steuern. Von asiatischer Sprache haben wir leider alle keine Ahnung, aber uns fällt dieser tolle Talk von Florian Rivoal zu dem Thema ein: Line breaking and related properties from CSS Text.

Die dir-Eigenschaft der Manifest-Datei

Die sagt, in welche Richtung die Schrift der darin hinterlegten Textbausteine läuft. Hammer! 😴💤

Das align–Attribut

So deprecated, dass sogar MDN sich weigert, es zu erklären. Früher haben wir es aber genutzt, um Inhalte im Netscape-Browser horizontal zu zentrieren, nachdem es dafür im IE ja das <center>-Element gab.

Zu guter Letzt: Programmiersprachen-Bashing Royal Rumble!

Aus irgendwelchen Gründen kommen wir vom rechten Pfad ab und driften über die historischen Eigenheiten von PHP hin zur Programmiersprache MUMPS. Und weil wir sowieso schonmal dabei sind, möchten wir Euch diesen Talk von einer vergangenen React Conf empfehlen: Let’s Program Like It’s 1999 von Lee Byron