Professioneller Stolz

Vom 20. bis 22. März war ich Teil der HTML5-Days in München. Zeitgleich liefen die JavaScript-Days, die AngularJS-Days und die React-Days. Die Teilnehmer hatten drei volle Tage Zeit, aus vielen Bereichen der Frontendentwicklung neue Anregungen und neues Wissen zu sammeln. Die immer hohen Teilnehmerzahlen sind Beleg für den Erfolg des Konzeptes.

Dieses Jahr hatte ich leider nur die Möglichkeit, eine einzige Session eines Kollegen mitzumachen. Zusätzlich zu meinen drei eigenen Sessions nahm ich noch am Speakers-Panel teil. Dabei sitzen möglichst viele der Speaker auf einer Bühne und sprechen über interessante Teilaspekte der Frontendentwicklung. Das ist recht launig und wabert zwischen ernst und scherzhaft hin und her.

Sowohl das Speakers-Panel als auch die Session des Kollegen gaben mir dieses Jahr zu denken.

Ich habe in meiner beruflichen Praxis recht wenig mit JavaScript zu tun. Wenn es um ernsthafte Programmierung geht, halte ich mich fern. Ich kenne meine Grenzen und kommuniziere diese auch offensiv. Kleinere DOM-Manipulationen mit jQuery sind hingegen nicht das Problem. Sollte ich in meinen Schulungen JavaScript nutzen, handelt es sich meist um kleinere jQuery-Skripte. Sie sind selten der Fokus meiner Ausführungen. Trotzdem gebe ich mir Mühe, keinen Schrott zu schreiben. Das wiederum geht bei JavaScript auch eher nicht, denn ein fehlerhaftes Programm würde nicht ausgeführt werden.

Anders ist dies bei HTML. Und das scheint beruhigenden Einfluss auf die Kollegen zu haben, die sich ausschliesslich mit JavaScript beschäftigen. In der von mir besuchten Session ging es definitiv nicht um die Beispiel-App, sondern um die Transformation derselben in eine mobile und eine Desktop-Applikation. Die Ausführungen waren sehr interessant, ich konnte gut folgen und denke nun dauernd darüber nach, welche Electron-App ich unbedingt machen muss.

Zu Beginn der Session stellte er Beispielcode vor – in diesem Fall sein HTML-Gerüst – und fragte, ob man Fehler sehe. Nun, wenn ich folgenden Code sehe, dann ist das für mich ein schwerer Fehler:

<div type="button" (click)="takePhoto()">
<i class="fa fa-camera fa-2x"></i>
</div>

An Stelle eines Buttons wird hier nur ein DIV missbraucht. Dank ganz viel JavaScript-Magic von Angular funktioniert dieses bedeutungslose DIV wie ein Button. An anderer Stelle der App nutzt er einen Button, kennt also dieses Element.

Diese extreme Nachlässigkeit bezüglich HTML begegnet mir immer wieder bei JavaScript-Tutorials. Es macht es mir schwer, die Artikel, Tutorials, ja deren Autoren und Sprecher ernst zu nehmen. Und es ärgert mich jedesmal masslos. Offensichtlich konzentriert sich der professionelle Stolz der Kollegen nur auf JavaScript, nicht auf die gesamte Problemlösung. Das finde ich fatal.

Der Fokus der Session und jeglicher Einführungen in React, Angular und sonstnochwas ist selbstverständlich JavaScript. HTML und CSS sollten dabei immer Randerscheinungen sein, die man nicht allzu genau erklären muss. Aber genau deshalb setzen sich unbewusst Codestandards durch. Mich beschleicht das Gefühl, keiner der Autoren (oder Sprecher) möchte sich eine Sekunde mit HTML auseinandersetzen, deshalb wird einfach mal alles in ein DIV oder auch zur Abwechslung mal in ein SPAN gepackt. Ich habe auch schon DIV-Container in SPAN-Containern gesehen. Da war der Autor definitiv nicht mit Wissen über HTML belastet.

