Boehrsi.de - Blog

Vor ein paar Tagen wurde ich in den Kommentaren gefragt wie ich zu Bulma kam, bzw. wie ich es im Vergleich zu anderen Frameworks sehe. In diesem Kontext vorweg schon einmal die Information, ich habe mir die Frameworks allgemein und oberflächlich angeschaut, kam zu Bulma und mache dort nun meinen ersten kompletten Tests, inklusive Implementierung.
Daraus ergibt sich, dass ich die anderen Frameworks bis dato noch nicht aktiv genutzt habe und meine Aussagen hier auf meinen Ersteindrücken basieren. Für mich waren in diesem Rahmen vor allem die folgenden Punkte relevant, bzw. bildeten die Anforderungen.

1. Dokumentation

Absolute Priorität hatte bei meiner Evaluation die Dokumentation. Ein Getting Started Guide ist immer gut, aber auch eine Vorstellung der Kernfunktionen muss vorhanden sein. Ergänzt werden sollte das ganze durch kleine Beispiele und vielleicht sogar ein paar komplexere Real-World Beispiele.

2. Lokale Nutzung ohne großen Aufwand

Ich hoste einen gewissen Teil meiner Daten gerne selbst und ein CSS Framework möchte man vielleicht auch anpassen. Vor allem bei den initialen Tests ist die anpassbare lokale Nutzung extrem wichtig für mich. Ich bin außerdem App- und Serverentwickler und habe entsprechend nur marginale, nicht sonderlich befriedigende, Begegnungen mit NPM und Konsorten gemacht. Aus diesem Grund möchte ich kein umfangreiches Build Environment mit diversen Tools, Abhängigkeiten und den damit verbundenen Problemen aufsetzen müssen, um ein möglichst pures CSS Framework zu nutzen. Vor allem wenn man sieht das es auch ohne geht.

3. Aktivität

Ein CSS Framework muss vielleicht nicht täglich aktualisiert werden, aber für mich ist es wichtig zu sehen, dass das ganze Projekt noch aktiv ist und im Falle von Problemen eventuelle Fragen und Issues auch bearbeitet werden können.

4. Kein / wenig JavaScript

CSS kann viel und mit HTML 5 in Verbindung mit CSS 3 sogar sehr viel. Entsprechend bin ich nicht der Meinung JavaScript sollte mir durch das UI Framework meiner Wahl aufgezwungen werden. Möchte ich JavaScript nutzen ist das absolut okay, aber nicht zwangsweise, nur weil eine Animation auf einem Button mit CSS Transitions nicht flexibel genug zu sein scheint.

5. Lizenz

Hier finde ich es durchaus gut wenn das Framework Open Source ist, denn dann kann man selbst Hand anlegen und Dinge tiefgehender verstehen, sofern man die möchte. Dieser Bereich hat für mich zwar nur sekundäre Relevanz bei der Entscheidung, ist aber durchaus ein erwähnenswerter Punkt für mich.

6. Website des Frameworks

Die Website eines CSS Frameworks sagt meiner Meinung nach das eine oder andere über das eigentliche Framework aus. Ich lege hier Wert auf ein aufgeräumtes Layout und gut zu findende Informationen. Es hilft mir nichts einen coolen One-Page-Scroller zu haben, der mir Null Informationen über das Framework vermittelt.

Diese Anforderungen sind die Basis für das folgende Ausschlussverfahren. Wobei ich etwas gruppieren muss, da die News sonst zu sehr ausartet. Im Folgenden führe ich verschiedene Bereiche auf, weswegen konkrete Frameworks für mich aus dem Rennen waren.

Build Environments / JavaScript und die Komplexität

Diverse der folgenden Frameworks, wie z.B. Tailwind open_in_new oder Vanilla open_in_new wollen gerne gebaut werden. Hier kann man mit NPM anfangen oder direkt Docker an den Start bringen. Ich verstehe dies bei so komplexen Systemen durchaus, es entspricht aber nicht meinem Einsatzzweck. Ich möchte schnell und einfach mit meinem CSS Framework arbeiten und wenn ich dafür zunächst einen Tag lang ein Build Environment aufsetzen muss, widerspricht das diesem Zweck komplett. Dies war kein kompletter Ausschlussgrund, aber definitiv ein Minuspunkt, sofern ein Framework von derartigen Setups abhing.

Keine Wartung

