Was können die Teilnehmenden in deinem Workshop lernen, dass ihnen bei ihren zukünftigen CSS-Projekten hilft?

Auf jeden Fall die Basics lernen – alles, was zum tiefen Verständnis von CSS gehört, damit man dann darauf aufbauen kann.

Wie siehst du die Rolle von künstlicher Intelligenz bei der Verbesserung der Barrierefreiheit im Web?

Künstliche Intelligenz unterstützt uns dabei sehr gut. Wir nutzen sie vor allem für automatisierte Tests. Da KI immer besser wird, verbessern sich auch unsere automatisierten Tests, was wiederum die Barrierefreiheit weiter steigert.

Hast du Tipps, wie Teams effektiv zusammenarbeiten können, um Barrierefreiheit in ihren Projekten zu integrieren?

Von Anfang an sollten alle ins Boot geholt werden. Kommunikation steht ganz oben: Entwickler und Designer müssen von Anfang an gut zusammenarbeiten, über alle Themen sprechen und auch Barrierefreiheit aktiv mit einbeziehen.

Welche praktischen Ansätze gibt es in deinem Workshop?

Wir haben viele kleine Aufgaben, bei denen sich die Teilnehmer ausprobieren und direkt hands-on lernen können. Dabei nehmen sie auf jeden Fall viel Wissen mit.

Du bist zum wiederholten Male auf den JavaScript & Angular Days, was lässt dich immer wieder zurückkehren?

Die Atmosphäre ist großartig. Hinter den Kulissen sind alle sehr nett – sowohl die Speaker als auch die Teilnehmer. Der Austausch mit den Teilnehmern und die Möglichkeit, Wissen zu verbreiten, finde ich besonders schön.

The post Lena Rosenboom im Interview: Automatisierte Tests und Accessibility durch KI appeared first on JavaScript & Angular Days.

Doch bevor wir nun mit CSS-in-JS loslegen, sehen wir uns die übrigen Styling-Möglichkeiten einer typischen React-Applikation an. Wobei mittlerweile auch der Begriff einer „typischen React-Applikation“ nicht mehr so eindeutig ist. Geht es nach dem React-Team und der offiziellen Doku, müssten wir hier von einer Next.js-Applikation sprechen. Eine rein clientseitige React-Applikation ist jedoch weiterhin auch ohne ein Fullstack-Framework möglich, nur sollten Sie hierfür nicht mehr auf das totgesagte Create React App setzen, sondern doch besser ein moderneres Werkzeug wie Vite nutzen. Generell ist es jedoch egal, welche Umgebung Sie nutzen, denn in Sachen Styling sind sie alle gleich. Die folgenden Optionen stehen Ihnen zur Verfügung:

• Globale Styles: Die einfachste Variante besteht darin, CSS ganz regulär in das HTML-Dokument der Applikation zu integrieren. Entweder über ein externes Stylesheet oder ein style-Tag. Dieses Styling gilt applikationsweit, verfügt über keinerlei Namespacing, außer Sie implementieren es selbst, und glänzt auch nicht mit Wiederverwendbarkeit.

• CSS-Importe: Die meisten React-Umgebungen wie Vite, aber auch Next.js, unterstützten den Import von CSS-Dateien in JavaScript. Dabei nutzen Sie das ECMAScript-Modulsystem, nur dass Sie CSS- statt JavaScript-Dateien importieren. Hier gelten die gleichen Einschränkungen wie bei den globalen Styles. Sie müssen also sehr behutsam vorgehen, damit importierte Stylesheets sich nicht plötzlich auf andere Teile oder gar die gesamte Applikation auswirken.

• CSS-Module: Deutlich besser wird die Situation mit CSS-Modulen. Hier schreiben Sie auch gewöhnlichen CSS-Code, müssen sich aber auf Klassenselektoren beschränken. Dafür sorgen die CSS-Module dafür, dass die Selektoren sich nur auf Ihre aktuelle Komponente und nicht auf die gesamte Applikation auswirken.

• CSS-Frameworks: In letzter Zeit haben CSS-Frameworks wie Tailwind erheblich an Popularität gewonnen. Sie sind zum einen sehr mächtig und arbeiten auf Basis von CSS. Dieser Aspekt ist gerade in Richtung Fullstack-Frameworks wichtig, da sich statische Stylesheets deutlich besser handeln und vorgenerieren lassen als dynamischer Code.

• CSS-in-JS: Der CSS-in-JS-Ansatz kommt vor allem JavaScript-Entwickler:innen entgegen. Hier müssen Sie zwar immer noch CSS schreiben, der Code ist jedoch in JavaScript eingebettet. Sie können den Funktionsumfang von CSS mit JavaScript erweitern und sogar Logik und Parametrisierung in den Styles implementieren. Bei allen Vorteilen gibt es bei CSS-in-JS-Lösungen teilweise Probleme im Zusammenhang mit Fullstack-Frameworks wie Next.js.

Erlebe Angular Trends live

16. - 20. März 2026

>

 

Populäre Vertreter von CSS-in-JS-Lösungen sind die Bibliotheken Styled-Components oder Emotion. In Listing 1 sehen Sie ein Beispiel für den Einsatz von Styled-Components.

const Button = styled.button`
  background-color: #4caf50;
  color: white;
  padding: 10px 20px;
  border: none;
  border-radius: 5px;
  cursor: pointer;
  font-size: 16px;
  transition: background-color 0.3s;
 
  &:hover {
    background-color: #45a049; 
  }
`;

Das Ergebnis einer solchen Styled-Component ist eine Komponente, die das Element, in diesem Fall einen Button, mit den Styles kombiniert. Sie können diese Komponenten wie gewöhnliche Komponenten benutzen. Alle Props des ursprünglichen Elements stehen Ihnen auch in der Styled-Component zur Verfügung, sodass Sie beispielsweise auf einen Klick auf den Button mit der onClick-Prop reagieren können.

StyleX – das Style-System von Facebook

In letzter Zeit war es eher ruhig in der CSS-in-JS-Welt, doch plötzlich sorgt eine Veröffentlichung für Aufsehen. Im November 2023 hat Facebook StyleX veröffentlicht, eine JavaScript-Bibliothek, um Styles für optimierte User Interfaces zu definieren, das sagt zumindest die Dokumentation des Projekts. Doch was steckt dahinter? Zunächst ist StyleX die Styling-Bibliothek hinter Facebook, Instagram, WhatsApp und Threads. Klingt verdächtig nach React? Richtig! Meta setzt StyleX auf seinen großen React-Plattformen ein, und das nicht erst seit Ende November 2023. Dieser Zeitpunkt war der erste öffentliche Commit in das GitHub-Repo des Projekts. Davor kam die Bibliothek schon längere Zeit intern zum Einsatz. Es ist also keine Beta-Software, sondern vielmehr eine zigfach getestete Lösung, die das Entwicklerteam jetzt auf den Markt wirft. Werfen wir also einen Blick auf die Bibliothek und auf die Aspekte, die sie von anderen ähnlichen Lösungen unterscheidet. Laut Dokumentation verfolgt StyleX eine ganze Reihe von Prinzipien:

• Co-Location: Die Styles sollen dort liegen, wo sie angewendet werden.

• Deterministic Resolution: Die Styles von StyleX sollen vorhersehbar sein, auch über Dateigrenzen hinweg: „The last style applied always wins“ – Der zuletzt angewendete Style gewinnt immer.

• Low-cost abstraction: StyleX versucht immer, die schnellstmögliche Lösung zu bieten. Standardfälle verursachen keine Laufzeitkosten. Das Definieren und Anwenden von Styles in einer Datei bringt keinen zusätzlichen Overhead mit sich. Verwenden Sie Styles über mehrere Dateien, entstehen geringe Laufzeitkosten.

• Small API Surface: Das API von StyleX besteht aus den beiden Funktionen create und props.

• Type-Safe Styles: StyleX ist mit Flow, dem Typsystem von Facebook, umgesetzt. Aus diesem Grund verfügen alle Styles über Typinformationen, die StyleX sowohl für Flow als auch für TypeScript zur Verfügung stellt.

• Shareable Constants: StyleX übersetzt CSS-Klassen, -Variablen und andere Identifier in JavaScript-Konstanten, sodass die Typsicherheit im Code nicht verloren geht.

• Framework-agnostic: StyleX klingt zwar sehr nach React und funktioniert auch hervorragend damit, Sie können aber auch andere Frameworks damit verwenden.

• Encapsulation: Alle Styles sind Klassen zugeordnet. Komplexe Selektoren werden nicht unterstützt, um die Implementierung so einfach, vorhersehbar und performant wie möglich zu halten.

• Readability & Maintainability over Terseness: Performance und Lesbarkeit stehen ganz oben auf der Prioritätenliste von StyleX. Das Werkzeug bewegt sich nahe an den Standardbezeichnungen von CSS.

• Modularity and Composability: StyleX versucht Styles so zu organisieren, dass sie wiederverwendbar sind und im besten Fall auch in Paketen organisiert und damit sogar zwischen Applikationen geteilt werden können.

• Avoid global configuration: StyleX kommt ohne zusätzliche Konfiguration aus.

• One small File over many smaller Files: StyleX erzeugt ein optimiertes CSS-Bundle, das initial geladen wird.

Diese Prinzipien klingen sinnvoll und durchdacht, doch wie sieht das Ganze in der Praxis aus? Für die CSS-in-JS-Lösung müssen Sie vor der Verwendung von StyleX das zugehörige Paket installieren. Das geschieht mit dem Kommando npm install @stylexjs/stylex. Theoretisch können Sie die dev-runtime von StyleX verwenden, die die Styles zur Laufzeit übersetzt. Hiervon rät StyleX jedoch ab. Stattdessen sollten Sie lieber das Babel-Plug-in verwenden.

Styles mit StyleX definieren und einbinden

Das API von StyleX besteht aus den beiden Funktionen create, mit der Sie die Styles definieren, und props, mit der Sie die Styles anwenden. Ein einfaches Beispiel könnte wie in Listing 2 aussehen.

import * as stylex from '@stylexjs/stylex';
 
const styles = stylex.create({
  headline: {
    color: 'red',
    textDecoration: {
      default: 'none',
      ':hover': 'underline',
    },
  },
});

Der create-Funktion übergeben Sie ein Objekt, in der Sie die verschiedenen Styles definieren können. Hier sehen Sie, dass es eine headline-Definition gibt. Deren Schriftfarbe ist rot, und wenn Sie die Maus über das Element bewegen, wird es unterstrichen. Im einfachsten Fall arbeiten Sie also wie in regulärem CSS mit Deklarationen, also mit Schlüsseln und Werten. Wo CSS auf Eigenschaftsnamen mit Bindestrichen setzt, arbeitet StyleX mit der CamelCase-Schreibweise. Der Grund dafür ist, dass Bindestriche in Eigenschaftsnamen nur erlaubt sind, wenn Sie sie in Anführungszeichen setzen würden. Noch mehr Kontrolle erlaubt Ihnen StyleX, wenn Sie für eine Eigenschaft ein Objekt als Wert angeben. In diesem Fall können Sie beispielsweise Pseudo-Klassen unterstützen. Zusätzlich dazu können Sie Pseudo-Elemente und Media Queries in Ihre Styles einbauen.

Haben Sie die Styles definiert, können Sie sie mit der props-Funktion in ein Element integrieren:

<h1 {...stylex.props(styles.headline)}>Hallo StyleX</h1>;

Sie können nicht nur einen Style, wie hier im Beispiel, übergeben, sondern beliebig viele. Damit können Sie einen Basis-Style definieren und diesen bei Bedarf teilweise überschreiben. Die zuletzt genannten Styles überschreiben dabei die vorhergehenden.

