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.

Wir sind Demodern – wir sehen uns als Agentur einer neuen Generation: offen, unkompliziert, 100% digital. Gegründet von Designern, liegt unsere Leidenschaft in innovativen, digitalen Inszenierungen und einer sinnvollen User Experience. Wir entwickeln unsere Projekte gemeinsam mit Spezialisten aus Strategie, Design, UX und Development. „Let’s push things forward“ ist unser Leitsatz und Philosophie. Darin steckt unsere eigene Veränderung, aber auch, Projekte neu zu betrachten und zu rechtem Mehrwert zu bringen.

Ihr könnt gerne Kontakt zu Florian oder Marisa direkt aufnehmen – oder ihr schaut auf demodern.de/jobs vorbei.

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!

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.

Diese Revision wird von LanguageTool unterstützt. LanguageTool ist ein intelligenter Schreibassistent für alle gängigen Browser und Textverarbeitungsprogramme.

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.

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.

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.

Die vuejs.de Conf ist die erste durch die vuejs.de Community organisierte VueJS Konferenz in Deutschland. Sie findet am 05. Oktober im Herzen Berlins statt und lockt nicht nur die deutschsprachige VueJS Community, sondern auch zahlreiche Gäste aus aller Welt an. Es erwarten dich 12 Talks von internationalen Vue Expert:innen, ein direkter Kontakt zur Vue Community in einem historischen Ambiente, inklusive toller kulinarischer Verpflegung.

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.

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.

Diese Revision wird von LanguageTool unterstützt. LanguageTool ist ein intelligenter Schreibassistent für alle gängigen Browser und Textverarbeitungsprogramme.

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.

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.

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.

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.

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.

Wahnsinn, sucht Gute. Aktuell am liebsten Frontend-Menschen mit React-Erfahrung. Du hast schon einige Projekte erklommen? Du hast ein Auge für gute Umsetzung? Dir ist bewusst, alle Probleme sowie Lösungen sind kommunikativer Natur, außer Einmachgläser, die nicht aufgehen wollen – da hat sich das Universum einfach gegen einen verschworen. Perfekt. Mehr Infos findest du unter wahnsinn.design/keinjira.

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.

Diese Revision wird euch präsentiert von newcubator, einem Softwaredienstleister mit den Standorten Dortmund und Hannover. Newcubator abeitet täglich an innovativen Webanwendungen oder mobilen Lösungen – auch für Branchen, die nicht in erster Linie digital unterwegs sind. Vielleicht hast du Lust, das Team als Lead Developer:in zu unterstützen? Idealerweise direkt am Standort Dortmund. Neben Programmieren und Coden, agierst du als aktive Schnittstelle zwischen Team und Kund:innen; Projektmanagement und kaufmännische Tätigkeiten wie Angebotserstellung oder Qualitätsmanagement gehören ebenfalls zu deinen Aufgaben.

Bei Newcubator bekommst du die Möglichkeit das Unternehmen aktiv mitzugestalten. – Mit einem außergewöhnlichen Team aus Software-Architekt:innen, UX-Designer:innen und Backend- und Frontend-Entwickler:innen.

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

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):

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.

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.

Du möchtest als Cloud Consultant bzw. Cloud Engineer durchstarten? Dann bist du bei Pexon genau richtig. Pexon ist spezialisiert auf die Entwicklung für die Bereiche Cloud, DevOps und Data und baut mit seinen Kunden CICD-Pipelines, Cloud-Native Software, Kubernetes-Cluster, Data-analytics-Pipelines in der Public-Cloud.

Du hast das Gefühl, du bist in den Bereichen noch nicht ganz sattelfest? Kein Problem: Pexons USP ist das Cloud-Bootcamp für Quereinsteiger und Softwareentwickler. Hier kannst du dich zwei Monate lang zu 100 Prozent auf Lernen konzentrieren und an verschiedenen Musterprojekten im Bereich Cloud arbeiten. Die ganze Zeit über wirst du von einem Mentor begleitet. Sobald du weit genug bist, bekommst du ein Projekt, das zu dir passt und Du startest als Vollzeit Consultant bei Pexon. Du wirst sehen, du kannst schnell Verantwortung übernehmen für Projekte, Kunden und Prozesse. Das klingt gut?

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