In kritischer Verteidigung der Frontend-Entwicklung

Artikel vom 12. Mai 2021. ISSN 1614-3124, #66. Schwerpunkt:  (RSS-Feed).

Die Frontend-Entwicklung ist ein Feld das es kennt, missverstanden und unterschätzt zu werden. Als ich die englische Fassung dieses Artikels schrieb, war das gerade gut sichtbar, als Shopifys CEO die Frontend-Entwicklung zur Angelegenheit von Junior-Entwicklern machte. Die Bemerkungen waren vielleicht ungenau – und wurden auf Twitter getroffen –, aber sie erscheinen dadurch nicht weniger entfremdet, was den Einfluss und die Wichtigkeit des Feldes anbelangt.

Inhalt

  1. Was ist Frontend-Entwicklung?
  2. Problem 1: Die Frontend-Entwicklung ist wesentlich umfangreicher
  3. Problem 2: Die Frontend-Entwicklung ist wesentlich komplexer
  4. Respektieren Sie die Frontend-Entwicklung

Was ist Frontend-Entwicklung?

Laut Wikipedia ist Frontend-Entwicklung »die Praxis, Daten durch den Einsatz von HTML, CSS und JavaScript in eine graphische Benutzeroberfläche zu überführen« (»the practice of converting data to a graphical interface, through the use of HTML, CSS, and JavaScript«).

Für jemand, der wenig von HTML hält, CSS wie eine Programmiersprache behandelt und JavaScript nur durch Kontakt mit JavaScript-Frameworks kennt, beginnen die Probleme gleich hier. Aus dieser Sicht muss die Welt der Frontend-Entwicklung unappetitlich und irrelevant anmuten.

Da dieses Verständnis der Frontend-Entwicklung als unappetitlich und irrelevant durchaus verbreitet zu sein scheint, haben wir es mit zwei Problemen zu tun: Auf der einen Seite scheint die Definition fehlerhaft, da mehr zur Frontend-Entwicklung gehört als HTML, CSS und JavaScript. Zum anderen scheint auch die Interpretation der Definition falsch, da HTML, CSS und JavaScript komplexer, interessanter und wichtiger sind als vieles, was es sonst in der Informationstechnologie zu studieren und praktizieren gibt.

Problem 1: Die Frontend-Entwicklung ist wesentlich umfangreicher

Frontend-Entwicklung bedeutet mehr als HTML, CSS und JavaScript. Unsere Definitionen, wie die von Wikipedia, sind zu eng gefasst. (Wie ich das Feld persönlich auch mal als sehr eng verstanden habe und damit fast zum Softwareentwickler wurde, habe ich mal auf der beyond tellerrand 2018 geschildert.)

Was ist die Frontend-Entwicklung denn noch? In ihrer Essenz ist Frontend-Entwicklung nutzernah, und als solches steht der Nutzer im Zentrum der verschiedenen Prioritäten der Frontend-Entwicklung. Frontend-Entwicklung ist nicht nur Entwicklung:

… und die Liste geht weiter. (Während diese Liste nützlich ist, um Frontend-Entwicklung umzudefinieren, impliziert sie nicht, dass ein Frontend-Entwickler ein Experte auf all diesen Gebieten sein muss. Sie bedeutet vielmehr, dass hier ein grundsätzliches Verständnis vorliegen sollte, und dass diese Bereiche als Optionen für weitere Spezialisierung dienen können.)

Um ein besserer Frontend-Entwickler zu werden, wird man nicht Backend-Entwickler, sondern ein besserer Designer sowie ein Vertreter des Benutzers – in dem Sinne, ein Verständnis von Design sowie Empathie für Menschen zu erwerben.

Wenn andere Entwickler auf Frontend-Entwickler herabschauen und ihre Arbeit nicht würdigen, zeigen sie nicht nur Unwissen über den Umfang und die Größe der Frontend-Entwicklung, sondern lenken Frontend-Entwickler von ihrer eigentlich Mission ab *. Diese Mission heißt nicht, weiter in den Server-Raum zu gehen, sondern die Fenster zu öffnen und auf die Nutzer dort draußen zu achten.

Problem 2: Die Frontend-Entwicklung ist wesentlich komplexer

Frontend-Entwicklung ist zudem viel komplexer, als gemeinhin angenommen wird – selbst wenn sie sich »nur« um HTML, CSS und JavaScript drehen würde. Der obige Abschnitt, darüber, wenig von HTML zu halten, CSS wie eine Programmiersprache zu behandeln und JavaScript nur durch Kontakt mit JavaScript-Frameworks zu kennen, gibt es schon preis:

Die Frontend-Entwicklung wird nicht ausreichend verstanden.