Aus den Style-Definitionen macht StyleX reguläre CSS-Klassendefinitionen, die es in einem separaten CSS-Bundle ablegt. Für die Anwendung der Styles integriert das Werkzeug die zugehörigen Klassen in die jeweiligen Elemente.

Weitere Features von StyleX

Neben diesen grundlegenden Features, die wir von jedem Styling-Werkzeug erwarten, bietet StyleX noch einige weitere Komfortfeatures. Alles nichts, was StyleX gravierend von der Konkurrenz abheben würde, aber insgesamt eine recht runde Sache.

Parametrisierung

Sie können die Styles, die Sie mit der create-Funktion erstellen, auch als Funktionen definieren. Damit können Sie ähnliche Styles in einem Block definieren und durch die Parameter das Verhalten steuern. Im folgenden Beispiel in Listing 3 sehen Sie den line-Style als Funktion implementiert, der Sie bei der Einbindung eine Hintergrundfarbe übergeben können.

const styles = stylex.create({
  line: (color: string) => ({
    backgroundColor: color,
  }),
});
 
<div {...stylex.props(styles.line('red'))}>line 1</div>
<div {...stylex.props(styles.line('green'))}>line 2</div>

Variablen und Theming

Das API von StyleX ist zwar übersichtlich, besteht jedoch nicht nur aus den beiden Funktionen create und props. Mit einer weiteren Funktion, der defineVars-Funktion, können Sie Variablen definieren. Diese Datei muss eine bestimmte Endung aufweisen. Zulässig sind beispielsweise .style.ts oder style.tsx. Nutzen können Sie diese Variablen dann in Ihren Style-Definitionen. Das in Listing 4 dargestellte Beispiel definiert eine Primärfarbe und einen Standardabstand und wendet sie dann auf ein h1-Element an.

import * as stylex from '@stylexjs/stylex';
export const colors = stylex.defineVars({
  primary: 'hotpink',
});
 
import { colors } from './tokens.stylex';
const styles = stylex.create({
  heading: {
    color: colors.primary,
  },
});

Noch einen Schritt weiter geht der Theme-Support von StyleX mit der createTheme-Funktion. Hier können Sie eine Gruppe von Variablen übergeben, die Sie mit defineVars definiert haben, und Standardwerte sowie Theme-spezifische Werte definieren.

Fazit

Für die Community ist StyleX ein brandneues Werkzeug, das einen ähnlichen Weg wie andere CSS-in-JS-Werkzeuge einschlägt, und doch hat es seine Besonderheiten. StyleX konzentriert sich auf Einfachheit und Performance. Es senkt die Einstiegshürde so weit, dass Sie innerhalb kürzester Zeit mit der Arbeit loslegen können. Die Integration in React ist hervorragend, aber auch mit Next.js lässt sich StyleX problemlos verwenden. Ob es sich gegen die etablierte Konkurrenz wie Styled-Components oder Emotion durchsetzen und sich im Markt etablieren kann, wird die Zeit zeigen.

The post CSS-in-JS mit dem brandneuen StyleX appeared first on JavaScript & Angular Days.

Willkommen, live von den JavaScript Days in München zurzeit. Die nächste Edition ist in Berlin, aber wir haben uns jetzt schon mal ein paar Trainer geschnappt und führen Interviews mit Ihnen durch und ich habe hier auch schon Thomas Puppe von ZEIT ONLINE.

Schön, dass du da bist. Nochmal kurz zu dir. Du bist Thomas Puppe von ZEIT ONLINE und bist tätig als Senior Web Developer in Berlin und neben den normalen Feature Entwicklungen bist du auch dafür bekannt, dass du Webseiten zugänglicher machst für Mensch und Maschine. Und das ist jetzt auch dein Schwerpunkt hier auf dem Summit. Dein Workshop ging um Web-Performance und gleich stelle ich dir auch noch ein paar Fragen dazu, wie man seine Seite so ein bisschen modernisiert und aufboostert.

Noch eine Frage vorweg: Was ist denn für dich persönlich das Spannendste an deiner Arbeit?

Das Spannendste ist eigentlich, dass man nie ausgelernt hat, würde ich sagen. Also das Web und die Browser und die ganze Servertechnologie und dann alles, was im Frontend passiert, da kommt immer so viel Neues dazu und selbst wenn nichts Neues dazu kommt, man kann immer tiefer eintauchen. Und wenn du denkst du hast ein Thema verstanden dann kommt jemand um die Ecke und zeigt dir einen komplett neuen Aspekt. Und das finde ich sehr spannend, dass es einfach nicht aufhört.

Erlebe Angular Trends live

16. - 20. März 2026

>

Dann erzähl mal. Also es ist eigentlich eine ganz große Frage. Wir haben jetzt mittlerweile 5G und Multi-Kernprozessoren. Warum sind unsere Webseiten immer noch so langsam? Also nicht alle, aber viele.

Ich glaube das hat mehrere Gründe. Zum einen den Technischen. Also es kommt immer mehr auf die Seiten drauf, sei es größere Fotos, bessere Videos oder neue Frameworks. Und das sorgt halt dafür, dass erstmal Seiten immer schwerer werden per se technisch, was Kilobytes angeht. Und dann gibt es glaube ich noch ein großes Defizit darin, dass man zum Beispiel in der Performance optimiert. Die Seite ist ja nicht per se langsam, nur weil sie React oder Angular verwendet. Das ist ja Quatsch. Und all die Technologien haben auch ihre Berechtigung. Jedes Tracking, jede Werbung hat ihre Berechtigung. Aber man kann die Sachen – ich sage immer so grob handwerklich – richtig und falsch machen. Und da gibt es glaube ich noch viel Schulungsbedarf oder viel fehlendes Bewusstsein, was aus meiner Sicht aber nicht nur eine Sache des Wissens ist. Die Entwickler sind alle motiviert Sachen besser zu machen. Ich glaube es fehlt auch noch viel Performance-Kultur in den Firmen. Also es wird viel Aufwand betrieben für SEO und es wird mancher Aufwand betrieben für Accessibility. Und genau das fehlt mir für die Performance, weil am Ende ist Performance auch eine Art von Accessibility und Performance ist vor allem gut für SEO. Und wenn das mit der gleichen Dringlichkeit behandelt würde, dann wäre das wird auch schneller.

Klingt nach einem guten Appell. Und das Ganze hat auch mit dem Google Ranking zu tun. Also wie wichtig ist wirklich die Website Performance für das Google Ranking?

Das lässt sich nicht so ganz beziffern, denn Google lässt sich natürlich nicht in die Karten schauen. Man weiß nicht welchen Anteil jetzt Performance im Vergleich zu Inhalten hat, sage ich mal. Aber wir wissen, das hat Google ja auch gesagt, dass die Performance auf jeden Fall einen Einfluss aufs Ranking hat – für Desktop-Seiten schon seit 2010, für Mobil seit 2018. Und seitdem haben verschiedene Firmen, Studien durchgeführt, haben Performance verbessert und danach ihr Google Ranking beobachtet. Und da gibt es Dutzende von Untersuchungen, die nahelegen, dass sich das Ranking dann direkt verbessert, nicht nur das Google Ranking. Es verbessern sie auch Sachen wie die Absprungrate, die sich verschlechtert, es werden mehr Käufe getätigt, es werden mehr Seiten besucht während einem Gesetz – also mehr Seiten geklickt während einem Besuch. Egal was man anguckt die ganze Interaktion mit den Seiten und das Engagement, worauf wir immer so gern geschaut wird, wird besser je schneller die Seiten sind.

Klingt gut. Gibt es auch bestimmte Metriken, die entscheidend sind für die Bewertung von Webseiten und kannst du uns diese nennen?

Ja, die gibt’s auch. Da ist Google transparent und macht viel Werbung dafür. Wir kommen aus einer Zeit, da wurde vor allem auf die Ladezeit geguckt und auf die Größe von Seiten, also in Kilobyte oder Megabyte. Das war dann aber mit der Zeit nicht mehr aussagekräftig genug und dann hat Google sogenannte Web Vitals benannt, also Vitalitätsmetriken einer Webseite. Da würde ich jetzt mal drei hervorheben. Das eine ist der sogenannte Largest Contentful Paint. Der besagt einfach wie lange dauert es, bis der größte, sichtbare Bereich auf der Webseite ist und stabil steht. Das ist relevant. Was dann noch unterhalb von dem passiert ist, nicht mehr so richtig, denn für den Besucher ist die Seite da und fertig. Eine zweite wichtige Sache ist der sogenannte Layout shift. Wenn während dem Besuch der Seite oder während dem Laden durch nachgeladene Elemente immer wieder die Seite durch die Gegend springt und sich Texte nach unten verschieben, weil Bilder nachgeladen werden und solche Sachen, dann shiftet das Layout. Auch das lässt sich messen und auch das bezieht Google in das Ranking mit ein als einen dieser Vitals. Der dritte Punkt ist Interaction: Ist die Seite responsiv, wenn ich draufklicke? Passiert dann direkt was? Oder wenn ich die Seite lade, kann ich sofort mit dir interagieren oder hängt sie erstmal? Das wäre die dritte Metrik. Und alle drei Sachen lassen sich messen und damit auch optimieren. Ich finde das eine ganz gute Entwicklung, weil es halt wirklich die User Experience anspricht und nicht nur eine reine Zahl oder keine abstrakte Zahl ist, sondern ganz konkret darauf einzahlt: Ist die Seite schnell da? Reagiert sie? Funktioniert sie schön für mich?

Okay und du meintest gerade bereits es gibt diese Metriken und man kann sie auch messen. Kannst du uns ein paar Tools empfehlen, womit man sie gut überprüfen kann?

In dem Workshop heute haben wir vor allem mit dem Browser DevTools gearbeitet. Also die eingebauten Tools die jeder Chrome, Edge und Firefox und Safari mitbringt. Mit den kommt man schon sehr weit. Gerade diese Web Vitals, die ich aufgezählt habe, kann man direkt während seiner Entwicklung in der Entwicklungsumgebung testen. Darauf aufsetzend, gibt es auch Tools, wie zum Beispiel Lighthouse. Das ist auch ein Tool, was in dem Browser Developer Tools mit eingebaut ist. Das gibt einem auch diese Metriken und gibt aber gleichzeitig Verbesserungsvorschläge. Also mein Browser sagt mir sogar was ich noch nicht optimal mache, was ich verbessern sollte und worauf ich achten sollte. Man muss halt nur wissen, wo man guckt. Das ist das eine Verbesserung. Und dann finde ich aber noch ganz wichtig Tools, mit denen man diese Optimierung transparent nach außen bringt. Damit meine ich firmenintern. Dashboards bauen, damit man sieht, wie sich die Performance unseres Shops entwickelt oder um Konkurrenzvergleiche zu machen – wie steht meine Seite gegenüber der Konkurrenz. Dafür nutze ich immer ein Tool. Das nennt sich SpeedCurve. Das hat schöne Dashboards und gute Benchmarks. Und mit diesen Dashboards kann ich auch mal in die Chefetage gehen und kann zeigen, wie unsere Lage aussieht, da können wir uns verbessern und da ist die Konkurrenz besser. Das finde ich ist jetzt der zweite Teil dieser Performance-Arbeit: Kultur zu schaffen in der Firma, um das Vertrauen zu verbessern und einfach dieses Bewusstsein zu wecken.

Kann man auf jeden Fall schon mal ausprobieren. Eine letzte Frage habe ich noch. Und zwar: Du hast gerade ein paar Tricks und Tipps genannt. Kannst du uns vielleicht als Sneak Preview einen konkreten Tipp geben, den man wirklich so umsetzen kann?