Ich wünsche mir von den Kollegen Sorgfalt. HTML und CSS sind genauso wichtige Sprachen, wie JavaScript. Nur weil den Kollegen Wissen und Verständnis für sie fehlen, sollten sie sie nicht wie bedeutungslose Wegwerfware behandeln. Bei ihren Tutorials und Workshops geht es ja nie um HTML und CSS. Aber das kleine bisschen, das sie nutzen, sollte dann zumindest durchdacht und gut sein. Wer unterschiedliche JavaScript-Frameworks, vielleicht auch noch zwei Backend-Sprachen, dazu diverse Programmierkonzepte beherrscht, kann mir nicht erklären, sich einfache Regeln der Semantik nicht merken zu können.

Ein anderes Problem scheinen JavaScript-Entwickler mit CSS zu haben. Auf dem Speakers-Panel wurde die Behauptung in den Raum gestellt, das Problem von CSS sei, dass es global funktioniere. In meinen Augen ist dies nicht nur die Stärke von CSS sondern einfach mal eine der Grundeigenschaften der Sprache. Wer dies als Problem sieht, sollte endlich CSS lernen oder die Arbeit denen überlassen, die es begriffen haben. Der starke Applaus des Publikums für meine Erwiderung lässt mich hoffen, dass sich die Haltung des Kollegen unter den Entwicklern nicht allzu großer Beliebtheit erfreut.

Nichtsdestotrotz ist diese Einstellung gegenüber CSS unter vielen Trainern und Autoren zu finden. Immer wieder stolpere ich über Artikel, die die globale Wirkung von CSS als Problem sehen. Mein Standpunkt dazu ist klar: Lernt CSS und beschäftigt Euch mit Architekturkonzepten wie BEM oder SMACSS! Dann wird deutlich, wie man im Team auch große Seiten und auch SPAs erstellt.

Es irritierte mich zudem, warum der Kollege so darauf versessen ist, HTML, CSS und JavaScript möglichst in einer Datei zu vermengen. Seit mehr als zehn Jahren wird uns erklärt, dass Spaghetticode mit vielen echo in PHP sehr schlecht sei und wir doch bitte PHP und HTML zu trennen hätten. Ich konnte dieser Forderung immer viel abgewinnen. Warum soll diese Trennung nun bei JavaScript nicht mehr gut sein? Das Interessante ist ja, dass immer mehr Backend-Entwickler ihre Liebe für JavaScript entdecken. Warum lassen sie einfach die bisherigen Best-Practices hinter sich? Bei einer Trennung der drei Ebenen fällt es auch leichter, HTML und CSS an einen Entwickler zu geben, der sich damit auskennt und auskennen will.

Ich wünsche mir, dass Trainer und Autoren im Bereich JavaScript zumindest gute Grundkenntnisse in HTML und CSS haben. Das HTML sollte nicht einfach hingerotzt sein. Der Autor/Trainer lehrt mit dem, was er schreibt und sagt. Er sollte sich seiner Verantwortung bewusst sein und keinen schlechten Code fördern. Wir Lernenden orientieren uns am Stil der Lehrer. Und wenn zu oft in JavaScript-Tutorials alles mit DIV und SPAN umgesetzt wird, verbreitet sich dieser schlechte Stil, pflanzt sich fort.

Im Jahr 2008 habe ich ein PHP-Buch in einer Rezension wegen extrem schlechten HTML-Codes verrissen. Dazu stehe ich auch heute noch. Auch wenn HTML weder bei den Angular-Artikeln/-Vorträgen noch bei dem PHP-Buch im Vordergrund stehen, erwarte ich ein Mindestmass an Sorgfalt. Das umso mehr, als gerade HTML eine unkomplexe Sache ist.

Liebe Kollegen: reisst Euch zusammen und schreibt besseren Code!

