Eine Entwicklerumfrage wie die State of CSS durchzuführen ist ein mehrstufiger Prozess. Zuerst müssen die Daten gesammelt werden. Dann werden sie in eine nutzbare Form gebracht. Schließlich werden clevere Wege gefunden, sie zu visualisieren und der Welt zu präsentieren.
Aber dann, wenn sich der Staub gelegt hat und der Traffic nachlässt, kommt mein Lieblingsteil: Tatsächlich über die Daten *nachzudenken*. Durch einen genaueren Blick auf unsere Daten und die Beobachtung, wie die Community unsere Ergebnisse diskutiert hat, traten drei unerwartete Trends in den Fokus.
Aber zuerst ein paar Hintergrundinformationen für diejenigen, die mit dem Projekt noch nicht vertraut sind.
Ich begann die State of JavaScript Umfrage vor drei Jahren im Jahr 2016, um meine eigenen Unsicherheiten über die Zukunft der Webentwicklung zu beantworten. Damals grassierte die JavaScript-Müdigkeit, und ich dachte, eine umfassende Entwicklerumfrage könnte sich als Gegenmittel erweisen.

Es stellte sich heraus, dass ich einen Nerv getroffen hatte: Die erste Umfrage war sehr beliebt und unser Publikum ist seitdem jedes Jahr gewachsen, ebenso wie der Umfang der Umfrage. (Raphael Benitte, Schöpfer der Nivo.js Dataviz-Bibliothek, schloss sich mir an, um mir bei der Datenverarbeitung und -visualisierung zu helfen.) Dieses Jahr markiert zum ersten Mal, dass wir in eine neue Dimension vorstoßen, nämlich in die nicht ganz einfache Welt von CSS.

Vorhersage 1: CSS hat immer noch viel unerforschtes Terrain
Eines der Dinge, die wir mit der Umfrage quantifizieren wollten, war, wie viel von CSS noch „unerforscht“ war. Mit anderen Worten, welche CSS-Features sind Entwicklern entweder unbekannt oder sie haben sie noch nicht verwendet. Aus diesem Grund haben wir uns in unserem Features-Bereich frühzeitig auf neue CSS-Eigenschaften konzentriert, wie Shapes, Masking oder scroll-snap, anstatt auf „langweilige“ Floats oder Tabellen.
Die daraus resultierenden Daten malen ein interessantes Bild: **Es stellt sich heraus, dass CSS, wenn man es so betrachtet, von einer vertrauten Landschaft zu einem wilden, unerforschten Dschungel wird.**
Ein Vergleich von Flexbox vs. CSS Grid veranschaulicht diesen Trend gut. Während fast jeder, der von Flexbox gehört hat, es auch benutzt hat, haben nur 55% der Entwickler, die von CSS Grid wissen, es tatsächlich ausprobiert. Das ist eine große Lücke, besonders für eine Technologie, die so wichtig ist wie CSS Grid!

Oder nehmen Sie CSS Shapes: 68% der Entwickler sind sich dessen bewusst, nur 31% dieser Gruppe hat die Funktion tatsächlich genutzt.

Dies deutet auf eine große Lücke zwischen dem hin, was wir kollektiv lernen wollen, und dem, was wir tatsächlich wissen. Dieses Wachstumspotenzial ist genau das, was CSS im Jahr 2019 so aufregend macht.
Vorhersage 2: Funktionales CSS wird weiter zunehmen
Wenn Sie alt genug sind, um sich an den CSS Zen Garden zu erinnern – oder um CSS durch ihn gelernt zu haben (in diesem Fall weiß ich, wie Sie sich fühlen, mein Rücken tut weh, wenn ich morgens aufstehe) – dann mag dieser nächste Trend seltsam oder sogar geradezu falsch erscheinen.

