Mit zwölfjähriger Geschichte und über 5.000 Downloads pro Folge ist Working Draft
der etablierteste Podcast für Webentwickler im deutschsprachigen Raum.
Wenn ihr neue Entwicklerkollegen sucht oder ein Produkt für Webentwickler
anbietet, schreibt uns unter sponsoring@workingdraft.de.
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.
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!
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!
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!
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.
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
Ä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
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.
Alex eröffnet unsere Sendung mit der Feststellung, dass nur ein geringer Prozentsatz aller Webseiten überhaupt organischen Suchverkehr von Google erhält, weil sie zu weit hinten in den Suchergebnissen auftauchen. Umso wichtiger ist es demnach, seine Seite für Suchmaschinen zu optimieren. Es gibt verschiedene Aspekte der Suchmaschinenoptimierung, darunter das technische SEO, sowie On-Page- und Off-Page-Optimierungen. Auf den vorderen Plätzen stehen qualitativer Inhalt, gute User Experience und technische Aspekte wie Ladezeiten und Sicherheit (in erster Linie HTTPS). Gutes SEO hat vor allem die Nutzer und ihre Zufriedenheit im Sinn.
Neben hochwertigen Inhalten kann auch eine Keyword-Recherche nicht schaden, um eine langfristige erfolgreiche Webseite zu gewährleisten. Zudem erörtern wir Tools (Google Ads Keyword Planner, keywordtool.io, Ahrefs, Semrush oder Moz) und Strategien zur effektiven Keyword-Recherche und Leistungsverbesserung von Webseiten, insbesondere im Hinblick auf die Core Web Vitals zur Steigerung der Benutzererfahrung. Wir gehen auch kurz auf verschiedene Core Web Vitals ein, wie den Cumulative Layout Shift (CLS) und Largest Contentful Paint (LCP), und wie man diese mit Tools wie Lighthouse messen kann. Auch die mobile User Experience und Accessibility spielen eine Rolle.
Zum Schluß widmen wir uns noch den (potentiellen) Herausforderungen im Zusammenhang mit AI-generierten Inhalten. Alex sieht Google in Zukunft ein stärkeres Gewicht auf Vertrauenswürdigkeit und Autorität legen. Hier sind Konsistenz und Qualität des Contents zentral.
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 einem kurzen Vorgeplänkel zu Vue.js wechseln wir sogleich zu Nuxt, das wie Next.js ein sogenanntes „Meta-Framework“ darstellt, nur dass es eben Vue nutzt, anstelle von React. Neben Nuxt gibt es noch Quasar, das ebenfalls auf Vue setzt.
Allen Meta-Frameworks ist gemein, dass sie eines der clientseitigen Templating-Systeme nehmen und sie um serverseitige Funktionen ergänzen. Die wichtigste davon: Das Routing-System.
Darüberhinaus ermöglichen Meta-Frameworks wie Nuxt es, statische Seiten zu erzeugen, die im Client ganz ohne JavaScript auskommen. Da unterscheiden sie sich von Konzepten wie den Server-Components von React, die es ledigleich ermöglichen, einzelne Komponenten vom Server rendern und refreshen zu lassen, das Frontend aber weiterhin im Browser orchestrieren.
Wir reden über die aktuellste Version von Nuxt und wie diese bei ihrem Release von der Community aufgenommen wurde. Und wir blicken nach vorne auf die kommende Version 4, die demnächst erscheinen soll. Anders als nach Version 3 ist hier nicht mit großen Breaking Changes zu rechnen. Für einen Vorgeschmack auf die Änderungen können aber jetzt schon in Nuxt 3 entsprechende „Future Flags“ aktiviert werden. Und für eine reibungslose Migration auf Version 4 gibt es dann noch sogenannte Codemods, die bestehenden Code für das neue Framework automagisch umschreiben.
An dieser Stelle schwenken wir um auf das Thema UnJS, welches eine Sammlung von kleinen und großen JavaScript-Helferlein ist. Zum ersten Mal hörten wir von UnJS von Joe Ray Gregory Anfang 2023, lernen aber erst jetzt, dass dies ebenfalls ein Projekt aus dem Vue-Kosmos ist.
Viele dieser Helferlein sind nämlich Spin-Offs von Projekten aus der Vue-Welt, von denen man aber annahm, dass sie auch für andere Projekte hilfreich sein könnten. Ein Beispiel ist der Webserver Nitro, der so etwas wie ein modernes Express + Connect darstelle und der nicht nur in Nuxt Verwendung findet, sondern auch in Analog.js, dem Meta-Framework für Angular.
Ein weiteres spannendes Paket ist Unplugin, das eine Art universelles Bindeglied zu allen existierenden Bundlern darstellt und einem so ermöglicht, ein Plugin leicht in jede Build-Chain zu integrieren.
Magic-Regexp ermöglicht es wiederum, Reguläre Ausdrücke in menschlicherer Sprache zu formulieren.
Dann gäbe es da noch ufo, das allerlei Tooling rund um das Verarbeiten von URLs bietet.
Und schließlich fontaine, mit dem sich aufeinander abgestimmte Schriften-Stacks erstellen lassen.
Zum Abschluss geht nochmal zurück zu Nuxt und Alex gibt uns gute Tipps für den Einstieg und nennt ein paar Stolperfallen, die man bei der Arbeit mit Nuxt besser vermeidet. Und wir behandeln auch die Frage, wo man sein Nuxt-Projekt am besten hostet. Neben Digital Ocean lautet Alex‘ Tipp hier: fly.io
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.
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.
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:
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. 🤯
Impressum: Christian Schaefer, Postfach 26 04 29, 40097 Düsseldorf, comments@workingdraft.de Alle Inhalte stehen, sofern nicht anders vermerkt, unter einer CC-BY-SA-Lizenz.
