Manche Leute hassen die Idee von CSS-in-JS von Grund auf. Allein der Name ist beleidigend. Ein klares Nein. Styling gehört nicht in JavaScript, sondern in CSS, etwas, das bereits existiert und auf das Browser optimiert sind. Trennung der Belange. Alles andere ist ein lächerlicher Fehltritt, ein Zeichen dafür, dass man nicht aus den Fehlern der Vergangenheit gelernt hat (wie das <font>-Tag und Ähnliches).
Manche Leute lieben die Idee von CSS-in-JS von Grund auf. Die räumliche Nähe von Templates und Funktionalität, wie in den meisten JavaScript-Frameworks, hat sich für sie als erfolgreich erwiesen, daher scheint das Einbinden von Styles ein natürlicher Schritt zu sein. Die Single-File-Komponenten von Vue sind hier ein Archetyp.
(Hier ist ein Video über CSS-in-JS, das ich mit Dustin Schau gemacht habe, falls du eine Einführung brauchst.)
Brent Jackson denkt, du solltest es definitiv lernen, bietet aber auch einige pragmatische Punkte dazu, was es tut und was nicht.
Was macht CSS-in-JS?
- Ermöglicht das Schreiben von CSS in JavaScript-Syntax
- Räumliche Nähe von Styles zu Komponenten
- Nutzung nativer JS-Syntaxfunktionen
- Nutzung von allem aus dem JS-Ökosystem
Wovon befreit dich CSS-in-JS nicht von der Notwendigkeit zu verstehen?
- Wie Styles auf das DOM angewendet werden
- Wie Vererbung funktioniert
- Wie CSS-Eigenschaften funktionieren
- Wie CSS-Layout funktioniert
CSS-in-JS entbindet dich nicht davon, CSS lernen zu müssen. Meistens jedenfalls.
Ich habe viel Gegenwind gegen CSS-in-JS gehört, in der Art von „ihr Leute greift zu CSS-in-JS, weil ihr CSS nicht versteht“ oder „Ihr macht das, weil ihr Angst vor der Kaskade habt. Ich weiß bereits, wie man CSS scopet.“ Ich finde solche Sachen eher als Sticheleien über die Gänge, die nicht besonders hilfreich sind.
Laura buns hat einen wunderbar zweiseitigen Artikel mit dem Titel „The web without the web“, von dem ein Teil über React und CSS-in-JS handelt.
Ich hasse React, weil CSS-in-JS-Ansätze standardmäßig dazu ermutigen, völlig in sich geschlossene Einzelkomponenten zu schreiben, anstatt zu versuchen, eine UI einer Website als Ganzes aufzubauen.
Du musst CSS-in-JS nicht verwenden, nur weil du React verwendest, aber es ist beliebt, und das ist eine sehr interessante und faire Kritik. Wenn du alles scopest, setzt du dich dann nicht einem höheren Risiko der Inkonsistenz aus?
Ich bin bisher ein Fan von CSS-Modulen, da es so leichtgewichtig ist, wie man bei CSS-in-JS nur sein kann, und nur das Scoping und die räumliche Nähe behandelt, das ist alles. Ich benutze es mit Sass, damit wir Zugriff auf Mixins und Variablen haben, die die Konsistenz fördern, aber ich kann mir vorstellen, wie es dazu führen könnte, in gefährliches Gebiet mit zu vielen Einzelteilen zu rutschen.
Und doch wären sie wegwerfbare Einzelteile. Code-splittbare Einzelteile. Alles existiert im Gleichgewicht.
Laura sagt weiter, dass sie CSS-in-JS-Ansätze wegen der Macht und Flexibilität, die sie bieten, mag.
Ich mag die Art und Weise, wie CSS-in-JS dir genug Abstraktion bietet, um weiterhin Tricks wie Blind-Eulen-Selektoren zu verwenden, und dir gleichzeitig die volle Kraft von JS gibt, um Dinge wie Container-Abfragen zu tun.
Martin Hofmann hat eine Seite erstellt, die BEM vs. Emotion vergleicht, die eine kleine „Alert“-Komponente betrachtet. Ich mag, wie es ein emotionsloser (buchstäblich, nicht im Bezug auf die Bibliothek) Vergleich ist, der die Syntax betrachtet. BEM hat einige Vorteile, insbesondere dass keine Werkzeuge benötigt werden und es leicht auf jedes Webprojekt übertragen werden kann. Aber der Emotion-Ansatz ist in vielerlei Hinsicht sauberer und sieht einfacher zu handhaben aus.
Ich würde gerne mehr emotionslose Vergleiche der Technologien sehen. Wahl A macht diese drei Dinge gut, ist aber hier und da schmerzhaft, während Wahl B diese anderen Dinge gut macht und ein paar andere Schmerzpunkte löst.
Wir haben kürzlich Scotts Jehl’s Beitrag verlinkt, der sich mit dem asynchronen Laden von CSS befasst. Scotts Eröffnungszeile:
Eines der wirkungsvollsten Dinge, die wir tun können, um die Seitenleistung und Ausfallsicherheit zu verbessern, ist das Laden von CSS auf eine Weise, die die Seitenrendern nicht verzögert.
Es ist bemerkenswert, dass ein reiner CSS-in-JS-Ansatz diese Fähigkeit auf natürliche Weise erhält, da das Styling in JavaScript gebündelt ist. Es ist zu einem Preis gebündelt. Ein Preis für die Leistung. Aber wir bekommen einen Teil dieser Kosten zurück, wenn wir andere rendern-blockierende Dinge eliminieren. Das sind interessante Dinge, die zumindest weitere Daten verdienen.
Ich werde vielleicht Prügel dafür einstecken, aber ich bin ein wenig weniger interessiert an Konversationen, die versuchen, CSS-in-JS dafür verantwortlich zu machen, dass die Eintrittsbarriere in die Branche erhöht wird. Das ist eine massive Sache, die man berücksichtigen muss, aber wir reden nicht davon, CSS abzuschaffen und alle zu einer anderen Sprache zu zwingen. Wir reden über Nischenbibliotheken für bestimmte Arten von Projekten in bestimmten Größenordnungen.
Ich denke, es lohnt sich, einen Blick auf CSS-in-JS-Ideen zu werfen, wenn...
- Sie sowieso an einem komponentenlastigen JavaScript-Projekt arbeiten.
- Sie bereits Templates, Funktionalität und Datenabfragen räumlich zusammenlegen.
- Sie glauben, dass Sie es nutzen können, ohne die Benutzererfahrung zu beeinträchtigen, z. B. indem Sie woanders Geschwindigkeit gewinnen.
- Ihr Team mit der erforderlichen Technologie vertraut ist, d. h. Sie stoßen keine Talente ab.
Max Stoiber ist ein uneingeschränkter Fan. Sein Beitrag zu diesem Thema spricht von dem Vertrauen, das dieser Stil ihm gibt, und der Zeit, die er spart, um das zu finden, was er braucht, beides Dinge, die ich als wahr empfunden habe. Aber er denkt auch, dass der Ansatz speziell für JavaScript-Framework-Anwendungen ist.
Wenn Sie ein JavaScript-Framework zum Erstellen einer Webanwendung mit Komponenten verwenden, ist CSS-in-JS wahrscheinlich eine gute Wahl. Besonders wenn Sie Teil eines Teams sind, in dem jeder grundlegendes JavaScript versteht.
Ich würde gerne Ihre Gedanken dazu in den Kommentaren hören. Haben Sie Ihre Gefühle dazu sortiert? Verrückt verliebt? Vor Abscheu kochend? Ich wäre am meisten daran interessiert, Erfolgsgeschichten oder Misserfolgsgeschichten von echten Projekten zu hören.
Ich persönlich bin völlig unvoreingenommen, andererseits halte ich es für eine gute Idee, da es eine Vielzahl neuer Möglichkeiten eröffnet.
Bevorzuge normales CSS, um eine einfache Methode zu haben
Wenn sich eine große Organisation für CSS-in-JS entscheiden würde und dann eines Tages beschließen würde, zu normalem CSS zurückzukehren. Der Prozess des Extrahierens oder Neucodierens des CSS scheint unglaublich schwierig zu sein. Solche irreversiblen Entscheidungen sind sehr schwer zu treffen.
Guter Punkt tatsächlich, daran habe ich nie gedacht.
Das ist kein Problem. Wie viele große Organisationen sind von einem LAMP-Stack zu etwas wie React gewechselt und wollen dann zurück? Die Websites, an denen ich gearbeitet habe, haben alle 4-7 Jahre ihren Stack von einer Plattform zur nächsten gewechselt.
@ Rocky Kev
Es ist ein Problem, wenn man keine vollständige Neuentwicklung machen möchte. Wenn man von LAMP zu React wechselt, möchte man eine Neuentwicklung.
Aber wenn man die Logik wechseln möchte, ohne das CSS neu zu schreiben, ist man gezwungen, dies ebenfalls neu zu schreiben (zu portieren).
Ich habe einige Gedanken dazu.
Das beste Argument für CSS-in-JS, das mir einfällt, ist: Trennung der Belange bedeutet nicht unbedingt Trennung der Sprachen. Also kann die Trennung der Belange genauso gut als Argument für CSS-in-JS verstanden werden. Ich habe die Freude an diesem komponentenweisen Ansatz in React gespürt.
Mein anderer Gedanke ist, dass ich es immer noch für sehr wichtig halte, JS nur dann zu verwenden, wenn es notwendig ist. Immer zu hinterfragen, ob es sein muss, und immer zu versuchen, Websites zu erstellen, die nicht von JS abhängig sind. Genau wie bei Flash damals.
Ich habe die Ressourcen im Sinn, die eine Website verbraucht. Nicht nur Traffic, sondern auch Energie. Da Websites im Durchschnitt 10-mal größer sind als vor 10 Jahren, befürchte ich, dass JS-Frameworks nur allzu oft dazu verwendet werden, die Arbeit der Entwickler zu erleichtern, ohne viele Vorteile für den Benutzer zu erzielen, sondern stattdessen die Website unnötig aufzublähen.
Die Frage könnte also lauten: Welche Technologie hilft wirklich der Sache und welche tröstet nur den Entwickler und kostet den Benutzer vielleicht sogar unnötigerweise?
„Ich befürchte, JS-Frameworks werden nur allzu oft verwendet, um die Arbeit der Entwickler zu erleichtern, ohne viele Vorteile für den Benutzer zu erzielen, sondern stattdessen die Website unnötig aufzublähen.“
Mit dieser Sorge bist du nicht allein. Der Fokus liegt zu sehr auf Tools, die das Erstellen von Produkten erleichtern. Das ist nicht dasselbe wie das Erstellen besserer Produkte.
Zwei Dinge, die ich mir wünschen würde, dass mehr Ingenieure/Entwickler annehmen würden
1) Nur weil du es kannst, heißt das nicht, dass du es tun solltest.
2) Weniger ist mehr.
Werkzeuge sind keine Allheilmittel. Mehr und schneller =/= Besseres Produkt. Leider ist das etwas, das die Branche anscheinend nicht zugeben will.
Diese aktuelle Umdeutung, dass die Trennung der Belange daran lag, dass CSS, JS und HTML unterschiedliche Sprachen waren, ist so rückständig. Sie sind unterschiedliche Sprachen, weil sie unterschiedliche Belange sind. Sie sind Belange, die davon profitieren, getrennt zu werden, weil sie sich häufig unabhängig voneinander ändern und von verschiedenen Arten von Entwicklern beigetragen werden können und sollten.
Es gibt sowohl horizontale als auch vertikale Belange. Nur vertikal zu schneiden, wird ebenso viele Nachteile haben wie nur horizontal zu schneiden.
Nein danke, SCSS mit BEM als Konvention ist völlig in Ordnung, Material UI ist ein perfektes Beispiel dafür, warum ich CSS in JS stark ablehne.
Ich schätze die unvoreingenommene Darstellung. Die Leute sollten die Werkzeuge benutzen dürfen, die sie effektiv machen. Es gibt viel Feindseligkeit gegenüber der Idee von CSSinJS und oft fühlt es sich wie Gatekeeping an, was meiner Meinung nach der Community mehr schadet als nützt.
Ich habe kein Problem mit dem Konzept, dass dein CSS in JavaScript geliefert wird, aber ich mag viele Implementierungen nicht, die die Art und Weise ändern, wie du mit der Sprache interagierst.
Das einzige CSS-in-JS, das mir gefallen hat, ist die Implementierung von Vue, da sie die Belange immer noch trennt, während ich Styles schreibe.
Auf der anderen Seite bin ich ein „Frontend of the Frontend“-Entwickler, der sich zu einer abgerundeten Frontend-Position entwickelt, daher werde ich empfindlich, wenn Leute an meinem CSS-Format herumfummeln.
Ich liebe es, dass CSS-in-JS nur die notwendigen „Deklarationen“ enthält. ;)
„Es ist bemerkenswert, dass ein reiner CSS-in-JS-Ansatz diese Fähigkeit auf natürliche Weise erhält, da das Styling in JavaScript gebündelt ist. Es ist zu einem Preis gebündelt. Ein Preis für die Leistung. Aber wir bekommen einen Teil dieser Kosten zurück, wenn wir andere rendern-blockierende Dinge eliminieren.“
Ja, einen Teil. Aber dieser Teil kommt auch mit einem sehr wichtigen WENN. Nämlich WENN sich jemand um die Leistung kümmert (lesen: Zeit, Budget und Priorität der Führung vorhanden sind).
CSS-in-JS war für mich schon immer eine moderne technische Wendung auf Büropolitik. Es gibt den Ingenieuren/Entwicklern mehr (zentralisierte) Kontrolle, und denen, die nicht zum inneren Kreis gehören, weniger. Es ist ein billiger und schmutziger Stellvertreter für die Unfähigkeit der Führung/des Managements, Konstruktionen basierend auf (traditionellem) Markup + CSS + JS zu verwalten. Die Technologie ist in Ordnung. Vielleicht nicht perfekt, aber nichts ist jemals perfekt. Aber sie erfordert Kooperation und Zusammenarbeit. CSS-in-JS versuchte, diese Reibung zu mindern, schuf aber andere Probleme.
Menschen und Kompromisse. Es läuft immer auf Menschen und Kompromisse hinaus.
CSS in JS ist eine Abscheulichkeit und wer auch immer beschloss, dass es eine gute Idee war, sollte sofort mit einem Hubschrauber zum Meer transportiert und unzeremoniell hineingeworfen werden. Es löst keines der Probleme, die es zu lösen vorgibt, entmutigt DRY-Code und fügt dem Entwicklungsprozess unnötige Komplexität hinzu.
Wir verwenden in unserer Organisation eine Komponentenbibliothek, die auf Material UI basiert. Eine der Aufgaben, die wir letztes Jahr erledigen mussten, war die Anwendung des neuen Corporate Stylings, das in dieser Komponentenbibliothek verwendet wurde, in einer Ember-App. Es dauerte 10 von uns 8 Monate, um etwas zu tun, das eine Copy-Paste-Aufgabe gewesen wäre, wenn das Team, das die Komponentenbibliothek erstellt hat, diesen lächerlichen Trend widerstanden und etwas Portables geschrieben hätte.
Ich bin jetzt in ein neues Team gewechselt, das die Komponentenbibliothek direkt verwendet. Warum müssen wir unsere App in eine ThemeProvider-Komponente wickeln und dann jede meiner einzelnen Komponenten in eine withStyles Higher-Order-Komponente, wenn eine einfache Importanweisung ausgereicht hätte? Warum erhalten wir JavaScript-Fehler in unseren Unit-Tests, weil wir all diesen Mist nicht für jeden Test eingerichtet haben? Warum macht Livereload einen vollständigen Seiten-Refresh für jede Stiländerung? Was genau können wir jetzt tun, was diesen Aufwand für den Kompromiss wert gemacht hätte?
Jeder, der denkt, CSS in JS sei eine gute Idee, verdient einen herzhaften Schlag auf den Kiefer, und sein Nachfolger kann nicht schnell genug kommen.
Mann, das hat sich gut angefühlt zu schreiben – danke, dass du mir das Forum gegeben hast, um das von der Seele zu reden
Jonathan, wie bezieht sich CSS-in-JS darauf?
Es scheint, als hättest du Higher-Order-Komponenten und Decorators zur Verwaltung von Styles verwendet, das ist nicht gerade ein gängiger Ansatz für CSS-in-JS.
Bitte erläutere
Vielleicht hätte das in einen Beitrag über Material UI statt über CSS-in-JS im Allgemeinen gehört. Ich habe Material UI kritisiert, weil wir es verwenden mussten und weil es eine beliebte Implementierung von CSS-in-JS ist.
Aber auch ohne Material UI besteht bei Styles immer noch Bedarf an globalen Styles für Dinge wie Schriftarten, Farbpaletten, Link-Styles, Gitterlayouts usw. Sie wollen immer noch Wiederholungen so weit wie möglich vermeiden, daher möchten Sie vielleicht Dinge wie Mixins oder Hilfsklassen verwenden, um dies zu vermeiden (z. B. eine Flex-Column-Mixin/Hilfsklasse).
Für die Anwendung dieser Dinge in CSS-in-JS sind Ihre Optionen:
1. Wiederholen Sie sich. Ständig. Und hoffen Sie, dass sich der Farbton des Corporate Reds, den Sie verwenden, nie ändert.
2. Verwenden Sie Provider und/oder Higher-Order-Komponenten, die all die Probleme verursachen, die in meiner OP erwähnt wurden.
3. Sie können diese in eine Art globalStyles.js-Datei aufnehmen, die Sie in alle Ihre Komponenten importieren (oder vielleicht Komponenten-Style.js-Dateien, wenn Sie es so machen), was immer noch mehr Arbeit ist, als sie einfach oben in Ihr Stylesheet zu importieren und sie kaskadieren zu lassen. Wenn dies nicht richtig geplant ist, kann es immer noch zu Überschreibungsbedarf kommen, was anscheinend eines der Probleme ist, die CSS-in-JS mit seinem wahnsinnigen Grad an komponentenspezifischem Scoping lösen will.
4. Benutzen Sie einfach CSS (oder SCSS oder was auch immer Ihr bevorzugter Präprozessor ist).
Persönlich würde ich Option 4 wählen, da Sie mit jeder anderen Option genauso gut CSS hätten verwenden können und Ihre Styles auch auf andere Projekte portieren könnten.
Das ist nur ein Problem von beliebten Laufzeit-CSS-in-JS-Lösungen wie Emotion oder Styled Components.
Es gibt CSS-in-JS-Lösungen ohne Laufzeit, die Babel verwenden, um CSS aus JS in statische CSS-Dateien zu extrahieren und diese statische CSS-Datei als CSS-Module zu verwenden. Perfekte Leistung, Kompatibilität mit allen CSS-Tools, wobei CSS in derselben JS-Komponenten-Datei verbleibt.
https://github.com/4Catalyzer/astroturf
https://github.com/callstack/linaria
https://github.com/lttb/reshadow
Ich mag kein CSS in JS. Es muss eine Art Tag in CSS eingefügt werden, das das benötigte CSS für die Komponente abruft.
Ich denke, für mich ist das #1 Argument, das ich gemacht habe, die Eintrittsbarriere, die es schaffen kann. Insbesondere in einer Zeit, in der Designer zunehmend technischer werden und wir den Aufstieg der Rolle des „UX Engineers“ erleben, sind viele dieser Designer bereits sehr versiert in der grundlegenden HTML/CSS-Manipulation und -Erstellung. Viele sind zu Sass (wie ich) übergegangen und finden es erfrischend, dadurch ein gewisses Maß an Kontrolle und Autonomie zu haben. Dann gibt es die nächste Organisationsebene wie BEM, SMACSS oder SuitCSS... und diese machen es einfach, Ihre Stile zu organisieren und darauf aufzubauen, innerhalb einer Hierarchie und mit klaren (hoffentlich) Regeln, die von Ihrer Organisation oder Ihrem Produkt definiert wurden.
Wenn man die Variable JS hinzufügt, für Leute, die sich vielleicht nicht so wohl fühlen, sagen wir mal, in einem React-basierten System, bringt das ein gewisses Risiko mit sich. Ich war in der Situation, dass jemand in unserer App arbeitete, der die JS-Syntax nicht kannte und stundenlang festhing, um etwas zum Laufen zu bringen. Ein anderer Fall, bei dem jemand etwas kaputt gemacht hat, sobald es in Produktion war... Es gibt also inhärente Risiken.
Jeder sollte offen für Neues sein, aber das Erzwingen von dem einen oder dem anderen ist nicht die Lösung. Ich denke, verlinkte Stylesheets sind immer noch der richtige Weg, besonders wenn es einfacher ist, Umgebungen einzurichten, die mit Sass, Less oder Stylus builden können, aber es gibt definitiv Vorteile für CSS-in-JS... die offensichtlichsten sind die direkte Manipulation neben dem JS. Das finde ich nützlich, wie die Durchführung zustandsabhängiger Dinge, die trivialer oder spezifischer für die Komponente sein könnten, anstatt sie in meine Sass-Bibliothek zu schreiben.
Ich stimme den Kommentaren von Jonathan Stevens oben teilweise zu, aber ich öffne mich der Idee ein wenig mehr als noch vor einem Jahr... bin aber immer noch sehr zögerlich, CSS-in-JS direkt als erste oder einzige Wahl zu überlassen. Ich wünschte, viele Teams würden nicht sofort damit anfangen, aus den gleichen Gründen, die er genannt hat. Man schränkt sich für die Zukunft ein, falls man größere oder auch kleinere Änderungen vornehmen möchte. Zumindest mit einer Sass-Bibliothek haben wir die Macht von Imports und können Komponenten und Layouts (für mich) einfacher kapseln.
Ich bin relativ neu in JS und am Anfang liebte ich die Idee von CSS-in-
JS. Da ich mehr genutzt und gelernt habe, gehe ich weg von so viel CSS-in-JS-Quelle. Ich denke, ein standardmäßig besserer Ansatz ist globales CSS/SCSS und vielleicht kleine spärliche Anpassungen in JS. Aber es hängt auch vom Projekt ab und von der Wahl der richtigen Werkzeuge für die Parameter des Projekts.
@Chuck Smith, das ist im Grunde das, was ich meine. Es sollte wirklich eine globale Kontrolle geben, und wenn man spezielle Anpassungen auf Komponentenebene benötigt, dann macht CSS-in-JS Sinn. Besonders für die Verwaltung von zustandsabhängigen Dingen, damit man nicht unbedingt das DOM manipulieren muss, um Modifier-Klassen zu ändern oder hinzuzufügen.
Warum nicht beides?
Es gibt ein Designsystem aus etablierten globalen Elementen, Utilities und Defaults in Vanilla CSS für das UI selbst und dann Erweiterungen von CSS-in-JS für zustandsverwaltete UI-Änderungen, wodurch ein Gleichgewicht zwischen anmutiger Degradation erreicht wird, wenn ein Benutzer entweder kein JS laden kann oder es deaktiviert hat. Auch wenn Sie die CSS-Dateien aus irgendeinem Grund von der JS-Datei trennen müssen, wird dies nicht zu einer sehr großen technischen Schuld, sondern es ist nur eine Übertragung dieser Styles zurück in das Ökosystem des Designsystems.
Ein großartiger Ansatz. Anders ausgedrückt: Absolut, es gibt viel Wert darin, das Äquivalent von „User Agent“-Styles in die Komponente zu integrieren und diese eng zu koppeln.
Ich betrachte Vue- oder Svelte-Single-File-Komponenten-Scoping nicht wirklich als CSS-in-JS. Sicher, es ist im Hintergrund, aber es befasst sich nur mit Scoping und hindert dich nicht daran, SCSS oder Stylus zu verwenden (genau wie CSS-Module), und es bietet eine weitaus niedrigere Eintrittsschwelle für Designer und andere, die hauptsächlich HTML und CSS kennen.
Ich denke, ein weitgehend unausgesprochenes Problem mit CSS-in-JS ist, dass es einfach schwieriger ist, ein groß angelegtes Designsystem damit sauber zu verwalten, soweit ich das beurteilen kann, wenn ich sehe, wie Leute es versuchen. Sicher, es ist möglich, es gut und sauber zu machen, aber es fügt eine weitere Wissensfläche hinzu, die für die ordnungsgemäße Arbeit an einem Projekt und die Dokumentation für jede Kombination von CSS-in-JS-Frameworks und -Ansätzen, die Sie verwenden, erforderlich ist. Dies führt unweigerlich zu mehr Komplexität und dazu, dass Leute von konsistenten oder Best-Practice-Ansätzen abweichen.
Das Thema Eintrittsbarriere ist wichtiger, als wir anerkennen. Es gibt Leute da draußen, die ihr Wissen dem zugänglich, performant und gut durchdachten HTML und CSS widmen, und sie sollten kein JS lernen müssen, nur um zu großen Webanwendungen beizutragen. Nicht, wenn wir neuere und bessere Frameworks als React wie Vue oder Svelte haben.
Und deshalb habe ich die Eintrittsbarriere erwähnt. Ich weiß, dass du jetzt ein großer Fan von Svelte bist, aber Vue hat die gleiche Idee, bei der du diese beiden Belange besser trennen und die Dinge ein wenig mehr, ich schätze, „koscher“ halten kannst. Und Ihr Punkt über Systeme in großem Maßstab ist der Grund Nr. 1, warum ich CSS-in-JS nicht als einzige Lösung mag. Wieder... es hat seine Vorteile, aber ich denke, die Nachteile überwiegen bei weitem die Vorteile. Im Vergleich zu Präprozessoren und Kompilierung oder Vanilla CSS.
Ist die Kosten von CSS-in-JS nicht, beliebige wiederverwendbare CSS in JS zu komponenten, was zu weitaus mehr JS zum Download führt?
@Sergey, da liegt die Ironie mit CSS in JS... und eines der Dinge, über die ich nachdenke, wenn es um die Kernidee von CSS-in-JS als Performance-Gewinn geht.
Ja zu allem. Insbesondere Ihr Punkt bezüglich der Single-File-Komponenten von Vue, die kein CSS-in-JS sind, zumindest was die „Developer Experience“ angeht!
Bis vor kurzem musste ich kein CSS-in-JS verwenden. Ich arbeite mit den Single-File-Komponenten von Vue.js und deren CSS-Modulen.
Aber kürzlich musste ich Werte berechnen, also musste ich ein Styling-Objekt erstellen. Nur um dann gegen die Wand zu laufen, als ich Pseudo-Elemente stylen musste und Medienabfragen verwenden musste. Beides ist, soweit ich weiß, nicht möglich.
Das kommt also noch zum Problem der Inkonsistenz hinzu.
Ich sehe den Vorteil von CSS-in-JS.
Das Problem, das ich jetzt habe, ist, dass ich JavaScript und React lernen muss, um es zu verwenden.
Ich hoffe, es wird mir bei der Website-Performance und dem Arbeitstempo helfen.
Normalerweise muss ich auf eine Website gehen, um manuell Critical Path Styling zu erstellen, jedes Mal, wenn ich Änderungen an einer Webseite vornehme.
Ich habe gehört, dass CSS-in-JS und/oder React dieses Problem lösen können.
Vielen Dank für den Artikel, war eine schöne Lektüre.
CSS-in-JS ist in der Tat am weitesten in der React-Welt verbreitet, also ist das fair, aber alle großen Player (z. B. Emotion) behaupten entweder zumindest, framework-agnostisch zu sein, oder haben Versionen davon, die mit anderen Frameworks funktionieren.
Aber wenn es so ist, wie Storybook mit mehreren Frameworks funktioniert, denkt es im Kern wie eine React-App und ein React-Entwickler.
CSS-in-JS scheint zu existieren, weil React keine eingebaute Möglichkeit hat, CSS in JSX-Dateien hinzuzufügen. Es hat mich lange gebraucht, um das zu erkennen. Aus Vue.js kommend, wo Single-File-Komponenten auch CSS als erstklassigen Bürger enthalten können, scheint die CSS-in-JS-Kluft eine vorübergehende Sache zu sein, die so lange dauern wird, wie React existiert. Wer weiß, wie lange das sein wird.
Ehrlich gesagt, es geht wirklich darum, das richtige Werkzeug für den Job zu wählen. Einfaches, normales CSS ist die größte und optimalste Wahl, die Sie treffen können. Nichts ist schneller, optimaler und besser kontrollierbar. Alles andere ist praktisch ein Kompromiss.
Prozessoren – geben Ihnen einige Wartungsmöglichkeiten, aber Sie verlieren das Gefühl von Effizienz und erhalten eine Reihe von Problemen wie Build-Änderungen, zusätzliche Verarbeitung, XXL-Selektor-Hölle und vieles mehr.
CSS in JS – SSR-Rendering hat Probleme, Optimierung des Renderings hat Probleme, Code-Duplizierung ist ein eigenes Problem, Konsistenz der Styles und etc. Auf der anderen Seite gewinnen Sie durch schnelle Iteration großer Teams über lange Zeit, Wartung ist einfacher, wenn Sie den gesamten Code für die Komponente an einem Ort haben und etc.
Ich mische mich zwar etwas spät ein, aber ich dachte, ich füge noch ein paar negative Punkte für CSS-in-JS hinzu, das meiner Meinung nach für die meisten Projekte zu viele Nachteile hat. Wenn Sie JS als Präprozessor verwenden möchten, schön, aber als Laufzeit, die über das Internet heruntergeladen werden muss, ist es ein Anti-Muster.
Ich bin froh, dass Sie die begrenzte Verteilung erwähnt haben. Aber IMHO ist das der Grund von Gründen gegen CSS-in-JS. Es gibt bisher immer noch keinen Konsens über die spezifische Bibliothek, die verwendet werden soll. Selbst wenn „alle“ sie verwenden würden, ist die Wiederverwendbarkeit von CSS unterirdisch. Das ist besonders schlecht beim Prototyping. Manchmal möchte ich einfach ein verdammtes Formular auf den Bildschirm kopieren, das einigermaßen gut aussieht!
Ich würde tatsächlich „mehr Code“ von der CSS-Seite entfernen und ihn zu JS verschieben. SASS/POSTCSS/LESS sind keine Laufzeit, aber sie können die meisten Probleme der Code-Wiederholung und -Eliminierung lösen. Der einzige Bereich, in dem CSS-in-JS hier gewinnt, ist das Lazy Loading. Aber das ist jetzt einfach mit externem CSS und Webpack (und ich nehme an auch mit Rollup/anderen) zu machen.
Der Grund, warum zu CSS-in-JS "mehr Code" hinzugefügt werden sollte, liegt darin, dass der Browser das gesamte JavaScript (das deutlich größer sein wird) herunterladen und parsen muss, um überhaupt etwas rendern zu können. Wenn Sie eine reine SPA mit einem einzigen Div namens "root" haben, spielt das keine Rolle, aber wenn Sie es richtig machen und entweder Isomorphic- oder statisches (Gatsby, etc.) initiales Rendering haben, wird Ihre Seite mit traditionellem CSS viel schneller angezeigt. Das liegt daran, dass nur das HTML und CSS (viel weniger Code und Parsezeit) heruntergeladen werden müssen, um die Ansicht anzuzeigen.
Auch Namespaced-Code gehört aufgrund von CSS-Modulen in die Spalte "Traditionelles CSS". Bei allem Respekt vor Chris, von dem ich weiß, dass er ein Friedensstifter zwischen den Parteien sein und zu Recht versuchen möchte, inklusiv zu sein, ist dies 2019 und dieses Argument hat sein Gewicht verloren. Sie könnten sagen, nun, es tut das nicht "out of the box", aber tut dann CSS-in-JS jenseits des Style-Tags etwas?
Browser-Caching (ohne komplexe Service-Worker-Einrichtung) und HTTP2 werden nicht erwähnt. Standard-CSS hat das von Anfang an (CSS-Zeit) out of the box. Separates CSS funktioniert auch besser mit HTTP2 und parallelen Anfragen.
Fehlende Konvention. Das ist ein weiteres riesiges Problem. da jede Bibliothek eine andere Konvention/Syntax hat. Die meisten Projekte, die ich gesehen habe, sind ein ziemliches Durcheinander von CSS, das überall im selben Date als Anwendungslogik gemischt ist. Es gibt einige, die sich daran gewöhnen und sagen: "Das ist ein Hauch von frischer Luft". Wer sind diese Leute und schreiben sie viel CSS? Was kann einfacher sein, als einen geteilten Bildschirm mit einer CSS-Datei auf der rechten Seite und der App auf der linken Seite zu haben?
Nicht zuletzt das Schwesterproblem von "HTML in JS" als primäres Mittel für den visuellen Aspekt von Komponenten. Haben wir vergessen, dass CSS bereits Komponenten hat? Das stimmt, Komponenten sind direkt in CSS eingebaut. Hier ist ein Beispiel
Warum fiel dieser Stil des Schreibens von CSS-Klassen aus der Mode? Angst vor dem Kaskadeneffekt und allem Globalen. Als Softwareentwickler wird man von Anfang an gelehrt und dazu tendiert, globale Variablen so weit wie möglich zu minimieren. Aber als jemand, der mit dem Entwerfen von Magazinen und Katalogen in QuarkXpress, Pagemaker und Indesign begann (wo Branding und Stil für jedes Produkt sehr einzigartig ist), ist mir klar, warum CSS so gestaltet wurde, wie es wurde.
Bedeutet das, dass einige der neueren Ideen von Softwareentwicklern, deren Expertise vielleicht nicht im Design liegt, nicht wertvoll sind? Natürlich sind sie das, und viele der von ihnen angesprochenen Probleme sind berechtigt. Aber wir müssen unseren Verstand benutzen und von den guten Teilen lernen, uns nicht einfach ergeben, um was auch immer das angesagte neue Ding zu benutzen und darüber zu schwadronieren. Vergessen wir nicht, dass einige der angesehensten Persönlichkeiten in der Web-Community dazu neigen, Softwareentwickler in großen Unternehmen zu sein, und infolgedessen lautere Stimmen haben. Wir haben leider nicht genug Jen Simmons oder Rachel Andrews auf der kreativen Seite, um das auszugleichen, also müssen wir nachdenken und sorgfältig sein (und ja, es zuerst ausprobieren), was wir zu umarmen wählen.
Für mich ist dies die Art von gedanklicher Verkrüppelung, die ich von Leuten erwarte, die nicht in der Lage sind, eine einzige Zeile HTML zu schreiben. Entschuldigung, wenn das hart klingt, aber das nennt man Trennung der Belange. HTML für das, was Dinge SIND - semantisch, grammatikalisch - CSS für das Aussehen. Und JavaScript? Das dient der Verbesserung einer bereits funktionierenden Seite. Zumindest für jede normale inhaltsgesteuerte Website.
Aber nein, Leute, die nie Semantik angenommen haben, sehen nichts Falsches daran, endlose präsentationsbasierte Klassen in ihre Seiten zu schleudern (siehe "bootcrap"), Caching-Modelle von so hoch oben zu beschmutzen, dass man meinen könnte, der Allmächtige sei gerade von einem Biertrinker-Treffen zurückgekehrt, und im Allgemeinen die Konzepte, unter denen HTML und CSS erstellt wurden oder warum sie überhaupt existieren, nicht zu verstehen oder anzunehmen!
Es ist nicht anders als die Tatsache, dass Sie 99% der Zeit style="" sehen und 100% der Zeit, was Sie wirklich sehen, ist Entwickler-Unwissenheit, Inkompetenz und Unfähigkeit. Nicht anders als wenn Sie sehen, wie Leute eine Seite mit einem H5 beginnen, oder innerHTML verwenden, oder irgendeinen anderen "na, scheiß auf gute Praktiken"-Unsinn, der das Brot und Butter der unwissenden Betrüger mit ihrem "JS für nichts und deine Skripte umsonst" zu sein scheint.
Das funktioniert nicht, so macht man das nicht.
Auch wenn Ihr Kommentar so unhöflich ist, bin ich froh, dass die Moderatoren ihn zulassen, da ich ein großer Verfechter der freien Meinungsäußerung bin (zumindest bis zu dem Punkt, an dem er eine ganze Gruppe(n) von Leuten oder jemanden mobbt, der aufhören möchte, dann zähle mich aus).
.
Wenn Sie überhaupt auf meinen Kommentar geantwortet haben (Sie sind kaum verständlich und gehen nicht auf meine Punkte ein, außer auf die Verwendung von CSS-Komponenten), ist es lustig, dass Sie annehmen, ich hätte nicht viel Erfahrung. Während ich als Grafikdesigner "begonnen" habe, programmiere ich seit 1997 Websites, mein Freund! Lange bevor CSS existierte, mit HTML 3, Netscape Navigator, CGI, ASP (original), dann PHP, jQuery/Vanilla JS bis heute mit React, Angular, Backend, Frontend, Ops usw. Ich bin ein Full-Stack-Entwickler, der viele hoch frequentierte Produkte von Start-ups bis zu Unternehmen entwickelt und daran gearbeitet hat. Am wichtigsten ist, dass ich durch all das hindurch nie aufgehört habe, auf Veränderungen und neue Ideen zu achten. Nicht um mich selbst zu loben, aber ich würde denken, dass ich qualifiziert bin, zumindest eine Meinung zu dem Thema zu haben.
Hören Sie zu, wenn Sie wollen, nicht, wenn Sie nicht wollen, aber wenn Sie meine Aufmerksamkeit wollen, müssen Sie zumindest ein rationales Argument für oder gegen etwas haben, das ich gesagt habe. Alles, was ich sehe, ist, dass jemand offenbar einen schlechten Tag hat und meint, semantische Klassen seien der reine Ausdruck des Bösen... aber er liefert keine Begründung dafür. Ich sehe nichts, was den aktuellen Zustand/das Chaos von CSS-in-JS-Bibliotheken und Konventionen widerlegt, nichts darüber, dass Browser für die Arbeit mit externen CSS-Dateien entwickelt und optimiert sind (und zu diesem Zeitpunkt) besser performen, und vor allem nichts Positives, um VORTEILE von CSS-and-JS gegenüber einer optimierten Architektur von traditionellem CSS und einem modernen Workflow (z. B. CSS-Module, Preprocessing usw.) zu unterstützen. Nur etwas über Bootstrap schlecht (was meiner Meinung nach die von mir beschriebenen CSS-Klassenmuster übermäßig liberal verwendet und zu viel Kopplung an spezifische HTML-Verschachtelungen verursacht).
Unübersichtlicher Code, der mit längeren, umständlicheren Prozessen, höheren finanziellen und personellen Kosten das widerspiegelt, was er tun soll, nur weil man es so machen kann, obwohl man es nie dokumentiert und einfach erwartet, dass jeder es sofort versteht? Melden Sie mich an!
JS ist zum sprichwörtlichen Hammer geworden und Entwickler sehen alles als Nägel.
Eine Sache, die ich hervorheben möchte, ist die zukünftige Kompatibilität.
Mit CSS müssen Sie sich nie um das Aktualisieren von Bibliotheken kümmern oder sich Gedanken über breaking changes machen.
Wir haben Styled Components bei deren erster Veröffentlichung verwendet, im Laufe der Zeit haben sie mehrere Updates veröffentlicht. Einige davon waren breaking changes. An Updates und der Verbesserung der Bibliothek ist nichts falsch, aber es ist am Ende des Tages ein Kostenfaktor.
Was haben wir getan? Wir haben Legacy-Komponenten in Styled Components belassen und die neuen verwenden reines altes CSS. Langsam werden wir CSS zurückbringen und Styled Components ganz abschaffen. Denn neue Entwickler brauchen Zeit, um damit produktiv zu werden (sie nennen es nervig) und es sind Kosten, die wir uns als kleines Startup mit so viel anderem auf dem Teller wirklich nicht leisten wollen.
Ich persönlich mag die Idee von CSS-in-JS, aber dann wieder, jedem das Seine.
CSS-in-JS mag eine gute Idee sein, da Render-Blocking damit eliminiert werden kann, aber auf jeden Fall wird es nicht einfach zu coden sein.
Das Hauptproblem, das ich mit CSS-in-JS habe, ist, dass Leute dazu verleitet werden, das gesamte CSS für eine Komponente in diese Komponente zu packen. Es ist noch nicht lange her, dass wir ein Refactoring durchführen mussten, weil die Ersteller einer Website beschlossen hatten, die Schriftfarbe und -größe in der Komponente festzulegen, und der Kunde an einer anderen Stelle auf der Website eine Kopie der Komponente mit einer anderen Farbe und Schriftgröße benötigte.
Danach beschloss der Kunde, die Gesamtgröße der Schrift ein wenig zu ändern, und wir mussten denselben Trick für alle Komponenten durchführen.
Also nein, CSS-in-JS ist nicht gut oder schlecht, es muss aus einem bestimmten Grund implementiert werden, und dieser Grund kann niemals "es ist populär" oder irgendein Mist wie "das machen die großen Unternehmen" sein.
Nach meiner Erfahrung schließt die Verwendung von CSS-in-JS nicht aus, dass man "eine Website-UI als Ganzes aufbaut". Ein Beispiel: In den letzten zwei Jahren haben wir unsere auf CSS-Modulen basierenden Komponenten zu Styled Components migriert. Viele dieser Komponenten werden in der gesamten App (und auch in anderen Apps) verwendet. Es war eine 1:1-Konvertierung mit dem Vorteil, dass man Klassenbindungen entfernen konnte, die für die bedingte UI-Logik erforderlich waren.
Was das haltlose Argument angeht "... Leuten greifen zu CSS-in-JS, weil sie CSS nicht verstehen", rendert CSS-in-JS CSS im Browser, was ... Verständnis von CSS erfordert, zumindest soweit ich das beurteilen kann. :)
Nichtsdestotrotz sind CSS-Module immer noch ausgezeichnet für die Handhabung globaler Stile und übergeordneter Komponenten und Wrapper, die möglicherweise keine komplexen UI-Interaktionen behandeln.
Ich benutze CSS-in-JS seit 4 Jahren, aber auch React, Vue und Angular (aka JavaScript-Frameworks) in den meisten Anwendungen, an denen ich gearbeitet habe. Ich gebe zu, ich bin voreingenommen gegenüber der Schönheit der Arbeit mit React und all den Praktiken, die die Community dafür verfügbar und populär gemacht hat.
CSS-in-JS war für mich eine lebensverändernde Erfahrung. Und es bricht wirklich keine der Styling-Paradigmen, der wirkliche Vorteil liegt mehr in der Strukturierung und Trennung von Styling-Belangen über Komponenten hinweg, dafür sind Styled Components oder Emotion gemacht, es hilft wirklich bei der Strukturierung einer Ordner-/Komponentenstruktur in jeder Anwendung.
Ich würde auch sagen, dass Vue kein CSS-in-JS ist. Das einzige, was CSS-in-JS ähnelt, wenn man mit Vue Single File Components arbeitet, ist, dass man kein globales Stylesheet hat und es (wenn man will) intern gescoped wird - abgesehen davon verwendet man normale CSS-Syntax mit bekannter Verschachtelungssyntax usw. (wenn man SASS oder LESS verwendet).
Bei der Recherche des Themas sehe ich auch Potenzial und Vorteile in CSSinJS. Ich vermute, meine anfängliche Frustration rührt von der Art und Weise, wie Material-UI es erfordert, Stile in Komponenten zu überschreiben. Nach einer ganzen Woche, in der ich Stile auf diese Weise geschrieben habe, triggert mich das immer noch...
Nun, ich stimme zu, dass nicht alle Webseiten-Entwickler dies als Beruf ausüben, sondern anderen helfen, Webseiten aus familiären Gründen/oder für kleine Vereine usw. zu schreiben.
Daher stimme ich zu, dass ich keine Zeit habe, JavaScript zu lernen, aber keine Probleme mit JavaScript-Bibliotheken habe, um in einigen Bereichen zu helfen.
Brianran
Toller Artikel!
Aus der traditionellen CSS/Sass-Perspektive kam mir der CSS-in-JS-Weg über Styled Components nach Beginn der Arbeit mit React perfekt vor. Ich genieße es wirklich, wie alles innerhalb der Komponente lokalisiert ist und bei Bedarf leicht verschoben werden kann. Ich war einst zu 100 % gegen die Vermischung von Stil und Funktion, aber Menschen ändern sich.
Das gesagt, es kann ein wenig unordentlich werden, sobald eine Komponente zu wachsen beginnt. Aber zu diesem Zeitpunkt denke ich, dass die Komponente zu viel bewirken will und ich sie in fokussiertere Komponenten refaktoriere.
Ich arbeite immer noch daran, was mein "perfekter" Ansatz für das Styling in React sein wird, aber im Moment bin ich mit CSS-in-JS zufrieden.
Außerdem, ein separater Gedanke hier zusätzlich zu meinem ersten.
Jen Simmons erwähnte etwas über CSS-in-JS, das ich weiterführen möchte. CSS sind "Cascading Style Sheets", aber wenn man es im CSS-in-JS-Stil verwendet, gibt es kein "Stylesheet" mehr. Sie gehen im Grunde alles durch Inline-Styles und es gibt keinen Sinn mehr für Hierarchie, wie man ihn bei einem präprozessor-basierten Ansatz oder einer gut dokumentierten CSS-Bibliothek hätte. Aber das ist der Punkt: Es gibt höchstwahrscheinlich keine zentrale Bibliothek mit diesem Ansatz. Man kann eine erstellen, aber wirklich, ich bin mir nicht sicher, ob dieser Ansatz tatsächlich "CSS" genannt werden kann, weil es keine Kaskade gibt... und ich schätze, es gibt auch kein richtiges Sheet.
Gedanken dazu?
Zustimmung, Spezifität verschwindet vollständig. Mit Vue kann ich UI-Framework-Komponentenstile überschreiben, indem ich einfach die Spezifität verwende. Mit React und Styletron muss ich hoffen, dass der Entwickler eine adäquate API zum Überschreiben von Stilen bereitstellt.
Wenn Sie sich um das Scoping kümmern, schreiben Sie einfach verschachtelte SCSS. Problem gelöst.
CSS-in-JS entbindet Sie übrigens nicht vom Schreiben von sauberem Code.
Für mich sieht es aus wie eine große Ausrede für JS-Entwickler, sich nicht mit CSS zu beschäftigen.
Die Vorteile der Kaskade überwiegen bei weitem die Spezifität des Komponentenansatzes
(wie üblich ist die größte Stärke von etwas auch die größte Schwäche).
Aber man braucht ein ziemliches Verständnis von CSS, um es richtig zu machen.
Meine Frage ist also, sollten JS-Entwickler CSS lernen?
Ich bin hier bei Ihnen, es scheint nur eine Möglichkeit für JS-Entwickler zu sein, noch eine Sache zu übernehmen, die ihre Sprache nicht tun muss, um eine andere zu vermeiden zu lernen.
Ich verwende CSS-Module in React, aber ich liebe das Konzept von CSS-in-JS in einer Single File Component wie Vue und werde Emotion für mein nächstes Projekt verwenden.
Mein Punkt für CSS-in-JS ist, dass bei einer sehr großen modularen Anwendung mit Hunderten von Komponenten das Teilen von .css/.scss-Dateien zu technischer Schuld wird, da es schwierig ist, unbenutztes CSS zu verwerfen, wenn die CSS-Architektur nicht richtig organisiert war.
Mit CSS-in-JS, wenn Sie Ihre App refaktorisieren oder ganze Features verwerfen, geht das gesamte CSS schmerzfrei mit, reduziert die Bundle-Größe und verhindert Fehler.
CSS-in-JS fühlt sich für meinen an React und Storybook orientierten Geist wie eine großartige Lösung an. Ich habe das Konzept zuerst durch JSS kennengelernt, Styled Components ist so etwas wie ein Zwischenschritt. Emotion habe ich noch nicht ausprobiert. Aber all diese Bibliotheken sind für die Komponentenwelt geschaffen, wenn Sie keine Apps mit React/Vue oder einer dieser Bibliotheken erstellen, dann haben Sie wahrscheinlich keinen Nutzen für CSS-in-JS.
Und da sie hauptsächlich für Komponentenbibliotheken erstellt werden, stellt sich die Frage, ob wir die Komponentengestaltung in einer einzigen Komponentendatei kapseln oder sie in zwei Teile aufteilen sollen - einer im JS-Ordner, der andere im CSS-Ordner.
Bedenken hinsichtlich der Wartbarkeit scheinen eher ein Problem der Thematisierung als der Komponentengestaltung für Funktionalität zu sein. Wenn es um die Stilorganisation geht, habe ich mir zur Aufgabe gemacht, Thematisierung und Komponentenfunk-tionelle Stile zu trennen. Semantic UI hat zum Beispiel darauf geachtet, keine stilistischen Meinungen zur Thematisierung abzugeben und die Thematisierung als etwas völlig separates zu behandeln. Dasselbe gilt für das unglaublich beliebte Bootstrap und andere Frameworks. Dann spricht es dafür, dass vielleicht bestimmte Stilregeln zum Kern der Komponente gehören, die sich je nach Thema nicht ändern, und bestimmte Stilregeln sich je nach Thema ändern können.
Die Regeln, die sich nicht ändern, können in derselben Komponentendatei leben, 1 Komponente 1 Datei. Das lässt die Thematisierungsdateien sowieso getrennt, weil sie es sein sollten. Es macht für mich keinen Sinn, zu zwei Orten zu gehen, nur um eine Sache zu ändern - Redux gibt mir bereits Flashbacks, nein!
Die wichtigere Unterscheidung ist, wann etwas als "Thematisierung" zählt und wann nicht. Das erfordert nun Übung und Weisheit, die ich mir wünschte, jemand könnte mir jetzt in den Kopf beamen, und das wird die Quelle sein, wo das Chaos entsteht.
Aber seien wir ehrlich, wenn wir uns in einem Projekt befinden, bei dem wir Form vs. Funktion nicht trennen können oder das Produkt noch nicht reif genug ist, um den Unterschied zu erkennen, oder der Stil die Funktion ist, dann wird jede Überentwicklung das Projekt zurückhalten. "Überentwicklung" in einem solchen Fall wäre für mich die Rückkehr zu den Tagen von SASS oder LESS und das Beibehalten von zwei getrennten Verzeichnisbäumen für eine einzelne Komponente, während "Überentwicklung" für andere neue Technologien bedeuten kann, die zur Lieferung des Produkts nicht notwendig sind.
Warum nicht beides CSS und CSS in JS? Ich style den Großteil meiner Websites mit einer selbst entwickelten Utility-Class-Bibliothek. Aber Container Queries funktionieren besser in JS, also wenn die Utility-Bibliothek keine Utility hat und das Feature nicht allgemein genug ist, um eine Ergänzung der Bibliothek zu rechtfertigen, dann benutze ich CSS in JS, um das Problem zu lösen. Während ich Plain CSS stark bevorzuge, ist es nicht so, als müssten wir uns für das eine oder das andere entscheiden.
Ich denke, CSS-in-JS hat seinen Platz in der komponenten-basierten Architektur und es gibt Vor- und Nachteile. Man muss nur das richtige Werkzeug für den Job wählen. Ich denke, es gibt definitiv einen Hype um einige CSS-in-JS-Lösungen, bei denen Leute sie verwenden, um ein Problem zu lösen, das sie nicht haben.
Ich würde jedoch argumentieren, dass die meisten Nachteile in Bezug auf Skalierung und Code-Wiederverwendung umgangen und leicht genug implementiert werden können, z. B. durch Verwendung von Preprocessing, Mixins, Komponenten-Wiederverwendung, globalen Utility-Klassen usw.
Ob dies natürlich so in der Praxis aussieht und ob Entwickler tatsächlich die Vorteile nutzen und Code-Duplizierung vermeiden, ist eine andere Frage, obwohl dasselbe für große BEM-Codebasen gesagt werden könnte.
Auch, falls jemand interessiert ist, habe ich einen Kialo-Poll dazu gestartet, Entschuldigung für den Clickbait-Titel...
kialo.com/css-in-js-is-a-great-idea-29721