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.

WAI-ARIA

Zunächst mal: WAI-ARIA != 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, WAI-ARIA 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.

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

>width: 57.98363527356473782736464546373337373737%;

body

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

font-si

ize: calc(1em + 1vw);