Was heute glaube ich ganz gut ankam bei den Entwicklern und Entwicklerinnen. Sie arbeiten ja viel. Wir sind auf den JavaScript Days und es wird viel mit React und Angular gearbeitet. Und so passiert es, dass bestimmte Ressourcen nicht gleich im ersten HTML-Load auf der Seite stehen. Ein Beispiel wäre so ein Hero Video, was von der Angular- oder React-App erst in die Seite gebracht wird oder die Web-Front, die im CSS der Seite steht. Das sind Sachen die kann der Browser erst spät entdecken, weil zum Beispiel muss die React-App abgeladen und ausgeführt werden, dann bringt sie das Video in die Seite und das lädt der Browser. Und das gibt es in HTML schon seit Ewigkeiten, aber es ist relativ unbekannt, das sogenannte Preload Attribut. Damit kann ich schon ganz oben, das ist einer der ersten Kilobytes, die geladen werden von der Seite, kann ich dem Browser schon ankündigen: Guck mal, du wirst nachher diese Schriftart und du wirst nachher dieses Video brauchen. Dann wird das parallel geladen und wenn meine React-App dann fertig ist und das Video in die Seite einbindet, ist es schon da. Dann hat der Computer das schon aus dem Netz gezogen. Das ist ein ziemlich simpler Trick, aber hatten sehr guten und großen Effekt.

Danke dass du da warst und Fragen beantwortet hast. Und falls ihr Interesse habt: Der nächste Summit kommt im Oktober. Da sind wir in Berlin.

The post Thomas Puppe im Interview appeared first on JavaScript & Angular Days.

Bei der Überlegung, wie viele Menschen von barrierefreier Appentwicklung profitieren, stellt man fest, dass es nicht nur 7,8 Millionen schwerbehinderte Menschen [6] betrifft, denn auch einigen der 18,3 Millionen Senioren [7] können barrierefreie Apps das Leben erleichtern.

Vorteile von PWAs

Es gibt native Apps und Progressive Web Apps (PWAs). Als native Apps werden Anwendungen auf mobilen Endgeräten bezeichnet, die speziell für das Betriebssystem des jeweiligen Endgeräts konzipiert und entwickelt wurden. Sie werden meist über die App Stores, die an das Betriebssystem gekoppelt sind, als kostenfreie oder auch kostenpflichtige Anwendungen vertrieben. PWAs hingegen werden mit HTML, CSS und JavaScript entwickelt, sind somit plattformunabhängig und können auf Desktop- und Mobile-Betriebssystemen eingesetzt werden.

Richtlinien, die dafür sorgen, dass Apps von allen Menschen mit unterschiedlichen körperlichen Einschränkungen bedient werden können, haben so viele Prüfungskriterien, wie notwendig sind, um alle körperlichen Beeinträchtigungen zu berücksichtigen. Die Anzahl der Prüfungsschritte bei den Richtlinien von Google, Apple und Microsoft sind unterschiedlich. Das bedeutet, wenn bei einer Richtlinie Prüfungsschritte fehlen, werden Menschen mit bestimmten körperlichen Beeinträchtigungen ausgrenzt.

PWAs sind plattformunabhängig, sie können also auf allen Betriebssystemen eingesetzt werden. Wenn eine PWA nach der EN 301 549 barrierefrei entwickelt wird, ist sie auf allen Betriebssystemen für alle Menschen mit körperlichen Beeinträchtigungen barrierefrei [8].

Erlebe Angular Trends live

16. - 20. März 2026

>

Um es auf den Punkt zu bringen: Die Entwicklung von barrierefreien PWAs sorgt dafür, dass alle Menschen mit unterschiedlichen körperlichen Beeinträchtigungen eine App auf jedem Betriebssystem bedienen können.

Richtlinie EN 301 549

Der Standard für Barrierefreiheit von Webinhalten, den das W3C 1999 eingeführt hat und der seitdem global angewendet wird, sind die Web Content Accessibility Guidelines (WCAG). Diese internationale Richtlinie wird kontinuierlich weiterentwickelt und erfuhr 2018 mit den WCAG 2.1 [9] ihre vorerst letzte Aktualisierung.

Die WCAG in ihrer aktuellen Fassung ist die Grundlage für die europäische Norm EN 301 549. Allerdings geht es in der EN 301 549 nicht nur um Barrierefreiheit im Web, sie beinhaltet ebenso Barrierefreiheit bei

• Hardware
• Nicht-Web-Dokumente
• Software
• Dokumentation und unterstützende Dienste

Die EN 301 549 ist also die erste Richtlinie, die der Komplexität des Themas digitale Barrierefreiheit Rechnung trägt und ist deswegen umfassender.

Um den Unterschied zwischen EN 301 549 und WCAG 2.1 deutlich zu machen, hier ein Beispiel: Wenn eine Webseite in Frankreich barrierefrei gemacht werden soll, dann kommt die EN 301 549 zur Anwendung. Bei einer Webseite in Amerika kommt hingegen die WCAG 2.1 zur Anwendung.

Die EN ist eine Richtlinie für Webprogrammierung. Deswegen ist es keine gute Idee, native Apps, die mit Java oder Swift entwickelt werden, nach der EN 301 549 barrierefrei zu entwickeln. PWAs nach der EN 301 549 barrierefrei zu machen, passt perfekt, weil diese mit HTML, CSS und JavaScript entwickelt werden.

Einzelne Kriterien der EN 301 549 umgesetzt
In den folgenden Abschnitten schauen wir uns anhand von praktischen Anwendungsbeispielen an, wie bestimmte Prüfungsschritte umgesetzt werden können.

Screenreadertauglichkeit

Ein Screenreader ist eine Vorlesefunktion für blinde Menschen. Da PWAs plattformunabhängig sind, gibt Tabelle 1 einen Überblick über Screenreader, die für unterschiedliche Betriebssysteme zur Verfügung stehen, und wie diese aktiviert werden können.

Screenreadertauglichkeit bedeutet, dass eine App-Oberfläche so entwickelt ist, dass sie von Screenreadern vorgelesen werden kann. Um das responsive Webdesign besser verwirklichen zu können, können Div-Container als Schaltflächen verwendet werden. Warum dies wichtig ist, wird im Abschnitt „Motorische Einschränkungen“ erklärt. Damit der Screenreader weiß, dass der Div-Container eine Schaltfläche ist, muss das role-Attribut [14] den Wert button bekommen. Um einen Text festzulegen, der von Screenreadern vorgelesen wird, muss das Attribut aria-label verwendet und ihm ein Wert zugewiesen werden. Hier ein HTML-Beispiel:

<div role="button" aria-label="Quiz starten">START</div>

Mit den Attributen role und aria-label wird der Div-Container zur screenreadertauglichen, responsiven Schalfläche.

PWAs können nicht nur in mobilen Betriebssystemen, Android und IOS, sondern auch auf Desktopbetriebssystemen (Windows, Ubuntu und macOS) ausgeführt werden. Diese Möglichkeit ist für Menschen interessant, bei denen aufgrund einer Behinderung eine motorische Einschränkung in den Händen vorhanden ist. Blinde Menschen können ebenso den Wunsch haben, eine PWA auf einem Computer oder Laptop bedienen zu können. Sobald eine PWA auf einem Computer ausgeführt wird, ist es wichtig, dass sie komplett ohne Maus, also nur per Tastatur bedienbar ist [15]. Deswegen sollten alle Bedienelemente per Tabulatortaste erreichbar sein. Dem Div-Container, der als Schaltfläche verwendet wird, wird deswegen das Attribut tabindex hinzugefügt. Hier ein HTML-Beispiel:

Nach dem Hinzufügen des Attributs sind die Div-Schalter per Tabulatortaste erreichbar und somit ist die Grundvoraussetzung des Tastaturbedienbarkeit erfüllt. Dazu gehört auch, dass wichtige Funktionen per Tastenkürzel ausgeführt werden können. Das hilft blinden und sehbehinderten Menschen. Tastenkürzel können mit JavaScript wie folgt realisiert werden:

document.addEventListener("keydown", (varevent) => {
  switch (varevent.key) {
    case "s":
      document.getElementById("btnStart").click();
      break;
    case "w":
      document.getElementById("btnWeiter").click();
      break;
  }
});

Der JavaScript-Code sorgt dafür, dass der Schalter Start durch Drücken des Buchstaben s und der Schalter Weiter mit dem Buchstaben w ausgeführt werden kann.

Sichtbarkeit des Tastaturfokus

Dieses Thema bekommt dann große Bedeutung, wenn eine PWA auf einem Computer oder Laptop ausgeführt wird. Menschen mit einer Sehbehinderung haben Probleme, zu erkennen, welches Bedienelement den Tastaturfokus hat. In Eingabefeldern wird der Textcursor oft als schmaler senkrechter Strich dargestellt. Das ist für Menschen mit einer Sehbehinderung sehr schwer zu erkennen. Microsoft hat im Betriebssystem Windows 11 hierfür eine Lösung. In Einstellungen | Barrierefreiheit | Textcursor kann bei Textcursor-Indikator [16] die Darstellung des Textcursors angepasst werden.

In PWAs kann der App-Entwickler dafür sorgen, dass aktive Bedienelemente die Farbe Gelb als Hintergrundfarbe zugewiesen bekommen. Wenn ein Bedienelement bei Aktivierung eine gelbe Hintergrundfarbe bekommt, ist das für Menschen mit Sehbehinderung sofort sichtbar. Das kann mit CSS sehr einfach gelöst werden:

#btnStart:focus{background-color: yellow; color: black;}

Barrierefreier Farbkontrast

Menschen mit einer Farbfehlsichtigkeit können nicht immer einer Farbe den richtigen Namen zuordnen. Ihnen fehlt das Gefühl, welche Farben zusammenpassen. Ein Text mit einer dunklen Schriftfarbe auf einer dunklen Hintergrundfarbe ist für sie ebenso wenig erkennbar wie Text mit einer hellen Schriftfarbe auf einer hellen Hintergrundfarbe. Für diese Menschen ist es wichtig, dass eine App-Oberfläche einen barrierefreien Farbkontrast zwischen Schriftfarbe und Hintergrundfarbe [17] hat. Die Überprüfung des Farbkontrasts auf Barrierefreiheit einer App-Oberfläche kann mit der kostenlosen Software Colour Contrast Analyser [18] vorgenommen werden.

Zur generellen Frage der Farbgestaltung von PWA-Oberflächen ist es auch möglich, sich Anregungen von Material Design [19] von Google zu holen.

Motorische Einschränkungen

Motorische Einschränkungen betreffen „kleine Bewegungen“ (Feinmotorik) und „große Bewegungen“ (Grobmotorik). Menschen mit motorischen Einschränkungen in den Händen können Probleme haben, zu kleine Schaltflächen anzutippen. Google führt deswegen in seinen Richtlinien zur barrierefreien Appentwicklung das Kriterium „Use large, simple controls“ auf [20]. Hier empfiehlt Google eine Mindestgröße von Schaltflächen von 48dpx48dp. Bei der Entwicklung von PWAs wird empfohlen, diese Mindestgröße umzusetzen, weil sie auch von dem Accessibility Scanner (so heißt das Überprüfungstool von Google) kontrolliert wird.

Menschen mit motorischen Einschränkungen können auf die Idee kommen, eine PWA auf einem Tablet, iPad oder Computer zu bedienen, mit der Hoffnung, dass dort die Schaltflächen größer dargestellt werden. Wie im Abschnitt Screenreadertauglichkeit erklärt, ist das der Grund, warum die Schaltflächen nicht als JavaScript-Buttons

<button onclick="myFunction()">Click me</button>

sondern als Divs

<div role="button" aria-label="Quiz starten" tabindex="0">START</div>

definiert werden.

