Frontend-Entwicklung ist ein Handwerk, keine Kunst. Es ist ein Handwerk, das nicht zu vernachlässigen ist. Denn am Ende landet jedes Design und jede Backend-Programmierung im Frontend und wird mittels HTML, CSS und manchmal auch JavaScript dargestellt. (Weitere Informationen zu diesem Thema finden Sie in unserem Expertenbeitrag: Am Ende ist doch alles HTML) Selbst komplett in JavaScript geschriebene Frontends werden am Ende im Browser in ihre Bestandteile zerlegt. Und da Inhalt mittels HTML und Gestaltung mittels CSS im Browser transportiert wird, sind Kenntnisse beider Sprachen wichtig.

Frontend-Entwicklung – Eine andere Welt

Aus der Sicht jedes anderen Projektbeteiligten ist die Frontend-Entwicklung eine seltsame Welt mit eigenen Regeln, denen sie selber nicht unterworfen sind. Designer versuchen zwar mittlerweile, die Flexibilität der Online-Welt mit ihren Designs abzubilden, können aber immer nur in ihren Tools (bspw. Photoshop oder Sketch) in fixen Dimensionen gestalten. Zudem gelingt ihnen in ihrer Software fast alles — völlig unbeeindruckt von den Fähigkeiten der Browser.

Backend-Entwickler hingegen haben einen klar definierten “Endgegner”. Wenn der Server mit PHP 7.3 läuft, kennen sie die Regeln, nach denen sie programmieren dürfen und können sich sicher sein, dass der Server, auf dem ihre Software läuft, auch 100 Prozent ihres Codes verstehen wird.

Ich als Frontend-Entwickler kann maximal Annahmen treffen, in der sicheren Gewissheit, dass diese oft danebenliegen. Meine einzige Sicherheit ist, dass es keinen fehlerfreien Browser gibt, der 100 Prozent von HTML, CSS oder JavaScript implementiert hätte. Und gäbe es zwei davon, würden sie sich noch immer unterscheiden, weil die Standards oft recht lax formuliert sind.

Regeln sind wichtig, aber Interpretationssache

Es ist wichtig, die Standards der Frontend-Techniken zu kennen. Es ist auch wichtig, Wissen über die Browserinterpretationen und -unterstützung dieser Standards zu sammeln. Mindestens genauso wichtig ist aber, die Grundregeln zu kennen, nach denen Sie ein wartbares, funktionierendes Frontend erschaffen können. Diese Regeln sind eigentlich sehr einfach zu merken und zu befolgen.

Ein pixelexaktes Frontend ist eine Illusion

Webdesign und Printdesign haben eine fundamentale Differenz: für das Web kann man keine exakten Kopien einer Idee erstellen. Jeder Browser und jedes Betriebssystem beeinflusst Details einer Webseite. Deshalb kann es keine wirklich pixelexakte Umsetzung eines Designs geben. Es ist und war auch nie sinnvoll. Denn schließlich ist es die Stärke des Internet, dass ein jeder Nutzer sich seine Umgebung so einrichten kann, wie es ihm beliebt und wie er sie benötigt. Das beginnt bei der Einstellung einer Schrift-Skalierung und endet beim Hochkontrastmodus unter Windows, den Menschen mit ganz starken Sehproblemen benötigen.

Meine Empfehlung für Webdesign und dessen Umsetzung mag ein wenig platt klingen und ist bewusst zugespitzt: “Macht euch locker!” Denn wenn man erst einmal begriffen hat, dass das eigene Design immer vom Endnutzer modifiziert werden kann, sieht man die eigene Arbeit mit anderen Augen. Webdesign ist immer nur ein Angebot, kein definitives und unverrückbares Endprodukt. Wer die hundertprozentige Kontrolle über ein Design braucht, ist im Internet falsch. Da sind die Spieleindustrie oder die Printindustrie besser als Betätigungsfeld geeignet.

Responsivität und Zugänglichkeit sind im eigenen Interesse

Es sollte im logischen Eigeninteresse eines jeden Seitenbetreibers sein, dass die eigene Seite von möglichst vielen Nutzern wahrgenommen werden kann. Dafür muss sich die Seite den Gegebenheiten anpassen können. Sie muss sich an die Umgebung anpassen können, also bspw. genauso gut auf einem Smartphone wie auf einem Laptop les- und bedienbar sein. Das nennen wir Responsive Webdesign

