Webseiten zu erstellen ist unglaublich facettenreich, egal ob es sich um eine einfache “Visitenkarte” eines kleinen Selbständigen oder um eine große E-Commerce-Seite handelt. Die Komplexität der einzelnen Facetten nimmt schlicht zu.
Am Ende benötigen wir meist jemanden, der sich um Server und die Infrastruktur kümmert. Gerade bei publikumsintensiven Seiten ist das eine Wissenschaft für sich. Wir benötigen auch meist jemanden, der sich um das CMS kümmert. Denn auch wenn eine Seite nicht besonders komplex ist und häufig aktualisiert wird, wird doch gerne ein CMS zur Pflege einer Website genutzt — oft schlicht aus Gewohnheit.
Wir benötigen natürlich auch jemanden, der das Frontend schreibt. Das muss auch noch jemand entwerfen und vielleicht sogar mit konzeptionellen Gedanken strukturieren. Eventuell existieren sogar Menschen, die sich um passende Texte bemühen.
Jede dieser vielen Tätigkeiten trägt einen kleinen Teil zum Gesamterfolg bei und ist je nach Projekt unterschiedlich intensiv ausgeprägt. Aber wie man es am Ende auch dreht und wendet, nicht alle Tätigkeiten haben eine direkte Auswirkung auf den Nutzer.
- Eine gute Infrastruktur bemerkt der Nutzer im Wesentlichen in Ausnahmesituationen. Wenn sehr viele Menschen gleichzeitig auf eine Seite zugreifen und diese dem Ansturm nicht Stand hält, fällt eine Vernachlässigung der Infrastruktur direkt auf.
- Insbesondere bei einer komplexen Seite erkennt man, ob sich jemand konzeptionelle Gedanken gemacht hat. Das beginnt schon bei der Benennung von Abschnitten und geht über die Strukturierung der Navigation zur Strukturierung jedes einzelnen Seitentyps.
- Gerade bei einer Applikation können Gedanken über Animationen die Nutzung positiv beeinflussen.
- Attraktiv aussehende Seiten haben es beim Nutzer sicherlich leichter als hässliche.
Allerdings wird sicherlich niemandem auffallen, mit welchem CMS eine Seite erstellt wurde. Eine direkte Auswirkung auf den Endnutzer können wir ausschließen. Das CMS ist eher interessant für die Seitenbetreiber.
Der Frontend-Entwickler als Mittler
Als Frontend-Entwickler ist es mein Job, die Ideen von Designern und Konzeptern umzusetzen. Denn ein Design in Photoshop oder Sketch ist nur so lange eine nette Idee, bis es jemand in echten Code für den Browser umgesetzt hat. Erst dann stellt sich heraus, ob und in welchen Browsern es funktioniert. Oft ist die Arbeit aber auch dahingehend geteilt, dass der Frontend-Entwickler seinen Code an einen Backend-Kollegen übergibt, der diesen dann in das CMS-eigene Template-System überführt, damit dynamischer Inhalt ausgegeben werden kann.
Schon immer war ich als Frontend-Entwickler ein Zwitterwesen zwischen Design und Entwicklung. Und bei mir und meinen Kollegen war es gängig — und sicherlich auch einfacher — ohne eine formale Ausbildung in den Job gerutscht zu sein. Hatte ich schon immer studierte Designer und Software-Entwickler als Kollegen, sind doch viele Frontend-Entwickler Quereinsteiger wie ich. Das fiel allein deshalb leicht, weil das Frontend mit keiner der gängigen Rollen vergleichbar ist. Es stellt etwas Neues dar. Designer kamen anfangs aus dem Print-Bereich und lernten mühsam den Unterschied zwischen CMYK und RGB. Software-Entwickler hatten vorher bspw. Desktop-Applikationen programmiert. Sie wurden zwar auch mal mit neuen Programmiersprachen konfrontiert, konnten manchmal aber mit dem Java des Studiums einfach fortfahren. Frontend-Entwickler hingegen betraten komplettes Neuland. Es gab vorher keine Software wie Browser. So fehlerhaft und unvollständig.
Als Frontend-Entwickler verstehe ich mich als Mittler zwischen Design und Backend. Ich muss beide verstehen, ohne ihre Jobs ausfüllen zu können. Und hin und wieder muss ich zwischen beiden “übersetzen”.
HTML und CSS sind sehr eigen
Ich designe nicht, aber ich programmiere auch nicht zwangsweise. Klar, in JavaScript kann ich eine Menge programmieren. Aber HTML und CSS lassen sich mit Mitteln der Informatik nicht erfassen. Und das scheint ein andauerndes Problem zu sein. Denn schließlich sind die Tätigkeiten nicht immer so strikt getrennt, wie ich sie eingangs beschrieben habe. Es gibt durchaus viele Designer, die ihre Entwürfe sehr gut in HTML und CSS umsetzen können. Und es gibt noch sehr viel mehr Backend-Entwickler, die Frontend-Code schreiben.
Es ist naheliegend, dass diese Backend-Entwickler versuchen, die neuen Techniken mit ihren erlernten Techniken in Einklang zu bringen. Es ist auch naheliegend, dass eine alternative Strategie sein kann, die “neuen” Techniken weniger zu schätzen. All das beobachte ich im Alltag. Dabei wird entweder ein Weg gesucht, um HTML, CSS und JavaScript in Richtung der erlernten Techniken (sehr oft Java) zu modifizieren. Oder aber es wird die Bedeutung der neuen Techniken negiert und ein sehr schlechter Code gepflegt.
Der beliebte CSS-Präprozessor Sass entstand aus der Frustration einiger Ruby-Entwickler über die CSS-Syntax. Sie wollten CSS schreiben, das mehr nach Ruby aussah. TypeScript befriedigt wiederum all diejenigen, die durch ihr Studium den Wert der Typisierung gelernt haben. Quereinsteiger wie mich lässt das kalt. Ich sage mir: diese Sprache funktioniert einfach anders, nimm es so an.
Für HTML gibt es zwar auch Kurzschreibweisen, allerdings hat sich keine ernsthaft durchgesetzt. Hier nehme ich leider eine gewisse Ignoranz wahr. Die gipfelt immer wieder in Tutorials (auch in Vorträgen auf Konferenzen), in denen einfach mal ein DIV zu einem Button (mit Hilfe von JavaScript) umfunktioniert wird. Es gibt in solchen Situationen offenbar kein Gefühl für schlechten Code.
Es wird dabei gerne übersehen, dass am Ende immer HTML, CSS und JavaScript herausfallen. Nur diese drei Sprachen werden vom Browser beherrscht. Bei TypeScript und JavaScript ist die Sache einfach, denn hier wandelt ein Transpiler (Babel) die eine in die andere Sprache.
Aber hingegen die Nutzung von Sass (oder Less oder Stylus) entbindet uns nicht von der Kenntnis der Grundmechanik von CSS. Auch diejenigen, die CSS in JS schreiben, schreiben am Ende CSS. Und es gelten auch hier die Kaskade, die Spezifität und das Boxmodell.
Und egal, ob ich HTML direkt oder über Pug oder React schreibe, am Ende steht da HTML. Es gelten die Regeln der Semantik, und es gelten die Regeln des HTML-Standards. Wer sich nicht daran hält, kann auf tolerante Browser setzen, schreibt am Ende aber schlechten Code.
Frontend- und Backend-Code zu schreiben ist keine Kunst. Es ist ein schlichtes Handwerk, das nach Regeln funktioniert. Diese Regeln sind in Standards definiert. Der große Unterschied zwischen Front- und Backend ist dabei, dass wir im Frontend keine echte Kontrolle über das Endergebnis haben. Wir kennen unser Gegenüber nicht. Jeder Browser ist anders schlecht, denn keiner ist fehlerfrei oder feature-complete. Außerdem kann jeder Benutzer seinen Browser individuell konfigurieren. Das ist auch sehr gut so. Der Umgang mit dieser Ungewissheit hat zwar etwas Kreatives, berechtigt aber nicht zum Brechen der Regeln.
Am Ende ist alles, was wir aus unseren CMSen ausgeben, HTML mit einer Beigabe von CSS und JavaScript. Sind diese drei Bestandteile nicht gleich gut erstellt, ist es egal, welche Brillanz die Entwickler im CMS und auf dem Server entfalten. Der wichtigste Teil der Webseite wäre schlecht erstellt. Und das sollte niemand als Kollateralschaden akzeptieren.
In meinem Artikel, Frontend-Entwicklung ist ein Handwerk, gebe ich eine Einführung in die Regeln des Frontends und wie man sie interpretieren sollte.
Bild von Fabrizio Van Marciano auf Pixabay
- 15 Farbtools für Webdesign, die Sie ausprobieren sollten - 11. November 2019
- Frontend-Entwicklung ist ein Handwerk - 14. Oktober 2019
- Kaskade und Spezifität — eine Einführung in die CSS-Grundlagen - 8. Oktober 2019
