Gude, ich bin Tobias Gebert, oder kurz: Arbeitgebert. (Wow, lustig!) Ne im Ernst: der Grund warum du hier bist, bin ich. Irgendwie bist du auf mich gekommen. Entweder durch mein entzückendes LinkedIn-Profil, Hörensagen, oder weil du mir mal eine Mail geschrieben hast und so schlau warst, die Domain zu besuchen. Ich bin Softwareentwickler mit Schwerpunkt Frontend, kümmere mich aber gerne um jegliche Anliegen, die während der Erstellung einer Web-Präsenz so auftauchen.

Ich bin studierter Kommunikationdesigner mit Schwerpunkt Print und fühle mich dafür zuständig, dir Informationen zukommen zu lassen, die du aufnehmen kannst und verstehst, egal wer du bist. Nun ja im Design – und vor allem im

wird das ja meistens etwas vernachlässigt und es scheint zum Job zu gehören, »Trends« zu kennen, neue Farbverläufe »print-ready« zu machen und die lustigen Fotokacheln auf der Website freshly animated zu drehen wenn man die Maus darüber bewegt. Wenn man aber den Beruf des Kommunikationsdesigners ernst nimmt, bewegt man sich schnell im Spannungsfeld zwischen Informationen und deren Verarbeitung, Ordnung, Barrierefreiheit, Zielgruppensensibilität etc. – sprich:

Das Interesse am Code hat sich eigentlich schon früh entwickelt. Um genau zu sein im Studium im dritten Semester, als panisch alle anfingen mit Indexhibit ihre Portfolio-Seite zu basteln, um die kläglichen Design-Schritte der vergangenen Semester für die Akquise von Praktika zu präsentieren. Wer es da verstand mit etwas

die Standard-Templates anzupassen, war der King auf dem Schulhof. Irgendwann hatte man dann genug von der steifen Struktur und bastelte sich die

-Seiten selbst. Ab da ging es dann recht schnell und mit jeder Aufgabe wuchs das Wissen. Und mit jedem Design, das man erstellte, fragte man sich wie man es selbst am schlausten umsetzen würde. Eine Symbiose die schon bald Früchte tragen sollte.

Als ich damals ernsthaft in die Welt des Codings eingestiegen bin, war die Welt noch simpel. Man programmiert sich in mühsamer Kleinarbeit die

-Templates zusammen. Der Kunde besorgt sich einen Webspace, man schiebt die fertige Seite mit FileZilla hoch und bekommt Geld für getane Arbeit. Nach einem halben Jahr kam dann vielleicht noch eine Änderung, man schiebt die Änderung hoch und Ruhe war. Der Server rendert, liefert und alles ist tutti.

Heutzutage kann man indes froh sein, wenn man ohne

überhaupt noch etwas auf der Seite sieht. Das was früher der Server gemacht hat, passiert nun »client-side« und alles wird irgendwie »hydrated«. Dafür wird dann irgendwas zusammen gebundled und als Ganzes zum Nutzer geschickt. Irgendwelche Daten werden empfangen, verarbeitet und »injected«. Das CMS baut keine Seiten mehr und alles ist »headless«. Genauso kopflos merkt man dann, dass die Seite ewig lädt, verliert die Lust, weil man gerade mit Edge-Netzwerk am Frankfurter Hauptbahnhof steht und du verlässt die Seite.

All das machen natürlich verschiedene »Frameworks«:

,

,

oder einfach

. Alle machen dann am Ende doch irgendwie das Gleiche: Daten zusammenführen, managen, Lifecycles und so weiter.

Viele sehnen sich dann bestimmt wieder nach der Zeit, wo man Websites auch ohne Javascript nutzen konnte. Wenn man dann keine Ahnung hat wie man das Zeug halbwegs statisch generiert hinbekommt, um sowas zu haben wie server-side Rendering, kommen dann wieder Tools ins Spiel wie

,

,

und was sonst noch so rum fliegt um den

zu »embracen«. Den ganzen Krempel muss man dann »deployen« auf irgendwelche Software-Tools, wie

,

oder

. Und dabei wollte der Kunde doch einfach nur eine »Website«.

Doch dass es auch anders geht, merkt man immer öfter. Mit der bescheidenen Daten-Infrastruktur in Deutschland ist es fast schon eine Frechheit dem Nutzer all die Animationen und Extra-Daten auf zu bürden. Es muss eben nicht immer 600kB JavaScript sein, die man laden muss, bis man etwas im Browser sieht. Es braucht keine Hover-Animationen, die ein Screenreader-Nutzer ohnehin nicht sieht. Zu aller erst muss eine Seite zugänglich sein, für jeden Nutzer. Daher ist mein Credo: Nutze deine Tools so, dass sie ihre Aufgabe erfüllen, nicht mehr und nicht weniger. Oder wie Rollkragenpullis sagen würden: Form follows Function.

Selbstverständlich kannst du der Meinung sein, dass du eine große Image-Stage brauchst, um dein Catering-Essen zu zeigen. Oder dass du Formulare in drei verschiedenen Accordions verstecken musst, obwohl du weißt dass das nicht gut für die User Experience ist – wenn du der Meinung bist, es geht nicht anders, dann baue ich dir das. Ich baue dir auch die komplexeste Microservice-Architektur die ohne drei verschiedene

nicht klar kommt. Aber meine Aufgabe ist es darauf hin zu weisen, welcher der einfachste Weg ist und für den Kunden die beste Lösung zu finden.