Weniger verdammten Code schreiben

Originaltitel: Writing Less Damn Code, http://www.heydonworks.com

Ich bin nicht gerade der begabteste Coder der Welt. Nein, wirklich nicht. Also versuche ich, so wenig Code wie möglich zu schreiben. Je weniger ich schreibe, desto weniger kann kaputtgehen, muss in Ordnung gebracht oder gewartet werden.

Ich bin aber auch faul, deshalb ist es alles nur Sauce. (ed: Vielleicht die Nahrungs‐Vergleiche lieber bleiben lassen?)

Aber dann stellt sich heraus, dass weniger zu schreiben auch der sicherste Weg ist, performantes Zeug im Web zu produzieren. Minifizieren? Okay. Komprimieren? Naja. Cache? Hört sich technisch an.
Von Anfang an ablehnen, etwas zu coden oder Code von jemand anderem einzubinden? Da kommen wir der Sache näher. Was am einen Ende hineingeht, muss am anderen in irgendeiner Form wieder herauskommen, sei es gekaut und durch die Magensäfte aufgelöst oder auch nicht. (ed: Ich habe mir das mit den Nahrungs‐Vergleichen nochmal überlegt)

Und das ist noch nicht alles. Anstatt auf gefühlte Performancegewinne zu setzen — also immer noch dieselbe Menge Code zu senden, aber vorher zu zerkauen (ed: ernsthaft) — kann man das Web‐Zeugs tatsächlich billiger machen. Meinem Datentarif ist es nämlich egal, ob mehrere kleine Häppchen oder ein großer Brocken übertragen werden; es ergibt am Ende dieselbe Summe.

Das beste am Streben nach weniger Code ist: Man hat am Ende nur das, was man wirklich braucht — nur das, was der Nutzer tatsächlich will. Ein riesiges Hero‐Image von einem Typ, der seinen Latte trinkt? Weg damit. Social‐Media‐Buttons, die Unmengen von Fremdcode einbinden und gleichzeitig Ihr Seitenlayout kaputtmachen? Rausschmeißen. Dieses Javascript‐Dingens, das dem Nutzer die rechte Maustaste entführt, um ein eigenes Menü anzuzeigen? Ab damit ins ewige Eis.

Es aber geht nicht nur darum, womit man die UX schädigt oder eben nicht. Die Art und Weise, wie man seinen (eigenen) Code schreibt, ist gleichzeitig ein großer Beitrag dazu, weniger davon zu schreiben. Hier sind ein paar Tipps und Ideen, die dabei helfen könnten. Über manche von ihnen habe ich früher schon geschrieben, aber im Zusammenhang mit Accessibility und Responsive Design. Ein flexibles, zugängliches Web führt ganz automatisch dazu, dass wir weniger versuchen, es zu kontrollieren. Code nicht zu schreiben, heißt oft auch, Code nicht umzuschreiben.

WAIARIA

Zunächst mal: WAIARIA != Web Accessibility. Es ist nur ein Mittel, um da, wo es nötig ist, die Kompatibilität mit gewissen assistiven Technologien zu verbessern, etwa Screenreadern. Deshalb ist die wichtigste Regel der Verwendung von ARIA, WAIARIA nicht einzusetzen, wenn es nicht sein muss.

LOL, also nicht so:

<div role="heading" aria-level="2">Subheading</div>

Sondern so:

<h2>Subheading</h2>

Der Vorteil bei der Verwendung geeigneter Elemente ist, dass man oft auch kein besonderes Verhalten coden muss. Die folgende Checkbox‐Implementierung ist nicht nur sehr viel HTML, sondern braucht auch noch Javascript, um Zustandswechsel zu realisieren und das Standard­verhalten sicherzustellen, Standardverhalten im Hinblick auf das name‐Attribut und die GET‐Methode. Es ist mehr Code, und weniger robust. Juhu!

<div role="checkbox" aria-checked="false" tabindex="0" id="checkbox1" 
     aria-labelledby="label-for-checkbox1"></div>
<div class="label" id="label-for-checkbox1">My checkbox label</div>

Styling? Keine Sorge, ist mit abgedeckt. Das heißt, wenn man überhaupt ein eigenes Styling braucht.

<input id="checkbox1" name="checkbox1" type="checkbox" />
<label for="checkbox1">My checkbox label</label>

