Was aus »Separation of Concerns« in der Frontend-Entwicklung geworden ist

Artikel vom 14. Dezember 2023. ISSN 1614-3124, #77. Schwerpunkt: (RSS-Feed für alle Themen).

Nicole Sullivan fragte die Entwicklergemeinschaft neulich, ob uns »Separation of Concerns« (SOC) – Trennung von Belangen, wie HTML-Struktur und CSS-Präsentation – noch dienlich sein würde. 58% antworteten SOC »funktioniere noch«, aber das Thema mutete komplexer und interessanter an.

Mein Gefühl und meine Entgegnung waren, dass es eine »große Ironie« gäbe – frei übersetzt, dass die »Trennung anfing, zu funktionieren, als viele vor etwa zehn Jahren aufhörten, sie anzustreben«, da dies der Zeitpunkt war, an dem »wir immer bessere CSS-Selektoren und Unterstützung für diese hatten, und JavaScript signifikant erweitert wurde«, aber auch »der Aufstieg der Frameworks begann, der den Niedergang von Dingen wie SOC beschleunigte und bedeutete«. Ich schloss damit, dass es »der Trennung nie besser ging – und auch nie schlechter«.

Ist es das, was mit der Trennung von Belangen passierte, in unserem Feld? Kann ich dies untermauern? Vielleicht.

Inhalt

  1. Was SOC ermöglicht, und was SOC verhindert
  2. SOC-Verbesserungen durch Webstandards
  3. SOC-Regressionen in Frameworks
  4. Die groĂźe SOC-Ironie

Was SOC ermöglicht, und was SOC verhindert

Was ermöglicht oder verhindert aber die Trennung von Belangen?

Die Antwort scheint zugleich einfach und schwierig.

Sie ist einfach, wenn wir danach gehen, dass »alles was Dokumentinhalte und -struktur anbelangt in HTML, alles was Darstellung in CSS, und alles was Verhalten anbelangt in JavaScript gehandhabt wird, und die Berührungspunkte auf das absolute Minimum beschränkt werden«.

Sie ist schwierig, wenn wir uns die einzelnen Möglichkeiten anschauen, die Trennung ermöglichen und verhindern, weil sie von spezifischen Funktionen von HTML, CSS und JavaScript (insbesondere der verschiedenen Arten, auf denen diese sich mit den anderen Sprachen überschneiden) sowie von Engineering-Prinzipien und -Kultur abhängen. Die Trennung von Belangen steht und fällt damit, aufgesucht und ausgeübt zu werden.

Es war schwer, diese Trennung in den 2000ern umzusetzen, und ist heute einfach, aber es gab damals ein paar Websites, auf denen sie erreicht wurde, genauso wie es heute viele Websites gibt, wo sie nicht respektiert wird. Das geht auf die Kappe von Engineering-Prinzipien und -Kultur, nicht von Webstandards oder Browser-UnterstĂĽtzung.

SOC-Verbesserungen durch Webstandards

Die leichteste Art, um Verbesserungen festzustellen, mag sein, auf CSS-Selektoren und Unterstützung für selbige zu schauen. Das liegt daran, dass alle Websites HTML einsetzen, und mehr Websites CSS als JavaScript verwenden; und es liegt daran, dass je weniger Bedarf es an Klassen und IDs gibt (die vorherrschenden Selektionsoptionen), desto höher die Wahrscheinlichkeit ist, HTML und CSS und damit Belange zu trennen.

Die Hypothese lautet anders ausgedrückt, dass wir in der Frontend-Entwicklung die geringste Trennung von Belangen, und ihre größte Vermengung, bei präsentationsbezogenem Markup beobachten – und dass das Bereitstellen effektiverer Selektoren dazu beiträgt, die Menge an präsentationsbezogenem Markup zu verringern.

Genau zu sagen, wie sich die Situation um Selektoren herum entwickelte, ist jedoch kompliziert, zeitaufwendig und fehleranfällig, da es erfordert, jeden Selektor zu prüfen; und dann nicht nur zu schauen, wann er spezifiziert wurde, sondern wann er erstmals unterstützt wurde; in jedem User-Agent; um dann deren Marktanteile zu ermitteln und berücksichtigen.

Vielleicht können wir etwas Gröberes, aber dennoch Aussagekräftiges probieren:

CSS-Spezifi­kation Anzahl Selek­toren Jahr des ersten Spe­zifika­tions­entwurfs Jahr der Spe­zifika­tions­veröffent­lichung
CSS 1 10+ ? 1996
CSS 2.1 22+ ? 2011
CSS Selectors Level 3 41? 2009? 2018
CSS Selectors Level 4 70+ 2011 ?

