<p>In dieser Revision sprechen wir mit Marius Kleidl (<a href="https://www.accoplex.com/">Web</a> / <a href="https://www.linkedin.com/in/marius-kleidl/">LinkedIn</a>), Webentwickler bei <a href="https://transloadit.com/">Transloaded</a> und Mitwirkender am Open-Source-Projekt <a href="https://tus.io/">TUS</a>, über das Thema Resumable Uploads – also Datei-Uploads, die auch dann weiterlaufen, wenn zwischendurch mal die Verbindung abraucht oder das Tab versehentlich geschlossen wird.</p>
<h3>Schaunotizen</h3>
<dl>
<dt>[00:01:13] Resumable Uploads</dt>
<dd>Wir starten mit der Frage, warum klassische Upload-Methoden im Web oft unzuverlässig sind – vor allem bei großen Dateien wie Videos. Gerade bei instabilen Verbindungen oder auf Mobilgeräten ist Frust vorprogrammiert: Einmal abbrechen heißt meistens von vorne anfangen. Mit Resumable Uploads gehört das der Vergangenheit an. Stattdessen kann der Upload pausieren, später fortgesetzt werden – ganz ohne Datenverlust.</p>
<p>Im Zentrum der Folge steht <a href="https://tus.io/">TUS</a>, ein Open-Source-Protokoll für Resumable Uploads, das Marius mitentwickelt. Wir reden über die Entstehung des Projekts, die technischen Grundlagen und wie man TUS in eigene Anwendungen integriert – sei es in Node.js, Go oder mit vorhandenen Client-Libraries. Besonders spannend: <a href="https://datatracker.ietf.org/doc/draft-ietf-httpbis-resumable-upload/">Die Spezifikation wird derzeit mit der IETF abgestimmt</a>, mit dem Ziel, Resumable Uploads langfristig als offiziellen HTTP-Standard zu etablieren.</p>
<p>Marius gibt uns außerdem einen Einblick in die Community-Arbeit hinter TUS, den Beitrag anderer Open-Source-Projekte und wie Entwickler:innen durch eigene Implementierungen zur Verbesserung beitragen können. Wir streifen Themen wie Caching, Storage-Backends und was eigentlich alles im Hintergrund passieren muss, damit so ein Upload wirklich „resumable“ ist.</p>
<p>Natürlich kommen auch die praktischen Fragen nicht zu kurz: Was muss man beachten, wenn man Resumable Uploads in ein bestehendes Projekt integriert? Wie sieht die Kommunikation zwischen Client und Server aus? Und wie viel Aufwand steckt wirklich dahinter?</dd>
</dl>
<h3>Links</h3>
<dl>
<dt><a href="https://tus.io/">TUS-Projekt</a></dt>
<dd>Die offizielle Webseite des TUS-Projekts, welches Resumable Uploads ermöglicht.</dd>
<dt><a href="https://transloaded.com/">Transloaded</a></dt>
<dd>Der Dienstleister für File-Processing, der Resumable Uploads unterstützt und individuelle Lösungen anbietet.</dd>
<dt><a href="https://api-file-uploader.com/">API-File-Uploader</a></dt>
<dd>Ein Open-Source-Projekt, das eine flexible API für den Datei-Upload aus verschiedenen Quellen bereitstellt.</dd>
</dl>


In dieser Revision sprechen wir mit Marius Kleidl (Web / LinkedIn),
Webentwickler bei Transloaded und Mitwirkender am Open-Source-Projekt TUS, über
das Thema Resumable Uploads – also Datei-Uploads, di…

Working Draft

In dieser Revision sprechen wir mit Marius Kleidl (Web / LinkedIn),
Webentwickler bei Transloaded und Mitwirkender am Open-Source-Projekt TUS, über
das Thema Resumable Uploads – also Datei-Uploads, die auch dann weiterlaufen,
wenn zwischendurch mal die Verbindung abraucht oder das Tab versehentlich
geschlossen wird.


SCHAUNOTIZEN

[00:01:13] RESUMABLE UPLOADS

Wir starten mit der Frage, warum klassische Upload-Methoden im Web oft
unzuverlässig sind – vor allem bei großen Dateien wie Videos. Gerade bei
instabilen Verbindungen oder auf Mobilgeräten ist Frust vorprogrammiert: Einmal
abbrechen heißt meistens von vorne anfangen. Mit Resumable Uploads gehört das
der Vergangenheit an. Stattdessen kann der Upload pausieren, später fortgesetzt
werden – ganz ohne Datenverlust.



Im Zentrum der Folge steht TUS, ein Open-Source-Protokoll für Resumable Uploads,
das Marius mitentwickelt. Wir reden über die Entstehung des Projekts, die
technischen Grundlagen und wie man TUS in eigene Anwendungen integriert – sei es
in Node.js, Go oder mit vorhandenen Client-Libraries. Besonders spannend: Die
Spezifikation wird derzeit mit der IETF abgestimmt, mit dem Ziel, Resumable
Uploads langfristig als offiziellen HTTP-Standard zu etablieren.

Marius gibt uns außerdem einen Einblick in die Community-Arbeit hinter TUS, den
Beitrag anderer Open-Source-Projekte und wie Entwickler:innen durch eigene
Implementierungen zur Verbesserung beitragen können. Wir streifen Themen wie
Caching, Storage-Backends und was eigentlich alles im Hintergrund passieren
muss, damit so ein Upload wirklich „resumable“ ist.

Natürlich kommen auch die praktischen Fragen nicht zu kurz: Was muss man
beachten, wenn man Resumable Uploads in ein bestehendes Projekt integriert? Wie
sieht die Kommunikation zwischen Client und Server aus? Und wie viel Aufwand
steckt wirklich dahinter?


LINKS

TUS-PROJEKT

Die offizielle Webseite des TUS-Projekts, welches Resumable Uploads ermöglicht.

TRANSLOADED

Der Dienstleister für File-Processing, der Resumable Uploads unterstützt und
individuelle Lösungen anbietet.

API-FILE-UPLOADER

Ein Open-Source-Projekt, das eine flexible API für den Datei-Upload aus
verschiedenen Quellen bereitstellt.

Revision 657: Resumable Uploads

<p>Peter, Stefan und Vanessa besprechen auch diese Woche wieder die Ergebnisse des <a href="https://2024.stateofjs.com/en-US">State of JS 2024</a>. In <a href="https://workingdraft.de/653/">Teil 1</a> stürzten sich die Hosts vor allem auf die neuen JavaScript Features, in <a href="https://workingdraft.de/655/">Teil 2</a> besprachen sie die Pain Points von JavaScript und Browser APIs,  die Leseliste und die Bibliotheken. In diesem vorletzten Teil schaffen die Hosts ganze zwei weitere Seiten der Umfrage: Meta-Frameworks und Testing.</p>
<h3>Schaunotizen</h3>
<dl>
<dt>[00:01:17] Meta-Frameworks</dt>
<dd>Die Hosts wenden sich zunächst der Frage zu, was Meta Frameworks denn eigentlich sind. Bekannte Namen sind <a href="https://nuxt.com/">Nuxt</a>, <a href="https://nextjs.org/">Next.js</a>, <a href="https://remix.run/">Remix</a>, <a href="https://svelte.dev/">SvelteKit</a>, etc. Doch was genau was so ein Meta Framework aus? Ist es eine &#8222;All in One&#8220; Lösung? Muss es zwangsweise auf einem anderen Framework basieren? Das bringt uns auch zu einer Endlos-Diskussion: Ist React ein Framework oder eine Library (deutsch: Bibliothek)? Wobei, React hat diese Frage nun selbst beantwortet: <a href="https://react.dev/#:~:text=with%20a%20framework-,React%20is%20a%20library,-.%20It%20lets%20you">Es ist eine Library</a>. Nun gut, die Hosts einigen sich darauf, dass man eine gewisse Erwartungshaltung an Meta-Frameworks hat: Sie kommen mit einem <a href="https://entwickler.de/javascript/vuejs-unter-der-lupe-der-vue-router">Router</a>, Zustandsverwaltung (<a href="https://entwickler.de/webentwicklung/die-sache-mit-dem-state">State Management)</a>, <a href="https://www.it-schulungen.com/wir-ueber-uns/wissensblog/was-ist-ssr-und-ssg.html">SSR und SSG</a> und weiteren bereits eingebauten Features.</dd>
<dd>Meta-Frameworks kommen mit diesen vielen nützlichen Features, keine Frage. Dennoch stellt man auch eine neue Abhängigkeit her. Das Benutzen dieser Meta-Frameworks kann es schwieriger machen, Bugs zu finden und zu fixen. Wie so oft, wenn man nicht mehr die Kontrolle über den kompletten Code hat. Sie können auch mit Sicherheitslücken kommen, wie es <a href="https://www.heise.de/en/news/Next-js-Critical-gap-allows-web-apps-to-be-compromised-10327299.html">kürzlich der Fall bei Next.js</a> war.</dd>
<dd>Wie auch in den beiden vorherigen Teilen sind sich die Hosts wieder in einem Punkt sicher: Es kommt auf die Entwickler:innen an, nicht auf das Meta-Framework.</dd>
<dd>Kleine Bibliotheken wie <a href="https://www.11ty.dev/">Eleventy</a> sind dennoch immer eine gute Wahl. Das liegt bei Eleventy daran, dass man HTML und CSS losgelöst von dem Tool schreibt. Das ermöglicht eine leichte Migration in der Zukunft.</dd>
<dt>[00:43:32] Testing</dt>
<dd>Bei dem Thema Testing leben die Hosts in verschiedenen Welten. Während Vanessa sich schon seit Jahren mi Tests in der Welt von Frontend Frameworks beschäftigt, hat der in der <a href="https://www.rust-lang.org/">Rust</a>-Welt lebende Stefan kaum Berührungspunkte mit Framework-Component Testing und kann die ganze Problematik daher gar nicht so genau nachvollziehen. Vanessa klärt also zunächst einmal über die ganze Tragödie von <a href="https://entwickler.de/testing/unit-testing-nach-frontend-art">Unit Tests</a> über <a href="https://web.dev/learn/testing/get-started/component-testing?hl=de">Component Tests</a> zu <a href="https://www.testautomatisierung.org/lexikon/e2e-testing/">End to End Tests</a> oder doch auch <a href="https://bleech.de/blog/wie-funktioniert-visual-regression-testing/">Visual Regression Tests</a> und <a href="https://www.novatec-gmbh.de/insights/blog/wann-snapshot-testing-dich-ueberschnappen-lassen/">Snapshot Tests</a> auf. Die Umfrage verrät, dass aktuell viel <a href="https://jestjs.io/">Jest</a> eingesetzt wird, jedoch niemand mehr so richtig glücklich mit diesem Tool ist. <a href="https://vitest.dev/">Vitest</a> ist stark auf dem Vormasch, genauso wie <a href="https://playwright.dev/">Playwright</a>. In <a href="https://workingdraft.de/652/">Revision 652</a> sprach kürzlich erst <a href="https://www.stefanjudis.com/">Stefan Judis</a> über automatisiertes Testing mit Playwright.</dd>
</dl>
<h3>Ähnliche Revision</h3>
<ul>
<li><a href="https://workingdraft.de/655/">Revision 655: State of JS 2024, Teil 2/4</a></li>
<li><a href="https://workingdraft.de/653/">Revision 653: State of JS 2024, Teil 1/4</a></li>
<li><a href="https://workingdraft.de/652/">Revision 652: Automatisiertes Testing mit Playwright</a></li>
<li><a href="https://workingdraft.de/633/">Revision 633: State of CSS 2024, Teil 1/3</a></li>
<li><a href="https://workingdraft.de/634/">Revision 634: State of CSS 2024, Teil 2/3</a></li>
<li><a href="https://workingdraft.de/635/">Revision 635: State of CSS 2024, Teil 3/3</a></li>
</ul>