Sie sollte aber auch von jedermann genutzt werden können, egal ob eine (vielleicht auch nur temporäre) Behinderung/Einschränkung vorliegt, oder nicht. In diesem Fall sprechen wir von Barrierefreiheit. Ich finde hingegen das englische Wort “Accessibility” passender. Auf Deutsch bedeutet es “Zugänglichkeit”. Und genau darum geht es: die Inhalte einer Seite sollen “zugänglich”, erfahrbar sein. Das Thema ist vielschichtig und spannend. Normalerweise wird mit Barrierefreiheit nur die “Optimierung für Blinde” verbunden. Doch das greift viel zu kurz. Accessibility thematisiert auch die Farbkontraste einer Webseite. Gute Farbkontraste helfen manchen Menschen mit Sehschwächen genauso gut wie einem Laptopnutzer, der im Sommer im Café bei intensivem Sonnenschein sitzt.

Bei Accessibility geht es auch um die Nutzung einer Webseite durch Menschen mit einem gebrochenen Arm, die deshalb eine Zeit lang nicht mit ihrer gewohnten Hand eine Maus bedienen können. So nebensächlich sich ein gebrochener Arm anhört: versuchen Sie einmal einen Tag lang, alle Webseiten nur mit der Tastatur oder mit der “falschen Hand” per Maus zu bedienen. Ich garantiere Ihnen, dass Sie viele negative Erfahrungen machen werden. Denn leider werden noch immer kleine Interaktionen gerne auf die Maus beschränkt, indem nur :hover, aber niemals :focus im CSS angesprochen wird. Vollkommen normal scheint zu sein, dass ein Tastaturfokus nie sichtbar ist, man also raten muss, wo genau auf der Seite man sich gerade befindet.

Auch die Benutzung eines Smartphones ist in gewisser Hinsicht eine Einschränkung im Vergleich mit einem Festrechner. Der zur Verfügung stehende Platz ist gering und die Benutzung der Finger zur Eingabe machen die Interaktion eher mühsamer als schneller. Deshalb sehe ich Responsive Webdesign und Barrierefreiheit als zwei Seiten der selben Medaille.

Erst eine gesunde Basis, dann die Verzierung

Eine Seite sollte am Ende von möglichst vielen Menschen wahrgenommen werden. Deshalb ist es klug, mit dem kleinsten gemeinsamen Nenner zu beginnen und dann “Schicht für Schicht” neue Features hinzuzufügen. Im Grunde verhalten sich die drei Sprachen HTML, CSS und JavaScript ebenso. Die Basis ist immer HTML, denn es gilt immer, einen Inhalt zu strukturieren. Um diesen Inhalt attraktiv zu machen, damit Menschen ihn gerne wahrnehmen wollen, nutzen wir CSS, die Designsprache. Sollten auf der Seite dynamische Elemente oder Inhalte existieren, nutzen wir für diese JavaScript. Die Basis der Seite sollte aber ohne CSS und JS nutzbar und erkennbar sein. Diese Grundidee wird Progressive Enhancementgenannt. Sie findet sich auch in einer Abwandlung in “mobile first” wieder. Also der Idee, eine responsive Seite erst einmal für die kleineren Bildschirme zu schreiben und die breiteren Bildschirme als Sonderfälle zu sehen, für die eventuell Design- und Layoutänderungen angestoßen werden müssen. Da mittlerweile alle wichtigen Publikumseiten mehr Zugriffe von mobilen Endgeräte, als von Laptops oder Festrechnern haben, ist dieser Ansatz durchaus sehr sinnvoll.

Diese Trennung der drei Schichten und die Lesbarkeit einer Seite auch ohne JavaScript ist bei normalen Contentseiten sinnvoll umsetzbar. Wenn aber dynamische Daten wichtig werden und es sich mehr um eine Applikation als eine Contentseite handelt, ist die Nutzung eines JavaScript-Frameworks sinnvoll. Diese verschmelzen dann die drei getrennten Ebenen weitgehend, sodass die Endprodukte ohne funktionierendes (!) JavaScript nicht konsumiert werden können.

Ein solches Vorgehen kann sinnvoll sein, sollte aber gründlich überdacht werden.

Den Zustand “kein JavaScript” gibt es grundsätzlich immer

Es ist ein sehr verbreiteter Irrglaube, dass nur eine kleine Minderheit von etwa zwei Prozent der Nutzer bewusst JavaScript ausgeschaltet haben und dem Rest immer JavaScript zur Verfügung steht.

Bis alle JS-Dateien geladen und fehlerfrei interpretiert sind, ist jeder Nutzer im Stadium “kein JS”. Bei den teils schlechten mobilen Internetverbindungen in Deutschland ist es nicht auszuschließen, dass man gerade mobil Probleme bekommt. Fehler im JS-Code führen zusätzlich zum Abbruch. Oder aber die Agentur ignoriert vollständig, dass es auch Browser gibt, die nicht die neuesten ES6-Features nativ unterstützen. Diese Browser lesen dann zwar die JS-Datei, verstehen sie aber nicht. Ist die Seite von JavaScript abhängig, kann man sie nicht mehr bedienen oder sieht nichts.