Von dem, was man beobachten kann, wird HTML geringschätzt. Viele Entwickler (einschließlich Frontend-Entwickler) investieren ein paar Stunden darin, HTML zu »lernen«, nehmen an, dass sie alles verstanden haben, und schreiben 1, 5, 10 oder 20 Jahre später das minderwertigste Markup. Wenn Sie sich anschauen, wie schlampig HTML geschrieben wird, von Fachleuten, ist die Situation eine Schande – anders kann man es mehr nicht sagen. Bei all dem, was um HTML herum schiefgeht – die jahrzehntelange Weigerung, HTML zu validieren †, der »Niedrigverbrauch« an HTML-Elementen oder die seltene Optimierung von HTML für den Produktionsgebrauch – ist es schlicht erbärmlich, was in diesem Teil des Feldes vor sich geht. Und das selbst wenn HTML nicht die wichtigste (Dokumenten-)Sprache des Webs wäre.

Wie ist dies bei CSS? CSS ist schon lange außer Kontrolle geraten. Symbolisch mache ich dies an dem Tag fest, an dem wir Custom Properties einführten: Auf Server-Seite waren wir schon immer in der Lage, mit Variablen zu arbeiten. Irgendwie aber festigte sich der Gedanke, dass CSS doch besser eine Programmiersprache wäre und dass damit auch Variablen in der Spezifikation landen müssten. Ich biege die Geschichte zurecht, aber das ist nicht tragisch – CSS ist schon vor langer Zeit explodiert und obwohl dies viele Vorteile hatte, hat dies auch alle Bestrebungen zunichte gemacht, CSS jemals zu verstehen, zu beherrschen und auszuschöpfen. Wir werden dort niemals hinkommen: Niemand wird CSS je verstehen, beherrschen oder ausschöpfen. Außer den Junior-Entwicklern natürlich, wie uns Shopify weismachen will, die dann aber auch gleich andere Entwicklerpositionen einnehmen sollten.

Und JavaScript? Wer schreibt denn natives JavaScript? Greift nicht jeder sofort nach dem Node-Ökosystem, mit mehr als einem JavaScript-Framework obendrauf? Was mit CSS passierte, hatte schon vorher mit JavaScript begonnen – dass Entwickler Abstraktionen dem Beherrschen der Sprache vorzogen. jQuery ist hier immer noch das prominenteste Beispiel, aber andere Frameworks wie qooxdoo sind noch älter. Dieser Tage stellen wir Leute noch nicht einmal mehr für native Entwicklungsfähigkeiten ein – wir rekrutieren nach Abstraktionen.

Was diese Absätze sagen, ist dass HTML, CSS und JavaScript – die Schlüsseltechnologien der Frontend-Entwicklung – für sich genommen schon so umfangreich, so wichtig, aber auch so undurchsichtig sind, dass im Vergleich dazu das Lernen einer Programmiersprache ein Witz ist. Ein schlechter Witz, wie sich herausstellt, der damit endet, dass Frontend-Entwicklung von Leuten außerhalb des Feldes lächerlich gemacht wird, und von Leuten im Feld unterminiert wird, weil ständig Abkürzungen genommen werden.

Respektieren Sie die Frontend-Entwicklung

Dieser schlechte Witz, und unser Erzählen von schlechten Witzen, muss aufhören.

Dieses Witzeerzählen, diese falsche Geschichte, ist uns schon teuer zu stehen gekommen.

Während das Schaufeln schon früh begann, als Webdesign und -entwicklung zu einem Allerwelts- und Wegwerfprodukt gemacht wurden (Dank an FrontPage und Dreamweaver), war es dann ein kleiner Teil des Feldes (Browser-Anbieter und Autoren von Standards), die Webentwicklung supercool, aber auch superkomplex machten. Diese Allerweltstransformation und Verkomplizierung, die über zwei bzw. ein Jahrzehnt anhielten, wurde begleitet von einem großen Teil des Feldes, der einfach zuschaute, und der damit der Frontend-Entwicklung vielleicht nicht zu einem Grab, aber doch einem recht geräumigen Loch verhalf.

Wo wir heute stehen, ist die Grundqualität des HTML, CSS und JavaScript, das professionelle Entwickler schreiben, katastrophal. Eine Art, das festzustellen, ist wenn Sie an die 90er und frühen 2000er zurückdenken, als wir uns über die Quereinsteiger beschwerten, Menschen, die just HTML und CSS gelernt hatten und sich nun Webdesigner (eigentlich: Webdekorateure) nannten, und die infolgedessen die Qualität und den Ruf des Feldes unterminierten. Für viele Jahre beschweren wir uns nun aber über unsere eigenen Leute, unsere Kollegen. Ausschließlich. Diese Kollegen, die gerne nicht in der Lage sind, ein Dokument, Stylesheet oder Skript händisch zu erstellen. Und nun, dank geringschätzender Bemerkungen eines Tech-CEOs, werden wir erinnert, dass dieses Pendel so weit geschwungen ist, mit solcher Wucht, dass wir den Eindruck bekommen mögen, die Frontend-Entwicklung wäre irrelevant. So verkorkst ist die Lage mittlerweile.