Peter, Stefan und Vanessa besprechen auch diese Woche wieder die Ergebnisse des
State of JS 2024. In Teil 1 stürzten sich die Hosts vor allem auf die neuen
JavaScript Features, in Teil 2 besprachen si…

Peter, Stefan und Vanessa besprechen auch diese Woche wieder die Ergebnisse des
State of JS 2024. In Teil 1 stürzten sich die Hosts vor allem auf die neuen
JavaScript Features, in Teil 2 besprachen sie die Pain Points von JavaScript und
Browser APIs,  die Leseliste und die Bibliotheken. In diesem vorletzten Teil
schaffen die Hosts ganze zwei weitere Seiten der Umfrage: Meta-Frameworks und
Testing.


SCHAUNOTIZEN

[00:01:17] META-FRAMEWORKS

Die Hosts wenden sich zunächst der Frage zu, was Meta Frameworks denn eigentlich
sind. Bekannte Namen sind Nuxt, Next.js, Remix, SvelteKit, etc. Doch was genau
was so ein Meta Framework aus? Ist es eine „All in One“ Lösung? Muss es
zwangsweise auf einem anderen Framework basieren? Das bringt uns auch zu einer
Endlos-Diskussion: Ist React ein Framework oder eine Library (deutsch:
Bibliothek)? Wobei, React hat diese Frage nun selbst beantwortet: Es ist eine
Library. Nun gut, die Hosts einigen sich darauf, dass man eine gewisse
Erwartungshaltung an Meta-Frameworks hat: Sie kommen mit einem Router,
Zustandsverwaltung (State Management), SSR und SSG und weiteren bereits
eingebauten Features.

Meta-Frameworks kommen mit diesen vielen nützlichen Features, keine Frage.
Dennoch stellt man auch eine neue Abhängigkeit her. Das Benutzen dieser
Meta-Frameworks kann es schwieriger machen, Bugs zu finden und zu fixen. Wie so
oft, wenn man nicht mehr die Kontrolle über den kompletten Code hat. Sie können
auch mit Sicherheitslücken kommen, wie es kürzlich der Fall bei Next.js war.

Wie auch in den beiden vorherigen Teilen sind sich die Hosts wieder in einem
Punkt sicher: Es kommt auf die Entwickler:innen an, nicht auf das
Meta-Framework.

Kleine Bibliotheken wie Eleventy sind dennoch immer eine gute Wahl. Das liegt
bei Eleventy daran, dass man HTML und CSS losgelöst von dem Tool schreibt. Das
ermöglicht eine leichte Migration in der Zukunft.

[00:43:32] TESTING

Bei dem Thema Testing leben die Hosts in verschiedenen Welten. Während Vanessa
sich schon seit Jahren mi Tests in der Welt von Frontend Frameworks beschäftigt,
hat der in der Rust-Welt lebende Stefan kaum Berührungspunkte mit
Framework-Component Testing und kann die ganze Problematik daher gar nicht so
genau nachvollziehen. Vanessa klärt also zunächst einmal über die ganze Tragödie
von Unit Tests über Component Tests zu End to End Tests oder doch auch Visual
Regression Tests und Snapshot Tests auf. Die Umfrage verrät, dass aktuell viel
Jest eingesetzt wird, jedoch niemand mehr so richtig glücklich mit diesem Tool
ist. Vitest ist stark auf dem Vormasch, genauso wie Playwright. In Revision 652
sprach kürzlich erst Stefan Judis über automatisiertes Testing mit Playwright.


ÄHNLICHE REVISION

 * Revision 655: State of JS 2024, Teil 2/4
 * Revision 653: State of JS 2024, Teil 1/4
 * Revision 652: Automatisiertes Testing mit Playwright
 * Revision 633: State of CSS 2024, Teil 1/3
 * Revision 634: State of CSS 2024, Teil 2/3
 * Revision 635: State of CSS 2024, Teil 3/3

Revision 656: State of JS 2024 – Teil 3/4

<p>Peter, Stefan und Vanessa besprechen weiterhin die Ergebnisse des <a href="https://2024.stateofjs.com/en-US">State of JS 2024</a>, so wie in der Vergangenheit auch bereits der State of CSS (Revision 633-635) besprochen wurden. In <a href="https://workingdraft.de/653/">Teil 1</a> stürzten sich die Hosts vor allem auf die neuen JavaScript Features. Nun geht es weiter mit den Schmerzpunkten von JavaScript und Browser APIs,  der Leseliste und den Bibliotheken.</p>
<h3>Schaunotizen</h3>
<dl>
<dt>[00:01:35] JavaScript Pain Points</dt>
<dd>Die JavaScript Pain Points Angaben in der Umfrage kamen durch eine Freitext Eingabe in der Umfrage zustande, Wie Peter, Stefan und Vanessa finden, eine wichtige Zusatzinformation, um die Ergebnisse etwas besser interpretieren zu können. Denn diese sind bei näherem Betrachten der eigentlichen Antworten gar nicht mehr so konkret wie die Liste an Kurzantworten erst erscheinen lässt. Ein viel besprochenes Thema ist EcmaScript Module &amp; Common JS. Das <em>ES Module</em> ist ein standardisiertes JavaScript-Modulsystem, das in ECMAScript 2015 (ES6) eingeführt wurde. Es wird in modernen Browsern und Node.js unterstützt. Das CJS Modulsystem wird hauptsächlich in Node.js verwendet. Es wurde entwickelt, bevor JavaScript ein offizielles Modulsystem hatte. Vor allem die Migration von CJS auf ESM wird als komplex und kompliziert genannt.</dd>
<dd>Ebenfalls benannt wird das Fehlen von Typen. Hierbei kommen Peter und Stefan zu dem Schluss, dass man TypeScript &#8222;einfach&#8220; dazu installieren, oder notfalls per IDE Extension hinzufügen kann. Sie sind also anderer Meinung als die Umfrage Ergebnisse.</dd>
<dd>Der nächste Schmerzpunkt, der genannt wird, ist der, der fehlenden Standardbibliothek. Hier argumentiert Stefan, dass das eigentlich kein Problem von der Sprache JavaScript, sondern der Runtime sei. Er streut nebenbei das Wissen herein, dass es ein Standard Committee gibt, dass sich nun um serverseitige Runtimes kümmern wird: das <a href="https://ecma-international.org/technical-committees/tc55/">TC55</a>. Stefan erzählt weiterhin, <a href="https://www.rust-lang.org/">Rust</a> hätte noch viel weniger Standards, da wäre alles frei konfigurierbar.</dd>
<dd>Der letzten besprochenen Schmerzpunkt ist die asynchrone Programmierung. Da hätte Stefan gerne viele mehr Prozente gesehen. Denn gerade seit es <a href="https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Statements/async_function">async/await</a> gibt, gibt es viele Verständnislücken über die asynchrone Programmierung. Er weist auf den hilfreichen Blogartikel &#8222;<a href="https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/">What color is your function</a>&#8220; von Bob Nystrom hin.</dd>
<dt>[00:30:35] Browser API Pain Points</dt>
<dd>Die Liste der Schmerzpunkte über Browser APIs ist doch sehr erheiternd zu lesen: Safari und Firefox. Und eigentlich auch Chrome. Peter, Stefan und Vanessa arbeiten sich durch die Liste und finden heraus: Das Hautproblem sei wohl, dass Chrome einige APIs freischaltet, die die anderen Browser noch nicht unterstützen. Dadurch gibt es Indifferenzen zwischen den Browsern. Doch ob es wirklich die Lösung ist, dass Chrome sich besser absprechen könnte?</dd>
<dt>[00:00:00] Readlist</dt>
<dd>In <a href="https://workingdraft.de/653/">Teil 1</a> besprachen die Hosts das JavaScript Feature <a href="https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Error/cause">error.cause</a>. Umso schöner nun zu sehen, dass viele der Ausfüllenden der Umfrage sich auch dieses Feature auf die Leseliste gesetzt haben.</dd>
<dt>[00:44:04] Bibliotheken</dt>
<dd>Über die Bibliotheken gibt es massig viele Daten anzuschauen. Doch für wen sind diese nun eigentlich interessant? Vermutlich eher, wenn man Inhalte für Blogartikel und Vorträge sammelt. Dennoch wüten sich Peter, Stefan und Vanessa durch die Daten. Webpack ist das meistebenuzte Tool, jedoch nicht das Beliebteste. React und Vite stehen beide hoch im Kurs. Zum konkreten Thema der JavaScript Frameworks besprechen die Hosts, dass man wohl irgendwie eine Entscheidung treffen muss &#8211; und richtig falsch ist keine, aber wohl oft trifft man wohl auch nicht die Richtige, wie man an den Schmerzpunkten wieder sieht. Denn hier werden Frameworks auch oft als zu komplex beschrieben. Die Hosts finden, dass Entwickler und Entwicklerinnen generell flexibel sein müssen in ihrem Beruf. Und jederzeit zwischen Frameworks wechseln können sollten.</dd>
</dl>
<h3>Links</h3>
<ul>
<li><a href="https://dev.to/sachagreif/state-of-js-2024-outreach-and-diversity-report-n0e#fn-footnotes-1">State of JS &#8211; Outreach</a></li>
</ul>
<h3>Ähnliche Revision</h3>
<ul>
<li><a href="https://workingdraft.de/653/">Revision 645: State of JS 2024, Teil 1</a></li>
<li><a href="https://workingdraft.de/633/">Revision 633: State of CSS 2024, Teil 1/3</a></li>
<li><a href="https://workingdraft.de/634/">Revision 634: State of CSS 2024, Teil 2/3</a></li>
<li><a href="https://workingdraft.de/635/">Revision 635: State of CSS 2024, Teil 3/3</a></li>
</ul>
<dl>
<dd></dd>
</dl>


Peter, Stefan und Vanessa besprechen weiterhin 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ürzten s…

Peter, Stefan und Vanessa besprechen weiterhin 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ürzten sich die Hosts vor allem auf die
neuen JavaScript Features. Nun geht es weiter mit den Schmerzpunkten von
JavaScript und Browser APIs,  der Leseliste und den Bibliotheken.


SCHAUNOTIZEN

[00:01:35] JAVASCRIPT PAIN POINTS

Die JavaScript Pain Points Angaben in der Umfrage kamen durch eine Freitext
Eingabe in der Umfrage zustande, Wie Peter, Stefan und Vanessa finden, eine
wichtige Zusatzinformation, um die Ergebnisse etwas besser interpretieren zu
können. Denn diese sind bei näherem Betrachten der eigentlichen Antworten gar
nicht mehr so konkret wie die Liste an Kurzantworten erst erscheinen lässt. Ein
viel besprochenes Thema ist EcmaScript Module & Common JS. Das ES Module ist ein
standardisiertes JavaScript-Modulsystem, das in ECMAScript 2015 (ES6) eingeführt
wurde. Es wird in modernen Browsern und Node.js unterstützt. Das CJS Modulsystem
wird hauptsächlich in Node.js verwendet. Es wurde entwickelt, bevor JavaScript
ein offizielles Modulsystem hatte. Vor allem die Migration von CJS auf ESM wird
als komplex und kompliziert genannt.