Funktionales CSS lehnt das platonische Ideal von reinem, unbeflecktem Markup ab, das frei von Styling-Bedenken ist, und befürwortet „funktionale“ (aka „atomare“ oder „Utility“) Klassen. Denken Sie an <div class="text-red text-medium border-1">...</div>.
Die Übernahme dieses Ansatzes bedeutet, dass Sie Ihr Stylesheet nicht magisch aktualisieren und Ihr gesamtes Design ändern können, ohne eine einzige Zeile Markup zu ändern. Aber seien Sie ehrlich, wie oft passiert das sowieso? Im Vergleich zur oft theoretischen Eleganz der Zen Garden-Philosophie bieten Bibliotheken wie Tailwind und Tachyons greifbare, reale Vorteile, was erklärt, warum sie so hoch angesehen sind. Tatsächlich belegen diese die Plätze 1 und 4 in Bezug auf das Zufriedenheitsverhältnis in der Kategorie CSS-Frameworks.

Besonders Tailwind scheint an Fahrt zu gewinnen, zumindest gemessen an der Twitter-Interaktion seiner Community als Reaktion auf die Umfrageergebnisse. Da es gerade Version 1.0 erreicht hat, ist es definitiv ein Projekt, das man im Auge behalten sollte!
Vorhersage 3: Der Kampf um CSS hat gerade erst begonnen
Wenn ich mir unsere Daten ansehe, kann ich mich des Gedankens nicht erwehren, ob „JavaScript-Müdigkeit“ bald durch „CSS-Müdigkeit“ ersetzt wird.
Bei der Bewertung von Technologien ist es wichtig, nicht nur die reinen Nutzungszahlen, sondern auch die Benutzerzufriedenheit zu betrachten. Schließlich möchten Sie nicht auf den neuesten Zug aufspringen, nur um festzustellen, dass die aktuellen Insassen es kaum erwarten können, wieder abzuspringen.
Dieses Streudiagramm, das in Quadranten unterteilt ist, ist dafür perfekt geeignet. Es stellt die Nutzung der Zufriedenheit gegenüber und macht es einfach, beliebte Werkzeuge mit hoher Zufriedenheit in ihrem eigenen Quadranten zu isolieren.