Raster und Spalten

Kann sich jemand erinnern, jemals eine Webseite mit mehr als drei Spalten gelesen oder genutzt zu haben und das gut gefunden zu haben? Ich nicht. Zu viel Zeug auf einmal, das nach meiner Aufmerksamkeit schreit. „Welches von den Dingern, die wie eine Navigation aussehen, mag wohl die Navigation sein, die ich suche?“ Es ist eine rhetorische Frage: Meine Geduld ist am Ende und ich habe die Seite verlassen.

Manchmal möchte man Dinge nebeneinander anordnen, sicher. Suchergebnisse oder so. Aber warum sollte man nur dafür eine ganze Tonne eines Grid‐Frameworks einbinden? Flexbox kann das mit ein paar wenigen Deklarationsblöcken.

.grid {
    display: flex;
    flex-flow: row wrap;
}
.grid > * {
    flex-basis: 10em;
    flex-grow: 1;
}

Und schon „flext“ alles ungefähr 10em breit. Die Anzahl der Spalten ergibt sich daraus, wie oft ungefähr 10em in die Viewport‐Breite passen. Erledigt. Weiter.

Ach ja, und wo wir schon dabei sind, müssen wir auch über so etwas reden:

width: 57.98363527356473782736464546373337373737%;

Habt ihr gewusst, dass genaue Maßangaben nach einem mystischen Verhältnis berechnet werden? Ein Verhältnis, das uns in Stille und Erhrfurcht versetzt? Also ich nicht, und es interessiert mich auch nicht. Macht den Porno‐Button einfach groß genug, dass ich ihn finde.

Ränder

Wir machen das so: Gleiche Randdefinitionen für alle Elemente mit dem Universal‐Selektor. Und nur da überschreiben, wo es nötig ist (das wird nicht oft sein).

body * + * {
    margin-top: 1.5rem;
}

Nein, der Universal‐Selektor ist nicht schlecht für die Performance. Das ist Quatsch.

Ansichten

Man braucht nicht das ganze Angular‐ oder Meteor‐Framework oder sowas, um eine einfache Webseite in verschiedene Ansichten aufzuteilen. Ansichten sind nur Teile der Seite, die sichtbar sind, während andere verborgen sind. Das kann CSS leisten:

.view {
    display: none;
}
.view:target {
    display: block;
}

Aber Single‐Page‐Apps müssen irgendwelches Zeug ausführen, wenn eine andere Ansicht aktiviert wird“, höre ich euch schon sagen. Dafür gibt es das hashchange‐Event. Braucht keine Bibliothek, und man kann Links ganz normal nutzen, so dass man sie sogar als Bookmark setzen kann. Das ist schön. Es gibt noch mehr zu dieser Technik, wenn’s jemand interessiert.

Schriftgrößen

Schriftgrößen anzupassen kann @media-Blöcke echt aufblähen. Daher sollte man CSS das machen lassen. Mit einer einzigen Zeile Code.

font-size: calc(1em + 1vw);

Ähm, das war’s schon. Hat sogar eine Mindest‐Schriftgröße, also keine winzigen Schriften auf Mobilgeräten. Dank an Vasilis, der mir das gezeigt hat.

10k Apart

Wie gesagt, ich bin nicht gerade der beste Coder. Ich kenne einfach nur ein paar Tricks. Aber ist ist möglich, mit nur wenig Aufwand verdammt viel zu erreichen. Das ist die Zielsetzung beim 10k‐Apart‐Wettbewerb — herauszufinden, was man mit nur 10k oder noch weniger alles anstellen kann. Es gibt große Preise zu gewinnen und als Preisrichter freue ich mich schon darauf, mich selbst rauszukicken, wenn ich mir all die faszinierenden Einträge ansehe; Ideen und Implementierungen, die mir selbst hätten einfallen sollen. Ich bin gespannt auf eure Beiträge.

Über den Artikel

Das Original stammt von Heydon Pickering, www.heydonworks.com/, die Übersetzung von Martin Kunkel, selfhtml@kennst.net.

SELFHTML e.V. hat die ausschließliche Genehmigung des Autors des Original‐Artikels, die deutsche Übersetzung zu veröffentlichen. Für Fragen zur weiteren Verwendung kontaktieren Sie bitte Heydon Pickering.

Kommentare sind geschlossen.