Mit Media Queries (gehört zu Cascading Style Sheets) kann dafür gesorgt werden, dass bei einer Displaygröße von 768 x 1024 die Schaltflächen größer dargestellt werden. Folgender CSS-Code zeigt, wie es geht:

@media only screen and (min-width: 768px){ 
  .schalter{
    height: 6.0rem;
  }
}

Es wird die Displaygröße 1024 × 768 abgefragt, die bei Tablets und iPads oft anzutreffen ist. Die Abfrage funktioniert ebenfalls bei Bildschirmauflösungen von Computern und Laptops. Wenn die Displaygröße zutrifft, werden die Div-Container, welche eine CSS-Klasse Schalter besitzen, in der Höhe auf 6.0 rem angepasst. Somit werden die Schaltflächen größer und Menschen mit motorischen Einschränkungen in den Händen haben es leichter, eine Schaltfläche mit dem Finger oder der Computermaus anzutippen.

Übernahme von Einstellungen des Betriebssystems

Bestimmte Personengruppen mit körperlichen Einschränkungen nehmen grundsätzliche Anpassungen im Betriebssystem vor mit der Erwartung, dass die Apps diese Einstellungen übernehmen. Sehbehinderte Menschen passen im Betriebssystem die Schriftgröße an. Menschen mit einer Farbfehlsichtigkeit können im Betriebssystem den hohen Kontrast aktivieren.

PWAs sollen, wenn installiert, so plattformnah wie möglich aussehen und sich auch so verhalten. Deswegen ist dieses Thema etwas komplex. Für Menschen mit einer Sehbehinderung ist es wichtig, dass die App-Oberfläche vergrößert bzw. gezoomt werden kann. Wie dies auf unterschiedliche Betriebssysteme umgesetzt wird, zeigt Tabelle 2.

Tabelle 2: Vergrößern der App-Oberfläche auf unterschiedlichen Betriebssystemen

An diesem Beispiel wird deutlich, dass es keine einheitliche Regel gibt. Bei drei Betriebssystemen wird das Zoomen in der App-Oberfläche umgesetzt und bei zwei Betriebssystemen wird die Einstellung im Betriebssystem übernommen. Dieses Wissen ist wichtig, wenn App-Entwickler bestimmte Barrierefreiheitsfunktionen auf unterschiedlichen Betriebssystemen testen möchten.

Progressive Web Apps auf Barrierefreiheit validieren

Nach der App-Entwicklung mit Barrierefreiheit im Blick muss zum Schluss herausgefunden werden, ob alles tatsächlich wie gewünscht funktioniert. Es gibt zwei grundsätzliche Methoden, PWAs auf Barrierefreiheit zu testen: ein automatisierter Test oder ein Test von Hand aufgrund der Richtlinien EN 301 549.

Zunächst wird der automatisierte Test mit dem Accessibility Scanner [21] betrachtet. Dieser ist für Smart-phones und Tablets ab Android 6.0 geeignet [22]. Auf einem Tablet mit Android 12 ist er erfreulicherweise schon vorinstalliert. Mit dem Accessibility Scanner können native Apps und PWAs auf Barrierefreiheit überprüft werden. Aktiviert wird er in Einstellungen | Bedienungshilfen | Accessibility Scanner. Zunächst wird eine Erlaubnis benötigt, dass der Scanner über anderen Apps eingeblendet werden darf. In den Einstellungen können das Textkontrastverhältnis, das Bildkontrastverhältnis und die Größe des Berührungsbereichs angepasst werden.

Es gibt zwei Möglichkeiten, mit dem Accessibility Scanner eine PWA auf Barrierefreiheit zu überprüfen: „Aufnehmen“ und „Snapshot“. „Aufnehmen“ macht jedes Mal ein Screenshot, wenn sich die App-Oberfläche ändert. Mit dieser Methode kann man sehr schnell eine komplette PWA auf Barrierefreiheit überprüfen. Bei „Snapshot“ kann der App-Entwickler festlegen, wann er die App-Oberfläche überprüfen möchte. Wenn der Accessibility Scanner Fehler findet, dann sind die Fehlermeldungen leicht verständlich formuliert, sodass der App-Entwickler weiß, was er zur Behebung tun muss.

Eine weitere Möglichkeit, die Barrierefreiheit einer PWA zu überprüfen, ist das kostenlose Tool Google Lighthouse [23]. Google Lighthouse ist im Browser Google Chrome in den Entwickler-Tools zu finden. Folgende Schritte müssen umgesetzt werden, um eine PWA mit Google Lighthouse auf Barrierefreiheit zu überprüfen: Die PWA in Google Chrome öffnen. Die Entwickler-Tools öffnen über das Menü Weitere Tools | Entwickler-Tools oder mit der Tastenkombination STRG + UMSCHALT + I. Jetzt das Menü „>>“ aktivieren und dann das Menü Lighthouse auswählen. Hier den Modus auf Navigation (Default) lassen. Bei Gerät die Option Mobil auswählen. Bei Categories die Option Bedienungshilfen auswählen. Jetzt mit Aktivieren des Schalters Analyze page load die Analyse auf Barrierefreiheit starten.

Wenn die Analyse beendet ist, wird ein Kreis angezeigt, in dem eine Zahl steht. Die Zahl 100 ist die beste Bewertung, die erreicht werden kann. Als Erstes werden Prüfungskriterien angezeigt, die nicht bestanden wurden. Weiter unten werden Elemente angezeigt, die manuell geprüft werden müssen. Noch weiter unten werden Bestandene Prüfungen und ganz unten Nicht zutreffend angezeigt. In der Kategorie Zusätzliche Elemente zur manuellen Überprüfung gibt es noch einen Link zur Seite „How To Do an Accessibility Review“ [24]. Hier gibt Google-Mitarbeiter Rob Dodson Tipps in Form eines YouTube-Videos und Text, wie eine Überprüfung auf Barrierefreiheit durchgeführt werden kann.

Die dritte Möglichkeit ist, die PWA nach den 98 Prüfungsschritten der EN 301 549 von Hand zu prüfen. Zusätzlich ist es hilfreich, die App von Menschen mit Behinderungen testen zu lassen. Ob beispielsweise eine PWA für blinde Menschen bedienbar ist, weiß ein blinder Mensch am besten.

Fazit

Das Entwickeln von barrierefreien PWAs ermöglicht es, barrierefreie Apps zu entwickeln, die auf allen Betriebssystemen den gleichen Standard in Sachen Barrierefreiheit zu Verfügung stellen. Das bedeutet, dass es keine Personengruppe gibt, die von der Nutzung einer App auf einem bestimmten Betriebssystem ausgeschlossen wird.

Links & Literatur
[1] https://www.gesetze-im-internet.de/bgg/__12a.html

[2] https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf

[3] https://developer.android.com/guide/topics/ui/accessibility/apps

[4] https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/iPhoneAccessibility/Making_Application_Accessible/Making_Application_Accessible.html

[5] https://docs.microsoft.com/de-de/windows/apps/design/accessibility/developing-inclusive-windows-apps

[6] https://www.destatis.de/DE/Themen/Gesellschaft-Umwelt/Gesundheit/Behinderte-Menschen/_inhalt.html

[7] https://www.destatis.de/DE/Themen/Querschnitt/Demografischer-Wandel/Aeltere-Menschen/bevoelkerung-ab-65-j.html

[8] https://www.bitvtest.de/bitv_test/das_testverfahren_im_detail/pruefschritte.html

[9] https://www.w3.org/TR/WCAG21/

[10] https://www.youtube.com/watch?v=vAwf4WFq1jg

[11] https://www.youtube.com/watch?v=ABdOTZUGZR0

[12] https://www.youtube.com/watch?v=6MjR498CyMM

[13] https://www.youtube.com/watch?v=HIKGTi8O9KQ

[14] https://webtest.bitv-test.de/index.php

[15] https://webtest.bitv-test.de/index.php?a=di&iid=267&s=n

[16] https://www.youtube.com/watch?v=cjl0gTkAVc8

[17] https://webtest.bitv-test.de/index.php?a=di&iid=260&s=n

[18] https://www.tpgi.com/color-contrast-checker/

[19] https://material.io/design/color/the-color-system.html

[20] https://developer.android.com/guide/topics/ui/accessibility/apps

[21] https://support.google.com/accessibility/android/answer/6376570?hl=de

[22] https://www.youtube.com/watch?v=GRV1kucMqIo

[23] https://developers.google.com/web/tools/lighthouse

[24] https://web.dev/how-to-review/

The post Progressive Web Apps barrierefrei entwickeln appeared first on JavaScript & Angular Days.

Was ist die Idee hinter Tailwind?

Tailwind ist ein Utility-first Framework. Es legt seinen Schwerpunkt auf die sogenannten Utility-Klassen und stellt, anders als andere Frameworks, keine vorgefertigten Komponenten zur Verfügung. Einige dieser Utility-Klassen kennen Sie aus anderen Frameworks wie beispielsweise Bootstrap, wo Sie mit den Spacing Utilitys die Innen- und Außenabstände festlegen können. So steht .mr-3 in Bootstrap für margin-right: 1rem;. Tailwind führt diesen Ansatz noch deutlich weiter und bietet für nahezu alle Aspekte des Stylings einer Webapplikation eine Lösung.

Die Arbeit mit dem Framework fühlt sich stellenweise stark nach (zu Recht) verpöntem Inline-Styling an. Auf den zweiten Blick stimmt das so jedoch nicht. Bei In-line-Styling haben Sie die Freiheit, aus allen verfügbaren Werten zu wählen. Die Utility-Klassen schränken diese Freiheit deutlich ein und bieten eine festgelegte Auswahl, beispielsweise für Abstände und Farben. Doch woher kommt unser schlechtes Gefühl, wenn wir das erste Mal auf eine HTML-Datei blicken, die mit Tailwind gestylt wurde? Adam Wathan, der Schöpfer von Tailwind, hat einen interessanten Blogartikel zu diesem Thema und seiner Reise auf dem Weg zu Tailwind geschrieben. Dem Ganzen liegt der Begriff Separation of Concerns zugrunde. HTML legt die Struktur der Webseite fest, CSS ist für das gute Aussehen zuständig und JavaScript kümmert sich um die Logik. Alle drei Elemente sind unabhängig voneinander und liegen in separaten Dateien.

Und dann kommen plötzlich Werkzeuge um die Ecke, die uns die Arbeit erleichtern sollen und brechen mit diesem zentralen Paradigma. Tailwind ist nicht das einzige Beispiel. Werfen wir doch mal einen Blick auf React beziehungsweise auf JSX. Ist JSX nicht auch nur eine Vermischung von JavaScript und HTML? Genau das ist es – aber mit dem Vorteil, dass React auf eine separate Template Engine verzichtet und der Code einer Komponente deklarativ und aus einem Guss entsteht. Natürlich können Sie in React auf JSX verzichten und Ihre Komponenten komplett mit React.createElement-Aufrufen übersähen, das macht nur in der Praxis kein Entwickler. Vielmehr gibt es Menschen, die JSX auch in anderen Kontexten wie beispielsweise in Vue-Applikationen einsetzen. Das Ganze fällt jedoch unter die Kategorie „persönliche Präferenz“.

