1 Kommentar // Lesezeit: 7 min.
Nur ein weiteres Framework?
Traditionelle CSS-Frameworks wie z.B. Bootstrap, Foundation und Bulma geben vor, wie HTML-Elemente, wie Buttons, Inputs und Tooltips etc. aussehen. Es werden vorgefertigte, mit CSS gestylte UI-Komponenten geliefert. So entstehen die für das jeweilige Framework typischen Styles, die sich auf diversen Websites ausmachen lassen. Soll heißen: Design-Elemente dieser Websites gleichen einander und sehen aus wie 'von der Stange'. Bootstrap liefert beispielsweise eine Button-Komponente:
<button type="button" class="btn btn-primary">
Bootstrap
</button>Codebeispiel 1: Button Komponente von Bootstrap
Obenstehender Code erzeugt folgenden Button:
UI-Komponente 1: Button von der Bootstrap Website (Quelle: Bootstrap)
Mit Hilfe der beiden CSS-Klassen btn und btn-primary werden CSS-Eigenschaften, wie unter anderem color, background-color, border, font-size, font-weight und text-decoration festgelegt.
Utility-Klassen
Anders ist es bei Tailwind CSS: Hier werden keine fertig gestylten UI-Komponenten, wie UI-Komponente 1, bereitgestellt. Durch Utility-Klassen lassen sich vielmehr UI-Komponenten auf granularer Basis erstellen. Mit granular ist gemeint, dass durch verwendete CSS-Klassen sich einzelne Eigenschaften eines Design-Elements, wie z.B. die CSS-Attribute color, background-color, aber auch display und text-align steuern lassen. Diese CSS-Klassen werden auch Utility-Klassen genannt. Der Button aus Codebeispiel 1 lässt sich mit Tailwind CSS wie in Codebeispiel 2 implementieren:
<button type=“button“ class="rounded bg-blue-500 hover:bg-blue-700 py-2 px-4 text-white">
Tailwind
</button>Codebeispiel 2: Button-Element mit Tailwind CSS Utility-Klassen
UI-Komponente 2: Tailwind CSS Button
Mit den verwendeten CSS-Klassen rounded, bg-blue-500, hover:bg-blue-700, py-2, px-4 und text-white werden Klassen vergeben, die jeweils einen Layout-Aspekt des Buttons abbilden:
| Utility-Klasse | CSS-Style |
|---|---|
| rounded | border-radius: 0.25rem; |
| bg-blue-500 | --tw-bg-opacity: 1; |
| py-2 | padding-top: 0.5rem; |
| px-4 | padding-left: 1rem; |
| text-white | --tw-text-opacity: 1; |
Tabelle 1: Utility-Klassen und ihre CSS-Eigenschaften
Was heißt 'Utility-First'?
Diesem granularen Ansatz hat sich Tailwind CSS verschrieben: Es trägt die Bezeichnung 'utility-first CSS framework' (Quelle: Tailwind CSS). Das vorangehende, sehr einfache Beispiel dient der Veranschaulichung des Utility-First Ansatzes. Die folgende UI-Komponente und zugehörige Codebeispiele stammen von Tailwind CSS und machen die Auswirkungen auf Umfang und Stil des Codes deutlich.
UI-Komponente 3: Chat-Komponente (Quelle: Tailwind CSS)
<div class="p-6 max-w-sm mx-auto bg-white rounded-xl shadow-lg flex items-center space-x-4">
<div class="shrink-0">
<img class="h-12 w-12" src="/img/logo.svg" alt="ChitChat Logo">
</div>
<div>
<div class="text-xl font-medium text-black">ChitChat</div>
<p class="text-slate-500">You have a new message!</p>
</div>
</div>Codebeispiel 3: Umsetzung der Chat-Komponente mit Tailwind CSS (Quelle: Tailwind CSS)
Im äußeren div-Element werden beispielsweise die Klassen flex, p-6 und rounded-xl verwendet. Die Klasse flex macht aus dem div-Element eine Flexbox, p-6 fügt ihm ein padding hinzu und rounded-xl rundet die Ecken des div-Elements ab. Die oben genannten Klassen und ihre Styles sind unten in Tabelle 2 aufgeführt.
| Utility-Klasse | CSS-Style |
|---|---|
| flex | display: flex |
| p-6 | padding: 1.5rem |
| rounded-xl | border-radius: .75rem |
Tabelle 2: Beispiele von Utility-Klassen
Bei Codebeispiel 3 fällt auf, dass die UI-Komponente mit nur sechs HTML-Elementen implementiert werden kann. Allerdings wurden dafür auffallend viele Utility-Klassen, vor allem im ersten div-Element verwendet.
Klassischer Ansatz
Im Gegensatz zu dem Utility-First Ansatz werden klassischerweise Styles von HTML-Code getrennt. Die Styles werden dann in Form von CSS-Dateien mit selbst definierten Klassen, Ids und weiteren Selektoren ausgelagert. Die Chat-Komponente (UI-Komponente 3) würde mit diesem Ansatz wie in Codebeispiel 4 umgesetzt werden.
<div class="chat-notification">
<div class="chat-notification-logo-wrapper">
<img class="chat-notification-logo" src="/img/logo.svg" alt="ChitChat Logo">
</div>
<div class="chat-notification-content">
<h4 class="chat-notification-title">ChitChat</h4>
<p class="chat-notification-message">You have a new message!</p>
</div>
</div>
<style>
.chat-notification {
display: flex;
max-width: 24rem;
margin: 0 auto;
padding: 1.5rem;
border-radius: 0.5rem;
background-color: #fff;
box-shadow: 0 20px 25px -5px rgba(0, 0, 0, 0.1), 0 10px 10px -5px rgba(0, 0, 0, 0.04);
}
.chat-notification-logo-wrapper {
flex-shrink: 0;
}
.chat-notification-logo {
height: 3rem;
width: 3rem;
}
.chat-notification-content {
margin-left: 1.5rem;
padding-top: 0.25rem;
}
.chat-notification-title {
color: #1a202c;
font-size: 1.25rem;
line-height: 1.25;
}
.chat-notification-message {
color: #718096;
font-size: 1rem;
line-height: 1.5;
}
</style>Codebeispiel 4: Umsetzung der Chat-Komponente mit HTML und externem CSS-File (Quelle: Tailwind CSS)
Bei Codebeispiel 4 ist anzumerken, dass die Styles zugunsten der Übersichtlichkeit in der HTML-Datei eingefügt sind, statt in einer externen Datei. Mit dieser Darstellung werden einige Aspekte deutlich:
- wenig HTML-Code mit wenigen, selbstdefinierten CSS-Klassen
- zahlreiche, selbst definierte Styles
Zusammenfassung: Vorteile und Nachteile von Utility-First
Wer mit HTML-Markup und Coding im Allgemeinen vertraut ist, der weiß, wie müßig es sein kann, sich passende Klassennamen für Komponenten zu überlegen und sowohl die Klassennamen als auch ggf. weitere Konventionen für die Benennung im Team abzustimmen. Mit Utility-Classes fällt dieser Aufwand weg. Außerdem steigt nach der Einarbeitung in das Framework die Produktivität, weil es keine Kontextwechsel zwischen dem Coding in CSS-Files und HTML-Files gibt.
Auf der anderen Seite wirkt die Tailwind CSS Komponente durcheinander und mit Klassen überladen. Mit dem Plugin Headwind für die IDE Visual Studio Code, werden die Klassennamen der HTML-Elemente beim Speichern der Datei automatisch in eine einheitliche Reihenfolge gebracht. Namen doppelter CSS-Klassen werden zudem entfernt.
Als weiteren Nachteil von Tailwind CSS kann man anführen, dass sich bei gleichen HTML-Elementen die Utility-Klassen im Markup wiederholen. Wenn man also z. B. einen Button an verschiedenen Stellen benutzen möchte, würden sich die Klassennamen in den verschiedenen Komponenten der Anwendung wiederholen. Dies würde gegen den Coding-Grundsatz mit dem Akronym 'DRY' – Don’t Repeat Yourself – im Coding verstoßen.
Wenn der Button in Codebeispiel 2 wiederholt im Code verwendet werden soll, könnte mit Hilfe der verwendeten Template-Engine (z. B. in vue- oder jsx-Formaten) eine wiederverwendbare Komponente angelegt werden, so wie es in Codebeispiel 5 gezeigt wird.
<template>
<button class="rounded bg-blue-500 hover:bg-blue-700 py-2 px-4 text-white">
Tailwind
</button>
</template>
<script>
export default {
name: ‘Button’,
};
</script>Codebeispiel 5: vue.js Button-Komponente mit Tailwind CSS Utility-Klassen
Framework-Overhead
Als ein weiterer Nachteil von Tailwind CSS und allgemein von CSS-Frameworks ist der Overhead anzuführen. Mit Overhead ist der Code-Anteil des Frameworks gemeint, der im verwendeten production build des Frameworks (z.B. bootstrap.min.css) enthalten ist, jedoch in der Applikation nicht verwendet wird. Bootstrap bietet hier die Möglichkeit beispielsweise nur die CSS-Klassen, die für das Grid-Layout benötigt werden, einzubeziehen. Bei Tailwind geschieht dies mit Hilfe der verwendeten Konfigurationsdatei tailwind.config.js.
module.exports = {
content: ['./src/**/*.{html,js}'],
theme: {
colors: {
…
},
fontFamily: {
…
},
} Codebeispiel 6: Tailwind CSS Konfigurationsdatei
Um einen Aspekt in Verbindung mit dem Overhead zu verdeutlichen, wird lediglich eine sehr reduzierte Konfigurationsdatei als Beispiel aufgeführt. Bei der Struktur der Konfigurationsdatei handelt es sich um ein JavaScript-Objekt. Der Key content enthält ein Array, in dem alle Pfade zu HTML-Templates, JavaScript-Komponenten und allen weiteren Ressourcen aufgeführt werden, die Tailwind CSS Klassennamen enthalten. Mit Hilfe von regulären Ausdrücken sucht Tailwind in diesen Dateien nach diesen Klassen, z.B. rounded, bg-blue-500, hover:bg-blue-700, py-2, px-4. Auf diese Art gefundene CSS-Klassen werden dem generierten CSS hinzugefügt. Es wird somit sichergestellt, dass nur wirklich benötigter CSS-Code mitgeliefert wird. Der Overhead ist mit dieser Maßnahme eliminiert.
| Nachteile | Vorteile |
|---|---|
| HTML-Code kann durch Anzahl der verwendeten Klassennamen recht komplex werden. | Es kann direkt im HTML-Code gearbeitet werden, ohne Kontextwechsel zwischen CSS- und HTML-Dateien. |
| Ohne Verwendung einer Template Engine entsteht ggf. redundanter Code. | Änderungen an einem HTML-Element oder in einer Komponente können vorgenommen werden, ohne andere Elemente zu beeinflussen (no side effects). |
| Es kann Overhead entstehen, wenn im JavaScript-Objekt der Konfigurationsdatei der Key content nicht korrekt konfiguriert ist. | Nach der Einarbeitung geht die Erstellung von Benutzeroberflächen zügig von der Hand. |
Kontaktieren Sie uns!
Wir sind eine Digitalagentur, die sich auf die Entwicklung digitaler Produkte spezialisiert hat. Unsere Kernthemen sind Webseiten und Portale mit TYPO3, eCommerce mit Shopware und Android und iOS-Apps. Daneben beschäftigen wir uns mit vielen weiteren Themen im Bereich Webentwicklung. Kontaktieren Sie uns gerne mit Ihren Anliegen!
Kommentare
Joël Mai
am 08.04.2024Hey! Cooler Beitrag!
Ich mach mir seit Monaten Gedanken darüber wie ich mein Frontend Stack für TYPO3 Projekte am besten aufbaue. Bootstrap fühlt sich bisher wie ein massiver Overhead an und [...] Hey! Cooler Beitrag!
Ich mach mir seit Monaten Gedanken darüber wie ich mein Frontend Stack für TYPO3 Projekte am besten aufbaue. Bootstrap fühlt sich bisher wie ein massiver Overhead an und Custom CSS für jedes Projekt ist sehr aufwendig. Bisher fahre ich daher mit einer Art Template und Post CSS Kombi... Tailwind klingt daher sehe verlockend, aber ich Frage mich wie sinnvoll es ist in der Kombination mit Fluid und Konfigurierbarkeit des Frontend durch Redakteure :/
Anregungen? Vorschläge?