Ebenfalls benannt wird das Fehlen von Typen. Hierbei kommen Peter und Stefan zu
dem Schluss, dass man TypeScript „einfach“ dazu installieren, oder notfalls per
IDE Extension hinzufügen kann. Sie sind also anderer Meinung als die Umfrage
Ergebnisse.

Der nächste Schmerzpunkt, der genannt wird, ist der, der fehlenden
Standardbibliothek. Hier argumentiert Stefan, dass das eigentlich kein Problem
von der Sprache JavaScript, sondern der Runtime sei. Er streut nebenbei das
Wissen herein, dass es ein Standard Committee gibt, dass sich nun um
serverseitige Runtimes kümmern wird: das TC55. Stefan erzählt weiterhin, Rust
hätte noch viel weniger Standards, da wäre alles frei konfigurierbar.

Der letzten besprochenen Schmerzpunkt ist die asynchrone Programmierung. Da
hätte Stefan gerne viele mehr Prozente gesehen. Denn gerade seit es async/await
gibt, gibt es viele Verständnislücken über die asynchrone Programmierung. Er
weist auf den hilfreichen Blogartikel „What color is your function“ von Bob
Nystrom hin.

[00:30:35] BROWSER API PAIN POINTS

Die Liste der Schmerzpunkte über Browser APIs ist doch sehr erheiternd zu lesen:
Safari und Firefox. Und eigentlich auch Chrome. Peter, Stefan und Vanessa
arbeiten sich durch die Liste und finden heraus: Das Hautproblem sei wohl, dass
Chrome einige APIs freischaltet, die die anderen Browser noch nicht
unterstützen. Dadurch gibt es Indifferenzen zwischen den Browsern. Doch ob es
wirklich die Lösung ist, dass Chrome sich besser absprechen könnte?

[00:00:00] READLIST

In Teil 1 besprachen die Hosts das JavaScript Feature error.cause. Umso schöner
nun zu sehen, dass viele der Ausfüllenden der Umfrage sich auch dieses Feature
auf die Leseliste gesetzt haben.

[00:44:04] BIBLIOTHEKEN

Über die Bibliotheken gibt es massig viele Daten anzuschauen. Doch für wen sind
diese nun eigentlich interessant? Vermutlich eher, wenn man Inhalte für
Blogartikel und Vorträge sammelt. Dennoch wüten sich Peter, Stefan und Vanessa
durch die Daten. Webpack ist das meistebenuzte Tool, jedoch nicht das
Beliebteste. React und Vite stehen beide hoch im Kurs. Zum konkreten Thema der
JavaScript Frameworks besprechen die Hosts, dass man wohl irgendwie eine
Entscheidung treffen muss – und richtig falsch ist keine, aber wohl oft trifft
man wohl auch nicht die Richtige, wie man an den Schmerzpunkten wieder sieht.
Denn hier werden Frameworks auch oft als zu komplex beschrieben. Die Hosts
finden, dass Entwickler und Entwicklerinnen generell flexibel sein müssen in
ihrem Beruf. Und jederzeit zwischen Frameworks wechseln können sollten.


LINKS

 * State of JS – Outreach


ÄHNLICHE REVISION

 * Revision 645: State of JS 2024, Teil 1
 * Revision 633: State of CSS 2024, Teil 1/3
 * Revision 634: State of CSS 2024, Teil 2/3
 * Revision 635: State of CSS 2024, Teil 3/3

Revision 655: State of JS 2024 – Teil 2

<p>Wusstet ihr, dass man mit der richtigen TypeScript-Config plötzlich wieder Lust auf JavaScript bekommt? Kein Witz – wir haben’s ausprobiert! </p>
<h3>Schaunotizen</h3>
<dl>
<dt>[00:01:08] <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/">TypeScript 5.8</a></dt>
<dd>Wir steigen ein mit einem TypeScript-Feature, das Stefan so begeistert hat, dass er direkt eine ganze Revision darüber machen wollte: die „Erasable Syntax Only“-Option. Wir diskutieren, warum diese Einstellung TypeScript endlich wieder zu einem erfreulichen Tool macht – besonders in Verbindung mit einer besseren Developer Experience und weniger magischem Code.</p>
<p>Danach nehmen wir TypeScript in Node-Projekten auseinander, sprechen über das Für und Wider von Linting vs. Type-Checking zur Laufzeit und streifen dabei auch Themen wie Build-Systeme, tsc vs. esbuild und warum man manchmal doch wieder Bock auf „einfaches JavaScript“ bekommt.</p>
<p>Zum Ende hin geht’s noch kurz um die Realität in Teams, in denen nicht alle TypeScript gleich intensiv nutzen – und um die Frage, ob TypeScript bald nur noch Linter mit Typen sein sollte.</dd>
</dl>


Wusstet ihr, dass man mit der richtigen TypeScript-Config plötzlich wieder Lust
auf JavaScript bekommt? Kein Witz – wir haben’s ausprobiert!


SCHAUNOTIZEN

[00:01:08] TYPESCRIPT 5.8

Wir steigen ein …

Wusstet ihr, dass man mit der richtigen TypeScript-Config plötzlich wieder Lust
auf JavaScript bekommt? Kein Witz – wir haben’s ausprobiert!


SCHAUNOTIZEN

[00:01:08] TYPESCRIPT 5.8

Wir steigen ein mit einem TypeScript-Feature, das Stefan so begeistert hat, dass
er direkt eine ganze Revision darüber machen wollte: die „Erasable Syntax
Only“-Option. Wir diskutieren, warum diese Einstellung TypeScript endlich wieder
zu einem erfreulichen Tool macht – besonders in Verbindung mit einer besseren
Developer Experience und weniger magischem Code.



Danach nehmen wir TypeScript in Node-Projekten auseinander, sprechen über das
Für und Wider von Linting vs. Type-Checking zur Laufzeit und streifen dabei auch
Themen wie Build-Systeme, tsc vs. esbuild und warum man manchmal doch wieder
Bock auf „einfaches JavaScript“ bekommt.

Zum Ende hin geht’s noch kurz um die Realität in Teams, in denen nicht alle
TypeScript gleich intensiv nutzen – und um die Frage, ob TypeScript bald nur
noch Linter mit Typen sein sollte.

Revision 654: TypeScript 5.8 – in Zukunft nur noch smarter Linter?