Ich war hier sehr schnell unterwegs, weil mich die Hausnummern interessierten. Wenn du Feedback und Anregungen senden möchtest, nehme ich gerne Anpassungen vor. (Danke!)

Zwar ist dies alles grob, aber dennoch finden wir eine interessante Gruppierung um 2010 herum: Um diese Zeit erreichte CSS 2.1 Reife, und Arbeit an CSS Selectors Level 3 und CSS Selectors Level 4 begann. Zudem können wir in diesem und den Folgejahren verbesserte Unterstützung für Selektoren erwarten.

Insgesamt kann man Anzeichen finden, dass die Trennung von Belangen zwischen HTML und CSS um 2010 herum deutlich einfacher wurde.

SOC-Regressionen in Frameworks

Schauen wir uns jetzt Frameworks an, um zu prüfen, ob etwas an der Idee dran ist, dass ihr Aufkommen gegen die Möglichkeiten lief, Belange zu trennen, die uns die Weiterentwicklung von CSS brachte.

Für diesen Zweck analysierte ich etwa 60 Frameworks (einschließlich der, die ich in The Little Book of HTML/CSS Frameworks aufzählte, und später ergänzte):

Viele weitere Frameworks wurden um 2010 herum (±4 Jahre) veröffentlicht, was bedeutet, dass dies keine vollständige Aufzählung ist, aber wir hier dennoch abbrechen können.

Es gibt einige Anzeichen, dass wir seit etwa dieser Zeit neue Frameworks hatten, die Belange nicht trennten, sondern diese mischten.

Die groĂźe SOC-Ironie

Was ist passiert, und können wir also von Ironie sprechen, wenn es um die Trennung von Belangen in der Frontend-Entwicklung geht?

Es scheint so. Die Trennung von Belangen war lange schwierig, und einer der einschränkendsten Faktoren war Selektorenvielfalt und -unterstützung.

Genau als sich das änderte, und mehr CSS-Selektoren eingeführt und unterstützt wurden, beobachteten wir eine große Zahl von Frameworks, die Darstellung an die Struktur koppelten, besonders durch den Gebrauch von präsentationsbezogenen Klassennamen.

Anstatt die neuen Selektoren zu verwenden (oder, um genauer zu sein, weniger, funktionale oder generische Namen zu benutzen), um das Markup zu verringern und es auf zukünftige CSS-Redesigns zu optimieren, gaben Frameworks diese Möglichkeit aus der Hand und garantierten vielmehr, dass Redesigns auch HTML-Änderungen erforderlich machten. Die enge Kopplung, die sie mit sich brachten, bedeutete das Gegenteil einer Trennung von Belangen.

❧ Bevor ich schließe, möchte ich betonen, dass weitere Daten helfen würden. Ich habe mit groben Zahlen für CSS-Selektoren gearbeitet, und konnte nicht »alle« Frameworks analysieren. Weitere Daten mögen die Hypothese stützen, oder eine neue erfordern. (Dazu könnte man auch nach Fällen schauen, in denen sich Trennung von Belangen tatsächlich verbessert hat.)

Schlussendlich möchte ich unterstreichen, was die Mehrheit in Nicoles Beitrag zum Ausdruck brachte – Trennung von Belangen, »Separation of Concerns« funktioniert. Sie könnte noch besser funktionieren, wenn wir mehr Unterstützung für alte aber ziemlich coole Features wie Stylesheet-Referenzen in HTTP-Headern hätten (Beispiel und Kontext), aber:

Die Trennung von Belangen funktioniert besser, als sie es je tat. Wir – und unser Tooling – machen wahrscheinlich nur keinen guten Gebrauch von ihr.

Mit Dank an Lars Knudsen fĂĽr Feedback zu diesem Beitrag.

War dies nützlich oder interessant? Teile (toote) diesen Beitrag, oder lad mich vielleicht auf einen Kaffee ein. Danke!

Ăśber mich

Jens Oliver Meiert, am 30. September 2021.

Ich bin Jens, und ich bin ein Engineering Lead und Autor. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin W3C und WHATWG verbunden und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Mit meinem aktuellen Umzug nach Spanien bin ich offen für eine neue Führungsposition im Frontend-Bereich. Beachte und empfehle gerne meinen Lebenslauf oder mein LinkedIn-Profil.

Ich experimentiere gerne, nicht nur in der Webentwicklung, sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Ansichten und Erfahrungen.