Hinzu kommt, dass diese ganze Separation of Concerns-Geschichte nur oberflächlich funktioniert. In vielen Applikationen findet man Klassen wie profile-picture oder Ähnliches. Diese Klassen nutzt dann das Stylesheet der Applikation, um den Inhalt zu stylen. Damit hängt das Styling jedoch an der Struktur der Applikation und es liegt viel Wissen um die Struktur und den Aufbau des HTML-Dokuments im Stylesheet. Tailwind dreht das um und verschiebt das Wissen über Stylingdetails ins HTML. Aber führt das nicht zu sehr vielen Duplikaten im HTML? Diese Frage ist berechtigt, allerdings gibt es auch hierfür Lösungen. Tailwind verbietet Ihnen nicht, eigene Klassen zu erstellen. Gerade für die Fälle, in denen Sie die gleichen Styles einheitlich auf mehrere Elemente anwenden möchten und es sich nicht nur um eine oder zwei Klassen handelt, ergibt es Sinn, eine eigene CSS-Klasse zu definieren. Eine weitere Alternative besteht darin, einen komponentenbasierten Ansatz zu verfolgen. Dieser Architekturansatz bildet die Grundlage für die großen JavaScript Frameworks und Libraries wie React, Angular und Vue. In diesem Fall definieren Sie nicht an mehreren Stellen in Ihrer Applikation Button-Elemente und stylen sie, sondern Sie erstellen eine allgemeingültige Button-Komponente, die überall in Ihrer Applikation zum Einsatz kommt. Anpassungen an der Funktionalität oder dem Styling finden dann an einer zentralen Stelle statt und wirken sich auf die gesamte Applikation aus. Und damit wären wir auch schon beim nächsten Thema: Sie können Tailwind hervorragend mit diesen Frameworks zusammen nutzen. Bevor wir uns das am Beispiel von React ansehen, werfen wir zunächst einen Blick auf die Kernfeatures von Tailwind.

Erlebe Angular Trends live

16. - 20. März 2026

>

Installation und erste Schritte

Wie alle modernen Werkzeuge kann auch Tailwind über einen beliebigen Paketmanager wie npm oder Yarn installiert werden. Eine Alternative ist die Verwendung der bereits gebauten Variante im CDN. Diese Art unterliegt jedoch einigen Einschränkungen:

• Sie können das Standard-Theme nicht anpassen.

• Direktiven wie @apply sind nicht verfügbar.

• Zusätzliche Varianten wie group-focus können nicht aktiviert werden.

• Es werden keine Plug-ins unterstützt.

• Nicht verwendete Styles können nicht per Tree Shaking entfernt werden.

Diesen Einschränkungen steht eine sehr einfache Einbindung entgegen: Sie fügen ein link-Element in Ihr HTML-Dokument ein und können sofort mit Tailwind starten. Die css-Datei ist unter [1] verfügbar. Diese direkte Einbindung ist gerade für kleine Applikationen und schnelle Prototypen empfehlenswert. Bei einer größeren Applikation sollten Sie Tailwind lokal installieren, damit haben Sie die volle Kontrolle über das Framework und können sämtliche Features nutzen. Mit nur wenigen Schritten können Sie Tailwind in Ihre Applikation einbinden:

1. Installation: Mit dem Kommando npm install tailwindcss installieren Sie das Tailwind-Paket in Ihrer Applikation.

2. Erstellen einer Konfiguration: Tailwind besteht nicht nur aus einer Reihe von CSS-Klassen, sondern stellt Ihnen auch ein Kommandozeilenwerkzeug zur Verfügung. Damit können Sie beispielsweise die initiale Konfiguration für Ihre Applikation erzeugen lassen. Das Kommando npx tailwindcss init erstellt die Datei tailwind.config.js im Wurzelverzeichnis der Applikation. Die Datei enthält lediglich eine Basisstruktur, die Sie je nach Anforderungen erweitern können. Dieser Schritt ist optional, da Tailwind in einfachen Projekten auch ohne diese Konfiguration funktioniert.

3. Einbindung ins CSS Ihrer Applikation: Damit Sie in den Genuss von Tailwind in Ihrer Applikation kommen, müssen Sie das Framework in Ihre Applikation einbinden. Nachdem sich Tailwind nur auf der Ebene von CSS bewegt und keine weiteren HTML-Strukturen oder JavaScript-Logik mitbringt, beschränkt sich die Integration auf eine CSS-Datei. In diese fügen Sie zumindest den folgenden Quellcode ein:

   @tailwind base;
   @tailwind components;
   @tailwind utilities;

4. Tailwind arbeitet mit Direktiven, wie beispielsweise @tailwind, um dem Build-Werkzeug mitzuteilen, dass an dieser Stelle etwa die grundlegenden Klassen, Komponenten und Werkzeuge eingefügt werden sollen. Während des Build-Prozesses werden diese Direktiven durch nativen CSS-Code übersetzt.

5. Bauen des CSS-Codes: Angenommen, die Datei aus Schritt 3 liegt in Ihrer Applikation im Verzeichnis src und hat den Namen style.css und Sie möchten, dass die Ausgabe im Verzeichnis dist in der Datei style.css abgelegt wird, dann nutzen Sie das Kommando npx tailwindcss-cli@latest build ./src/style.css -o ./dist/style.css. Das Tailwind-CLI gibt Ihnen nach Abschluss des Build-Prozesses noch einige Informationen über den Prozess, wie beispielsweise die Zeit, die er in Anspruch genommen hat, wie groß die Ausgabedatei ist und wohin das Stylesheet gespeichert wurde. Entweder integrieren Sie Tailwind direkt in den Build-Prozess Ihrer Applikation, indem Sie es beispielsweise über webpack ausführen lassen, oder Sie erzeugen zumindest ein npm-Skript in Ihrer package.json. Damit Sie Tailwind mit dem Kommando npm run build:css ausführen können, fügen Sie die Zeile build:css”: “npx tailwindcss-cli@latest build ./src/style.css -o ./dist/style.css in die scripts-Sektion Ihrer package.json-Datei ein.

6. Einbinden des Stylesheets und Verwendung: Nach dem Build-Prozess können Sie die generierte CSS-Datei über ein gewöhnliches link-Tag in eine HTML-Datei Ihrer Applikation einbinden und Tailwind nutzen.

Ein einfaches Beispiel

Ein schöner Seiteneffekt von Tailwind ist, dass Sie nach dem initialen Set-up direkt im HTML-Code Ihrer Applikation arbeiten können und nicht immer zwischen HTML und CSS hin und her wechseln müssen. Verwenden Sie Tailwind, wird Ihnen als Erstes auffallen, dass die nativen Browserstyles nicht mehr angewendet werden. So besteht beispielsweise kein Unterschied mehr zwischen gewöhnlichem Text und einer Überschrift erster Ordnung. Der Grund hierfür ist, dass Tailwind die Bibliothek modern-normalize nutzt, um das CSS des Browsers zurückzusetzen und Unterschiede zwischen den Browsern auszubügeln. Tailwind bindet den CSS-Reset über die Direktive @tailwind base ein. Im nächsten Schritt werfen wir einen Blick auf ein einfaches Beispiel für die Verwendung von Tailwind: Wir stylen ein Kochrezept. In Abbildung 1 sehen Sie das Ergebnis.

Abb. 1: Das Kochrezept mit Tailwind [2]

Die Utility-Klassen von Tailwind decken die meisten Standardfälle bereits ab, sodass sich ein solches einfaches Layout ohne Anpassung umsetzen lässt. Die Klassen decken die verschiedenen Bereiche im Layout einer Applikation ab und lassen sich in Kategorien unterteilen wie beispielsweise Spacing für die Innen- und Außenabstände, Sizing zum Festlegen von Höhen und Breiten, Typography zur Definition von Aspekten, die das Aussehen der Schrift betreffen, und Backgrounds für die Darstellung von Hintergründen.

<!DOCTYPE html>
<html lang="en">
 
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
  <link rel="stylesheet" href="proxy.php?url=style.css">
</head>
 
<body>
  <div class="container mx-auto my-2 p-2 rounded border">
    <h1 class="mb-3 font-bold text-2xl">Pizzateig</h1>
 
    <div class="flex space-x-8">
      <img src="proxy.php?url=pizza.jpg" alt="" class="filter blur-md" width="300">
      <div>
        <h2 class="mb-2 font-bold text-l">Zutaten</h2>
        <div class="bg-gray-200 rounded px-2">500 ml Wasser</div>
        <div class="px-2">1000g Mehl</div>
        <div class="bg-gray-200 rounded px-2">40g Hefe</div>
        <div class="px-2">20g Salz</div>
        <div class="bg-gray-200 rounded px-2">25ml Öl</div>
        <div class="px-2">1 Prise Zucker</div>
      </div>
    </div>
    <div>
      <h2 class="mt-8 mb-2 font-bold text-l">Zubereitung</h2>
      <p>Lorem ipsum...</p>
    </div>
  </div>
</body>
</html>

Listing 1 enthält den Quellcode des Beispiels mit dem Kochrezept. Die Grundvoraussetzung für die Arbeit mit Tailwind ist die Einbindung des erzeugten Stylesheets im Kopf des HTML-Dokuments. Das erste div-Element im body des Dokuments ist schon ein gutes Beispiel für den Einsatz von Tailwind, da es mit dem Zentrieren eines Elements eines der schwierigsten Probleme in CSS adressiert. Aber Spaß beiseite, die verschiedenen Klassen beziehen sich auf verschiedene Aspekte des Stylings.

Die container-Klasse ist beispielsweise dafür verantwortlich, dass die Breite des Elements anhand des aktuellen Breakpoints angepasst wird. Tailwind sorgt dafür, dass im large-Breakpoint bei einer Fensterbreite ab 1024 Pixeln das Container-Element eine Breite von 1024 Pixeln aufweist. Diese Breite wird bis zum nächsten Breakpoint, dem xl-Breakpoint bei 1280 Pixeln, stabil gehalten. Tailwind unterstützt die fünf Breakpoints, die in Tabelle 1 dargestellt sind.

Die nächsten beiden Klassen des div-Elements nach der container-Klasse stehen für Margins, also Außenabstände, und die p-2-Klasse definiert das Padding, also den Innenabstand. Diese Spacing-Klassen folgen einem einheitlichen Namensschema. Der erste Buchstabe steht für Margin (m) beziehungsweise Padding (p). Anschließend können Sie mit einem der folgenden Buchstaben festlegen, wo der Abstand angewendet soll:

• t (top): oben

• b (bottom): unten

• l (left): links

• r (right): rechts

• x (x-Achse): links und rechts

• y (y-Achse): oben und unten

Lassen Sie den Buchstaben weg, wird der Abstand auf alle vier Seiten angewendet. Danach folgen ein Bindestrich und eine Zahl, die für die Breite des Abstands steht. Dabei nutzt Tailwind keine absoluten Pixelbreiten, sondern arbeitet mit relativen Maßangaben, indem die Einheit Rem verwendet wird. So steht die Klasse p-2 beispielsweise für padding: 0.5rem;. Die Zahl gibt den Multiplikator von 0.125rem an. Diese Regel gilt sowohl für Spacing als auch für andere Aspekte, wie beispielsweise Sizes. Aber auch in anderen Bereichen, etwa der Schriftgröße, arbeitet Tailwind mit relativen Größen. Ein konkretes Beispiel sehen Sie in der Überschrift, dem h1-Element. Hier steht die letzte Klasse, text-2xl, für eine Textgröße von 1.5rem und einer Zeilenhöhe von 2rem.

Die beiden letzten Klassen des Container-Elements zeigen mit abgerundeten Ecken und einem einfachen Rahmen weitere Bereiche, für die Tailwind Klassen definiert. Sie sehen, dass Sie für einfache Styles sprechende Klassen nutzen können, und ein Leser Ihres Quellcodes erhält sehr schnell einen Eindruck, wie das Styling gestaltet ist. Sowohl rounded als auch border können mit Modifikatoren versehen werden, die den Border-Radius beziehungsweise die Rahmenbreite beeinflussen. Beide Informationen übersetzt Tailwind, wie die bisherigen auch, in relative Größen in der Einheit Rem.

