Vergleich von Styling-Methoden in 2020

Auf Smashing behandelt Adebiyi Adedotun Lukman all diese Styling-Methoden. Es ist im Kontext von Next.js, was durchaus wichtig ist, da Next.js einige spezifische Arbeitsweisen mit diesen Werkzeugen bietet, React ist und somit eine komponentenbasierten Architektur hat. Aber die besprochenen Styling-Methoden gehen über Next.js hinaus und können breit auf viele Websites angewendet werden.

Hier sind meine heißen Meinungen zur gesamten Inhaltsübersicht der Styling-Möglichkeiten heutzutage.

• Reguläres CSS. Wenn du kannst, tu es. Keine Build-Tooling ist erfrischend. Es wird gut altern. Das Einzige, was ich *wirklich* vermisse, ohne weitere Tools, ist das Verschachteln von Media Queries innerhalb von Selektorblöcken.
• Sass. Sass ist schon lange dabei und immer noch ein äußerst beliebter CSS-Präprozessor. Sass ist in viele andere Tools integriert, daher bedeutet die Wahl von Sass nicht immer dasselbe. Eine einfache Sass-Integration kann so einfach sein wie ein sass --watch src/style.scss dist/style.css npm-Skript. Sobald du dich mit der Tatsache abgefunden hast, dass du einen Build-Prozess hast, kannst du beginnen, Dateien zu verketten, zu minifizieren, Caches zu brechen und all diese Dinge zu tun, die du wahrscheinlich sowieso irgendwie tun wirst.
• Less & Stylus. Ich bin überrascht, dass sie nicht populärer sind, da sie schon immer Node-basiert waren und gut mit der Verbreitung von Node-gestützten Build-Prozessen zusammenarbeiten. Ganz zu schweigen davon, dass sie schöne, funktionsreiche Präprozessoren sind. Ich habe nichts gegen beide, aber Sass ist allgegenwärtiger, wird aktiver entwickelt und kanonisches Sass funktioniert jetzt gut in Node.
• PostCSS. Ich bin nicht von PostCSS überzeugt, weil ich es nicht liebe, die gewünschten Verarbeitungsfunktionen mühsam zusammenzusuchen. Das hat auch den negativen Nebeneffekt, dass sich der Prozess des Schreibens von CSS von Projekt zu Projekt unterscheidet. Außerdem mag ich die Idee nicht, moderne Funktionen "weg zu präprozessieren", von denen einige wirklich nicht präprozessiert werden können (z. B. benutzerdefinierte Eigenschaften können nicht präprozessiert werden). Aber ich liebte Autoprefixer, als wir das wirklich brauchten, das auf PostCSS basiert.
• CSS Modules. (Basiert auf PostCSS). Wenn du mit Komponenten in jeder Technologie arbeitest, geben dir CSS-Module die Möglichkeit, CSS auf diese Komponente zu beschränken, was eine unglaublich großartige Idee ist. Ich mag diesen Ansatz, wo immer ich ihn bekommen kann. Dein Modul-CSS kann auch Sass sein, sodass wir dort das Beste aus beiden Welten haben.
• CSS-in-JS. Seien wir ehrlich, das bedeutet "CSS-in-React". Wenn du Vue schreibst, schreibst du Stile so, wie Vue dir hilft. Dasselbe mit Svelte. Dasselbe mit Angular. React ist das unvoreingenommene, das dir die Wahl zwischen Dingen wie styled-components, styled-jsx, Emotion lässt... es gibt *viele* davon. Ich habe Projekte in React und benutze einfach Sass+CSS Modules und finde das gut, aber viele Leute mögen auch CSS-in-JS-Ansätze. Ich verstehe es. Du bekommst die Beschränkung automatisch und kannst coole Dinge tun, wie Props in Styling-Entscheidungen einzubeziehen. Könnte großartig für ein Designsystem sein.
• Alles auf Utility-Styles setzen: Große Vorteile: kleine CSS-Dateien, konsistente, aber flexible Stile. Großer Nachteil: Du hast eine Milliarde Klassen, die alle in deinem Markup vermischt sind, was es umständlich macht, sie zu lesen und zu refaktorieren. Ich bin nicht überzeugt, aber ich verstehe es, diese Vorteile treffen für einige Leute wirklich.

Wenn du einige andere heiße Meinungen zu diesem Spektrum hören möchtest, haben die Syntax FM-Jungs kürzlich dazu geäußert.