3 Kommentare

  1. Jens, ich kommentiere viel zu selten, weil ich selten noch was hinzufügen kann ausser, ja genau. Aber hier: JA GENAU.
    Vielen Dank. 100% Zustimmung, vielleicht noch ergänzt darum, dass mir diese Arroganz auf den Altsack geht, mit der behauptet wird, dass HTML/CSS, URLs und curl-able Links Altlasten aus den 90ern seien, und man nun im Zeitalter der Apps doch bitte mal die Semantikkirche im Dorf lassen sollte. Ich habe den Eindruck, dass nun mit der (JS)Development Welt das passiert, was vor Jahren mit der (Grafik)Design Welt und dem Web passierte — in beiden Fällen der (Irr)Glaube, oder die gemeinsame Halluzination, dass der „richtige“ Umgang damit eben so und so zu sein habe, und so gegen, statt mit, den Urbausteinen, der DNA, des „webs“ zu arbeiten.

  2. Ich kann deine Einstellung zu der Trennung der 3 Technologien HTML, CSS und JavaScript nachvollziehen, sehe aber auch einen gravierenden Nachteil dieser Vorgehensweise: Die durchaus sinnvolle Idee der „Separation of Concerns“ wird eher zu einer „Separation of Technologies“. Ich schreibe keine BEM- oder „js-whatever“-Klassennamen in das HTML weil mein HTML dadurch schöner aussieht oder mehr semantische Informationen beinhaltet. Letztendlich baue ich mir eine Art API für mein CSS bzw. JavaScript. Problem dabei: Ich habe eine Abhängigkeit zueinander an 2 getrennten Orten und riskiere, dass die beiden sich nicht mehr zusammen weiterentwickeln. Bei modernen Front End-Frameworks wie React oder Angular 2 schreibe ich typischerweise HTML + JavaScript in eine Datei. Das ganze ist dann schön gekapselt und ich weiß sofort, welche Event-Handler und Variablen zu welchem Markup gehören. Bei CSS bin ich mir da noch nicht so ganz sicher, ob das eine gute Idee ist, die Stylesheets in die Datei für die jeweilige Komponente zu schreiben. Wenn ich in jeder Komponente weißen Text auf schwarzem Hintergrund haben will, müsste ich die beiden CSS-Zeilen theoretisch in jeder Komponente erneut aufführen. Eine durchdachte CSS-Architektur scheint mir da momentan noch sinnvoller zu sein, aber man handelt sich natürlich Nachteile wie nicht klar abgegrenzte Komponenten-Grenzen ein.

    Bei dem Einsatz von semantisch sinnvollem, barrierefreien/-armen HTML stimme ich dir vollends zu. Es gibt kaum entsprechende Beispiele in den Dokumenten. Gleichzeitig war es noch nie so einfach, ein DIV mit einem OnClick-Handler und etwas CSS zu einem Button zu machen.

  3. > Es irritierte mich zudem, warum der Kollege so darauf versessen ist, HTML, CSS und JavaScript möglichst in einer Datei zu vermengen.

    Da kommt es imho schon etwas darauf an, was genau der Kollege da macht. Beispielsweise kann man (muss man aber nicht) bei Vue mit single File Components arbeiten, bei denen genau das gemacht wird. Allerdings nicht im Sinne von <div onClick="updateCSS("background:red")>, sondern innerhalb eines Files sauber getrennt in <template> (Markup), <script> und <style> (letztere auch gescoped bei Bedarf). Das Schöne ist, man hat alles an einem Ort, was diese eine Komponente angeht, während man den Separation of concern weiter verfolgt bzw. noch mehr dazu gezwungen wird, modular zu denken. Klar kann das unübersichtlich werden bei komplexen Komponenten, aber da kann man das auch in drei Dateien verteilen. Das Prinzip hat dennoch etwas: Alle Markup-Teile, Styles und Methoden, die ich da rein schreibe, gehen auch nur diese Komponente was an.