Das *g* zum Wochenende: CSS: A New Kind Of JavaScript
Gunnar Bittersmann
- css
- javascript
- lesetipp
-1 Felix Riesterer0 Rolf B0 Robert B.0 pl
Ist zwar erst Donnerstag und erst für die wenigsten schon Wochenende, aber das will ich euch nicht bis morgen vorenthalten:
#CSS: A New Kind Of JavaScript [1]
Heydon Pickering hat das Ganze mal auf den Kopf gestellt und so die ganze Absurdität von CSS-in-JS aufgezeigt – mit dem ihm eigenen Sinn für Spott. Köstlich!
LLAP 🖖
Verlinkt jetzt auf Heydons eigene Website. Der Artikel ist auch auf medium.com zu lesen. ↩︎
Lieber Gunnar,
schnarch
Heydon Pickering hat das Ganze mal auf den Kopf gestellt und so die ganze Absurdität von CSS-in-JS aufgezeigt – mit dem ihm eigenen Sinn für Spott. Köstlich!
Er hätte mal lieber einen Artikel geschrieben, wie man mit JavaScript Animationen berechnet, um sie als CSS-Code via <style>
in den <head>
zu injizieren. Das kann nämlich sehr performant laufen und ist für den JavaScriptler wunderbar mit Templates (also vorgefertigten CSS-Code-Schnipseln) zu machen!
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Er hätte mal lieber einen Artikel geschrieben, wie man mit JavaScript Animationen berechnet
Ist das sein Steckenpferd? Wenn nein, warum sollte er dann solch einen Artikel schreiben?
Das tun andere. Ich glaube, du suchst Artikel/Vorträge von Ania Migas (szynszyliszys).
LLAP 🖖
Er hätte mal lieber einen Artikel geschrieben, wie man mit JavaScript Animationen berechnet
Ist das sein Steckenpferd?
Sein Steckenpferd scheint das typisch herablassende Witzeln eines Schnösels über andere zu sein, und zwar nicht, weil das dumme Zeug der anderen so witzig ist, sondern einfach, weil er sich für was Besseres, einen Auserwählten hält.
Dass du das auch witzig findest, wundert mich nicht.
@@Walter
weil er sich für was Besseres, einen Auserwählten hält.
Mein Gott, Walter! Du kennst Heydon persönlich?
Ich kenne ihn und ich habe nicht den Eindruck, dass er sich für was Besseres hält.
Ich würde auch nicht behaupten, dass die CSS-in-JS-Jünger sich für was Besseres halten. Nur dass sie CSS-in-JS für was Besseres halten, und da gibt es gute Gründe dagegenzuhalten.
LLAP 🖖
Lieber Gunnar,
Mein Gott, Walter! Du kennst Heydon persönlich?
das muss er nicht. Die Texte Heydons darf ein jeder selbst mit seiner eigenen Wahrnehmung empfinden, wie er oder sie das eben wahrnimmt.
Ich kenne ihn und ich habe nicht den Eindruck, dass er sich für was Besseres hält.
Im Beisammensein wirkt fast jeder Mensch anders, als in einer rein schriftlichen - und damit bis zu einem gewissen Grad entpersonalisierten - Kommunikation. Walter hat nur Heydons Aufsätze, Du hast ihre Inhalte im Kontext Deiner persönlichen Bekanntschaft mit Heydon. Das ist ein sehr großer Unterschied!
Ich würde auch nicht behaupten, dass die CSS-in-JS-Jünger sich für was Besseres halten. Nur dass sie CSS-in-JS für was Besseres halten, und da gibt es gute Gründe dagegenzuhalten.
Aber ihre Selbstdarstellung im Netz wirkt auf viele Nicht-Insider ganz schnell so. Erinnerst Du Dich an meine Vorwürfe, Du (und andere) wollten missionieren? Woher das wohl kam... ist auf jeden Fall dieselbe Quelle wie Walters Reaktion.
Liebe Grüße,
Felix Riesterer.
Ich würde auch nicht behaupten, dass die CSS-in-JS-Jünger sich für was Besseres halten. Nur dass sie CSS-in-JS für was Besseres halten, und da gibt es gute Gründe dagegenzuhalten.
Ich habe auch herzlich über den Artikel gelacht, hättest du ihn hier nicht geteilt, hätte ich das vermutlich getan. Eine ernsthafte Diskussions-Grundlage kann der Artikel aber gar nicht sein, viele Witze funktionieren nur wegen drastischer Verkürzung von CSS-in-JS-Lösungen auf das CSS Object Model. Beispielsweise unterstützen die meisten CSS-in-JS Frameworks serverseitiges Generieren von CSS-Dateien und müssen damit nicht im Browser ausgeführt werden. Der CSS-in-JS Community geht es nicht darum ein neues Paradigma zu beschwören, sondern Lösungen für diverse Probleme von CSS zu finden - das Mittel der Wahl ist dafür JavaScript (konträr zu anderen Lösungen wie SASS oder Less). Mal geht es darum, die Dateigröße von CSS zu minimieren, mal darum Dead-Code zu eliminieren, mal um die Interopabilität mit Komponenten-basierten JS-Frameworks, und manchmal auch nur darum einen Weg zu finden strukturiert Stylesheets zu schreiben. Eine ernsthafte Kritik sollte sich detailliert mit den Problemen befassen und alternative Lösungsvorschläge diskutieren. Aber ich schätze auch humorvolle Beitrag zur Debatte, wenn nichts anderes, lockert es zumindest die Stimmung etwas auf.
@@1unitedpower
Der CSS-in-JS Community geht es nicht darum ein neues Paradigma zu beschwören, sondern Lösungen für diverse Probleme von CSS zu finden
Ich habe eher den Eindruck, sie sehen oftmals als Probleme an, was sie nicht verstehen: Kaskade, Spezifität, Andersartigkeit von CSS gegenüber JavaScript. Was aber gar keine Probleme sind, die „gelöst“ werden müssten. Genau das nimmt Heydon aufs Korn.
LLAP 🖖
@@1unitedpower
Der CSS-in-JS Community geht es nicht darum ein neues Paradigma zu beschwören, sondern Lösungen für diverse Probleme von CSS zu finden
Ich habe eher den Eindruck, sie sehen oftmals als Probleme an, was sie nicht verstehen: Kaskade, Spezifität, Andersartigkeit von CSS gegenüber JavaScript. Was aber gar keine Probleme sind, die „gelöst“ werden müssten. Genau das nimmt Heydon aufs Korn.
Ich versuch mal anhand von styled-components zu erklären, wo die Vor- und Nachteile von CSS-in-JS liegen. Dazu hol ich mal etwas weiter aus, auch in dem Wissen, dass nicht jeder Leser schon mal von CSS-in-JS gehört haben wird. Zu HTML4-Zeiten war HTML noch eine Suppe aus semantischen und präsentations-bezogenen Elementen:
⸾ ⸾ ⸾ ⸾
┌───────┐
│ Suppe │
└───────┘
Spätestens mit HTML5 hat sich eine klare Trennung der Zuständigkeiten durchgesetzt: HTML dient der semantischen Auszeichnung der Dokumentstruktur und CSS der Präsentation:
┌───────┐
│ HTML │
├───────┤
│ CSS │
└───────┘
Seit einigen Jahren hat sich zu dieser vertikalen Trennung der Zuständigkeiten auch eine horizontale Trennung gesinnt. Wiederverwendbare UI-Widgets, wie Navigationen oder Map-Views, werden als unabhängige, in-sich-abgeschlossene Komponenten entwickelt. Das macht aus Software-Engineering-Perspektive Sinn, weil der Verwender des Map-Views nicht die Implementations-Details kennen muss, sondern nur die öffentliche Schnittstelle.
┌──────────────────┬──────────────┐
│ Navigation HTML │ MapView HTML │
├──────────────────┴──────────────┤
│ CSS │
└─────────────────────────────────┘
styled-components spinnen diese Idee weiter, und erlauben die horizontale Trennung auch dem CSS-Layer fortzusetzen:
┌──────────────────┬──────────────┐
│ Navigation HTML │ MapView HTML │
├──────────────────┼──────────────┤
│ Navigation CSS │ MapView CSS │
├──────────────────┴──────────────┤
│ Globales Theme CSS │
└─────────────────────────────────┘
Der Hintergrund-Gedanke ist ein ähnlicher: Der Verwender einer stilisierten Komponente, sollte sich nicht mit den Implementations-Details rumschlagen, sondern nur mit einer definierten CSS-Schnittstelle. Die Schnittstelle bildet ein sogenannter ThemeProvider, das ist eine globale Sammlung von CSS-Regeln, die von allen Komponenten geteilt werden.
Das hat ein paar Nachteile:
Aber auch ein paar Vorteile
hallo
- Man vermeidet toten CSS-Code und CSS-Wucher
Ich glaube nicht, dass das gewucher mit JS weniger wird. Und ich glaube angesichts des Caches nicht an totes CSS.
Die Frage ist halt, ist man in der Lage Site-übergrifend eine einzige Style-Guideline zu vertreten, dann sind CSS-Angaben in Komponenten Gift.
Ist man dazu aber nicht in der Lage, weil man sich à la Zen-Garden präsentiert, dann sind Komponenten-CSS die einzig Gewähr für operable Komponenten.
Ideal aber wäre, wenn eine Komponente mit ihrem eigenen Default CSS daher kommt, welche dann bedingt in toto ersetzt werden kann durch das der übergeordneten Styleguide folgende Styleheet, falls sich der Autor darum kümmert.
Dazu bräuchte es aber eine Erweiterung der Syntax.
<body
<component>
<h1>
~~~
Eigentlich sollte die Regel
body h1 {}
gar nicht die Komponente berühren dürfen, wenn der Autor der Komponente sein CSS vor Überschreibung schützen will.
Mir fallen derzeit nur iframes ein, um CSS abzukapseln.
Das CSS mit ID-Selektoren vollzupfeffern ist ein no go.
--
Neu im Forum!
Signaturen kann man ausblenden!
Die Frage ist halt, ist man in der Lage Site-übergrifend eine einzige Style-Guideline zu vertreten, dann sind CSS-Angaben in Komponenten Gift.
Vielleicht verstehe ich dich falsch, aber das klingt für mich nach Theming. Ich habs vermutlich nicht ausführlich genug erklärt.
Ideal aber wäre, wenn eine Komponente mit ihrem eigenen Default CSS daher kommt, welche dann bedingt in toto ersetzt werden kann durch das der übergeordneten Styleguide folgende Styleheet, falls sich der Autor darum kümmert.
Du hast JavaScript, ein Default-Style ist damit kein Problem:
const styledH1 = styled.h1`color: ${props => props.theme.color || 'black'};`
Mir fallen derzeit nur iframes ein, um CSS abzukapseln. Das CSS mit ID-Selektoren vollzupfeffern ist ein no go.
Stilisierte Komponenten haben immer isolierte Scopes und du wirst nur in Ausnahmefällen mit CSS-Selektoren in Berührung kommen, weil sie vom Compiler automatisch generiert werden. Max Stoiber, einer der Erfinder von styled-components, erklärt in dem verlinkten Video wie das funktioniert und wie sie auf die Idee gekommen sind. Wenn du nur nach einer Scoping-Lösung suchst, dann gäbe es da noch css-modules
Hallo Gunnar,
ich habe mich vor allem bei den Kommentaren weggeschmissen.
Rolf
hallo
ich habe mich vor allem bei den Kommentaren weggeschmissen.
Darf man fragen, wie du das gemacht hast?
Hallo beatovich,
nein. Das wäre mir peinlich…
Rolf
Hallo Gunnar,
das ist ja eine innovative Technik!
Ich hätte noch weitere Vorschläge Webapps zu vereinfachen:
span
hinzugefügt werden kann und implizit den Click-Handler sowie das Ersetzen der location
durch den Wert der Referenz erledigt.div
s und span
s mit ein paar Standardvorgaben des Styles als so eine Art „Templatebaukasten“, z.B. „h1“ für den Titel eines Blocks (groß und bold) mit ein paar Abstufungen für Zwischenüberschriften oder „em“ für etwas kursiv Hervorgehobenes.Viele Grüße
Robert
@@Robert B.
das ist ja eine innovative Technik!
Nicht wahr‽
Ich hätte noch weitere Vorschläge Webapps zu vereinfachen:
Web…? Was für Apps?
- Ein Attribut „href“ (Hyperreferenz), das ähnlich zu data-* zu einem
span
hinzugefügt werden kann und implizit den Click-Handler sowie das Ersetzen derlocation
durch den Wert der Referenz erledigt.
Das nenne ich doch mal innovativ! Das weitergedacht: Damit könnte man ja wirklich sowas wie ein Web weben. Und das gar weltweit!
LLAP 🖖
das erinnert mich an meinen Kollegen Helmut der im Sommerschlußverkauf eine Jacke beim Anprobieren einfach nicht zugeknöpft bekam -- Obwohl er es wohl mindestens 20x probiert hat, irgendwie war immer der Bauch im Weg.
Dummerweise haben das einige der anderen Kollegen mitbekommen.. und selbst Jahre später, immer dann, wenn sich Helmut eine Jacke anzog, brach die ganze Bande in ein schallendes Gelächter aus. Und das umso mehr, je dümmer Helmut schaute 😉
Der weiß bis heute nicht warum wir damals so gelacht haben. MfG
@@pl
das erinnert mich an meinen Kollegen Helmut der im Sommerschlußverkauf eine Jacke beim Anprobieren einfach nicht zugeknöpft bekam […]
Der weiß bis heute nicht warum wir damals so gelacht haben. MfG
Ich werd auch morgen nicht wissen, warum dich Heydons Artikel an Helmut erinnert. Vielleicht ist es das H am Anfang des Vornamens. Ansonsten hat das Eine mit dem Anderen nichts zu tun, IMHO.
LLAP 🖖
Ansonsten hat das Eine mit dem Anderen nichts zu tun, IMHO.
Doch, hat es. Ne ganze Menge sogar 😉
Also dann, bis zum nächsten g zum Wochenende.
MfG
Der weiß bis heute nicht warum wir damals so gelacht haben.
Tolle Mobbing-Aktion, total witzig und charakterstark von euch. Statt dich damit zu brüsten, solltest du dich in Grund und Boden schämen.
Hallo 1unitedpower,
Tolle Mobbing-Aktion, total witzig und charakterstark von euch. Statt dich damit zu brüsten, solltest du dich in Grund und Boden schämen.
Den gleichen Gedankengang hatte ich auch gerade.
LG,
CK