Für mich ist es wie erwähnt wichtig eine aktive Software zu nutzen und leider gibt es auch bei den CSS Frameworks ein paar inaktive. Dazu gehört für mich mini.css open_in_new, welches mir eigentlich gut gefiel, aber durch ein archiviertes GitHub Repository für mich sehr abschreckend wirkt. Auch Materialize open_in_new schied dadurch für mich aus, denn hier war nicht viel Aktivität zu erkennen, abseits von über 600 offenen Issues.

Zu klein

Einige Frameworks gefielen mir auf den ersten Blick gut, auch wenn sich z.B. drüber streiten lässt ob ein Framework direkt HTML Tags bearbeiten oder aber via Klassen nutzbar sein sollte. Doch für meinen Einsatzzweck fehlten einige komplexere UI Komponenten.
Ich brauche keine Allround Lösung, aber ein Set an simplen und komplexeren Grundelementen und Strukturen, da ich sonst auch komplett auf ein CSS Framework verzichten könnte. In diese Kategorie fielen für mich Pure.css open_in_new, Skeleton open_in_new und Milligram open_in_new, wobei vor allem letzteres zu Beginn zu meinen Favoriten gehörte

Zu groß

Auch wenn ich mir das eine oder andere an Komponenten wünsche, mein CSS Framework muss minified keine 500 KB groß sein. In diese Kategorie fällt z.B. Vanilla open_in_new oder Bootstrap open_in_new.
Ein Monster von einem CSS Framework, mit extrem vielen Möglichkeiten, wäre wohl eine passende Beschreibung für jedes dieser Frameworks. So interessant ich derartige Frameworks finde, mein Einsatzzweck ist durchaus minimalistisch veranlagt und dadurch wurde es mir z.B. mit Vanilla leider schnell zu viel. Ich kann mir sehr gut vorstellen, dass ein Webentwickler mit vorhandenem Build Environment und einem größeren Projekt, mit solch großen Frameworks extrem gute Ergebnisse liefern kann, doch für mich ist das leider nichts. Bulma open_in_new war für mich persönlich hier gerade so an der Grenze.

Unübersichtlich / Probleme mit der Dokumentation oder der Syntax

Wenn ich auf den ersten Blick nicht alle Informationen erhalte bin ich schnell weg. Dies gilt vor allem im großen Markt der CSS Frameworks und deswegen bin ich z.B. bei Base open_in_new schnell abgesprungen. Hier fehlten mir visuelle Komponenten, die klar machen was passiert mit welchem Code.
Bei Tailwind open_in_new war zwar alles dokumentiert und auch Beispiele gab es viele, aber hier war ich etwas vom Aufbau abgeschreckt. Alles ist dankenswerterweise extrem flexibel, aber das spiegelt sich auch in der Syntax wieder, welche für mich etwas unleserlich und anstrengend wirkt. Ausschließlich persönliche Präferenz, aber die Art und Weise wie die Klassen benannt und konkateniert werden gefällt mir schlicht nicht. Hier könnte man natürlich sagen, dass das doch kein Grund ist. Aber wenn man 20 Frameworks zur Auswahl hat, kann man sich derartige Haarspaltereien durchaus erlauben.

Aussehen der UI

Während man natürlich alles anpassen kann, gibt es eine Grundkonfiguration in den meisten Frameworks. Dabei geht es um Rahmen, Rundungen, Farben und den generellen Aufbau. In diesem Bereich hatte ich Spectre.css open_in_new und Picnic CSS open_in_new, welche mir persönlich nicht gefielen. Vor allem zu kräftige Farben oder aber unklar definierte UI Komponenten waren hier Probleme für mich.

Übersehen / vergessen

Es gibt so viele Frameworks, dass man irgendwann froh ist eines gefunden zu haben was einem gefällt. Ist es möglich das es was besser gibt? Auf jeden Fall, aber früher oder später will man ja auch anfangen die eigentliche Website zu entwickeln. Diesem Denken ist unter anderem Foundation open_in_new zum Opfer gefallen.

Als Fazit kann ich sagen, dass ich mit diesem Beitrag leider nicht den initialen Kommentar direkt beantworten kann, da ich mich mit Tailwind leider nicht technisch auseinandergesetzt habe, aber ich habe versucht euch meinen - durchaus sehr subjektiven - Entscheidungsfindungsprozess näher zu bringen und hoffe das ich dadurch zumindest eine geringe Entscheidungshilfe sein kann, falls sich auch jemand von euch die Frage nach dem passenden CSS Framework stellt.