Die Ergebnisse des „State of CSS“ Surveys erscheinen bald und ich ahne jetzt schon mal, dass sich das seltsame Gefühl, das ich schon beim Ausfüllen hatte, noch verstärken wird. Ich finde ja die Antwortmöglichkeiten „Nie davon gehört“, „Kenne ich (habe es aber noch nicht verwendet)“ und „Habe ich verwendet“ wirklich treffend, hatte aber die ganze Zeit das schlechte Gefühl, zwar ein hochinformierter Entwickler zu sein („kenn’ ich, kenn’ ich, kenn’ ich, das auch und das sowieso“), mein Wissen aber viel zu selten einzusetzen. Oder zumindest nicht dazu komme, es einzusetzen. Das mag ja auch etwas mit dem Alter zu tun haben, als ich mit Mitte Zwanzig die Nächte durchgecodet habe und alles ausprobiert habe, was nicht bei drei wieder deprecated war, kannte ich zunächst wenig, habe aber alles ausprobiert und angewendet. Heute komme ich mit dem Set an CSS aus, das ich mir in den letzten Jahren (Jahrzehnten) erarbeitet habe. Altes CSS ist schneller geschrieben, als neues gelernt. Und dann ist ja auch immer die Browserunterstützung so wichtig!
Ich merke das an jungen Kollegen, die sich über jeden Fitzel an Information über neues Zeug erfreuen und ununterbrochen darüber reden wollen, was sie wieder geiles gestern Abend ausprobiert haben. Und ich frag man dann so, ob die keine Familie haben (natürlich nicht!).
Dabei ist das so schade! Viele der neuen Techniken sind hochinteressant und lösen meist Dinge elegant, die früher™ nicht gingen. Trotzdem habe ich, privat oder auf der Arbeit, viele Sachen noch nicht in den produktiven Einsatz gebracht, auch wenn sie schon breite Browserunterstützung haben, oder sogar baseline sind. Ein paar Beispiele: Container Queries, Subgrid, color(), den CIE LAB Farbraum, text-wrap: balance, @property, @layer, ich könnte noch Stunden so weiter machen, aber das ist schon so peinlich genug.
Aber mal ehrlich, was geht hier schief? Ganz einfach: das meiste funktioniert auch ohne diese Features. Es sind teilweise wirkliche Technologiesprünge, auf die wir ewig gewartet haben (bspw. Container Queries), aber sie wirken eben eher nach innen. Damals™, wir hatten ja nichts, als box-shadow eingeführt wurde, da kam uns das wie eine CSS-Mondlandung vor. Mit einer Zeile Code stundenlanges Grafikschnippeln und nächtelange Diskussionen mit renitenten Designer*innen auf einen Schlag aus der Welt geschafft, das war Fortschritt! Dagegen stinken Container Queries irgendwie ab, weil ging ja bisher auch ohne…
Zum Glück kann ich anderen Leuten sagen, sie sollen mal dies oder jenes ausprobieren. Denn wenn ich das (in meiner Position als Teamlead und Frontend-Graubart) mache, fühlen sich die jungen Leute legitimiert und haben noch mehr Spaß daran. Und hinterher können sie mir dann die Praxisbeispiele zeigen. 😉 Alternativ könnte ich das natürlich auch so wie früher an meinen privaten Projekten ausprobieren, hier hätte ich ja noch eine Menge Raum dafür. Aber wie gesagt, ich hab ja Familie…
3 Comments
Da wird ja parallel altern ist es vermutlich kein grosses Wunder, wenn ich jetzt festhalte, dass ich sehr ähnlich fühle. Aber … neben dem “Ich hab Routine in alten Dinge”-Faktor, gibt es aber glaube ich noch einen weiteren Aspekt, der die Einführung neuer Techniken erschwert: Bestehende Code-Basen, je grösser, desto schlimmer. Davor hat uns Getting Real immer gewarnt und es ist weiterhin wahr. Aber das ist latürnich nur ein Hinderniss, aber kein Grund dagegen. Vermutlich kommt man langfristig einfach nicht drum rum, bei grossen Code-Basen Bereiche mit unterschiedlichem Technik-Status zu haben.
That being said: Container-Queries … mega-geil!
Parallel dazu erwische ich mich aber auch ständig dabei, dass ich denke: Der Wert, dem wir Technik in den 00er zugemessen haben, war eigentlich nicht richtig. Wir hätten uns mehr auf Content konzentrieren sollen … aber vielleicht ist das auch nur ein Teufelchen auf meiner Schulter.
Hi Ben!
Wie zum Teufel hast du mich hier so schnell gefunden? Ich wollte doch erstmal Content aufbauen im Geheimen. 😀
Was die Größe der Codebase angeht: die kann ich nicht als Ausrede bringen. Wir haben ja nicht nur unsere Teams aufgeteilt, sondern eben auch die Codebasen. Wir zerschneiden den ollen Monolythen wo es eben geht und ich habe mir mit meinem Team einzelne Brocken herausgehauen: Kommentarsystem (eine Basis), Engangement-Elemente (Schranken, Abonerv, eine Basis), Spiele usw. Dadurch haben wir schon einiges an Flexibilität gewonnen, bspw. um Svelte einzuführen.
Designerisch sind wir natürlich vom Mutterschiff abhängig, aber gerade so Layoutzeug wie Container Queries könnten wir bestimmt ausprobieren. Ich setze da wirklich auf die jungen Leute 😛 obwohl, denen muss ich erstmal abgewöhnen alle Nase lang Tailwind und TypeScript auszupacken… 😀
Gute Frage, ich sehe ja jetzt erst, dass das hier unter einer .dev top level domain läuft. Also die Antwort: Über meinen Feedreader. Der behauptet aber die Feed-URL für den Feed zu “Nico Brünjes Blog” laute http://nicobruenjes.de/feed/ … ah und … siehe da: Das leitet um zu https://nicobruenjes.dev/feed/ … there you have it.
Container Queries haben wir überigens auch in einer fette Code-Basis als nachträgliches Feature eingebaut. Zusammen mit Single-Directory Components (aka “Ich-bin-gar-kein-Storybook”-Storybook ). Ging gut.