Das HTML sollte sinnvoll sein

HTML ist als Sprache wesentlich einfacher, als jegliche Programmiersprache. Seltsamerweise treffe ich aber gerade sehr viele Softwareentwickler, die keinen Überblick über HTML haben und es oft auch gering schätzen. Dabei kann ich nicht oft genug betonen: egal was Du auf dem Server für tolle Sachen machst, am Ende ist alles HTML!

Es ist eigentlich ganz einfach: am Anfang steht die Frage, welcher Art ein Inhalt ist. Dabei ist die Optik vollkommen egal. Ist es eine Überschrift, ein Absatz? Kann man eine Liste formen oder eine Tabelle? All das wird durch HTML-Elemente und die entsprechenden Tags und Attribute repräsentiert. Die Details von HTML sind wesentlich weniger komplex und wesentlich schneller zu erlernen, als jegliche Programmiersprache. Und da am Ende alles HTML ist, ist es auch sinnvoll, dieses zu lernen.

Es gibt zudem Elemente, die mehr zur Verfügung stellen, als die einfache Semantik. Das “Hello World” von HTML und CSS ist der Button. Er passt in diesem Zusammenhang auch sehr gut. Denn ein Button kann nicht nur ein Formular absenden. Er ist auch die korrekte Wahl, um eine JavaScript-Funktion auszuführen, bspw. um ein Overlay zu öffnen. Dieser Button besitzt klar definierte Zuständen (States), die er an den Browser kommuniziert. Würden wir nun keinen Button nutzen, wie dies gerne in Tutorials für beliebte JavaScript-Frameworks gemacht wird, müssten wir all die eingebauten Funktionen nachbauen. Das können wir uns sparen.

<!– Das ist richtig! →
<button type=”submit”>Das Formular absenden</button>
<button type=”button”>Das Overlay öffenen</button>

<!– Das ist komplett falsch! →
<div class=”btn”>Das ist ein Fake-Button</div>

<!– Das ist noch immer nicht besser! →
<div class=”btn” role=”button”>Das ist ein Fake-Button</div>

<!– Das ist auf halbem Weg zum Button, ist aber kein Button! →
<a href=”linkziel.html” class=”btn”>Das ist ein Fake Button</a>

Die Optik kommt später und ist von der Funktion entkoppelt

Bleiben wir beim eben angesprochenen Button. Die Optik eines Buttons ist mittels CSS schnell verändert. Mit wenigen Zeilen lassen wir jeden Button wie einen Link aussehen oder machen seine Box-Optik einfach attraktiver.

.button-sieht-aus-wie-link {
border: none;
background: transparent;
text-decoration: underline;
padding: 0;
display: inline;
cursor: pointer;
}

.mein-button {
border: none;
padding: 8px;
background-color: #a20000;
color: #fff;
cursor: pointer;
font-size: 1rem;
}


.mein-button:hover,
.mein-button:focus {
background-color: #000;
}

Bei CodePen habe ich eine Testseite erstellt, auf der ich ein wenig mit dem Button und der Button-Optik experimentiere:

See the Pen
Button-Varianten by Jens Grochtdreis (@jensgro)
on CodePen.

Wir machen solche optischen Veränderungen ständig. Jede richtig erstellte Navigation ist eine Linkliste. Doch keine sieht wie eine Liste aus. Wir verändern diese Listen mittels CSS, damit sie horizontal laufen und einmal eine Tab-Optik haben, einmal dicke Unterstriche oder auch einfach nebeneinander stehende Blöcke sind.

Frontend-Entwicklung – Fazit

Wie beim Backend und beim Design hat die Frontend-Entwicklung ganz eigene Regeln. Es ist hilfreich und wichtig, diese Regeln zu kennen und sie zu befolgen. Denn nur dann ist eine gut wartbare Webseite möglich, die auch möglichst viele Nutzer erreicht. Eine Nichtbefolgung einzelner Regeln hat Konsequenzen, über die man sich im Klaren sein muss. Die allerwichtigste Erkenntnis ist aber in meinen Augen die, dass wir keine Kontrolle über das Ergebnis unserer Arbeit haben. Wir machen einen fundierten Vorschlag, den jeder Nutzer nach seinen Vorlieben und Rahmenbedingungen verändern kann. Diese Erkenntnis ist wichtig und die Basis aller folgenden Regeln.

Bildnachweis: Photo by Lee Campbell on Unsplash

Jens Grochtdreis
Letzte Artikel von Jens Grochtdreis (Alle anzeigen)

Große Auswahl an günstigen Domain-Endungen – schon ab 0,08 € /Monat
Jetzt Domain-Check starten