Was in diesem Diagramm auffällt, ist, dass der dichteste Bereich der „Bewertungs“-Quadranten ist. Mit anderen Worten, die Technologien mit *geringer* Nutzung und hoher Zufriedenheit, die immer noch um die Vorherrschaft kämpfen. Dies ist genau der Zustand, in dem sich auch das JavaScript-Ökosystem befindet. Viele Anwärter, aber bisher wenige entscheidende Gewinner.
Das ist nicht unbedingt schlecht: Ja, es macht das Leben des durchschnittlichen Entwicklers schwerer, wenn es darum geht, das richtige Werkzeug auszuwählen, aber hey, dafür tun wir das, was wir tun! Außerdem kann Wettbewerb nur dem Ökosystem als Ganzes zugutekommen. Wenn sich der Staub gelegt hat, werden hoffentlich die bestmöglichen Optionen überlebt haben!
CSS im Jahr 2019
Insgesamt zeigt die State of CSS-Umfrage, dass dies nicht mehr das CSS Ihres Großvaters ist. Jahrelang haben wir Entwickler uns gerne über die Unzulänglichkeiten von CSS und seine mangelnden leistungsstarken Funktionen beschwert. Aber im Jahr 2019 fordert uns CSS heraus, Taten folgen zu lassen: Hier sind all die Funktionen, die Sie sich immer gewünscht haben. Was machen Sie jetzt damit?
Ich persönlich freue mich sehr darauf, noch tiefer in diese neue Welt des Stylings einzutauchen. Und natürlich, um 2020 wieder reinzuschauen, um zu sehen, welche neuen Trends wir dann finden!
Ich persönlich verstehe nicht, warum „Vorhersage 2: Funktionales CSS wird weiter zunehmen“ immer beliebter wird.
Kann mir jemand den Vorteil erklären, eine Million verschiedene Klassennamen in jedem HTML-Element zu schreiben, um jedes mögliche CSS-Eigenschaft/Wert-Paar darzustellen, ist produktiver, als einfach richtige Elementselektoren in Kombination mit gut benannten Klassen auf einer Website zu verwenden?
Was ist, wenn ich später möchte, dass jeder einzelne „h1″-Tag auf der Website mehr oberen Rand hat. Bedeutet das, dass ich eine Suche und Ersetzung auf jedem einzelnen „h1″-Tag meiner Website durchführen und die Klasse „m-top-20“ oder was auch immer mit einer Klasse wie „m-top-10“ oder etwas Ähnlichem ersetzen muss… ich verstehe es einfach nicht…
Ich bin Ihrer Meinung. Ein Kollege versucht mich immer wieder davon zu überzeugen, wie großartig Tailwind ist. Seine beste Begründung ist, dass er Leute in seinem Team hat, die keine echten Web-Experten sind und dies sie daran hindert, etwas zu vermasseln – für mich kein ausreichender Grund. Funktionales CSS erinnert mich an die schlechten alten Zeiten von font-Tags und FrontPage. Und nachdem ich Websites ändern musste, indem ich sie durchging und jeden einzelnen font-Tag und Inline-Style entfernte, möchte ich nie wieder dorthin zurückkehren.
Der einzige Bereich, in dem es funktionieren könnte, ist, wenn eine Website vorlagengesteuert ist und Sie nur wenige Vorlagen ändern müssen. Das ist für mich immer noch kein guter Grund, es nutzen zu wollen.
Es ist ein Traum auf komponentenbasierter Websites, wie ein modernes JavaScript-Projekt oder alles, was Twig/Handlebars/Blade usw. verwendet. Wenn ich meine H1 ändern möchte, bearbeite ich meine Überschriftenkomponente, und sie ändert jede Überschrift auf der Website, da sie alle auf diesen Überschriften-Partial verweisen. Wenn Ihre Website nicht auf diese Weise aufgebaut ist, wird sie für Sie überhaupt nicht funktionieren, und ich kann Ihre Skepsis verstehen.
https://frontstuff.io/in-defense-of-utility-first-css ist eine wirklich gute Lektüre zu diesem Thema.
Sobald Sie eine Komponente benötigen (damit Sie die unzähligen Klassen ändern können, die sie benötigt), um eine Überschrift auszugeben, denke ich, sind Sie im Kreis herumgekommen. Ich prognostiziere, dass Tabellen und Inline-Styles als nächstes zurückkommen werden.
Es ist ein Ergebnis von komponentenbasierter Benutzeroberfläche in Kombination mit realen Szenarien.
In der Praxis ist CSS vollständig von der DOM-Struktur abhängig. Selbst bei der Arbeit mit einem Content-Management-System, bei dem Sie das genaue Markup nicht vorhersagen können, wüssten Sie, wann ein Absatz-Tag im Vergleich zu einem Tabellen-Tag platziert wird usw. CSS Zen Garden funktionierte, weil das Markup nie geändert wurde, deshalb war es ein großartiges Testfeld, um zu demonstrieren, wie flexibel CSS ist.
Dies ist eine subjektive Beobachtung, aber ich habe auch noch nie einen Designer gesehen, der eine umfassende Änderung angefordert hat, die nicht von einer Vielzahl zusätzlicher kleinerer Änderungen begleitet wurde. (Dies liegt größtenteils daran, wie Farbton und Helligkeit zusammenwirken.) Die Realität ist, dass Sie niemals eine weitreichende Änderung an CSS vornehmen würden, ohne Ihre Arbeit zu überprüfen. Da Komponenten oft ohnehin als Ganzes gewartet werden, macht die Verwendung beschreibender Tag-Namen die Beziehung zwischen DOM und CSS offensichtlicher.
Wenn Sie jedoch KEINEN komponentenbasierter Ansatz verwenden, können allgemeinere Klassennamen für Sie von Vorteil sein.
Tailwind-Befürworter sind verwirrend. Tailwind lehnt jahrzehntelange Branchen-Best-Practices und Empfehlungen für Architektur und Programmierung ab; seine Existenz ist regressiv und kontraintuitiv zur Browser- und Gerätetechnologie.
Außerhalb der kleinen Blase der Tailwind-Befürworter und einer Handvoll fehlgeleiteter Blogger meidet die breitere Industrie es (wie im Diagramm „Zufriedenheit vs. Nutzung“ oben zu sehen).
„Besonders Tailwind scheint an Fahrt zu gewinnen, zumindest gemessen an der Twitter-Interaktion seiner Community als Reaktion auf die Umfrageergebnisse.“
Ja klar – natürlich, eine kleine Community wirkt größer, wenn sie lauter ist.
Das klingt alles gut und schön, aber der Grund, warum wir Grid und all die anderen schicken Dinge nicht benutzen, ist... das verdammte IE :/
Ältere Browser zu ignorieren mag für „Codepen-Entwickler“ (Entwickler, die nur zum Spaß und für sich selbst codieren) funktionieren, aber dort, wo ich arbeite, wird es noch ein paar Jahre dauern, bis wir Grid nutzen.
Also nein, wir sind nicht faul oder dumm, wir sind an Verträge gebunden.
Sie können IE unterstützen und trotzdem CSS Grid verwenden. Sie können CSS @supports verwenden. Sie schreiben Legacy-Code (Float oder Display Table Layout) für IE und umschließen Ihren modernen Grid-Code mit
@supports(grid: auto){ ... }. Die modernen Browser erhalten Grid und IE erhält Legacy-Layout. Dann, wenn IE im Januar 2020 endlich seinen langsamen und qualvollen Tod stirbt, entfernen Sie einfach den Legacy-Code.Nebenbei bemerkt, ich wette, sobald Microsoft im Januar 2020 Windows 7 einstellt, werden IT-Abteilungen schnell zu einem moderneren Betriebssystem mit MS Edge wechseln. Das Betreiben alter, nicht unterstützter Betriebssysteme in Kombination mit alten Browsern ist ein Sicherheitsalbtraum. Angesichts all der Datenpannen und Ransomware, die herumschwirren, werden alle Unternehmen ihre Computersysteme sicher haben wollen, sonst könnte es sie Millionen kosten.
„Bibliotheken wie Tailwind und Tachyons bieten greifbare, reale Vorteile“
Wie zum Beispiel? Die Nachteile werden gut erklärt; Sie können Ihr Stylesheet nicht aktualisieren. Aber was sind diese greifbaren Vorteile? Ich habe das schon ein paar Mal gelesen, bin aber immer noch ratlos, warum ich das in Betracht ziehen sollte.
Wenn Sie mehr erfahren möchten, können Sie mit diesen beiden fast klassischen Beiträgen beginnen
https://mrmrs.cc/writing/scalable-css
https://www.smashingmagazine.com/2013/10/challenging-css-best-practices-atomic-approach
Wenn Sie immer noch interessiert sind, gibt es hier viele weitere (und neuere) Artikel, die von hier verlinkt sind: https://johnpolacek.github.io/the-case-for-atomic-css
Ich benutze Tailwind seit anderthalb Jahren. Ich kann mir nicht vorstellen, CSS anders zu schreiben. Ich habe an einem großen Designsystem gearbeitet, wahrscheinlich etwa 100 einzigartige Komponenten. Das bereinigte CSS ist 6 KB (gzip). Mit BEM oder einem anderen nicht Utility-First-Framework wäre es unmöglich, solche Ergebnisse zu erzielen. Und es ist so schnell zu arbeiten… Ich muss mir keine Klassennamen ausdenken, ich muss mich nicht wiederholen…
display: flexist dreimal auf meiner gesamten Website definiert. Einmal für jeden Breakpoint… Ich liebe es Blutig.Interessanter Artikel. Die erste Vorhersage, die davon spricht, dass CSS immer noch ein Territorium ist, das von Fachleuten selbst nicht gut erforscht wird, ist etwas, das ich gut nachvollziehen kann und das meine Arbeitsweise widerspiegelt – meine Süchte, meine Bindungen.
Als Flexbox aufkam, löste es so viele Designprobleme effizient, dass ich mich daran gewöhnte. Um mit CSS GRID zu beginnen, einer schlankeren, ausgefeilteren und erheblich einfacheren Lösung, musste ich gezielte Übungen in meinen Projekten machen. Ich musste mit vielen Fehlern, wenigen Erfolgen und Verzögerungen fertig werden. Oft griff ich auf den Komfort des bereits beherrschten Flexbox zurück.
Die zweite Vorhersage zu funktionellem CSS werde ich niemals adaptieren. Funktionales CSS erscheint mir wie ein Witz. Es ist fast so, als würde man Inline-CSS mit Klassen machen. Der Code sieht furchtbar aus. Ich weiß nicht, ob es um Frische oder reine Ästhetik geht, aber ich unterstütze und verteidige die platonische Idee der größtmöglichen Trennung zwischen HTML-Datei und Stil-Datei.