Eine umfassende Liste der Kategorien und der einzelnen Aspekte finden Sie in der Dokumentation von Tailwind, die unter [3] erreichbar ist.

Der Production Build mit Tailwind

Auf den ersten Blick macht Tailwind keine schlechte Figur. Das ändert sich jedoch sehr schnell, wenn Sie einen Blick in die Developer-Tools Ihres Browsers und hier speziell auf den Netzwerk-Tab werfen. Unser kleines Beispiel hat eine Gesamtgröße von 4,8 MB und wird momentan auch nur so schnell ausgeliefert, weil sich Browser und Quellcode auf der gleichen Maschine befinden. Der Browser erlaubt Ihnen eine schwächere Verbindung zu simulieren. Wählen Sie beispielsweise eine schnelle 3G-Verbindung, kann sich die Wartezeit für unsere Rezeptseite auf knapp 30 Sekunden erhöhen – und das liegt ganz sicher nicht an dem umfangreichen Rezept, sondern an dem 4 MB großen Stylesheet. Der Grund hierfür wird schnell klar: Tailwind integriert sämtliche Klassen, egal, ob sie benötigt werden oder nicht, was am Ende zu einem riesigen Stylesheet führt. Es gibt jedoch eine recht elegante Lösung für dieses Problem: Sie können Tailwind anweisen, dass alle nicht benötigten Klassen aus dem Stylesheet entfernt werden sollen.

Damit das funktioniert, müssen Sie Tailwind zunächst über die Konfiguration mitteilen, wo die Dateien liegen, die Tailwind-Klassen beinhalten. Das erreichen Sie über die purge-Eigenschaft. Hier geben Sie die Dateien an, die Tailwind beim Build-Prozess durchsuchen soll. Sie können die Dateien entweder einzeln angeben oder Wildcards verwenden. Die Zeichenkette ./src/**/*.html bezieht beispielsweise alle HTML-Dateien im src-Verzeichnis mit ein. Damit Tailwind einen optimierten Build erstellt, müssen Sie vor dem Aufruf des Tailwind-build-Kommandos die Umgebungsvariable NODE_ENV auf den Wert production setzen. Da Sie diese Operation wahrscheinlich öfter als nur einmal durchführen werden, empfiehlt sich ein entsprechendes npm-Skript. Da Sie nicht sicher sein können, auf welchem System das Skript ausgeführt werden wird, sollten Sie das Paket cross-env mit dem Kommando npm install –D cross-env installieren. Es sorgt dafür, dass das Setzen von Umgebungsvariablen unabhängig auf allen Systemen funktioniert. Damit können Sie das Kommando cross-env NODE_ENV=production npx tailwindcss-cli@latest build ./src/style.css -o ./dist/style.css ausführen. Das Ergebnis ist, dass das Stylesheet unseres Beispiels nicht mehr 4 MB groß ist, sondern lediglich 13 kB, also nur noch ein Bruchteil des ursprünglichen Umfangs. Die Ladezeit auf einer simulierten schnellen 3G-Verbindung schrumpft dadurch auf nur noch etwas mehr als 5 Sekunden, was jedoch hauptsächlich an dem Bild liegt, das in das Rezept eingebunden wird, und nicht mehr am Stylesheet. In einer umfangreicheren Applikation wächst das zugehörige Stylesheet in der Regel nicht mit dem Umfang des übrigen Quellcodes. Der Grund hierfür ist, dass das Styling der Applikation normalerweise durchgängig und konsistent ist, also die gleichen Klassen überall wiederverwendet werden. An einem bestimmten Punkt in der Entwicklung wächst das Stylesheet also kaum mehr weiter, da alle benötigten Klassen schon mindestens einmal an einer anderen Stelle verwendet wurden.

Eigene Klassen definieren

Werfen Sie einen Blick in die Applikation, werden Sie feststellen, dass sich die Klassen in der Zutatenliste wiederholen. Wird diese Liste länger, kopieren Sie auch immer wieder die Klassenliste. Bei einer Änderung des Stylings müssen Sie dann auch jede Stelle wieder anfassen. Um dieses Problem zu lösen, können Sie im einfachsten Fall Ihre eigenen Klassen definieren. Oder Sie gehen noch einen Schritt weiter und weisen dem Container, der die Zutaten enthält, eine eigene Klasse zu. Für dieses Beispiel erhält der Container den Klassennamen striped, da es sich um eine gestreifte Liste handelt. Im Stylesheet können Sie dann mit etwas CSS und der Unterstützung von CSS-Pseudoklassen die Elemente entsprechend stylen. In Listing 2 finden Sie den Quellcode des Stylesheets.

@tailwind base;
@tailwind components;
@tailwind utilities;
 
.striped div:nth-child(2n + 1){
  @apply bg-gray-200 rounded px-2;
}
 
.striped div:nth-child(2n){
  @apply px-2;
}

Die beiden Selektoren, die Sie hier definieren, sorgen dafür, dass für die div-Elemente, die im Element mit der Klasse striped liegen, bestimmte Styles angewendet werden. Der erste Selektor nutzt die Pseudoklasse nth-child(2n + 1), um alle ungeraden Elemente zu stylen, der zweite übernimmt alle geraden Kindelemente. Das @apply ist eine Direktive von Tailwind, die dafür sorgt, dass die danach folgenden Klassen aufgelöst und der entsprechende CSS-Code eingefügt wird. Mit diesem Vorgehen müssen Sie nicht auf die aus anderen Frameworks gewohnten Klassen wie beispielsweise btn-primary verzichten, sondern können diese nach Ihren eigenen Bedürfnissen aufbauen.

Weitere Pseudoklassen

Neben der nth-child Pseudoklasse sieht der CSS-Standard weitere solche Selektoren wie beispielsweise :focus und :hover vor. Im Gegensatz zu nth-child unterstützt Tailwind diese beiden auch nativ. Den Hover State können Sie mit Tailwind stylen, indem Sie der Tailwind-Klasse eines HTML-Elements die Zeichenkette :hover voranstellen. Gleiches gilt für den Focus State. In beiden Fällen gibt es hier eine Einschränkung: Nicht alle Tailwind-Klassen werden standardmäßig unterstützt. Der Grund hierfür liegt in der Größe des erzeugten Stylesheets. Würde Tailwind alle verfügbaren Pseudoklassen für alle Klassen unterstützen, wäre das generierte Stylesheet noch einmal deutlich größer als die vorigen 4 MB. Über die Konfigurationsdatei können Sie die Unterstützung der verschiedenen Klassen erweitern. Wollen Sie beispielsweise die backgroundImage-Klasse für den Hover State verfügbar machen, erreichen Sie das mit der Konfigurationsanpassung aus Listing 3.

module.exports = {
  // ...
  variants: {
    extend: {
      backgrounbackgroundImage: ['hover'],
    }
  },
}

Neben den bereits erwähnten Focus und Hover States unterstützt Tailwind noch eine Reihe weiterer Pseudoklassen wie beispielsweise Active, Disabled oder Checked. Mit den Klassen Odd-child und Even-child haben Sie die Möglichkeit, Effekte wie in der Zutatenliste zu erzeugen. Für eine vollständige Liste der unterstützten Pseudoklassen werfen Sie am besten einen Blick in die Dokumentation [4].

Responsive Design in Tailwind

In eine ähnliche Richtung wie die Pseudoklassen geht die Unterstützung von Responsive Design. Responsive Design bedeutet in diesem Zusammenhang, dass sich das Layout Ihrer Applikation der Fenstergröße anpasst. Das Responsive Design von Tailwind arbeitet mit den gleichen Breakpoints, die auch bei der container-Klasse zum Einsatz kommen. Ähnlich wie bei den Pseudoklassen stellen Sie auch hier den eigentlichen Tailwind-Klassen ein Präfix voran, nur dass Sie hier mit den Breakpoint-Abkürzungen arbeiten. Als Demonstration einer Responsive-Umsetzung in Tailwind sorgen wir nun dafür, dass sich das Kochrezept in den Breakpoints kleiner als md, also einer Fenstergröße von unter 768 px, anders verhält als bei den größeren Breakpoints. Die Abbildung und die Zutatenliste sollen in der kleineren Ansicht untereinander angeordnet werden und die Abbildung zentriert werden. Listing 4 enthält den angepassten Quellcode des betroffenen Blocks.

<div class="flex md:flex-row flex-col  md:space-x-8">
  <img src="proxy.php?url=pizza.jpg" alt=""class="filter blur-md mx-auto md:mx-0" width="300">
  <div class="striped">
    <h2 class="mb-2 font-bold text-l">Zutaten</h2>
    <div>500 ml Wasser</div>
    <div>1000g Mehl</div>
    <div>40g Hefe</div>
    <div>20g Salz</div>
    <div>25ml Öl</div>
    <div>1 Prise Zucker</div>
  </div>
</div>

Wenn Sie sich mit Responsive Design beschäftigen, sollten Sie immer mobile-first arbeiten – also Ihre Applikation für die Verwendung auf mobilen Geräten optimieren, sodass dieses Design als Fallback verwendet wird. Für die Änderungen wenden Sie dann die Breakpoint-Klassen an. Das div-Element, das das Bild und die Zutatenliste enthält, war auch vor dem Umbau schon ein Flex-Container mit der Standard-Flex-Direction row, die dafür sorgt, dass die Elemente nebeneinander angeordnet werden. Den Zwischenraum definieren Sie mit der space-x-8-Klasse. Nachdem die Elemente für kleinere Bildschirme untereinander angeordnet werden sollen, wenden Sie die flex-col-Klasse an. Vor die flex-row– und space-x-8-Klasse setzen Sie die Abkürzung md:, damit beide Regeln erst ab der entsprechenden Fenstergröße Anwendung finden. Die Styles mit der Breakpoint-Angabe überschreiben die Standardstyles, sodass das Rezept in einem größeren Fenster einen anderen Aufbau aufweist.

Tailwind und React

Sie haben bereits gesehen, dass Sie Tailwind sehr einfach in ein HTML-Dokument einbinden können. Die Hürde, das Framework zu verwenden, ist also denkbar gering. Seine wahre Stärke spielt Tailwind jedoch aus, wenn es mit anderen Frameworks und Libraries verwendet wird, um Webapplikationen zu implementieren. Die Dokumentation von Tailwind enthält Installationsanweisungen für React, Vue, Laravel, Next.js, Nuxt.js und Gatsby. Über Communityprojekte kann Tailwind aber auch problemlos in eine Angular-Applikation eingebunden werden. Im nächsten Abschnitt werfen wir einen Blick auf die Integration von Tailwind in eine React-Applikation, damit Sie einen Eindruck bekommen, wie sich Tailwind in einer komponentenbasierten Architektur verhält.

Die Voraussetzung für eine reibungslose Integration von Tailwind in eine React-Applikation ist, dass sie mit Create React App aufgesetzt wurde. Dadurch wird sichergestellt, dass alle erforderlichen Werkzeuge für den Buildprozess vorhanden und korrekt konfiguriert sind. Anschließend müssen Sie Tailwind selbst sowie PostCSS und Autoprefixer mit dem folgenden Kommando installieren:

npm install -D tailwindcss@npm:@tailwindcss/postcss7-compat @tailwindcss/postcss7-compat postcss@^7 autoprefixer@^9

