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.
18. März 2025 | Kommentare deaktiviert für Revision 653: State of JS 2024, Teil 1/4
Peter, Stefan und Vanessa besprechen die Ergebnisse des State of JS 2024, so wie in der Vergangenheit auch bereits der State of CSS (Revision 633-635) besprochen wurden. In Teil 1 stürzen sich die Hosts vor allem auf die neuen JavaScript Features.
Schaunotizen
[00:03:44] State of JS 2024 – Teil 1
Peter, Stefan und Vanessa sind sich zumindest bei Einem einig: Die Motivation, um die Umfragen „State of X“ auszufüllen, ist die eigene Weiterbildung. Dieses Jahr gab es 14.000 Personen, die die Umfrage ausgefüllt haben. Ob die Ergebnisse generell nur eher etwas über Enthusiasten aussagt?
Egal ob JS, HTML oder CSS. Gar nicht mehr zu einig waren sie sich dann darin, wie interessant die einzelnen abgefragten JavaScript Features sind, oder auch wie interessant die Ergebnisse davon.
Zuerst widmen sich die Hosts der Funktion groupBy. Doch vielmehr als nur über die Funktion zu sprechen, besprechen Peter, Stefan und Vanessa, ob es sich lohnt, bestehende Alternativen mit der nun nativen Funktion auszutauschen. Stefan spricht sich für eine Verschlankung der Codebasis aus und plädiert dafür, neue Sprachfunktionen zu nutzen, sobald sie verfügbar sind. Peter wirft die Frage auf, welcher bestehende Code dadurch ersetzt würde. Ein Beispiel dafür ist eine selbstgeschriebene groupBy-Funktion, die nicht ersetzt wird, weil sie gut funktioniert und leicht anders arbeitet als mögliche Alternativen. Zudem gibt es hier kein Risiko. Anders sieht es aus, wenn externe Programmbibliotheken ins Spiel kommen – hier könnten unvorhergesehene Änderungen auftreten, und generell ist das Ziel, die Anzahl an Abhängigkeiten möglichst gering zu halten.Im Gespräch über die bekannte Bibliothek Lodash wird darauf hingewiesen, dass man das Rad nicht neu erfinden möchte. Gleichzeitig merkt Peter an, dass es in bestimmten Fällen doch notwendig sein kann, eigene Lösungen zu schreiben, um spezielle Anforderungen zu erfüllen. Insgesamt herrscht jedoch Einigkeit darüber, dass Lodash nicht mehr zeitgemäß ist. Viele seiner Funktionen stammen aus einer anderen Entwicklungsära und lassen sich mittlerweile durch native Sprachmittel ersetzen.
Neben diesen strategischen Überlegungen geht es auch um aktuelle Neuerungen in JavaScript. Private Felder für Klassen erweisen sich als nützlich, um Objekte zu erweitern – etwa durch zusätzliche Methoden für Zeichenketten oder Mengen. Die Fehlerbehandlung wird mit der cause-Eigenschaft verbessert. Damit ist es möglich, einen abgefangenen Fehler mit einer neuen Meldung erneut auszulösen und dabei die ursprüngliche Ursache zu erhalten, was insbesondere für Fehlerprotokollierung nützlich ist. Wer sich näher damit beschäftigen möchte, findet eine ausführliche Beschreibung bei MDN.
[00:30:36] Nullish Coalescing
Ein weiteres Thema ist der sogenannte Nullish Koaleszenzoperator (??), die sich vom logischen Oder-Operator (||) dadurch unterscheidet, dass sie nur bei null und undefined greift, während || auf alle falschen Werte reagiert – also auch auf false, die Zahl 0, leere Zeichenketten oder NaN. Beide Operatoren lassen sich beliebig verketten. MDN. Eng damit verbunden ist die Kurzschreibweise für logische Zuweisungen (||=), die es ermöglicht, Werte nur dann zu setzen, wenn sie bislang einen falschen Zustand haben. MDN.
Ein weiteres kleines, aber oft übersehenes Detail ist die sogenannte Hashbang-Syntax (#!). Diese ist vor allem in Kommandozeilen-Werkzeugen von Bedeutung, die in JavaScript geschrieben sind. Sie ermöglicht es, Skripte ohne expliziten Aufruf der Laufzeitumgebung auszuführen, etwa beim Starten eines Programms aus einer Paketkonfigurationsdatei heraus.
[00:34:40] Logical Assignment
Inneren Feldern von Objekten lassen sich nun auch neue Werte zuweisen, wenn ihr aktueller Wert falsy ist. Also wiederum nun wieder alle falsy Werte im Gegensatz zu dem vorher besprochenem Thema.
[00:41:12] String Features, Array Features
Beim Blick auf die neuen Möglichkeiten zur Verarbeitung von Zeichenketten zeigt sich, dass diese nur selten gebraucht werden. Ein Beispiel ist die Methode replaceAll, die etwa genutzt werden kann, um überflüssige Leerzeichen aus nutzergenerierten Inhalten zu entfernen. Zum Thema Array Features gibt es eine Liste von Funktionen, die es eigentlich vorher auch schon so gab – nur jetzt sind die Objekte immutable geworden. Also die Funktion ändert nicht mehr das Originalobjekt, sondern gibt ein neues Array wieder.
Doch ihr Nutzen hält sich unserer Hosts nach in Grenzen. Besonders in reaktiven Anwendungsarchitekturen wie React könnten sie jedoch für die Verarbeitung unveränderlicher Daten hilfreich sein.
[00:46:36] Async Features, Set Features, Group Features, Language Pain Points
In der asynchronen Programmierung zeigt sich, dass Promise.allSettled hilfreich ist, wenn auf mehrere Dateien für die Lokalisierung einer Anwendung gewartet werden muss.
Neue Funktionen für Mengen (Sets) sind zwar interessant, aber wären mit einer besseren grafischen Darstellung leichter verständlich gewesen.
Die Beantwortung der Nutzungshäufigkeit von groupBy wird kritisch hinterfragt. Nur ein Drittel der Befragten gibt an, diese Funktion zu verwenden – doch möglicherweise liegt das auch daran, dass viele bereits eigene Lösungen im Einsatz haben.
Schließlich geht es um den Einsatz von Programmiersprachen und Werkzeugen. Die Nutzung von TypeScript ist ungebrochen hoch, mit einer Umfragequote von nahezu 100 Prozent. Künstliche Intelligenz spielt im Entwicklungsalltag eine eher untergeordnete Rolle: Ein Fünftel verzichtet ganz darauf. JavaScript wird von 95 Prozent der Befragten im Beruf eingesetzt, 40 Prozent programmieren auch in der Freizeit damit – wobei hier eine gewisse Überschneidung wahrscheinlich ist.
[00:55:21] Browser APIs
Abschließend widmen sich den Hosts den Antworten zum Thema der Browser APIs. Es gint viel Begeisterung für die bevorstehende Temporal-API, die die Arbeit mit Zeitwerten erheblich vereinfachen wird. MDN. Ein oft geäußerter Wunsch bleibt die Einführung statischer Typisierung direkt in JavaScript sowie umfangreichere Standardbibliotheken.
8. Oktober 2024 | Kommentare deaktiviert für Revision 632: Server Side Rendering mit Frontend Frameworks
Mit Gast Hans-Christian Otto (Chef bei Suora und Tröter bei @muhdiekuh@ruhr.social) reden Peter und Vanessa über Server Side Rendering mit Frontend Frameworks. Im Verlauf wird Server Side Rendering mit SSR abgekürzt, und Hans-Christian Otto kurz Christian genannt.
Schaunotizen
[00:02:15] Server Side Rendering mit Frontend Frameworks
SSR mit Frontend Frameworks ist ein komplexes Thema. Generell besprechen Christian, Peter und Vanessa kurz den Werdegang des Webs, von „Standard“ SSR über Hydration wie bei z.B. Vue.js zu der Resumability von Qwik. Und irgendwo dazwischen ist das SSR mit Frontend Frameworks angesiedelt. Im Zusammenhang mit Hydration und clientseitigem Rendern bespricht Christian das Problem mit SEO. Isomorphisches und dynamisches Rendern sind hier die Stichpunkte. Dabei gibt es zunächst einmal sog. Meta-Frameworks wie Nuxt oder Nextjs. Gestartet hat die Idee diese Revision aufzumachen, mit dem Hype um die React Server Components. React Server Components (RSC) sind eine neue Funktion von React, mit der Teile der Benutzeroberfläche auf dem Server gerendert werden. Sie ermöglichen es, schwere Berechnungen oder Datenverarbeitungen serverseitig durchzuführen und nur das fertig gerenderte HTML an den Client zu senden, wodurch weniger JavaScript auf dem Client ausgeführt werden muss. Server-Komponenten sind nicht interaktiv und eignen sich besonders für statische Inhalte, können aber mit clientseitigen Komponenten kombiniert werden, um interaktive Funktionen bereitzustellen. Peter geht speziell auf Web Components ein, da diese eine immer präsenter werdende Rolle in der Welt der Webentwicklung spielen. Lit ist hier nur ein Beispiel. Denn Web Components verhindern ein Vendor-Lock-In. Denn wie bei so vielem heißt es bei der Entscheidung für oder gegen SSR mit Frontend Frameworks – und wenn ja, mit welcher Technologie – auch: es kommt eben darauf an: Risikoabwägungen und Abhängigkeiten müssen für das jeweilige Projekt passen.
6. August 2024 | Kommentare deaktiviert für Revision 625: TailwindCSS v4 Alpha
Nein, noch ist TailwindCSS v4 nicht heraus, und wir können noch die Füße still halten. Puh. Aber mit welchen Neuerungen können wir rechnen? Dies besprechen wir mit TailwindCSS-Dauergast Milan!
Schaunotizen
[00:02:41] TailwindCSS v4 Alpha
Nachdem wir in der Vergangenheit bereits zu TailwindCSS 1,TailwindCSS 2 und TailwindCSS 3 entsprechende Episoden aufgenommen haben, setzen wir uns erneut mit unserem letztmaligen Gast Milan zusammen. In der vorherigen Revision 624 sprachen wir bereits über die Neuigkeiten bei den Versionen 3.1, v3.2, v3.3, und v3.4 und berichteten über unsere Erfahrungen.
Eine große Neuerung, in der wir tief ins Detail gehen, ist die Umstellung des Parsers in Rust. Zum anderen die Umstellung von PostCSS zu LightningCSS.
Wer Lust hat, es auszuprobieren, kann sich entweder die Alpha Version bei NPM besorgen, die seit März verfügbar ist. Oder aber man benutzt den Playground und stellt die ersion auf v4 um.
Außerdem berichten wir über die Neuigkeit im TailwindCSS Universum, wie zum Beispiel die Updates bei dem Prettier Plugin und Catalyst von TailwindUI.
16. Juli 2024 | Kommentare deaktiviert für Revision 624: TailwindCSS: Neuigkeiten in v3 und Erfahrungsberichte
Nachdem wir in der Vergangenheit bereits zu TailwindCSS 1,TailwindCSS 2 und TailwindCSS 3 entsprechende Episoden aufgenommen haben, setzen wir uns erneut mit unserem letztmaligen Gast Milan zusammen. Wir besprechen die Neuerungen in der 3. Version von TailwindCSS und blicken retrospektiv auf unsere Erfahrungen zurück.
Schaunotizen
[00:00:00] TailwindCSS: Neuigkeiten in v3 und Erfahrungsberichte
Anfangs geben wir einen Rückblick auf die Geschichte von TailwindCSS. Wie fing alles an, wie viele Personen arbeiten an dem CSS Framework, und was denkt die Community mittlerweile darüber. TailwindCS ist ein Utility-First CSS Framework. Damit unterscheidet es sich von Bootstrap, Bulma und Co. Es gibt keine Button Klassen oder andere Komponentenklassen. Dafür haben die Erfinder von TailwindCSS allerdings das Tool TailwindUI gebaut.
Wir besprechen, warum TailwindCSS sehr gut für eine komponentenbasierte Entwicklung geeignet ist, und was wir als die großen Vorteile von dem Framework empfinden. Im Anschluss gehen wir auf den technischen Werdegang von TailwindCSS ein, angefangen bei Less Dateien bis hin zu der großen Änderung auf PostCSS.
Im Weiteren besprechen wir die Neuigkeiten, die es in den Versionen v3.1, v3.2, v3.3, und v3.4 gab. Am Ende gibt es einen Cliffhanger für die folgende Revision 625, bei der wir – auch wieder mit Milan – über die Tailwind v4 Alpha Version sprechen werden.
10. Januar 2024 | Kommentare deaktiviert für Revision 600: Live
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:
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.
[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.
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.
2. Januar 2024 | Kommentare deaktiviert für Revision 599: Glücksrad mit reichlich SVG und CSS-Datentypen!
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!
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.
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.
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.
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.
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.
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.
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!
19. Dezember 2023 | Kommentare deaktiviert für Revision 598: Erfolgreiches Onboarding – Einblicke mit Hans & Vanessa
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.
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!
12. Dezember 2023 | Kommentare deaktiviert für Revision 597: Neues in Safari, Teil 2 von 2
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.
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.
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.
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.
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.
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.
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 contentals 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.
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.
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.
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.
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.
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“ 😃
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.
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!
5. Dezember 2023 | Kommentare deaktiviert für Revision 596: Neues in Safari, Teil 1 von 2
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.
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.
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!
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“.
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!
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!
20. November 2023 | Kommentare deaktiviert für Revision 593: Webentwickler:innen erfolgreich einstellen – Einblicke mit Hans & Vanessa
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.
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.
