Dieser Beitrag ist eine detaillierte Antwort auf die Fragen aus diesem Gespräch auf Twitter . Der Autor des Originals, Sunil Pye, ist der Autor der relativ beliebten Glamour- Bibliothek und arbeitet als Entwickler auf Facebook.
Wie ist Javascript bequemer als CSS? Wie wird das Schreiben von CSS in JS besser unterstützt?
Ich werde gerne über dieses Thema sprechen. Ich muss sofort sagen, dass CSS-in-JS-Lösungen Overhead haben, aber normalerweise ist dieser Preis durch die Vorteile gerechtfertigt, die sie bringen. Manchmal können sie nützlich sein, aber dies bedeutet auch nicht, dass CSS-in-JS immer und überall verwendet werden sollte.
Das Wichtigste in CSS-in-JS (cij) sind also CSS-Selektoren. Der größte Vorteil von cij ist, dass Computer diese Selektoren automatisch generieren können. Konventionen wie OOCSS usw. Im Prinzip sind sie gut, aber sie basieren auf handgeschriebenen Selektoren, deren Eindeutigkeit im gemeinsamen Namespace nur schwer zu gewährleisten ist, da immer die Möglichkeit einer Überschneidung besteht. Wenn dies jetzt nicht der Fall ist, kann dies nach drei Jahren geschehen, wenn Ihr Team wächst und sich die Umstände ändern. Diese Situation wird durch Bibliotheken von Drittanbietern noch verschärft. Die Einschränkung des Umfangs von CSS-Selektoren kann auch mit CSS-Modulen erreicht werden, die gerade für diese Gelegenheit beliebt sind.
Bei all diesen Ansätzen ist es jedoch sehr schwierig, Selektoren statisch zu analysieren und herauszufinden, welche fehlerhaft sind (oder Tippfehler enthalten), was bedeutet, dass sie im Codeüberprüfungsprozess manuell überprüft werden müssen, was die Effektivität des Befehls verringert. Wir müssen die Hilfe von Computern nutzen und dürfen uns nicht auf die Integrität und Fehlerfreiheit von Menschen verlassen (weil dies nicht der Fall ist). CSS-in-JS ermöglicht die Automatisierung der Generierung eindeutiger Selektoren und Bezeichner.
Darüber hinaus eröffnet die verbesserte Kontrolle über CSS-Selektoren neue Möglichkeiten, die zuvor nicht leicht zugänglich waren. Zum Beispiel können wir einfach eine kritische CSS-Extraktion implementieren, indem wir HTML-Blöcke mit den benötigten Stilen abgleichen, sodass wir nur 1-2 KB CSS auf die Seite laden können, die für die anfängliche Anzeige der Seite benötigt wird. Ohne Laufzeit! Frameworks wie Gatsby und Next nutzen dies aktiv, um Leistungsindikatoren in darauf basierenden Projekten zu verbessern. Sie binden kritisches CSS direkt in das herunterladbare HTML ein, einfach weil es so wenig wiegt, dass es besser wäre als eine zusätzliche Anfrage, die das Laden von Seiten blockiert. Dies reduziert die anfängliche Renderzeit der Seite erheblich. Darüber hinaus trägt es auch zur Lösung der Probleme der herunterladbaren Javascript-Größe bei! Die Vorteile ergeben sich aus der Anwendung von kritischem CSS sowie der Verwendung von dynamischem import() , Code-Aufteilung und Entfernen von nicht verwendetem Code. (Im Gegensatz zu den ständig wachsenden Dateien im Legacy-Stil, in die Entwickler nur neuen Code einfügen, weil sie Angst haben, den vorhandenen zu berühren. Zu diesem Thema gibt es einige Analysen .)
Eine ähnliche Situation bei der Umsetzung von Themen. Wussten Sie, dass CSS-Variablen , auch wenn sie sehr interessant sind, nicht zu den Anwendungsfällen passen, für die sie ursprünglich vorgesehen waren, und das alles, weil die Fallback-Methoden für alte Browser entweder sehr kompliziert oder minderwertig waren? Dies bedeutet, dass sie normalerweise als globale Konstanten verwendet werden, aber sehr selten als Variablen, deren Wert im Browser dynamisch bestimmt wird. Mit einer CSS-CSS-Laufzeit können Sie Werte von JS an Stile übergeben, um dies zu ermöglichen.
Tatsächlich wird es Ihnen gefallen: Sie können endlich ehrlich CSS-Variablen in allen Browsern verwenden, dh native Funktionen ohne Laufzeit in Browsern, die sie unterstützen, und eine spezielle Laufzeit für ältere Browser. (Ich habe hier mehr darüber geschrieben und - wenn ich das richtig verstehe - ist dies die einzige Bibliothek, die dies erreicht hat).
In einer komplexen SPA-Situation mit einer Reihe von Komponenten und dem asynchronen Laden von Ressourcen wie Skripten und Stilen können Sie die genaue Reihenfolge der Ladestile nicht garantieren. Sie müssen also entweder Laufzeitlösungen erstellen, um die Reihenfolge der Stile zu gewährleisten, oder nur verwenden !important , sogar wenn Sie sich an eine Art CSS-Methode halten . Sie haben beispielsweise ein Element mit class=“ab” , aber die Klassen a und b in verschiedenen Stildateien definiert. Sie können sich der endgültigen Form des Blocks nicht sicher sein, wenn Sie keine eindeutige Reihenfolge der Stildateien haben. Die Facebook-Codebasis enthält Tausende von Verwendungen von !important , obwohl der Code von qualifizierten Programmierern unter Verwendung von SOLID-Prinzipien und guter Interaktion mit dem Designteam geschrieben wurde.
Dies bezieht sich oft auf den Umgang mit CSS als wäre es Javascript - da wir vor 10 Jahren bereits ähnliche Probleme für JS gelöst haben - Bibliotheken und Module haben sich im globalen Namespace ( $ und dergleichen) registriert und mussten bei der Verbindungsreihenfolge sehr vorsichtig sein Skripte in HTML. Aber wir waren nicht für immer dort festgefahren - jetzt verwenden wir Module und Montagesysteme nähen sie in einer garantiert korrekten Reihenfolge zusammen. Das ist für uns einfach und transparent.
Beim Betrachten realer Projekte ist mir auch aufgefallen, dass Sie in der CSS-in-JS-Welt weiterhin traditionelle Architekturansätze (wie OOCSS oder SMACSS usw.) verwenden können. Elemente dieser Architekturen werden hier durch JS-Objekte anstelle der + Auswahlblöcke dargestellt Stile. Ich gehe so vor und es funktioniert gut für mich. Hier können Sie mehr darüber lesen.
Ich bin mir auch der Nachteile von CSS-in-JS bewusst. Genau aus diesem Grund gibt es keine „kanonische“ Bibliothek, die CSS-in-JS darstellt - es handelt sich um ein Spektrum verschiedener Lösungen, von statischem Vanille-CSS einerseits bis zu volldynamischen Bibliotheken wie gestylten Komponenten andererseits. Präprozessoren wie SASS oder LESS scheinen senkrecht zu diesem Spektrum zu sein, da sie theoretisch von jeder dieser Bibliotheken nach Ermessen ihrer Autoren verwendet werden können. Jede dieser Bibliotheken hat ihre Nachteile: Einige extrahieren Stile in der Assembly-Phase, damit keine Laufzeitkosten entstehen, andere konzentrieren sich auf die Richtigkeit oder Bequemlichkeit für Entwickler, andere auf die effektive Implementierung komplexer Animationen und so weiter. Diese Vielfalt ist eine natürliche Reaktion auf die Notwendigkeit unterschiedlicher Lösungen für unterschiedliche Arbeitsaufgaben in einer zu schnell wachsenden Branche. Dies geschieht nicht nur bei Bibliotheken - Entwickler von Webstandards (ShadowDOM und andere) versuchen auch tapfer, diese Probleme zu lösen, sondern ihre Lösung weist auch Nachteile auf, von denen das geringste darin besteht, dass sie noch nicht überall verfügbar sind, was die Verwendung inakzeptabel macht in vielen Teams.
Früher hatte ich starke Gefühle dafür, aber ich habe meine Ansichten in den letzten Monaten gemildert. Es stellt sich heraus, dass die Wahrheit tatsächlich irgendwo in der Mitte liegt - es hängt von den Teams, Anforderungen, Zeit, Dokumentation und vielen anderen Faktoren ab. Darüber hinaus glaube ich nicht, dass dieser Text die „endgültige Form“ dieser Idee darstellt. Wir sollten das Experimentieren in diesem Bereich fördern, damit wir herausfinden können, was wir sonst noch besser machen können, und einige dieser Dinge sogar in Browser einbetten.
PS Zu spät wurde mir klar, dass ich vergessen hatte, das Kontrollkästchen "Übersetzung" zu aktivieren, daher wurde es so veröffentlicht. Link zum Original .
Habr, korrigiere die Schnittstelle. Warum kannst du das Übersetzungsflag nach der Veröffentlichung nicht hinzufügen?