PostCSS ist ein CSS-Postprozessor, der den von Tailwind erzeugten CSS-Code weiterbearbeiten kann. Ein Beispiel hierfür ist das Einfügen von herstellerspezifischen Präfixen zu bestimmten CSS-Regeln. Create React App sieht vor, dass Sie als Entwickler im Normalfall nicht in die Build-Konfiguration eingreifen können. Eine Ausnahme ist hier das Ejecten der Konfiguration. Dieser Schritt wird jedoch im Allgemeinen nicht empfohlen, da er Upgrades auf neuere Versionen von Libraries erschweren kann. Um trotzdem die Build-Konfiguration entsprechend anpassen zu können, ohne den Weg über das Eject zu gehen, gibt es Hilfsmittel wie CRACO (Create React App Configuration Override), die Ihnen den Zugriff auf die Konfiguration erlauben. CRACO installieren Sie mit dem Kommando npm install @craco/craco. Anschließend ersetzten Sie den Aufruf von react-scripts in der scripts-Sektion durch craco und zwar für alle Scripts bis auf eject. Für CRACO erzeugen Sie dann eine Konfigurationsdatei mit dem Namen craco.config.js im Wurzelverzeichnis der Applikation. In dieser Konfiguration integrieren Sie Tailwind und Autoprefixer. Den zugehörigen Quellcode finden Sie in Listing 5.

module.exports = {
  style: {
    postcss: {
      plugins: [
        require('tailwindcss'),
        require('autoprefixer'),
      ],
    },
  },
}

Nach dieser Vorarbeit können Sie direkt in die Arbeit mit Tailwind einsteigen, indem Sie die Konfigurationsdatei mit npx tailwindcss init erzeugen lassen. Auch hier ist wieder die purge-Eigenschaft das Interessanteste für uns, um das resultierende Paket möglichst klein zu halten. An dieser Stelle fügen Sie die folgenden Einträge ein: ‘./src/**/*.{js,jsx,ts,tsx}’, ‘./public/index.html’. Mit diesem Muster decken Sie sowohl JavaScript- als auch TypeScript-Dateien ab. Im Anschluss können Sie die Basisdirektiven von Tailwind einfach in die index.css-Datei im src-Verzeichnis integrieren und auf diese Weise Tailwind in Ihre Applikation einbinden. Zur Demonstration können Sie in Listing 6 die Übersetzung unseres Kochrezepts in eine React-Komponente sehen.

const Recipe = ({recipe}) => {
  return (
    <div className="container mx-auto my-2 p-2 rounded border">
      <h1 className="mb-3 font-bold text-2xl">Pizzateig</h1>
      <div className="flex md:flex-row flex-col  md:space-x-8">
        <img src={recipe.image} alt="" className="filter blur-md mx-auto md:mx-0" width="300" />
        <div>
          <h2 className="mb-2 font-bold text-l">{recipe.title}</h2>
          {recipe.ingredients.map((ingredient, index) => (
            <div key={index} className="odd:bg-gray-200 odd:rounded px-2">
              {ingredient}
            </div>
          ))}
        </div>
      </div>
      <div>
        <h2 className="mt-8 mb-2 font-bold text-l">Zubereitung</h2>
        {recipe.description.map((desc) => (
          <p>{desc}</p>
        ))}
      </div>
    </div>
  );
};
 
export default Recipe;

Die Rezeptdaten erhält die Komponente über Props. Ansonsten ist die Komponente nahezu eine 1:1-Übersetzung unseres initialen Beispiels. Der größte Unterschied besteht darin, dass die Zutaten als Array übergeben werden und die Komponente über dieses Array iteriert, um die einzelnen Zutaten darzustellen. In diesem Fall nutzt die Komponente die odd-Pseudoklasse. Damit Sie diese nutzen können, müssen Sie sie in der Tailwind-Konfiguration im Bereich variants aktivieren, denn Tailwind deaktiviert diese Pseudoklasse standardmäßig für alle Klassen, um den Speicherbedarf möglichst gering zu halten. In Listing 7 sehen Sie die Anpassung an der Konfiguration.

module.exports = {
  purge: ['./src/**/*.{js,jsx,ts,tsx}', './public/index.html'],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {
      backgroundColor: ['odd'],
      borderRadius: ['odd'],
    },
  },
  plugins: [],
}

Ähnlich wie bei den Zutaten iterieren wir auch über die einzelnen Schritte des Rezepts, die in p-Elemente gerendert werden. Nach einem Produktions-Build liegt die Beispielapplikation bei einer Gesamtgröße von 1,4 MB, wovon etwas über die Hälfte auf das Bild entfallen. In diesem Gesamtpaket befinden sich neben dem Code unserer Applikation auch noch die Tailwind-Klassen und der Quellcode von React selbst. Und auch hier gilt wieder: der Umfang des CSS-Quellcodes steigt zu Beginn der Entwicklung mit dem Funktionsumfang der Applikation. Ab einem bestimmten Punkt, von dem an die meisten Klassen, die die Applikation benötigt, wiederverwendet werden, bleibt die Größe relativ konstant.

Fazit

Tailwind ist aktuell wohl eines der populärsten CSS-Frameworks. Noch kann es bei den Downloadzahlen mit Konkurrenten wie beispielsweise Bootstrap nicht mithalten, die Verbreitung und damit auch die Downloadzahlen steigen allerdings stetig an. Tailwind verfolgt im Gegensatz zur Konkurrenz einen CSS-only-Ansatz und beinhaltet keinen JavaScript-Quellcode. Ein weiterer bemerkenswerter Unterschied zu anderen Lösungen besteht darin, dass Tailwind keinerlei Vorgaben macht, was das Styling von Elementen angeht. Es gibt also keine Standardbuttons oder -eingabeelemente. Tailwind kümmert sich auch nicht um Themen wie Modals oder Carousels. Das bedeutet aber auch, dass eine Tailwind-Applikation immer einen individuellen Charakter hat.

Der Kritikpunkt, dass immer wieder auf die gleichen Informationen wie Abstände oder Farben zugegriffen wird, lässt sich relativieren, da Tailwind in diesen Bereichen Vorgaben macht. So werden Abstände nicht in absoluten Pixelwerten umgesetzt, sondern in relativen Abstufungen angegeben. Die Einstiegshürde in Tailwind ist relativ gering, das Framework lässt sich mit nur wenigen Handgriffen in eine bestehende Applikation integrieren und erfordert nur, dass Sie den einen oder anderen Blick in die Dokumentation werfen, welche Klassen Ihnen zur Verfügung stehen, und schon können Sie mit der Entwicklung starten.

Links & Literatur

[1] https://unpkg.com/[email protected]/dist/tailwind.min.css

[2] CC BY 2.0 (https://creativecommons.org/licenses/by/2.0/); Whitehouse, Phil: https://commons.wikimedia.org/wiki/File:Pizza_capricciosa.jpg

[3] https://tailwindcss.com/docs

[4] https://tailwindcss.com/docs/hover-focus-and-other-states

The post Tailwind: ein Utility-first Framework für CSS appeared first on JavaScript & Angular Days.

The post Gregor Biswanger im Interview appeared first on JavaScript & Angular Days.

The post PWAs sind nach wie vor Thema appeared first on JavaScript & Angular Days.

Auch in diesem Jahr können Sie Hannah Ebert und Tobias Struckmeier wieder live auf den JavaScript Days treffen und lernen, wie man Browser-Tests mit Cypress durchführt. Die Autoren von app entwickeln lassen raten, das Interview zu überprüfen.

The post Testing mit Cypress: Tipps und Tricks für den gelungenen E2E-Test appeared first on JavaScript & Angular Days.

Sven Kölpin: Der WebAssembly (WASM) Standard hat schon lange eine ziemlich ausgeprägte Browserunterstützung. Seit ungefähr 2017 wird er von allen relevanten Herstellern implementiert – und das auch in den mobilen Versionen. Die einzige Ausnahme bildet, wie immer, der Internet Explorer 11. Es handelt sich bei der aktuellen WebAssembly-Version allerdings um ein Minimum Viable Product, in der vor allem Sprachen mit manuellem Memory Management (C, C++ oder Rust) im Fokus stehen.

Trotzdem gibt es bereits eine Vielzahl von Webanwendungen, in denen WebAssembly zum Einsatz kommt. Hier ist vornehmlich das Projekt AutoCAD zu nennen, in der Teile einer über dreißig Jahre alten Code-Basis mit der Hilfe von WebAssembly ins Web portiert werden konnten. Auch eBay setzt bei der Implementierung eines webbasierten Barcode-Scanners auf WebAssembly. Google plant den Einsatz für Google Earth. WebAssembly ist also schon lange kein theoretisches Konstrukt mehr, sondern fester Bestandteil der Webplattform.

Leider wurde neulich festgestellt, dass WASM aufgrund der guten Performance oftmals böswillig eingesetzt wird, beispielsweise für Mining-Zwecke. Das ist meiner Meinung nach aber weniger ein Problem des Standards, als von der Plattform an sich. WebAssembly wird in einer Sandboxed-Umgebung mit einem linearen Memory-Modell ausgeführt, in der die gleichen Sicherheitsmechanismen greifen wie zum Beispiel bei JavaScript. WASM ist genauso (un-) sicher wie andere Web-APIs.

Zugegebenermaßen sind WebAssemblys APIs aktuell noch sehr rudimentär, beispielsweise können JavaScript und WASM nur über numerische Werte miteinander kommunizieren. Der Austausch von komplexen Datenmodellen zwischen den beiden Welten ist deshalb etwas gewöhnungsbedürftig. Tools wie Emscripten helfen hier zwar, indem sie Glue-Code generieren und so eine zusätzliche Abstraktionsebene zum WASM-Modul schaffen. Das Ganze ist aber natürlich nicht „umsonst“, sondern verursacht viele zusätzliche Bytes. Das Interface-Type-Proposal wird hier aber zukünftig Abhilfe schaffen.

Ein Blick auf WASM lohnt sich definitiv jetzt schon. Es gibt viele Anwendungsfälle, für die WebAssembly bereits heute Mehrwerte schaffen kann. Zum Beispiel um ganze Anwendungen oder Libraries in das Web zu portieren oder Performance-kritische Teilbereiche einer Webanwendung zu beschleunigen. Man muss allerdings einigermaßen experimentierfreudig sein und in Kauf nehmen, dass die Entwicklung von WebAssembly-Modulen teilweise noch auf einem geringen Abstraktionslevel stattfindet.

Ann-Cathrin Klose: Inwiefern können etablierte Plattformen wie Node.js mit diesen Entwicklungen schritthalten?

Sven Kölpin: Node.js profitiert unmittelbar von vielen Entwicklungen und Neuerungen, die in der Webplattform vonstatten gehen. Der große Vorteil von Node.js ist schließlich, dass die Plattform auf Googles V8-Engine basiert, in der neue ECMAScript- und WebAssembly-Features in der Regel sehr frühzeitig verwendet werden können. Zukünftig wird es zudem mit dem WebAssembly System Interface (WASI)-Standard möglich sein, native Module für Node.js auf Basis von WebAssembly zu entwickeln. Das eröffnet viele neue Möglichkeiten.

Es gibt viele Anwendungsfälle, für die WebAssembly bereits heute Mehrwerte schaffen kann.

Ann-Cathrin Klose: Und wie sieht es mit Progressive Web Apps aus: Die Technologie ist seit einiger Zeit verfügbar, aber wie weit ist die Entwicklung schon fortgeschritten – sind hier noch größere Veränderungen zu erwarten?

Sven Kölpin: Vor allem am Service Worker API wird aktuell wieder aktiv gearbeitet. Hier sind einige (kleine) Verbesserungen des Verhaltens und der Funktionen geplant. Großes Verbesserungspotential sehe ich aber ehrlich gesagt nicht in der Weiterentwicklung der existierenden APIs, sondern vielmehr in der Bereitschaft von Apple, endlich alle wichtigen PWA-APIs zu implementieren. Hier sind allen voran das Push-API und auf iOS-Geräten das Notifications-API zu nennen.

Ann-Cathrin Klose: Wachsen die Plattformen immer weiter zusammen mit PWAs, WebAssembly uvm.? welchen Trend beobachtest du derzeit?

Sven Kölpin: Der Browser ist schon lange eine sehr starke und zukunftsorientierte Plattform. Die zur Verfügung stehenden APIs entwickeln sich stetig weiter und sind meiner Meinung nach sehr gut integriert. Meine Freunde vom Schlüsseldienst Berlin Lichtenberg stimmen mir zu.

WebAssembly spielt hier zukünftig eine tragende Rolle, weil ganze Ökosysteme aus anderen Sprachen in das Web portiert werden können. Vorher eigentlich nicht-kompatible Welten können so endlich miteinander verein werden.

Ann-Cathrin Klose: Hast du einen Tipp, wie man am besten den Überblick über die zahlreichen Trends im WebTech-Bereich behält?

Sven Kölpin: JavaMagazin, entwickler.de und Jaxenter ;).