<p>Peter, Stefan und Vanessa besprechen die Ergebnisse des <a href="https://2024.stateofjs.com/en-US">State of JS 2024</a>, 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.</p>
<h3>Schaunotizen</h3>
<dl>
<dt>[00:03:44] State of JS 2024 &#8211; Teil 1</dt>
<dd>Peter, Stefan und Vanessa sind sich zumindest bei Einem einig: Die Motivation, um die Umfragen &#8222;State of X&#8220; 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?</dd>
<dd>Egal ob JS, <a href="https://2024.stateofhtml.com/en-US">HTML</a> oder <a href="https://2024.stateofcss.com/en-US">CSS</a>. 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.</dd>
</dl>
<dl>
<dd>Zuerst widmen sich die Hosts der Funktion <code data-start="383" data-end="392">groupBy</code>. 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 <code data-start="455" data-end="464">groupBy</code>-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.</dd>
</dl>
<dl>
<dt>[00:21:03] Syntax features: Private Fields, <code data-start="2233" data-end="2240">error.cause</code></dt>
<dd>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 <code data-start="1581" data-end="1588">cause</code>-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 <a href="https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Error/cause" target="_new" rel="noopener noreferrer" data-start="1893" data-end="1989">MDN</a>.</dd>
<dt>
<dl>
<dt>[00:30:36] Nullish Coalescing</dt>
<dd>Ein weiteres Thema ist der sogenannte Nullish Koaleszenzoperator (<code data-start="2049" data-end="2053">??</code>), die sich vom logischen Oder-Operator (<code data-start="2094" data-end="2098">||</code>) dadurch unterscheidet, dass sie nur bei <code data-start="2140" data-end="2146">null</code> und <code data-start="2151" data-end="2162">undefined</code> greift, während <code data-start="2179" data-end="2183">||</code> auf alle falschen Werte reagiert – also auch auf <code data-start="2233" data-end="2240">false</code>, die Zahl <code data-start="2251" data-end="2254">0</code>, leere Zeichenketten oder <code data-start="2281" data-end="2286">NaN</code>. Beide Operatoren lassen sich beliebig verketten. <a href="https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing" target="_new" rel="noopener noreferrer" data-start="2337" data-end="2435">MDN</a>. Eng damit verbunden ist die Kurzschreibweise für logische Zuweisungen (<code data-start="2508" data-end="2513">||=</code>), die es ermöglicht, Werte nur dann zu setzen, wenn sie bislang einen falschen Zustand haben. <a href="https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Operators/Logical_OR_assignment" target="_new" rel="noopener noreferrer" data-start="2608" data-end="2709">MDN</a>.</dd>
<dd>Ein weiteres kleines, aber oft übersehenes Detail ist die sogenannte Hashbang-Syntax (<code data-start="2800" data-end="2804">#!</code>). 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.</dd>
</dl>
</dt>
</dl>
<p>[00:34:40] Logical Assignment</p>
<dl>
<dt>
<dl>
<dd>Inneren Feldern von Objekten lassen sich nun auch neue Werte zuweisen, wenn ihr aktueller Wert <code data-start="2151" data-end="2162">falsy</code> ist. Also wiederum nun wieder alle <code data-start="2151" data-end="2162">falsy</code> Werte im Gegensatz zu dem vorher besprochenem Thema.</dd>
</dl>
</dt>
</dl>
<p>[00:41:12] String Features, Array Features</p>
<dl>
<dt>
<dl>
<dd>Beim Blick auf die neuen Möglichkeiten zur Verarbeitung von Zeichenketten zeigt sich, dass diese nur selten gebraucht werden. Ein Beispiel ist die Methode <code data-start="3226" data-end="3238">replaceAll</code>, 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 &#8211; nur jetzt sind die Objekte <em>immutable</em> geworden. Also die Funktion ändert nicht mehr das Originalobjekt, sondern gibt ein neues Array wieder.<br />
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.</dd>
</dl>
</dt>
</dl>
<p>[00:46:36] Async Features, Set Features, Group Features, Language Pain Points</p>
<dl>
<dt>
<dl>
<dd>In der asynchronen Programmierung zeigt sich, dass <code data-start="3622" data-end="3642">Promise.allSettled</code> hilfreich ist, wenn auf mehrere Dateien für die Lokalisierung einer Anwendung gewartet werden muss.</dd>
<dd></dd>
<dd>Neue Funktionen für Mengen (Sets) sind zwar interessant, aber wären mit einer besseren grafischen Darstellung leichter verständlich gewesen.</dd>
<dd></dd>
<dd>Die Beantwortung der Nutzungshäufigkeit von <code data-start="3908" data-end="3917">groupBy</code> 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.</dd>
<dd>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.</dd>
</dl>
</dt>
</dl>
<dl>
<dt>[00:55:21] Browser APIs</p>
<dl>
<dd>Abschließend widmen sich den Hosts den Antworten zum Thema der Browser APIs. Es gint viel Begeisterung für die bevorstehende <code data-start="4647" data-end="4657">Temporal</code>-API, die die Arbeit mit Zeitwerten erheblich vereinfachen wird. <a href="https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Temporal" target="_new" rel="noopener noreferrer" data-start="4722" data-end="4815">MDN</a>. Ein oft geäußerter Wunsch bleibt die Einführung statischer Typisierung direkt in JavaScript sowie umfangreichere Standardbibliotheken.</dd>
</dl>
</dt>
</dl>
<h3>Links</h3>
<ul>
<li><a href="https://dev.to/sachagreif/state-of-js-2024-outreach-and-diversity-report-n0e#fn-footnotes-1">State of JS &#8211; Outreach</a></li>
</ul>
<h3>Ähnliche Revision</h3>
<ul>
<li><a href="https://workingdraft.de/633/">Revision 633: State of CSS 2024, Teil 1/3</a></li>
<li><a href="https://workingdraft.de/634/">Revision 634: State of CSS 2024, Teil 2/3</a></li>
<li><a href="https://workingdraft.de/635/">Revision 635: State of CSS 2024, Teil 3/3</a></li>
</ul>


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 Hos…

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.

[00:21:03] SYNTAX FEATURES: PRIVATE FIELDS, ERROR.CAUSE

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.

SCHLIESSLICH 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



ABSCHLIESSEND 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ÄUSSERTER WUNSCH BLEIBT
DIE EINFÜHRUNG STATISCHER TYPISIERUNG DIREKT IN JAVASCRIPT SOWIE UMFANGREICHERE
STANDARDBIBLIOTHEKEN.


LINKS

 * State of JS – Outreach


ÄHNLICHE REVISION

 * Revision 633: State of CSS 2024, Teil 1/3
 * Revision 634: State of CSS 2024, Teil 2/3
 * Revision 635: State of CSS 2024, Teil 3/3

Revision 653: State of JS 2024 – Teil 1

<p>In dieser Episode sprechen wir mit <a href="https://www.stefanjudis.com/">Stefan Judis</a> über Playwright. Stefan ist Entwickler, <a href="https://www.stefanjudis.com/blog/">Blogger</a>, Autor des <a href="https://webweekly.email/">&#8222;Web Weekly&#8220;-Newsletters</a> und Speaker mit einer Leidenschaft für Web-Technologien, insbesondere für Web-Performance, neue Features in modernen Browsern und Barrierefreiheit.</p>
<h3>Schaunotizen</h3>
<dl>
<dt>[00:02:09] <a href="https://playwright.dev/">Playwright</a></dt>
<dd>Playwright ist ein ein leistungsfähiges End-to-End-Testing-Framework von Microsoft und darauf ausgelegt, stabile und zuverlässige Tests für Webanwendungen zu ermöglichen. Im Gegensatz zu älteren Test-Frameworks wie Selenium unterstützt Playwright moderne Features wie automatische Wartezeiten, Testisolierung und die Möglichkeit, mit mehreren Browser-Kontexten gleichzeitig zu arbeiten. Entwickler können Tests für Chromium (Chrome und Edge), WebKit (Safari) und Firefox schreiben – und das mit nur einer einzigen API.</p>
<p>Ein zentrales Feature ist die Fähigkeit, Tests parallel auszuführen, was die Laufzeit von Test-Suites erheblich reduziert und die Continuous-Integration-Pipelines beschleunigt. Besonders für Teams, die viele Tests automatisieren, bietet Playwright hier große Vorteile.</p>
<p>Ein wichtiger Aspekt, über den wir sprechen, ist die Art und Weise, wie Playwright UI-Tests durchführt. Die Auswahl von Elementen ist dabei besonders robust gelöst: Playwright nutzt sogenannte „Auto-Waits“, das heißt, es wartet automatisch, bis ein Element im DOM vorhanden, sichtbar und interaktiv ist, bevor eine Interaktion stattfindet. Das reduziert eine der größten Frustquellen beim End-to-End-Testing – nämlich Tests, die aufgrund von Timing-Problemen fehlschlagen.</p>
<p>Zusätzlich erlaubt Playwright komplexe Selektoren, darunter CSS-, XPath- und Text-Selektoren, aber auch speziellere Methoden wie <code>getByRole</code>, um barrierefreie Elemente gezielt zu testen. Besonders praktisch ist auch, dass Playwright Shadow DOM und iFrames unterstützt, womit es sich besonders gut für moderne Webanwendungen eignet, die diese Techniken intensiv nutzen.</p>
<p>Ein weiteres Thema sind Race Conditions. Da Playwright nicht nur die UI testet, sondern auch Interaktionen mit dem DOM und asynchrone Prozesse genau beobachten kann, hilft es, Probleme aufzudecken, die durch nicht deterministisches Verhalten entstehen. Gerade bei Single-Page-Applications oder Anwendungen mit vielen dynamischen Inhalten kann Playwright dazu beitragen, Bugs zu finden, die sonst nur schwer zu reproduzieren sind.</p>
<p>Wir sprechen außerdem über die Möglichkeiten von visuellem Regressiontesting mit Playwright. Theoretisch lassen sich Screenshots und sogar Videoaufnahmen von Testläufen erstellen, um Änderungen in der Benutzeroberfläche zu erkennen und zu überprüfen. Allerdings haben wir selbst diese Funktionalität noch nicht ausprobiert – deshalb interessiert uns: Nutzt ihr visuelles Regressiontesting mit Playwright? Welche Erfahrungen habt ihr damit gemacht?</p>
<p>Stefan gibt außerdem Tipps, wie sich Playwright in bestehende Continuous-Integration/Continuous-Deployment-Pipelines einbinden lässt. Besonders für Teams, die bereits mit CI/CD arbeiten, ist es wichtig, dass Test-Frameworks sich reibungslos in bestehende Workflows einfügen. Playwright bietet hier viele Optionen, darunter die Integration mit GitHub Actions, Jenkins und anderen CI-Systemen.</p>
<p>Ein weiteres Highlight ist die Playwright Trace Viewer-Funktion. Damit lassen sich Tests detailliert analysieren, indem sämtliche Interaktionen, DOM-Änderungen und Konsolen-Ausgaben einer Testausführung gespeichert und später Schritt für Schritt durchgegangen werden können. Das erleichtert die Fehlersuche nach einem gescheiterten Pipeline-Durchlauf erheblich.</dd>
</dl>
<h3>Links</h3>
<dl>
<dt><a href="https://playwright.dev/">Playwright</a></dt>
<dd>Die Hauptseite von Playwright mit Dokumentation und Ressourcen.</dd>
<dt><a href="https://github.com/microsoft/playwright">Playwright GitHub Repository</a></dt>
<dd>Das offizielle GitHub-Repository von Playwright mit Quellcode und Beitragsrichtlinien.</dd>
<dt><a href="https://www.lambdatest.com/playwright">Playwright Tutorial auf LambdaTest</a></dt>
<dd>Ein ausführliches Tutorial zur Nutzung von Playwright für automatisierte Tests.</dd>
<dt><a href="https://www.browserstack.com/guide/playwright-tutorial">Playwright Tutorial auf BrowserStack</a></dt>
<dd>Ein Leitfaden zur Verwendung von Playwright für Testautomatisierung.</dd>
<dt><a href="https://playwright.dev/docs/trace-viewer">Playwright Trace Viewer</a></dt>
<dd>Ein Tool zur detaillierten Analyse von Testläufen, um Fehler besser nachzuvollziehen.</dd>
<dt><a href="https://playwright.dev/docs/test-parallel">Parallelisierung in Playwright</a></dt>
<dd>Eine Dokumentation zur effizienten Nutzung der Parallelisierungs-Funktionen von Playwright.</dd>
<dt><a href="https://playwright.dev/docs/selectors">Element-Selektoren in Playwright</a></dt>
<dd>Übersicht über die verschiedenen Selektoren und deren Nutzung.</dd>
<dt><a href="https://webweekly.email/">Web Weekly Newsletter</a></dt>
<dd>Stefan Judis&#8216; wöchentlicher Newsletter mit aktuellen Themen rund um Webentwicklung.</dd>
<dt><a href="https://www.patreon.com/stefanjudis">Unterstütze Stefan auf Patreon</a></dt>
<dd>Hilf Stefan dabei, weiterhin großartige Inhalte zu erstellen, indem du ihn auf Patreon unterstützt!</dd>
<dt><a href="https://www.youtube.com/playlist?list=PLMZDRUOi3a8NtMq3PUS5iJc2pee38rurc">Playwright Tips</a></dt>
<dd>Stefans Playlist für Checkly mit Videos zu Playwright.</dd>
</dl>


In dieser Episode sprechen wir mit Stefan Judis über Playwright. Stefan ist
Entwickler, Blogger, Autor des „Web Weekly“-Newsletters und Speaker mit einer
Leidenschaft für Web-Technologien, insbesonder…

In dieser Episode sprechen wir mit Stefan Judis über Playwright. Stefan ist
Entwickler, Blogger, Autor des „Web Weekly“-Newsletters und Speaker mit einer
Leidenschaft für Web-Technologien, insbesondere für Web-Performance, neue
Features in modernen Browsern und Barrierefreiheit.


SCHAUNOTIZEN

[00:02:09] PLAYWRIGHT

Playwright ist ein ein leistungsfähiges End-to-End-Testing-Framework von
Microsoft und darauf ausgelegt, stabile und zuverlässige Tests für
Webanwendungen zu ermöglichen. Im Gegensatz zu älteren Test-Frameworks wie
Selenium unterstützt Playwright moderne Features wie automatische Wartezeiten,
Testisolierung und die Möglichkeit, mit mehreren Browser-Kontexten gleichzeitig
zu arbeiten. Entwickler können Tests für Chromium (Chrome und Edge), WebKit
(Safari) und Firefox schreiben – und das mit nur einer einzigen API.



Ein zentrales Feature ist die Fähigkeit, Tests parallel auszuführen, was die
Laufzeit von Test-Suites erheblich reduziert und die
Continuous-Integration-Pipelines beschleunigt. Besonders für Teams, die viele
Tests automatisieren, bietet Playwright hier große Vorteile.

Ein wichtiger Aspekt, über den wir sprechen, ist die Art und Weise, wie
Playwright UI-Tests durchführt. Die Auswahl von Elementen ist dabei besonders
robust gelöst: Playwright nutzt sogenannte „Auto-Waits“, das heißt, es wartet
automatisch, bis ein Element im DOM vorhanden, sichtbar und interaktiv ist,
bevor eine Interaktion stattfindet. Das reduziert eine der größten Frustquellen
beim End-to-End-Testing – nämlich Tests, die aufgrund von Timing-Problemen
fehlschlagen.

Zusätzlich erlaubt Playwright komplexe Selektoren, darunter CSS-, XPath- und
Text-Selektoren, aber auch speziellere Methoden wie getByRole, um barrierefreie
Elemente gezielt zu testen. Besonders praktisch ist auch, dass Playwright Shadow
DOM und iFrames unterstützt, womit es sich besonders gut für moderne
Webanwendungen eignet, die diese Techniken intensiv nutzen.

Ein weiteres Thema sind Race Conditions. Da Playwright nicht nur die UI testet,
sondern auch Interaktionen mit dem DOM und asynchrone Prozesse genau beobachten
kann, hilft es, Probleme aufzudecken, die durch nicht deterministisches
Verhalten entstehen. Gerade bei Single-Page-Applications oder Anwendungen mit
vielen dynamischen Inhalten kann Playwright dazu beitragen, Bugs zu finden, die
sonst nur schwer zu reproduzieren sind.

Wir sprechen außerdem über die Möglichkeiten von visuellem Regressiontesting mit
Playwright. Theoretisch lassen sich Screenshots und sogar Videoaufnahmen von
Testläufen erstellen, um Änderungen in der Benutzeroberfläche zu erkennen und zu
überprüfen. Allerdings haben wir selbst diese Funktionalität noch nicht
ausprobiert – deshalb interessiert uns: Nutzt ihr visuelles Regressiontesting
mit Playwright? Welche Erfahrungen habt ihr damit gemacht?

Stefan gibt außerdem Tipps, wie sich Playwright in bestehende
Continuous-Integration/Continuous-Deployment-Pipelines einbinden lässt.
Besonders für Teams, die bereits mit CI/CD arbeiten, ist es wichtig, dass
Test-Frameworks sich reibungslos in bestehende Workflows einfügen. Playwright
bietet hier viele Optionen, darunter die Integration mit GitHub Actions, Jenkins
und anderen CI-Systemen.

Ein weiteres Highlight ist die Playwright Trace Viewer-Funktion. Damit lassen
sich Tests detailliert analysieren, indem sämtliche Interaktionen,
DOM-Änderungen und Konsolen-Ausgaben einer Testausführung gespeichert und später
Schritt für Schritt durchgegangen werden können. Das erleichtert die Fehlersuche
nach einem gescheiterten Pipeline-Durchlauf erheblich.


LINKS

PLAYWRIGHT

Die Hauptseite von Playwright mit Dokumentation und Ressourcen.

PLAYWRIGHT GITHUB REPOSITORY

Das offizielle GitHub-Repository von Playwright mit Quellcode und
Beitragsrichtlinien.

PLAYWRIGHT TUTORIAL AUF LAMBDATEST

Ein ausführliches Tutorial zur Nutzung von Playwright für automatisierte Tests.

PLAYWRIGHT TUTORIAL AUF BROWSERSTACK

Ein Leitfaden zur Verwendung von Playwright für Testautomatisierung.

PLAYWRIGHT TRACE VIEWER

Ein Tool zur detaillierten Analyse von Testläufen, um Fehler besser
nachzuvollziehen.

PARALLELISIERUNG IN PLAYWRIGHT

Eine Dokumentation zur effizienten Nutzung der Parallelisierungs-Funktionen von
Playwright.

ELEMENT-SELEKTOREN IN PLAYWRIGHT

Übersicht über die verschiedenen Selektoren und deren Nutzung.

WEB WEEKLY NEWSLETTER

Stefan Judis‘ wöchentlicher Newsletter mit aktuellen Themen rund um
Webentwicklung.

UNTERSTÜTZE STEFAN AUF PATREON

Hilf Stefan dabei, weiterhin großartige Inhalte zu erstellen, indem du ihn auf
Patreon unterstützt!

PLAYWRIGHT TIPS

Stefans Playlist für Checkly mit Videos zu Playwright.

Revision 652: Automatisiertes Testing mit Playwright

<p>In dieser Episode sprechen wir mit <a href="https://www.linkedin.com/in/marco-bretschneider-norderstedt/">Marco Bretschneider</a> über den ARIA-Standard und dessen Bedeutung für Barrierefreiheit bei dynamischen Webinhalten. Ein Accessibility-Audit war für sein Team der Ausgangspunkt, ARIA intensiver zu nutzen – daraus entstanden in seiner Firma die &#8222;ARIA of the week&#8220;-Sessions, die bis heute wertvolle Ergebnisse liefern.</p>
<h3>Schaunotizen</h3>
<dl>
<dt>[00:01:15] <a href="https://www.w3.org/WAI/standards-guidelines/aria/">Accessible Rich Internet Applications (ARIA)</a></dt>
<dd>Wir starten mit einem historischen Exkurs zur Entstehung von ARIA und werfen einen Blick darauf, welche bestehenden Standards als Vorbild dienten. ARIA wurde nämlich stark von Accessibility-APIs aus der Desktop-Welt inspiriert, darunter <a href="https://en.wikipedia.org/wiki/Microsoft_Active_Accessibility">Microsoft Active Accessibility (MSAA)</a> und <a href="https://developer.apple.com/documentation/accessibility/accessibility-api/">Apples Accessibility API</a>. Diese Ansätze wurden auf das Web übertragen, um mit Technologien wie JavaScript, React und Angular umzugehen, die für assistive Technologien lange Zeit schwer zugänglich waren.</p>
<p>Marco erklärt, wie ARIA den Accessibility-Tree eines Browsers beeinflusst und assistiven Technologien wie Screenreadern wichtige Zusatzinformationen liefert, die mit reinem HTML nicht immer verfügbar sind.</p>
<p>Anschließend gehen wir auf die Funktionsweise einer Auswahl des ARIA-Vokabulars ein. Wir sprechen etwa darüber, wie Tabs mit Rollen wie <code>role="tablist"</code> und Attributen wie <code>aria-controls</code> korrekt umgesetzt werden und warum bestimmte Tastatur-Interaktionen bei ARIA ein absolutes Muss sind. Außerdem reden wir über die Unterschiede zwischen Toggle-Buttons, Checkboxen und Switches sowie die Einsatzmöglichkeiten von Live-Regions mit <code>aria-live</code>.</p>
<p>Am Ende bleibt die zentrale Erkenntnis: ARIA ist ein mächtiges Werkzeug, aber es muss gezielt und mit Bedacht eingesetzt werden. Wichtig ist ein grundlegendes Verständnis des Accessibility-Trees. Gut umgesetztes ARIA macht dynamische Webinhalte nicht nur zugänglicher, sondern erleichtert auch Entwickler*innen die Arbeit, indem es Barrierefreiheit strukturiert und nachvollziehbar macht.</dd>
</dl>
<h3>Links</h3>
<dl>
<dt><a href="https://www.smashingmagazine.com/printed-books/inclusive-front-end-design-patterns/">Inclusive Front-End Design Patterns</a></dt>
<dd>Ein Buch mit praxiserprobten Frontend-Design-Mustern, die Barrierefreiheit und Usability in den Vordergrund stellen.</dd>
<dt><a href="https://open-ui.org/">Open UI</a></dt>
<dd>Eine Initiative zur Standardisierung von UI-Komponenten, die auch Barrierefreiheit im Blick hat.</dd>
<dt><a href="https://inclusive-components.design/">Inclusive Components</a></dt>
<dd>Eine Website, die praktische Anleitungen und Beispiele bietet, um zugängliche UI-Komponenten zu entwickeln.</dd>
<dt><a href="https://www.w3.org/WAI/ARIA/apg/patterns/tabs/">W3C ARIA Authoring Practices: Tabs</a></dt>
<dd>Offizielle W3C-Dokumentation zu Best Practices für die Umsetzung von Tabs mit ARIA.</dd>
<dt><a href="https://html.spec.whatwg.org/multipage/links.html#link-type-next">HTML Spec: Link Type Next</a></dt>
<dd>Die offizielle HTML-Spezifikation zu den Link-Typen <code>rel="next"</code> und <code>rel="prev"</code>.</dd>
<dt><a href="https://www.procontext.de/aktuelles/2010/02/was-ist-usability-wirklich.html">Was ist Usability wirklich? (ProContext)</a></dt>
<dd>Ein Artikel, der das Konzept der Gebrauchstauglichkeit-Messung und die Stufen der Usability erklärt.</dd>
<dt><a href="https://www.smashingmagazine.com/printed-books/inclusive-front-end-design-patterns/">Inclusive Front-End Design Patterns</a></dt>
<dd>Ein Buch mit praxiserprobten Frontend-Design-Mustern, die Barrierefreiheit und Usability in den Vordergrund stellen.</dd>
<dt><a href="https://html.spec.whatwg.org/multipage/">HTML Living Standard</a></dt>
<dd>Die aktuelle HTML-Spezifikation, die vom WHATWG gepflegt wird.</dd>
</dl>


In dieser Episode sprechen wir mit Marco Bretschneider über den ARIA-Standard
und dessen Bedeutung für Barrierefreiheit bei dynamischen Webinhalten. Ein
Accessibility-Audit war für sein Team der Ausga…

In dieser Episode sprechen wir mit Marco Bretschneider über den ARIA-Standard
und dessen Bedeutung für Barrierefreiheit bei dynamischen Webinhalten. Ein
Accessibility-Audit war für sein Team der Ausgangspunkt, ARIA intensiver zu
nutzen – daraus entstanden in seiner Firma die „ARIA of the week“-Sessions, die
bis heute wertvolle Ergebnisse liefern.


SCHAUNOTIZEN

[00:01:15] ACCESSIBLE RICH INTERNET APPLICATIONS (ARIA)

Wir starten mit einem historischen Exkurs zur Entstehung von ARIA und werfen
einen Blick darauf, welche bestehenden Standards als Vorbild dienten. ARIA wurde
nämlich stark von Accessibility-APIs aus der Desktop-Welt inspiriert, darunter
Microsoft Active Accessibility (MSAA) und Apples Accessibility API. Diese
Ansätze wurden auf das Web übertragen, um mit Technologien wie JavaScript, React
und Angular umzugehen, die für assistive Technologien lange Zeit schwer
zugänglich waren.



Marco erklärt, wie ARIA den Accessibility-Tree eines Browsers beeinflusst und
assistiven Technologien wie Screenreadern wichtige Zusatzinformationen liefert,
die mit reinem HTML nicht immer verfügbar sind.

Anschließend gehen wir auf die Funktionsweise einer Auswahl des ARIA-Vokabulars
ein. Wir sprechen etwa darüber, wie Tabs mit Rollen wie role="tablist" und
Attributen wie aria-controls korrekt umgesetzt werden und warum bestimmte
Tastatur-Interaktionen bei ARIA ein absolutes Muss sind. Außerdem reden wir über
die Unterschiede zwischen Toggle-Buttons, Checkboxen und Switches sowie die
Einsatzmöglichkeiten von Live-Regions mit aria-live.

Am Ende bleibt die zentrale Erkenntnis: ARIA ist ein mächtiges Werkzeug, aber es
muss gezielt und mit Bedacht eingesetzt werden. Wichtig ist ein grundlegendes
Verständnis des Accessibility-Trees. Gut umgesetztes ARIA macht dynamische
Webinhalte nicht nur zugänglicher, sondern erleichtert auch Entwickler*innen die
Arbeit, indem es Barrierefreiheit strukturiert und nachvollziehbar macht.


LINKS

INCLUSIVE FRONT-END DESIGN PATTERNS

Ein Buch mit praxiserprobten Frontend-Design-Mustern, die Barrierefreiheit und
Usability in den Vordergrund stellen.

OPEN UI

Eine Initiative zur Standardisierung von UI-Komponenten, die auch
Barrierefreiheit im Blick hat.

INCLUSIVE COMPONENTS

Eine Website, die praktische Anleitungen und Beispiele bietet, um zugängliche
UI-Komponenten zu entwickeln.

W3C ARIA AUTHORING PRACTICES: TABS

Offizielle W3C-Dokumentation zu Best Practices für die Umsetzung von Tabs mit
ARIA.

HTML SPEC: LINK TYPE NEXT

Die offizielle HTML-Spezifikation zu den Link-Typen rel="next" und rel="prev".

WAS IST USABILITY WIRKLICH? (PROCONTEXT)

Ein Artikel, der das Konzept der Gebrauchstauglichkeit-Messung und die Stufen
der Usability erklärt.

INCLUSIVE FRONT-END DESIGN PATTERNS

Ein Buch mit praxiserprobten Frontend-Design-Mustern, die Barrierefreiheit und
Usability in den Vordergrund stellen.

HTML LIVING STANDARD

Die aktuelle HTML-Spezifikation, die vom WHATWG gepflegt wird.

Revision 651: Accessible Rich Internet Applications (ARIA)

<p>In dieser Episode sprechen wir mit der freiberuflichen UX/UI-Designerin und Nachhaltigkeitsforscherin Sandy Dähnert (<a href="https://www.sandydaehnert.de/">Web</a> / <a href="https://www.linkedin.com/in/sandy-daehnert/">LinkedIn</a>) über die Herausforderungen und Chancen im nachhaltigen UX- und UI-Design.</p>
<h3>Schaunotizen</h3>
<dl>
<dt>[00:02:08] Sustainable Web Design</dt>
<dd>Sandy beschäftigt sich seit 2018 intensiv mit diesem Thema und erklärt uns, was nachhaltiges Design bedeutet – und warum es weit über den ökologischen Aspekt hinausgeht. Wir richten unseren Blick auf die drei Dimensionen der Nachhaltigkeit: ökologisch, ökonomisch und sozial. Dabei wird schnell klar, dass der Fokus oft nur auf der Umwelt liegt, während Themen wie Barrierefreiheit, Diversität und ethisches Design genauso wichtig sind.</p>
<p>Ein zentraler Punkt unserer Diskussion ist die Rolle der Nutzerforschung. Wir müssen verstehen, wie unterschiedliche Interessen und Bedürfnisse die Gestaltung von Interfaces beeinflussen. Eine divers zusammengesetzte Nutzergruppe sorgt nicht nur für bessere Produkte, sondern macht auch unsere Verantwortung als Designer:innen deutlich. Sandy schlägt darüberhinaus aber auch vor, Personas nicht nur für Menschen, sondern auch für nicht-menschliche Elemente wie die Natur zu erstellen (sogenannte „Non-Human-Personas“), um die Auswirkungen unserer Designs auf die Umwelt besser zu berücksichtigen.</p>
<p>Natürlich schauen wir uns auch technische Entscheidungen an, die einen CO₂-Fußabdruck hinterlassen. Wie viel Daten eine Website überträgt, welche Hosting-Anbieter wir wählen und wie sich Design-Entscheidungen auf den Stromverbrauch auswirken – all das spielt eine Rolle. Sandy zeigt uns, dass minimalistisches Design nicht nur ästhetische Vorteile hat, sondern auch einen positiven Einfluss auf die Umwelt haben kann. Wir sprechen über Tools wie <a href="https://www.websitecarbon.com">Website Carbon</a> oder <a href="https://www.ecograder.com">EcoGrader</a>, die uns dabei helfen, die Performance und Nachhaltigkeit von Webseiten zu analysieren.</p>
<p>Zum Schluss reflektieren wir noch über unsere Verantwortung als Designer:innen und Unternehmen. Wir diskutieren, wie wir ethische Überlegungen in den Designprozess integrieren können, welche konkreten Schritte sich umsetzen lassen und warum es wichtig ist, sich kontinuierlich weiterzubilden. Nur wenn wir verschiedene Perspektiven einbeziehen und bewusste Entscheidungen treffen, können wir die Herausforderungen der Nachhaltigkeit meistern und echten Wandel vorantreiben. 🌱</dd>
</dl>
<h3>Links</h3>
<dl>
<dt><a href="https://w3c.github.io/sustyweb/">W3C Web Sustainability Guidelines</a></dt>
<dd>Richtlinien und Best Practices für nachhaltiges Webdesign</dd>
<dt><a href="https://greentheweb.com">Green the Web</a></dt>
<dd>Sandys Webseite mit Ressourcen über nachhaltiges Design, Tools und Best-Practice-Beispielen.</dd>
<dt><a href="https://greentheweb.com/podcast-de/">Der Green the Web Podcast</a></dt>
<dd>Sandys Podcast über nachhaltiges UX/UI Design.</dd>
<dt><a href="https://www.green.io">Green.io Konferenz</a></dt>
<dd>Eine Veranstaltung zum Thema nachhaltiges Design und Entwicklung.</dd>
<dt><a href="https://www.websitecarbon.com">Website Carbon</a></dt>
<dd>Analysiert den CO2-Fußabdruck von Webseiten und gibt Empfehlungen zur Reduktion.</dd>
<dt><a href="https://www.ecograder.com">EcoGrader</a></dt>
<dd>Ein weiteres Tool zur Bewertung der ökologischen Fußabdrücke von Webseiten.</dd>
<dt><a href="https://www.youtube.com/watch?v=N_6sPd0Jd3g">Cost of a pixel color (Android Dev Summit &#8217;18)</a></dt>
<dd>Dieser Vortrag zeigt, wie der Dark Mode den Energieverbrauch von OLED-Displays reduziert, und auch, dass blaue Pixel mehr Strom verbrauchen als andere Farben.</dd>
<dt><a href="https://www.bbc.co.uk/rd/articles/2023-08-sustainability-energy-saving-radio-tv-led-graphics">Introducing the energy saving concept of Lower Carbon Graphics</a></dt>
<dd>Developing and implementing a new idea which we believe has already saved energy in homes across the UK.</dd>
<dt><a href="https://www.bbc.com/mediacentre/2025/bbc-rd-dark-mode">Switching from light to dark mode on apps and websites uses more energy</a></dt>
<dd>BBC R&#038;D find energy saving recommendation doesn’t take into account user behaviour</dd>
</dl>


In dieser Episode sprechen wir mit der freiberuflichen UX/UI-Designerin und
Nachhaltigkeitsforscherin Sandy Dähnert (Web / LinkedIn) über die
Herausforderungen und Chancen im nachhaltigen UX- und UI-D…

In dieser Episode sprechen wir mit der freiberuflichen UX/UI-Designerin und
Nachhaltigkeitsforscherin Sandy Dähnert (Web / LinkedIn) über die
Herausforderungen und Chancen im nachhaltigen UX- und UI-Design.


SCHAUNOTIZEN

[00:02:08] SUSTAINABLE WEB DESIGN

Sandy beschäftigt sich seit 2018 intensiv mit diesem Thema und erklärt uns, was
nachhaltiges Design bedeutet – und warum es weit über den ökologischen Aspekt
hinausgeht. Wir richten unseren Blick auf die drei Dimensionen der
Nachhaltigkeit: ökologisch, ökonomisch und sozial. Dabei wird schnell klar, dass
der Fokus oft nur auf der Umwelt liegt, während Themen wie Barrierefreiheit,
Diversität und ethisches Design genauso wichtig sind.



Ein zentraler Punkt unserer Diskussion ist die Rolle der Nutzerforschung. Wir
müssen verstehen, wie unterschiedliche Interessen und Bedürfnisse die Gestaltung
von Interfaces beeinflussen. Eine divers zusammengesetzte Nutzergruppe sorgt
nicht nur für bessere Produkte, sondern macht auch unsere Verantwortung als
Designer:innen deutlich. Sandy schlägt darüberhinaus aber auch vor, Personas
nicht nur für Menschen, sondern auch für nicht-menschliche Elemente wie die
Natur zu erstellen (sogenannte „Non-Human-Personas“), um die Auswirkungen
unserer Designs auf die Umwelt besser zu berücksichtigen.

Natürlich schauen wir uns auch technische Entscheidungen an, die einen
CO₂-Fußabdruck hinterlassen. Wie viel Daten eine Website überträgt, welche
Hosting-Anbieter wir wählen und wie sich Design-Entscheidungen auf den
Stromverbrauch auswirken – all das spielt eine Rolle. Sandy zeigt uns, dass
minimalistisches Design nicht nur ästhetische Vorteile hat, sondern auch einen
positiven Einfluss auf die Umwelt haben kann. Wir sprechen über Tools wie
Website Carbon oder EcoGrader, die uns dabei helfen, die Performance und
Nachhaltigkeit von Webseiten zu analysieren.

Zum Schluss reflektieren wir noch über unsere Verantwortung als Designer:innen
und Unternehmen. Wir diskutieren, wie wir ethische Überlegungen in den
Designprozess integrieren können, welche konkreten Schritte sich umsetzen lassen
und warum es wichtig ist, sich kontinuierlich weiterzubilden. Nur wenn wir
verschiedene Perspektiven einbeziehen und bewusste Entscheidungen treffen,
können wir die Herausforderungen der Nachhaltigkeit meistern und echten Wandel
vorantreiben. 🌱


LINKS

W3C WEB SUSTAINABILITY GUIDELINES

Richtlinien und Best Practices für nachhaltiges Webdesign

GREEN THE WEB

Sandys Webseite mit Ressourcen über nachhaltiges Design, Tools und
Best-Practice-Beispielen.

DER GREEN THE WEB PODCAST

Sandys Podcast über nachhaltiges UX/UI Design.

GREEN.IO KONFERENZ

Eine Veranstaltung zum Thema nachhaltiges Design und Entwicklung.

WEBSITE CARBON

Analysiert den CO2-Fußabdruck von Webseiten und gibt Empfehlungen zur Reduktion.

ECOGRADER

Ein weiteres Tool zur Bewertung der ökologischen Fußabdrücke von Webseiten.

COST OF A PIXEL COLOR (ANDROID DEV SUMMIT ’18)

Dieser Vortrag zeigt, wie der Dark Mode den Energieverbrauch von OLED-Displays
reduziert, und auch, dass blaue Pixel mehr Strom verbrauchen als andere Farben.

INTRODUCING THE ENERGY SAVING CONCEPT OF LOWER CARBON GRAPHICS

Developing and implementing a new idea which we believe has already saved energy
in homes across the UK.

SWITCHING FROM LIGHT TO DARK MODE ON APPS AND WEBSITES USES MORE ENERGY

BBC R&D find energy saving recommendation doesn’t take into account user
behaviour

Revision 650: Sustainable Web Design

<p>Schepp und Hans erörtern in dieser Revision, anlässlich eines <a href="https://engineeringkiosk.dev/podcast/episode/174-frontend-engineering-metriken-im-team-einf%C3%BChren-mit-dem-working-draft-podcast/">Gastbeitrags</a> zum Adventskalender des <a href="https://engineeringkiosk.dev/">Engineering Kiosk Podcasts</a>, die vielfältigen Aspekte von Engineering KPIs, deren Bedeutung für Benutzerinteraktion und Nutzererfahrung sowie die Notwendigkeit regelmäßiger Anpassungen im Einklang mit Unternehmenszielen.</p>
<h3>Schaunotizen</h3>
<dl>
<dt>[00:01:13] Engineering KPIs</dt>
<dd>Los geht’s mit einem Rückblick auf die Weihnachtsepisode beim Engineering Kiosk, in der sie erste Gedanken zu KPIs geteilt hatten. Schnell wird klar: KPIs sind genauso vielfältig wie die Perspektiven der beiden.</p>
<p>Hans bringt ein Beispiel aus der Praxis und erklärt, wie man die Performance eines Produkts messen kann – etwa in einem Online-Shop: Wie viele Besucher:innen kaufen wirklich etwas? Oder bei einer Video-Streaming-Plattform: Wie viele schauen regelmäßig und wie lange bleiben sie dran? Solche KPIs helfen nicht nur Entwicklerteams, sondern auch Produktverantwortlichen, die richtigen Entscheidungen zu treffen. Schepp wiederum macht deutlich, dass KPIs mehr als reine Technik sein sollten. Sie sollen auch die Benutzererfahrung verbessern. Ein Highlight in der Diskussion: die Core Web Vitals wie <a href="https://web.dev/articles/lcp?hl=en">Largest Contentful Paint</a> oder <a href="https://web.dev/articles/cls?hl=en">Cumulative Layout Shift</a> – unverzichtbare Metriken für die Optimierung der User Experience (höre dazu auch <a href="https://workingdraft.de/533/">Revision 533: Frontend Performance Metriken – Die Core Web Vitals</a>). Am Ende sind sich beide einig: KPIs sollten immer aus der Sicht der Nutzer:innen betrachtet werden.</p>
<p>Ein weiterer wichtiger Punkt ist das regelmäßige Überprüfen und Anpassen bestehender KPIs. Hans plädiert für regelmäßige Meetings, um Metriken und Ziele auf Kurs zu halten. Auch das Thema Alerting thematisieren wir: Was tun, wenn KPIs plötzlich aus der Reihe tanzen? Schnelles Handeln ist hier entscheidend. Aber Achtung: Zu viele Metriken gleichzeitig sind kontraproduktiv. Ein Fokus auf die wirklich relevanten KPIs den größten Nutzen bringt – für Unternehmen und Nutzer:innen.</dd>
</dl>


Schepp und Hans erörtern in dieser Revision, anlässlich eines Gastbeitrags zum
Adventskalender des Engineering Kiosk Podcasts, die vielfältigen Aspekte von
Engineering KPIs, deren Bedeutung für Benutz…

Schepp und Hans erörtern in dieser Revision, anlässlich eines Gastbeitrags zum
Adventskalender des Engineering Kiosk Podcasts, die vielfältigen Aspekte von
Engineering KPIs, deren Bedeutung für Benutzerinteraktion und Nutzererfahrung
sowie die Notwendigkeit regelmäßiger Anpassungen im Einklang mit
Unternehmenszielen.


SCHAUNOTIZEN

[00:01:13] ENGINEERING KPIS

Los geht’s mit einem Rückblick auf die Weihnachtsepisode beim Engineering Kiosk,
in der sie erste Gedanken zu KPIs geteilt hatten. Schnell wird klar: KPIs sind
genauso vielfältig wie die Perspektiven der beiden.



Hans bringt ein Beispiel aus der Praxis und erklärt, wie man die Performance
eines Produkts messen kann – etwa in einem Online-Shop: Wie viele Besucher:innen
kaufen wirklich etwas? Oder bei einer Video-Streaming-Plattform: Wie viele
schauen regelmäßig und wie lange bleiben sie dran? Solche KPIs helfen nicht nur
Entwicklerteams, sondern auch Produktverantwortlichen, die richtigen
Entscheidungen zu treffen. Schepp wiederum macht deutlich, dass KPIs mehr als
reine Technik sein sollten. Sie sollen auch die Benutzererfahrung verbessern.
Ein Highlight in der Diskussion: die Core Web Vitals wie Largest Contentful
Paint oder Cumulative Layout Shift – unverzichtbare Metriken für die Optimierung
der User Experience (höre dazu auch Revision 533: Frontend Performance Metriken
– Die Core Web Vitals). Am Ende sind sich beide einig: KPIs sollten immer aus
der Sicht der Nutzer:innen betrachtet werden.

Ein weiterer wichtiger Punkt ist das regelmäßige Überprüfen und Anpassen
bestehender KPIs. Hans plädiert für regelmäßige Meetings, um Metriken und Ziele
auf Kurs zu halten. Auch das Thema Alerting thematisieren wir: Was tun, wenn
KPIs plötzlich aus der Reihe tanzen? Schnelles Handeln ist hier entscheidend.
Aber Achtung: Zu viele Metriken gleichzeitig sind kontraproduktiv. Ein Fokus auf
die wirklich relevanten KPIs den größten Nutzen bringt – für Unternehmen und
Nutzer:innen.

Revision 649: Engineering KPIs

<p>Mit <b>Matthias Ott</b> (<a href="https://matthiasott.com/">Web</a>, <a href="https://mastodon.social/@matthiasott">Mastodon</a>, <a href="https://newsletter.ownyourweb.site/">Newsletter</a>) quatschen Schepp und Peter über das Indie Web im Allgemeinen und persönliche Websites im Besonderen.</p>
<h3>Schaunotizen</h3>
<dl>
<dt>[00:01:01] Personal Web Sites</dt>
<dd>Matthias ist der Schöpfer des Newsletters <a href="https://newsletter.ownyourweb.site/">Own Your Web</a>, in dem (unter anderem) die persönliche, selbstentwickelte und keinen Regeln gehorchende Webseite eine prominente Rolle spielt. Warum man eine Personal Web Site statt Social Media haben wollen könnte und wie diese gebaut sein könnte, ist Kernthema der Sendung. Faustregel: alles kann, nichts muss! Wir schauen uns ein paar Beispiele an (von <a href="https://lynnandtonic.com/">Lynn Fisher</a> bis <a href="https://css-tricks.com/">CSS-Tricks</a>), sprechen über technische wie inhaltliche Herausforderungen (z.B. Leser-Kommentare) Publikations-Paradigmen wie <a href="https://indieweb.org/POSSE">POSSE</a> und den Umgang mit großen Plattformen. Wir enden mit einer Diskussion rund um <a href="https://de.m.wikipedia.org/wiki/RSS_(Web-Feed)">RSS</a> als Abo-Kanal, Syndikations-Mechanismus (z.B. via <a href="https://rss-parrot.net/">RSS Parrot</a>) und <a href="https://rknight.me/blog/styling-rss-and-atom-feeds/">Styling-Ziel</a> für eine sehr hippe und coole Technologie namens XSLT.</dd>
</dl>


Mit Matthias Ott (Web, Mastodon, Newsletter) quatschen Schepp und Peter über das
Indie Web im Allgemeinen und persönliche Websites im Besonderen.


SCHAUNOTIZEN

[00:01:01] PERSONAL WEB SITES

Matthia…

Mit Matthias Ott (Web, Mastodon, Newsletter) quatschen Schepp und Peter über das
Indie Web im Allgemeinen und persönliche Websites im Besonderen.


SCHAUNOTIZEN

[00:01:01] PERSONAL WEB SITES

Matthias ist der Schöpfer des Newsletters Own Your Web, in dem (unter anderem)
die persönliche, selbstentwickelte und keinen Regeln gehorchende Webseite eine
prominente Rolle spielt. Warum man eine Personal Web Site statt Social Media
haben wollen könnte und wie diese gebaut sein könnte, ist Kernthema der Sendung.
Faustregel: alles kann, nichts muss! Wir schauen uns ein paar Beispiele an (von
Lynn Fisher bis CSS-Tricks), sprechen über technische wie inhaltliche
Herausforderungen (z.B. Leser-Kommentare) Publikations-Paradigmen wie POSSE und
den Umgang mit großen Plattformen. Wir enden mit einer Diskussion rund um RSS
als Abo-Kanal, Syndikations-Mechanismus (z.B. via RSS Parrot) und Styling-Ziel
für eine sehr hippe und coole Technologie namens XSLT.

Revision 648: Personal Web Sites

<p>Zur Fortsetzung der Barrierefreiheits-Mini-Podcast-Serie hatten Hans und Peter dieses Mal <strong>Nina Jameson</strong> zu Gast! Nina ist digitale Barrierefreiheitsexpertin und Co-Gründerin der <a href="https://gehirngerecht.digital/">Gehirngerecht Digital GmbH</a>. Folgt <a href="https://www.linkedin.com/in/nina-jameson-355a201aa/">ihr</a> und <a href="https://www.linkedin.com/in/tobias-roppelt/">ihrem Mitgründer</a> auf LinkedIn oder hört euch einfach an, mit welcher Leichtigkeit sie unbedarfte Podcaster durch den WCAG-Dschungel führt!</p>
<h3>Schaunotizen</h3>
<dl>
<dt>[00:00:00] WCAG-Spezifikationen lesen und verstehen</dt>
<dd>Wir kreisen in dieser Revision um die <a href="https://de.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines">Web Content Accessibility Guidelines</a> sowie verwandte Dokumente und Regulierungen. Nina erklärt die Struktur <a href="https://www.w3.org/TR/WCAG22/">der Spezifikationen</a> und wie sie für Otto Normalwebentwickler:in zu lesen und zu verstehen sind. Wir quatschen unter anderem über die Szenarien für die Anwendung der WCAG-Specs, wie die Erfolgskriterien funktionieren und sogar über <a href="https://www.w3.org/TR/WCAG22/#conformance-claims">die Spezifikation von Spezifikations-Conformance-Claims.</a> Jenseits der W3C-Bleiwüsten-Wegweiser kommen wir nicht umhin, auch ein wenig über das leidige Thema der Umsetzung im Alltag zu sprechen. Was bringen <a href="https://employment-social-affairs.ec.europa.eu/policies-and-activities/social-protection-social-inclusion/persons-disabilities/union-equality-strategy-rights-persons-disabilities-2021-2030/european-accessibility-act_en">European accessibility act</a> und <a href="https://www.bmas.de/DE/Service/Gesetze-und-Gesetzesvorhaben/barrierefreiheitsstaerkungsgesetz.html">Barrierefreiheitsstärkungsgesetz</a>, welche Webdev-Patterns stehen der Barrierefreiheit grundsätzlich entgegen und wie lässt sich Accessibility in die tägliche Webentwicklungs-Arbeit integrieren? Nina empfiehlt die <b>Handreichungen der Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik</b> (z.B. für typische <a href="https://handreichungen.bfit-bund.de/barrierefreie-uie/0.3/bedienelemente.html">Bedienelemente</a>, Rest stehe <a href="https://www.bfit-bund.de/DE/Publikation/publikation.html">Publikationen auf bfit-bund.de</a>) sowie die in der WCAG stets mitverlinkten <a href="https://www.w3.org/WAI/WCAG22/Understanding/">Understanding</a>&#8211; und <a href="https://www.w3.org/WAI/WCAG22/quickref/">How to Meet</a>-Dokumente für die jeweiligen Erfolgskriterien. Am Ende streifen wir noch kurz das in <a href="https://workingdraft.de/646/">Revision 646</a> bereits ausführlich beackerte Thema „automatisches Testing“. Nina empfiehlt <a href="https://www.deque.com/axe/devtools/">axe DevTools</a>, <a href="https://www.tpgi.com/arc-platform/arc-toolkit/">ARC Toolkit</a> und die <a href="https://wave.webaim.org/">WAVE Web Accessibility Evaluation Tools</a>, hat für Lighthouse hingegen nicht ganz so viel Enthusiasmus übrig.</dd>
</dl>


Zur Fortsetzung der Barrierefreiheits-Mini-Podcast-Serie hatten Hans und Peter
dieses Mal Nina Jameson zu Gast! Nina ist digitale Barrierefreiheitsexpertin und
Co-Gründerin der Gehirngerecht Digital G…

Zur Fortsetzung der Barrierefreiheits-Mini-Podcast-Serie hatten Hans und Peter
dieses Mal Nina Jameson zu Gast! Nina ist digitale Barrierefreiheitsexpertin und
Co-Gründerin der Gehirngerecht Digital GmbH. Folgt ihr und ihrem Mitgründer auf
LinkedIn oder hört euch einfach an, mit welcher Leichtigkeit sie unbedarfte
Podcaster durch den WCAG-Dschungel führt!


SCHAUNOTIZEN

[00:00:00] WCAG-SPEZIFIKATIONEN LESEN UND VERSTEHEN

Wir kreisen in dieser Revision um die Web Content Accessibility Guidelines sowie
verwandte Dokumente und Regulierungen. Nina erklärt die Struktur der
Spezifikationen und wie sie für Otto Normalwebentwickler:in zu lesen und zu
verstehen sind. Wir quatschen unter anderem über die Szenarien für die Anwendung
der WCAG-Specs, wie die Erfolgskriterien funktionieren und sogar über die
Spezifikation von Spezifikations-Conformance-Claims. Jenseits der
W3C-Bleiwüsten-Wegweiser kommen wir nicht umhin, auch ein wenig über das leidige
Thema der Umsetzung im Alltag zu sprechen. Was bringen European accessibility
act und Barrierefreiheitsstärkungsgesetz, welche Webdev-Patterns stehen der
Barrierefreiheit grundsätzlich entgegen und wie lässt sich Accessibility in die
tägliche Webentwicklungs-Arbeit integrieren? Nina empfiehlt die Handreichungen
der Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik
(z.B. für typische Bedienelemente, Rest stehe Publikationen auf bfit-bund.de)
sowie die in der WCAG stets mitverlinkten Understanding– und How to
Meet-Dokumente für die jeweiligen Erfolgskriterien. Am Ende streifen wir noch
kurz das in Revision 646 bereits ausführlich beackerte Thema „automatisches
Testing“. Nina empfiehlt axe DevTools, ARC Toolkit und die WAVE Web
Accessibility Evaluation Tools, hat für Lighthouse hingegen nicht ganz so viel
Enthusiasmus übrig.

Revision 647: WCAG-Spezifikationen lesen und verstehen

<p>In dieser Folge geht es darum, wie man Barrierefreiheit in der Web-Entwicklung richtig testet – mit Fokus auf praxisnahe Tipps. Anna Maier (<a href="https://www.linkedin.com/in/anna-maier-045739143/">LinkedIn</a> / <a href="https://nerdculture.de/@annam">Mastodon</a>), eine erfahrene Web-Entwicklerin und IT-Consultant, zeigt Hans und Schepp, worauf es wirklich ankommt.</p>
<aside class="message long-message">
<h3>Unser Sponsor</h3>
<p><a href="https://mittwald.de/hitc?ref=workingdraft.de"><img class="alignnone size-medium wp-image-3774" style="display: block; max-width: 350px; width: 100%; float: right; margin-bottom: 1rem; margin-left: 1rem;" src="https://workingdraft.de/wp-content/uploads/2023/03/Podcast_Banner_Mittwald_-Hosting_neu_gedacht_945x314px.jpg" alt="" /></a></p>
<div class="message_content">
<p>Am <strong>13. Juni 2025</strong> lädt mittwald zum <strong>Head in the Cloud Summit</strong> ein – ein Tag voller Inspiration und Austausch auf dem mittwald Campus. Hier treffen sich Webworker, Developer und Digitalagenturen, um voneinander zu lernen.</p>
<p>Freu dich auf spannende Talks und Sessions zu <strong>Cloud &amp; DevOps</strong>, <strong>Technology</strong> und <strong>Culture &amp; Creativity</strong>. Von den Herausforderungen der digitalen Arbeitswelt bis hin zu den Trends von morgen – hier bekommst du Einblicke von den klügsten Köpfen der Branche.</p>
<p>Die Tickets sind begrenzt, also schnell buchen auf <a href="https://mittwald.de/hitc?ref=workingdraft.de">mittwald.de/hitc</a>.
</div>
</aside>
<h3>Schaunotizen</h3>
<dl>
<dt>[00:02:00] (Automatisiertes) Testing von Barrierefreiheit</dt>
<dd>Wir starten direkt Mal mit der Feststellung, dass automatisierte Tests zwar ein guter Anfang, aber bei weitem nicht genug sind. Denn Tools wie WAVE oder Accessibility Insights können nämlich nur 20-30 Prozent der Barrieren erkennen. Anna erklärt, warum der Rest einfach menschliches Augenmaß und echte Nutzererfahrung braucht. Ohne manuelle Tests geht’s nicht – da kommen Maschinen einfach an ihre Grenzen.</p>
<p>Konsequenterweise lautet Annas Empfehlung, echte Nutzerinnen und Nutzer in den Testprozess einzubinden. Vor allem Menschen, die regelmäßig assistive Technologien wie Screenreader nutzen, liefern Einblicke, die kein Tool bieten kann. Außerdem gibt es Agenturen, die auf solche Benutzer-Tests spezialisiert sind. Das lohnt sich, um echte Probleme zu erkennen und zu lösen.</p>
<p>Wir sprechen über Linter-Tools, die schon während der Entwicklung helfen, typische Fehler zu vermeiden. Das ist ein einfacher Weg, Barrieren früh zu reduzieren.</p>
<p>Beim Thema AI-Tools bleibt Anna kritisch. Generische Lösungen können helfen, bieten aber oft nicht die nötige Tiefe. Stattdessen empfiehlt sie spezialisierte Tools, die auf Barrierefreiheit ausgerichtet sind. Sie ist optimistisch, dass solche Tools in Zukunft durch AI noch besser werden könnten, indem sie gezielte Vorschläge basierend auf echten Nutzeranalysen liefern.</p>
<p>Kurz gesagt: Automatisierte Tests sind nur der Einstieg. Für echte Barrierefreiheit braucht es manuelles Testing, Nutzerfeedback und gute Tools.</dd>
</dl>
<h3>Links</h3>
<dl>
<dt><a href="https://www.w3.org/WAI/WCAG21/quickref/">WCAG Quick Reference</a></dt>
<dd>Eine umfassende Übersicht der Web-Content-Accessibility-Guidelines.</dd>
<dt><a href="https://wave.webaim.org/">WAVE Tool</a></dt>
<dd>Ein Tool, das Web-Accessibility-Probleme identifiziert, um die Barrierefreiheit zu verbessern.</dd>
<dt><a href="https://accessibilityinsights.io/">Accessibility Insights</a></dt>
<dd>Ein Tool zur Analyse von Webseiten auf Barrierefreiheit und zur Unterstützung bei manuellem Testen.</dd>
<dt><a href="https://github.com/annam002/automated-accessibility-testing ">Annas Automated Accessibility Testing GitHub Repo</a></dt>
<dd>Ein Repository mit nützlichen Skripten und Beispielen zum automatisierten Testen von Barrierefreiheit.</dd>
</dl>


In dieser Folge geht es darum, wie man Barrierefreiheit in der Web-Entwicklung
richtig testet – mit Fokus auf praxisnahe Tipps. Anna Maier (LinkedIn /
Mastodon), eine erfahrene Web-Entwicklerin und IT…

In dieser Folge geht es darum, wie man Barrierefreiheit in der Web-Entwicklung
richtig testet – mit Fokus auf praxisnahe Tipps. Anna Maier (LinkedIn /
Mastodon), eine erfahrene Web-Entwicklerin und IT-Consultant, zeigt Hans und
Schepp, worauf es wirklich ankommt.


UNSER SPONSOR



Am 13. Juni 2025 lädt mittwald zum Head in the Cloud Summit ein – ein Tag voller
Inspiration und Austausch auf dem mittwald Campus. Hier treffen sich Webworker,
Developer und Digitalagenturen, um voneinander zu lernen.

Freu dich auf spannende Talks und Sessions zu Cloud & DevOps, Technology und
Culture & Creativity. Von den Herausforderungen der digitalen Arbeitswelt bis
hin zu den Trends von morgen – hier bekommst du Einblicke von den klügsten
Köpfen der Branche.

Die Tickets sind begrenzt, also schnell buchen auf mittwald.de/hitc.


SCHAUNOTIZEN

[00:02:00] (AUTOMATISIERTES) TESTING VON BARRIEREFREIHEIT

Wir starten direkt Mal mit der Feststellung, dass automatisierte Tests zwar ein
guter Anfang, aber bei weitem nicht genug sind. Denn Tools wie WAVE oder
Accessibility Insights können nämlich nur 20-30 Prozent der Barrieren erkennen.
Anna erklärt, warum der Rest einfach menschliches Augenmaß und echte
Nutzererfahrung braucht. Ohne manuelle Tests geht’s nicht – da kommen Maschinen
einfach an ihre Grenzen.



Konsequenterweise lautet Annas Empfehlung, echte Nutzerinnen und Nutzer in den
Testprozess einzubinden. Vor allem Menschen, die regelmäßig assistive
Technologien wie Screenreader nutzen, liefern Einblicke, die kein Tool bieten
kann. Außerdem gibt es Agenturen, die auf solche Benutzer-Tests spezialisiert
sind. Das lohnt sich, um echte Probleme zu erkennen und zu lösen.

Wir sprechen über Linter-Tools, die schon während der Entwicklung helfen,
typische Fehler zu vermeiden. Das ist ein einfacher Weg, Barrieren früh zu
reduzieren.

Beim Thema AI-Tools bleibt Anna kritisch. Generische Lösungen können helfen,
bieten aber oft nicht die nötige Tiefe. Stattdessen empfiehlt sie spezialisierte
Tools, die auf Barrierefreiheit ausgerichtet sind. Sie ist optimistisch, dass
solche Tools in Zukunft durch AI noch besser werden könnten, indem sie gezielte
Vorschläge basierend auf echten Nutzeranalysen liefern.

Kurz gesagt: Automatisierte Tests sind nur der Einstieg. Für echte
Barrierefreiheit braucht es manuelles Testing, Nutzerfeedback und gute Tools.


LINKS

WCAG QUICK REFERENCE

Eine umfassende Übersicht der Web-Content-Accessibility-Guidelines.

WAVE TOOL

Ein Tool, das Web-Accessibility-Probleme identifiziert, um die Barrierefreiheit
zu verbessern.

ACCESSIBILITY INSIGHTS

Ein Tool zur Analyse von Webseiten auf Barrierefreiheit und zur Unterstützung
bei manuellem Testen.

ANNAS AUTOMATED ACCESSIBILITY TESTING GITHUB REPO

Ein Repository mit nützlichen Skripten und Beispielen zum automatisierten Testen
von Barrierefreiheit.

Revision 646: (Automatisiertes) Testing von Barrierefreiheit

Wöchentlicher Podcast für Frontend Devs, Design Engineers und Web-Entwickler:innen

PODLIST

Working Draft

Wöchentlicher Podcast für Frontend Devs, Design Engineers und Web-Entwickler:innen.

Neue Episoden

Revision 657: Resumable Uploads

Working Draft

Revision 656: State of JS 2024 – Teil 3/4

Working Draft

Revision 655: State of JS 2024 – Teil 2

Working Draft

Revision 654: TypeScript 5.8 – in Zukunft nur noch smarter Linter?

Working Draft

Revision 653: State of JS 2024 – Teil 1

Working Draft

Revision 652: Automatisiertes Testing mit Playwright

Working Draft

Revision 651: Accessible Rich Internet Applications (ARIA)

Working Draft

Revision 650: Sustainable Web Design

Working Draft

Revision 649: Engineering KPIs

Working Draft

Revision 648: Personal Web Sites

Working Draft

Revision 647: WCAG-Spezifikationen lesen und verstehen

Working Draft

Revision 646: (Automatisiertes) Testing von Barrierefreiheit

Working Draft