Es ist Zeit, dass sich dies ändert. Bisher war dies eine kleine Tirade, aber hier folgen einige Vorschläge.

  1. Respektieren Sie HTML.

  2. Respektieren Sie CSS.

  3. Respektieren Sie JavaScript.

  4. Verstehen Sie, dass diese drei Sprachen, besonders zusammengenommen, komplexer sind als irgendeine Programmiersprache. Die Frontend-Entwicklung ist Dokument-, Formatierungs- und Skriptsprachenterritorium.

  5. Verstehen Sie, dass Frontend-Entwicklung auf einem robusten Verständnis dieser Sprachen basiert; ein Verständnis, das nahezu unmöglich zu erreichen ist (und schier lächerlich, von Junior-Entwicklern einzufordern).

  6. Verstehen Sie, dass Frontend-Entwicklung über HTML, CSS und JavaScript hinausgeht – nicht in die Richtung, in die es die Sofwareentwicklung gerne haben möchte, das Backend, aber in Richtung des Nutzers: Barrierefreiheit; Performance; Benutzerfreundlichkeit; Design; Informationsarchitektur; &c. pp.

  7. Wenn Sie keiner sind, lassen Sie Frontend-Entwickler in Ruhe. Sie sagen Ihnen auch nicht, wie Sie Ihre Arbeit machen sollen.

  8. Respektieren Sie die Frontend-Entwicklung.

Wenn wir dies tun, bezwingen wir die Unterstellung, dass Frontend-Entwickler zweitklassige Entwickler seien, die bei der erstbesten Gelegenheit in Backend- oder »Full-Stack«-Entwickler konvertiert werden müssen.

Wir würden Frontend-Entwickler eher als erstklassige Entwickler erkennen, und sie unterstützen, um Ordnung in das Chaos zu bringen, das »Webentwicklung als Wegwerfprodukt« und »Webentwicklung als Softwareentwicklung« angerichtet haben.

Als Frontend-Entwickler und Manager im Bereich Frontend-Entwicklung müssen wir unserem Feld ebenfalls mehr Respekt zeigen, und von uns selbst mehr verlangen. Dass mancher Output unseres Feldes erbärmlich ist – ich wiederhole das gerne – ist zu einem großen Teil unsere eigene Verantwortung. Während andere begreifen müssen, was Frontend-Entwicklung eigentlich heißt, müssen wir auch endlich vor der eigenen Haustür kehren.

Lassen Sie uns dies zusammen endlich angehen. Alle. Danke.

Mit Dank an Jad Joubran fĂĽr Feedback zu diesem Beitrag.

Um etwas Spaß zu haben, ermutigen die anderen Knappen Eisenherz zu trinken. Mit Schmeicheleien bringen sie ihn dazu, von seinen großen Ambitionen zu erzählen.

Abbildung: Eisenherz der Frontend-Entwickler. (Copyright King Features Syndicate, Inc., vertrieben durch Bulls.)

* Wir mĂĽssen an dieser Stelle jedoch auch zugeben, dass Frontend-Entwickler leicht abzulenken sind. Ich kenne keinen, der es nicht anstreben wĂĽrde, auch ein guter Softwareentwickler zu sein. Wenn dieser Teil des Egos des Frontend-Entwicklers dazukommt, schauen wir wieder hinter uns, aufs Backend, und nicht nach vorne, aufs Frontend.

† Wir haben den blinden Fleck der Validierung für viel zu lange kleingeredet. Wir haben nicht gesehen, wie der ganze invalide Code das Handwerk und die Profession von innen heraus auffressen würde. Stellen Sie sich vor, Ihr Mechaniker, Ihr Anwalt oder Ihr Arzt würden ihr Handwerk so angehen, wie Frontend-Entwickler es mit HTML tun. Wenn sie dies tun würden, befänden sie sich in derselben Malaise, in der sich heute Frontend-Entwickler befinden – nachweislich ohne professionelle Standards, in einem Feld, das andauernd am Rande einer Identitätskrise steht, hinterfragt und gemobbt von den Nachbardisziplinen und – richtigerweise – nicht von allen vertraut.

HierĂĽber tooten?

Ăś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 gearbeitet, bin W3C und WHATWG verbunden und schreibe und prüfe Bücher für O’Reilly und Frontend Dogma. 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.

Wenn du eine Frage oder Anregung zu dem hast, was ich schreibe, sende bitte jederzeit eine Nachricht. Danke!