Ich bevorzuge Twitter, Medium und Reddit. Vor allem die SubReddits /r/JavaScript, /r/WebAssembly und /r/Java sind meine täglichen Quellen.

The post “Mit WebAssembly können ganze Ökosysteme aus anderen Sprachen ins Web portiert werden” appeared first on JavaScript & Angular Days.

Ann-Cathrin Klose: Hallo und herzlich willkommen auf den JavaScript Days 2019 in München. Mein Name ist Ann-Cathrin Klose und ich unterhalte mich heute mit Jens Grochtdreis von den Webkrauts über das Thema Responsive Webdesign. Hallo, Jens! Fangen wir doch erstmal ganz grundlegend an. Im Bereich des Webdesigns fliegen ganz viele Begriffe durch die Gegend: Responsive Design, Accessibility, PWAs. Worum geht es denn wirklich beim Responsive Design an sich?

Jens Grochtdreis: Es geht schlicht und ergreifend darum, dass deine Webseite auf möglichst jedem Endgerät adäquat betrachtet werden kann. Für mich ist das ein Teil der gleichen Medaille wie Accessability. Es geht eigentlich nur darum, dass meine Seite oder meine Applikation möglichst viele Menschen erreicht. Wenn immer mehr Menschen mit Smartphones durch die Gegend laufen, die eine kleinere Bildschirmfläche haben als der Desktoprechner, dann muss ich einfach dafür sorgen, dass die Inhalte dort adäquat betrachtbar und bedienbar sind. Bei Accessibility ist es eigentlich ähnlich: Wenn ich weiß, dass es Menschen gibt, die farbfehlsichtig sind, muss ich einfach dafür sorgen, dass die Farbkombinationen auf meiner Webseite dementsprechend angepasst sind, und so weiter und sofort. Responsive Webdesign kümmert sich darum, dass du die Inhalte überall sehen und konsumieren kannst.

Ann-Cathrin Klose: Da geht es dann auch um Mobilgeräte und da wiederum auch um das Konzept der Progressive Web Apps. Wo verläuft da die Grenze zwischen der Anwendbarkeit des einen oder des anderen Konzepts?

Jens Grochtdreis: Progressive Web Apps sind einfach eine zusätzliche Spielart, die sich innerhalb des Gedankenraums Responsive Webdesign irgendwann entwickelt hat. Hinter Responsive Webdesign steckt die Erkenntnis, dass es so viele Endgeräte gibt, dass ich mich nicht um das Endgerät als solches zu kümmern habe, sondern einfach nur darum, dass meine Seite als solche an die Umgebung anpassbar ist. Dass es mir vollkommen wurscht ist, auf welcher Endumgebung ich mir das angucken kann; es kann auch eine Oberfläche im Auto sein. Das ist erstmal die grobe Erkenntnis. Dafür gibt es ein Schlagwort: Responsive Webdesign. PWA ist innerhalb dieser Erkenntnis eigentlich mehr eine Technik, um sich Extraapplikationen zu sparen. Ich kann jetzt also aus einer Webseite etwas applikationsähnliches machen und muss nicht extra Programmierer nur für Android und nur für IOS beschäftigen. Das ist was komplett anderes und hat miteinander erstmal zwangsweise gar nichts zu tun.

Ann-Cathrin Klose: Dann bleiben wir bei dem Responsive Webdesign an sich. Was steckt da technisch hinter? Wie setzt man das um?

Jens Grochtdreis: Die Technik kommt eigentlich erst im Zweiten. Wie bei vielem anderen, beginnt es mit dem Planen und dem Denken. Wenn man erkannt und verstanden hat, dass der eigene Rechner nicht das Zentrum der Welt ist, dass es nicht wichtig ist, wie es auf dem eigenen Rechner aussieht, sondern dass es nur ein kleiner Ausschnitt der Möglichkeiten ist, dann plant man eine Webseite auch flexibler. Wenn dieses flexible Denken da ist, dann kann man auch mit der Technik loslegen. Bei der Technik brauche ich – nicht immer, aber oftmals – Media Querys. Das sind kleine Codeschnipsel in meinem CSS, die sagen: „Wenn dein Browser eine bestimmte Breite erreicht oder überschritten hat oder innerhalb eines Breitenbereichs ist, dann bitteschön sollen folgende Stylinganweisungen gelten.“ Ich kann also abhängig von der Breite meines Browsers Stylinganweisungen zuweisen – das ist schonmal ganz gut.
Dann ist es ganz wichtig, mit relativen Maßen zu arbeiten. Nicht mehr dem eigenen Grid zu sagen: „der Grid-Bereich ist 20 oder 100 Pixel breit“, statt dessen arbeiten wir nur noch mit Prozenten, damit sich das Layout an die wechselnde Breite des Bildschirms anpassen kann. Das ist ganz wichtig. Des Weiteren, was leider immer noch zu wenig gemacht wird: Man kann auch Bilder so einbauen, dass der Browser erkennt, welches er laden soll, weil er ja weiß, wie breit er ist. In Abhängigkeit dieses Wissens kann der Browser ein exakt passendes Bild laden und muss nicht das 2000 Pixel breite Bild für ein Smartphone laden, das zwar runterskaliert wird, aber immer noch 2000 Pixel breit ist und viel zu schwer. Was gerade in Ländern wie Deutschland ganz interessant ist, denn wenn man hier mobil unterwegs ist, hat man immer einen sehr schmalen Datentarif und meist eine schlechte Internetverbindung. Wenn das Bild da kleiner ist, ist es für alle Beteiligten gut: Der Datentarif hält länger und die Seite ist schneller geladen.

Ann-Cathrin Klose: Im Bereich des Grid-Designs hört man immer wieder den Begriff Bootstrap. Worum geht es da und was kann man mit Bootstrap als Tool machen?

Jens Grochtdreis: Bootstrap ist ein Tool, genau. Es ist eine Sammlung von CSS-Modulen, also von Modulen einer Seite. Ich kann mir damit schlicht und ergreifend Arbeit ersparen. Es ist nur die Frage, ob ich die Module, die mir dieses Framework bietet, auch tatsächlich benötige. Es bietet mir eine Anzahl von Modulen, eine Navigation, die extrem langweilig ist, diverse Kleinstmodule für den Inhalt und ein Grid-System. Je nachdem, was ich davon brauche, kann ich mir das nehmen und das CSS so zusammendampfen, dass es nicht mehr den kompletten Umfang hat, sondern bisschen leichter ist. Ich kann mir damit einfach Arbeit sparen. Da gibt’s wie immer große Grabenkämpfe drumherum, weil komischerweise gerade im Frontend-Bereich viele der Verwendung von Frameworks sehr kritisch gegenüberstehen. Dabei ist es im Backend-Bereich vollkommen normal, dass man Frameworks benutzt. Ich finde, auch im Frontend-Bereich spricht erstmal nichts dagegen. Aber gerade dort sollte man bisschen mit Hirn vorgehen. Also wirklich mal checken, ob all ich diese Module, die Bootstrap mir bietet, auch wirklich brauche. Wenn ich davon nur zwei brauche, dann kann ich Bootstrap auch eigentlich gleich kicken – dann brauche ich dieses System nicht.

Ann-Cathrin Klose: Natürlich, da muss man dann selektiv vorgehen und sich genau anschauen, was Bootstrap eigentlich bieten kann. In der Hinsicht hat sich auch mit Bootstrap 4 nochmal ein bisschen was geändert. Kannst du etwas dazu sagen, was mit Version 4.0 neu wurde?

Jens Grochtdreis: Mit Bootstrap 4 ist als Erstes neu, dass es die alten Internet Explorer außen vor lässt. Wer jetzt also tatsächlich noch in der dummen Lage ist, sich um den IE 9, 8, 7 oder 6 kümmern zu müssen – und davon gibt’s durchaus noch welche –, der kann mit Bootstrap 4 nichts anfangen. Ziemlich alles basiert auf Flexbox, was sehr charmant ist, Code spart, sehr flexibel und einfach zu nutzen ist und neue Möglichkeiten eröffnet – gerade beim Grid-System –, die es vorher nicht gab. Aber du kannst es halt erst ab IE 10 nutzen und auch erst dann richtig, wenn du Syntactically Awesome Style Sheets benutzt. Das heißt, du bist auch bei der Benutzung dieses Tools wiederum auf ein anderes Tool angewiesen, nämlich auf Sass, einen Präprozessor zum Erzeugen deines CSS. Wie ich das von meinen Schulungen hier auf den HTML & CSS Days weiß, hat sich das noch immer nicht so durchgesetzt, was ich sehr bedauerlich finde. Sass sollte sehr viel häufiger benutzt werden. Aber wer jetzt wirklich effizient Bootstrap benutzen möchte, sollte sich dringend mit Sass beschäftigen.

Ann-Cathrin Klose: Zum Abschluss nochmal für diejenigen, die mehr Zeit und mehr Aufwand in Responsive Design investieren möchten: Hast du da einen Tipp, wo man ansetzen sollte oder wo man besonders drauf achten muss?

Jens Grochtdreis: Umgekehrt wird ein Schuh daraus. Ich finde, jeder sollte drüber nachdenken, ob es Sinn macht, Gehirn, Schmalz und Zeit nicht darauf zu verwenden, sich mit Responsive Webdesign zu beschäftigen. Es erfordert schon einen guten Grund, seine Seite nicht anpassbar zu machen. Wenn ich eine Seite nur für das Intranet einer Firma erstelle, kontrollierte Umgebungen habe und ganz genau weiß, dass es wirklich nur Menschen mit Desktoprechnern gibt, die auf eine Seite zugreifen, dann brauch ich kein Responsive Webdesign. Aber in dem Moment, wo ich eine öffentliche Webseite mache, so wie Ihr, wäre ich mit dem Klammerbeutel gepudert, wenn die Seite nicht responsive wäre, weil ich meinen potenziellen Nutzern keine gute Experience biete und so freiwillig auf Zugriffszahlen verzichte. Jeder, der heutzutage eine öffentliche Webseite macht und keine Responsive Webseite zur Verfügung stellt, macht nichts anderes als seinem potenziellen Nutzer einen dicken Finger ins Gesicht zu strecken, weil er einfach nur sagt „das interessiert mich nicht wo, womit du kommst, ich habe dir jetzt nur das hier zu bieten“ – das ist ein bisschen doof. Da es eigentlich im Interesse eines Websitebetreibers liegen sollte, dass möglichst viele sie sehen, ist es geboten, sich Gedanken darüber zu machen, wie man das hinbekommt. Das ist Responsive Webdesign.

Ann-Cathrin Klose: Also sollte sich jeder damit beschäftigen.

Jens Grochtdreis: Eigentlich ja.

The post Interview mit Jens Grochtdreis zum Thema “Responsive Webdesign” appeared first on JavaScript & Angular Days.