praegnanz.de büro für intervernetzte medien

Gerrit, 05.02.2015

Aufrüsten gegen den Minderwertigkeits­komplex

Früher war alles besser war Webdesigner noch ein recht gut abgegrenzter, einzelner Beruf, den begeisterungsfähige, technikaffine und geschmackssichere Menschen wunderbar erlernen und ausüben konnten. Ob alleine oder in einer Agentur spielte dabei kaum eine Rolle. Manchmal erhielt man Unterstützung von einem klassischen Grafiker, manchmal konnte eine Webmasterin im Projekt Hilfestellung leisten. 90% der benötigten Arbeiten im Kontext „Website“ konnten von einer Person geleistet werden.

Seit Mitte der Nullerjahre gab es dann verstärkt Webapplikationen mit Serverkomponente , und seit diesem Jahrzehnt werden diese immer stärker mit clientseitiger Logik und Dynamik ausgestattet, bis hin zu reinen Frontend-Apps. Dazu kommt eine Vielfalt an Endgeräten und Nutzungssituationen und – schwupps – ist der Beruf des Webdesigners nicht mehr so klar abgegrenzt wie früher! Es wird spezialisiert wie nichts Gutes, und viele Kolleginnen, die sich früher eventuell allroundmäßig „Webdesignerin“ genannt hätten, sind heute Frontend-Entwicklerinnen. Als solche haben sie nur noch am Rande mit visueller Gestaltung zu tun, und auch das Wissen über die Serverseite – sprich: Datenbanken, CMSe und Serverperformance – überlassen sie anderen Experten.

Nun stehen sie also da, die Frontend-Entwickler, und suchen nach einer neuen Identität für sich und ihre Tätigkeit, und ein bisschen nackt fühlt man sich ja schon. Man kann auf sich alleine gestellt kaum noch eine halbwegs gescheite Website, geschweige denn eine Applikation bauen, dafür braucht es ein Team! Und wenn man sich die einzigen Frontend-Sprachen anguckt, die man zur Verfügung hat, sind diese konzeptionell 20 Jahre alt, nicht mehr sehr praxisnah, zu theoretisch und wirken nicht einmal sonderlich professionell. Blöd! Da hat man den Anspruch, ein richtiger Programmierer zu sein, will sauberen Code schreiben, um auf hohem Niveau für das Frontend zu entwickeln, und womit muss man klarkommen? HTML, CSS und JavaScript? Ernsthaft? Die gleiche Technologie, mit der seit 1997 hässliche Websiten für den Netscape Navigator gebaut werden?

Wahrlich: Die nackten Webstandard-Technologien müssen für junge, gut ausgebildete Informatiker eine echte Zumutung sein! So hatten sie sich das nicht vorgestellt, dass alle richtigen Programmierer über sie lachen und mit dem Finger auf sie zeigen! Richtige Programmierer schreiben C#, Objective-C oder Ruby, sie haben mächtige Entwicklungsumgebungen, feste Typen, Runtimes, VMs. Sie vergleichen Compilergeschwindigkeiten und beobachten die Effizienz von Garbage-Collectoren. Sie deployen auf Devices und testen automatisiert, ob ihre Apps zu häufig crashen. Das sind die Freuden, die das native Programmieren ausmachen! Und natürlich die Tatsache, dass man – zumindest gefühlt – im Bereich der nativen Anwendungen mehr Geld verdienen kann.

Meine steile These ist, dass sich aus dem oben beschriebenen Missverhältnis in den letzten vier bis fünf Jahren eine Art Gegenbewegung gebildet hat, die Frontend-Entwickler weltweit zusammengebracht hat, um gegen die gefühlte Verniedlichung ihres Berufes anzukämpfen. Um gemeinsam die Kränkung wieder wettzumachen. Um die Frontend-Entwicklerin professioneller werden, oder zumindest wirken zu lassen.

Das Resultat dieser – teilweise neidgetriebenen – Anstrengungen ist die Explosion von Meta-Programmierung im Frontend-Bereich. Man hat das Gefühl, dass sich heute fast niemand mehr herablässt, noch normales HTML, CSS und JavaScript zu schreiben. Alles wird kompiliert: HAML zu HTML, SASS zu CSS, CoffeeScript zu JavaScript. Um den ganzen Meta-Code wieder zusammenzusetzen, benötigt man neben Node.js auch einen Package-Manager in Form von npm, ein Build-Tool wie Grunt, Gulp oder Broccoli, sowie groteske Mengen an Node-Plugins für die genannten Build-Tools. Doch als ob wir noch nicht genug Abstraktionsstufen hätten, kommen Tools wie Bower und Yeoman noch obendrauf und automatisieren das automatisierte Automatisieren von automatischem Frontend-Code, der aber in weiten Teilen sowieso „Out of the Box“ von Bootstrap geliefert wird. Und wenn man im Jahre des Herrn 2015 ernsthaft einen Job als Frontend-Dev haben möchte, sollte man ganz schnell noch ein paar Brocken Backbone, React.js und AngularJS lernen, sonst wird das eher nichts.

Mal Spaß beiseite: Viele der genannten Tools sind natürlich sinnvoll und können Zeit sparen, und es ist nicht cool, sich über ihren Einsatz lustig zu machen. Dennoch macht sich seit einiger Zeit bei mir das Gefühl breit, dass das Waffenarsenal der Frontend-Devs mehr und mehr zum Selbstzweck wird, sowie zur Rechtfertigung, dass man eben doch mithalten kann mit den echten Programmieren und ihren fetten IDEs und Prozessen. Dass man automatisierte Toolchains und Deployment-Techniken beherrscht. Und dass man damit ein genauso ernstzunehmender Programmierer sein kann.

Mag alles sein. Ein bisschen Kindergarten scheint mir aber ebenfalls im Spiel zu sein. Kaum eine Woche vergeht, ohne dass man seine Toolchain grundlegend aufrüsten, oder eventuell sogar um eine weitere Automatisierungs- oder Abstraktionsschicht ergänzen muss, um ständig up to date zu bleiben. Ich frage mich, ob die jeweiligen Projekte tatsächlich so umfangreich und hochkomplex sind, oder ob nicht auch einfach ein latenter Minderwertigkeitskomplex verantwortlich ist, der ganz selbstverständlich auftritt, wenn man an einfache und primitive Techniken gefesselt ist, wie sie HTML, CSS und JavaScript in Vergleich zu kompilierten Sprachen darstellen.

Ich für meinen Teil möchte sagen – auch im Interesse einer einfachen und nachvollziehbaren Arbeitsweise: Behaltet die Verhältnismäßigkeit im Auge! Könnt ihr den Einsatz all eurer Tools wirklich gut begründen? Oder ist es nur Angeberei und behindert euch und eure Kollegen bzw. Nachfolger? Verbringt Ihr mehr Zeit beim Feintunen eures Gruntfiles als mit dem Entwurf einer eleganten und gut dokumentierten Programmarchitektur? Ein bisschen weniger Frickeln und ein bisschen mehr Pragmatismus tut manchmal auch ganz gut. Vielen Dank, der alte Mann hat fertig.

27 Kommentare

  1. Katharina am 6. Februar 2015 #

    DANKE!
    Ich sehe das genauso wie du und unterschreibe vollkommen. Was hab ich denn davon, x Tools für ein Tool für ein Tool zur Programmierung zu haben, wenn es doch anders genauso geht – und vielleicht sogar noch besser, weil ich einfach die volle Kontrolle darüber habe und weiß, was ich tue?

    Ich habe vor ca. 10 Jahren meine erste Webseite geschrieben und bis heute hat sich daran nicht viel geändert. Seit ca. einem Jahr bauen viele unserer Seiten hier in der Agentur auf Bootstrap auf. Darüber bin ich dann auch irgendwie zu SASS gekommen. Es hat alles seine Vor- und Nachteile. Aber wenn ich mir anschaue, was andere Frontendler NOCH alles nutzen (siehe deine Aufzählung oben), bekomme ICH Minderheitskomplexe, weil ich nicht weiß, wie ich mich überhaupt noch trauen kann, mich selbst “Webdesigner” oder nun “Frontend Developer” zu nennen, wenn ich doch NUR einfach es HTML mit CSS und ab und zu SASS schreibe?!

    Ich hoffe, dass der Trend zur Verkomplexität irgendwann wieder nachlässt und man sich einfach wieder auf das Entwickeln einfacher und gut bedienbarer, zugänglicher Webseiten beschränkt. Denn dafür braucht man keine 100 Tools, sondern Know-How und Erfahrung, welche man nur durch langjährige Arbeit erhält. Und diese Erfahrung macht uns doch zu guten Frontendlern, und nicht das Beherrschen von 1000 Tools, die niemand wirklich braucht … oder?

    Liebe Grüße,
    Katharina

  2. hochitom am 6. Februar 2015 #

    ich sehe das ganze etwas anders. vielleicht weil ich noch recht jung im business bin und zu netscape zeigen noch im kindergarten war :) ich persönlich sehe diese ganzen tools als praktische helferleins, die mir helfen meinen code sauber zu strukturieren und meine dev files dann eben mit grunt oder gulp für den livebetrieb optimiere. niemand ist deswegen ein besserer oder schlechterer Entwickler weil er jetzt tool x nutzt oder eben nicht.

  3. Jens Grochtdreis am 6. Februar 2015 #

    HAML und Sass entstanden aus dem Wunsch eines Backendprogrammierers, auch im Frontend seine von Ruby gewohnte Syntax nutzen zu können. Er abstrahierte zwei Nicht-Programmiersprachen so, dass sie fast wie Programmiersprachen aussehen.

    Solche Übergriffe vom Backend aufs Frontend gibt es oft, man denke nur an GWT von Google. Sie sind verständlich, weil eine große Anzahl von Backend-Entwicklern auch Frontend-Code schreiben müssen, ohne wirklich zu begreifen, dass HTML und CSS komplett anders funktionieren als ihre jeweiligen Programmiersprachen.

    Die von Dir genannte Toolchain ist ebenso ein Ausfluss dieser Grenzverschiebung. Denn Tools wie Ant gibt es schon lange und Automatisierung ist ein alter Hut – im Backend. Es ist eine wirklich große Leistung, diese Automatisierung so zu portieren, dass jeder halbwegs intelligente und willige Frontend-Entwickler sie nutzen kann.

    Es ist dabei aber wie immer: die Dosis macht das Gift. Man kann sich mit Grunt extrem verkünsteln. Aber ich habe damit mittlerweile Prozesse automatisiert, die früher entweder nicht realistisch gingen oder recht lange gedauert haben. Natürlich hat mich das Einarbeitungszeit gekostet. Aber erstens schärft das meinen Blick für technische Innovationen und zweitens hat es sich schon mehrfach ausgezahlt.

    Trotzdem spricht grundsätzlich nichts dagegen, die technischen Hilfsmittel wie Sass und Grunt einfach wegzulassen. Man braucht sie nicht zwingend. Aber es ist wie mit elektrischen Fensterhebern im Auto: nicht notwendig, aber wenn Du sie mal genutzt hats, möchtest Du nicht mehr kurbeln.

    Der andere Aspekt – die Komplexität von Applikationen – ist schwer zu leugnen. Allerdings habe ich auch den Eindruck, dass alte Hasen wie wir den Jungspunden an der AngularJS-Kanone noch den ein oder anderen wichtigen Hinweis geben könnten. Dass es bspw. eine Semantik über HTML gibt, die man nutzen kann, ohne alles mit JS zu machen und zu verändern.

    Apps gab es in der grauen Vorzeit, von der Du als “früher” sprichst, nicht. Sie sind eine technische Neuerung. Es ist müssig, darüber zu lamentieren. Man kann nur entscheiden, ob man diesen Teil des Spektrums abdecken kann/möchte oder nicht. Es ist ja nicht so, dass es nun nur noch Seiten mit AngularJS und ReactJs gibt. Sie sind noch immer in der Minderheit und werden es sicherlich auch bleiben. Wer sich für diese Nische begeistert, hat einiges zu lernen. Aber das kann ja auch Spaß machen. Bis dann eine der Techniken eingestampft wird oder von einer anderen abgelöst wird.

    Alle anderen machen wie bisher ihre Seiten mit HTML, CSS und ein wenig JavaScript, das dank jQuery bedienunsgfreundlicher geworden ist. Solche Seiten sind schon kompliziert genug, weil die Endgeräte vielfältiger geworden sind.

    Ich finde es aktuell sehr spannend und toll. Besser, als noch vor 10 Jahren. Und ich weiss sehr wohl, dass ich früher einen größeren Prozentsatz der möglichen Frontend-Entwicklung beherrschte, als ich es heute tue. Trotzdem finde ich die Möglichkeiten einfach spannend und möchte sie nicht gegen die langweilige Vergangenheit eintauschen.

  4. Stephan am 6. Februar 2015 #

    Es macht keinen Sinn, bei einem 5-Seiter mit einer Image-Slider-Funktion jQuery-Bibliotheken drauf zu werfen.
    Aber (!) wenn man in einem Team an einer etwas aufwänderigen Seite entwickelt, zwingen einen Frameworks und die diversen Helferlein ala Grunt erstens dazu, sauberen Code zu schreiben und haben zusätzlich noch den Effekt, dass alle Entwickler auf der selben Basis arbeiten. CSS-Frameworks ala Bootstrap sind meistens auch zu viel des Guten, bieten aber durch die diversen Resets und Grid-Systeme auch als Schnittstelle für die Design-Abteilung. Die müssen sich dann nämlich auch an die Restriktionen halten.

    Wer aber nicht in einem Team Websites entwickelt, braucht den meisten Rotz davon aber nicht und hat den Vorteil, dass er auch über die Grenzen solcher Frameworks hinaus entwickeln kann.

  5. Andreas Dantz am 6. Februar 2015 #

    Ich glaube, dass das zum sehr großen Teil eine Wahrnehmungssache ist. Die „Szene“ ist wesentlich größer und natürlich machen dann auch mehr Leute mehr Dinge. Natürlich kann man nicht alles kennen/nutzen/ausprobieren.

    Niemand zwingt dich, irgendwas zu benutzen. Am Ende zählt das Ergebnis und während sich einige Köche im Schleifen ihrer Messer verlieren, schneiden andere völlig abgestumpft. Jeder muss für sich den gesunden Mittelweg finden und sonst den Preis reduzierter Produktivität zahlen. Aber das gilt ja irgendwie auch für alles im Leben.

  6. Gerrit am 6. Februar 2015 #

    Ich mag die Messer-Analogie.

  7. Marc am 6. Februar 2015 #

    Ich denke, entscheidend ist, dass man weiß, was man da tut. Im Endeffekt geht es doch darum, wie man am Ende eine technisch saubere und performante Website hinbekommt (Design-, Usability- und Accessibilitygesichtspunkte mal außen vor, die haben imho wenig mit den Tools oben zu tun). Also: Reduzieren von Requests, Optimieren von Grafiken und überhaupt mal Verstehen, wie das alles – vor allem im RWD – zusammenhängt.

    Das war nämlich früher weniger im Fokus. Wir hatten ja nichts, vor allem keine vernünftigen Internetleitungen. Heute werden die Megabytes durch die Leitung oder eben den Äther gejagt, als wenn es kein Morgen gäbe. Da werden Javascripte eingebaut ohne Rücksicht auf Verluste und das immer schön einzeln alles im Head. WordPress macht das mit seinen Plugins ja auch ganz gerne habe ich gehört. Es funktioniert ja.

    Jetzt gibt es Tools, um Sachen zu automatisieren. Das ist schon ziemlich cool. Ich mache aus zehn Scripts eines, aus vielen getrennten Stylesheets ebenso. Ich kann sehr einfach meine Stylesheets modular aufbauen, ohne dass ich (wie früher) durch @imports die Requests hochschraube. Das ist doch schon ziemlich dufte. Und wenn mich die Syntax von HTML/CSS/JS nervt, kann ich etwas nutzen, das mir viel flotter von der Hand geht.

    Ein Beispiel: Ich nutze eine zentrale mediaquery-JSON, mit der ich die Breakpoints für alles definiere, für CSS, JS und Responsive Images. Das wollte ich unbedingt so haben, weil ich nicht alles dreimal ändern will. Also habe ich mir den Scheiß mittels Stylus, enquire.js und dem picture Polyfill so zusammengebaut. Die Zeit, die ich dafür gebraucht habe, hätte sicher für das dreimalige Ändern von media queries in 100 Projekten gereicht. Aber: Ich habe etwas gelernt. Und ich habe die Performance einer Seite überhaupt das erste mal richtig getestet (um meine Verbesserungen auch zu sehen).

    Zurück zu den o.g. Tools: Ich habe ein bißchen den Eindruck, dass gerne die Entwicklung von Web Apps und die Erstellung klassischer Websites in einen Topf geschmissen wird. Während ich bei einer App sicherlich eine anderer/erweiterte Toolchain aufbauen müsste, sehe ich das bei Websites eigentlich gelassen. Ich brauche hier kein Bower, um bei jedem Build in den (wenn es gut läuft) zwei Monaten der Erstellungszeit auf jeden Fall die neueste Version irgendwelcher Scripts zu inkludieren. Ich brauche eine Version jedes Scripts die performant funktioniert. Wenn ein Webseitenprojekt abgeschlossen ist und funktioniert, brauche ich auch 1 Jahr später nicht zwingend die neueste Version. Also brauche ich in meinem Build-Prozess Bower nicht. Was anderes wäre es in einem durchgehenden Prozess zur Erstellung/Erweiterung/Pflege einer App oder eben eines sehr großen Webseitenprojektes. Da kann man schon eher darüber nachdenken, auch Tools für Apps nutzen. Jeder, wie er will. Solange er weiß, was er da tut.

    Abschließend: Einen guten Frontendler zeichnet das aus, was am Ende im Browser des Nutzers ankommt. Nicht der Prozess, der das ursprünglich zusammengebaut hat.

  8. Peter am 6. Februar 2015 #

    Der aktuelle Trubel um Frontend-Tools ist so groß, weil es sie vorher nicht gab und man jetzt alles durchprobieren muss, um herauszufinden was man wirklich braucht. So wie es früher 9000 General-Purpose-DOM-Libraries gab die verschiedene Konzepte ausprobierten, bis heute im Prinzip nur noch jQuery übrig geblieben ist.

  9. Der Caspers am 6. Februar 2015 #

    Mal ein Anekdötchen aus dem praktischen Agenturalltag:

    Site muss in ein paar Wochen fertig sein, weil Print und TV dann startet, darf aber wie üblich nicht viel kosten. Also werden da Leute drangesetzt, bei denen der Fancy Jobtitle nicht im entferntesten mit Erfahrung und Wissen korreliert. Und weil das Projekt ja so ähnlich ist wie ein anderes für den gleichen Kunden, kopiert man einfach mal das Github-Repo von dem (allerdings ungleich komplexeren) anderen Projekt rüber – da hat man da ja schon das Grundgerüst mitsamt Toolchain, mit dem man dann ganz schnell fertig sein müsste.

    Mehr technisches Verständnis hat PM eh nicht (Architektur? Wofür das denn?), warum auch, es reicht ja, wenn man in Jira die Burn Rate beobachtet und Freitags immer schimpft wenn die Linien zu weit auseinanderlaufen.

    Dummerweise waren in der hochkomplexen Toolchain aber jede Menge Bugs. Und dummerweise war der Einzige, der die noch verstanden hat und es hätte fixen können, nicht mehr in der Agentur. Dumm gelaufen

    Also haben die tagelang damit verbracht, auf ihren Windows-Möhren Ruby ans laufen zu kriegen, gruntfiles zu debuggen, etc. pp., Ihr kennt das. Problem war nämlich, dass die „Frontend-Entwickler“ tatsächlich nur ganz prima in Jade-Templates die Tab-Taste drücken konnten und ansonsten CSS darin bestand, dass man zusätzlich zu Bootstrap 2 noch Bootstrap 3 oben draufknallt und dann noch custom styles hinterherschmeißen, die alles überschrieben. Resultat war dann generiertes CSS nördlich von 0,5 MB.

    Der Kern des Problems: Keiner von denen war mehr in der Lage (oder war noch nie in der Lage gewesen), mal ’ne komplette Seite in HTML/CSS/JS selber zu schreiben (der Lead Developer hat mich gefragt, wofür denn dieses main-Element wäre, dass ich da reingeschrieben hab…). Ohne die ach so super tollen Tools und Frameworks waren die komplett aufgeschmissen.

    Fazit: Tools sind prima, wenn man sie beherrscht. Ab einem gewissen Grad der Komplexität (und der ist heutzutage sehr schnell erreicht) machen diese Tools nur noch dann Sinn, wenn man in der Lage ist, zur Not auch einen Schritt zurückzurollen und es in der gleichen Qualität auch ohne hinzukriegen.
    Wenn man sich aber diesen Tools ausliefert ohne sie zu verstehen, dann macht’s ganz zwangsläufig Bumm.

    Nachtrag: Während dessen hab ich mich lächelnd zurückgelehnt, den Editor meiner Wahl geöffnet und hatte abends so viele Templates fertig dass noch genug Zeit war, um dem Grafiker zu erklären, wie er mit Tontrennung die PNGs nur noch halb so groß kriegt. Kannte er nämlich auch noch nicht, weil er ja eigentlich Kreativer ist und nur Slices produzieren konnte.

  10. David Strauß am 6. Februar 2015 #

    Sich gezwungen fühlen etwas zu tun/verändern/verwenden weil es andere tun nennt man Gruppenzwang, egal ob es dabei um Webentwicklung oder Kochen (um den sehr guten Messer Vergleich aufzugreifen) handelt.

    Die Ursache dafür liegen aber bei einem selbst und nicht bei der Unmenge an Tools. Wenn jemand ständig das neueste verwenden will soll er doch, mein Team und ich bleiben lieber bei unserem bewährten Repertoire.

    Klar ist es Wahnsinn das jede Woche ein neues Framework/Tool entsteht und aufgegriffen wird. Mir persönlich ist in diesem Fall aber ein Überangebot lieber als das Gegenteil. Ich habe mir daraus pragmatische Lösungen herausgesucht die mir die Arbeiten erleichtern die ich sowieso erledigen muss um Qualität zu liefern. Da ist es egal ob es die Website eines Fußballers ist oder eine Infoscreen Anwendung basierend auf Ember.js.

    Um das zu konkretisieren:

    Scss weil Variablen wirklich praktisch sind für Farben, Font Definitionen etc.

    Bourbon und Neat weil sie unaufdringlich sind und unseren Vorstellungen entsprechen wenn es darum geht wie man Raster etc. aufbaut.

    Verkleinern und zusammenführen von CSS und JavaScript damit es pro Typ nur einen Request gibt.

    ImageOptim um jede Grafik automatisch zu optimieren wenn ein neuer Build des Projektes erstellt wird.

    Und zu guter letzt ein Bash Script damit mit einem einzigen Kommando ein neuer Build erstellt werden kann der dann auch sofort deployed wird. Nie wieder in einem FTP Programm irgendwelche Dateien herumziehen, juhu.

  11. Michael Seiler-Gerstmann am 6. Februar 2015 #

    Schöner Artikel!

    Vor ca. 14 Tagen habe ich noch einen Kollegen zu mir gerufen weil ich in der Entwicklung eines Frontendmodules beim Sass Code unwohl gefühlt habe. In den bis dahin geschriebenen 40 Zeilen war eine Zeile nativer CSS Code – da kommt doch wahrlich die Frage auf ob das der Weg ist, den wir folgen wollen.

    Selbst in kleinen Projekten möchte man auf einmal nicht mehr auf Compiler verzichten, installiert Node, Grunt, Bower oder nutzt gar noch eine Abstaktionsschicht wie irgendwelche Generatoren. Manchmal geht gar der Spass verloren weil man die ganze Zeit nur schaut das ja keine Zeile zu viel im Code ist, gar doppelt auftaucht oder den x-ten Wert noch in eine Variable auslagern kann. Und vor allem ob der Output dann noch stimmt.

    Kaum ein Projekt in dem man nicht mindestens 20 npm Pakete installiert hat, kaum jemand macht sich Gedanken über die Wartbarkeit und deren Abhängigkeiten.

    Die Frage ?? Verbringt Ihr mehr Zeit beim Feintunen eures Gruntfiles als mit dem Entwurf einer eleganten und gut dokumentierten Programmarchitektur? ?? ist halt auch einfach berechtigt. Zu mindestens ist der Aufwand und die Pflege, das testen und evaluiere- ein enorm hoher Zeitaufwand.

    Wenn das Team eingeschworen ist, Standards und Guides definiert hat, funktioniert die schnelle Entwicklung und Wartung von Seiten prima. Wenn man jedoch manchmal dann den Code von Freelancern oder anderen Agenturen zugesandt bekommt, schaut man auch manchmal einfach ins leere. Da wurde dann Gulp benutzt oder Less, statt Typescript Coffeescript und dann noch andere Ordnerstrukturen oder andere Dokumentationsstandards- spätestens dann, wäre mir persönlich eine einfache HTML Datei und eine saubere Dokumentation lieber.

    Ich bin froh das es all die Tools gibt, möchte einige nicht mehr missen. Sogleich auch die automatisierten Prozesse wie Tests oder das Releasen. Ich finde die Spezialisierung auf bestimmte Bereiche toll, man kann sich doch den Code anschauen, von jemand der sich Datenbanken, Programmiersprachen, SEO und barrierefreies, responsives Webdesign auf die Fahne geschrieben hat. Irgendwas sieht immer murks aus. Aber manchmal, manchmal hätte ich Lust einfach wieder natives CSS zu schreiben, die Datenbanken selber einzurichten und bei einer PHP Frage zu googlen, statt diese gleich an den Profi hinter mir weiterzuleiten.

  12. Nils Pooker am 6. Februar 2015 #

    Es gibt über den Fotografen Helmut Newton die Anekdote, dass er in einem Restaurant vom Chefkoch höchstpersönlich empfangen wurde, der sagte “Sie machen so fantastische Bilder, Sie müssen eine erstklassige Kamera haben.” Newton erwiderte nichts. Beim Hinausgehen sagte er zum Chefkoch “Das Essen war fantastisch, Sie müssen erstklassige Töpfe haben.”

    Ich sehe allerdings keine Minderwertigkeitskomplexe, die durch Toolchains kompensiert werden sollen. Ich würde Tools an sich auch nicht in Frage stellen. Probleme treten aber immer dann auf, wenn der Gebrauch von Tools zum Selbstzweck, also zu einem betonierten Konzept “gibt es, also nutzen wir es” werden. Kein Kunde wird nach dem Launch sagen “OK, die UX ist grottenschlecht, die Informationsarchitektur ist auch nach vier Iterationen komplett an der Zielgruppe vorbei, das CMS kann hier keine Sau bedienen und das Design entspricht null unserem CI, aber hey, Ihr habt die neuesten und besten Tools verwendet, das gibt ‘ne Sondergratifikation!”

    Kurz gesagt: wer 50 % der Zeit für Codefrickelei durch geniale Tools einspart, aber durch mangelhafte Projektplanung dann noch 400% Zeit draufsatteln muss, hat trotzdem versagt. Werkzeuge sind also Mittel zum Zweck, nicht weniger, aber auch nicht mehr. Je größer die Komplexität des Tools ist, umso größer ist nicht nur die Notwendigkeit, diese Komplexität zu beherrschen, es besteht auch die Gefahr, dass die vermeintlich schnelle und sauber Lösung durch deren Verwendung zu Problemen führt, die man ohne diese Tools überhaupt nicht gehabt hätte.

    Der Flaschenhals, der solche Tools mittlerweile ja im Monatsrythmus generiert, ist sicher auch die Komplexität der Anforderungen an modernes Webdesign, erst recht für Einzelkämpfer. Tools sind da willkommene Heferlein, um dieser Aufgabe noch Herr zu werden. Aber auch hier muss m.M.n. immer die Frage der Angemessenheit in Abhängigkeit zum Ziel gestellt werden. Achja, für Projektplanung gibt es auch total geile Tools. Es gibt aber auch Notizblock und Bleistift.

    Auf alle Fälle ist dieser Beitrag mal wieder sehr erfrischend und kommt genau zur richtigen Zeit. Die Anfänge dieser elendigen Rüstungsspirale hatte ich vor genau 5 Jahren übrigens mal in einem Artikel für das heutige Webmagazin thematisiert, wenn auch mit Schwerpunkt auf die Anforderungen an Hard- und Software.

  13. Emselino am 6. Februar 2015 #

    Nun, ich finde deine Kritik irgendwo berechtigt. Allerdings muss man hier doch eine große Unterscheidung zwischen Webseiten und Webapplikationen (Frontend) machen. Für ersteres benötigt man einfach keine große Toolchain, solange es eine kleinere Site ist.

    Sobald man aber einmal eine solche Applikation gebaut hat und Blut an Tools wie Livereload, Sass und Karma (Tests, das was den “stinknormalen” Webdesigner, der sich einbildet echte Applikationen schreiben zu können, vom Profi unterscheidet ;) ) geleckt hat, möchte man sie nicht missen. Zusätzlich bei jedem speichern einen Linter drüberlaufen zu lassen, spart eine Menge Zeit beim debuggen. Denn seien wir ehrlich: meistens ist es nur ein Komma das man vergessen hat ;)
    Und ja: das Web hat sich professionalisiert und damit steigt auch die Professionalisierung der Arbeitsumgebung. Wir Programmierer sind faule Hunde, und alles was uns das Leben einfacher macht, wird nun mal genutzt

  14. Timo am 6. Februar 2015 #

    Zu der Unterscheidung zwischen Frontend Developer und Webdesigner möchte ich gerne aus dem Unternehmensumfeld anmerken, dass die Unterscheidung durchaus Sinn ergeben kann und dem Webdesigner nicht die Existenz-Berechtigung abspricht.

    In einem Unternehmen, dass sein eigenes Webprodukt-/Webshop entwickelt und pflegt, haben beide Berufe ihre Berechtigung. Der Webdesigner arbeitet oft direkt mit dem Marketing bei der Erstellung von Landingpages, Kampagnen und Pflege des Website/des Blogs zusammen, während der Frontend Developer als Teil des Produkt-Development-Teams für das eigentliche Produkt verantwortlich ist.

    Das bedeutet auch, dass beide unterschiedliche Qualifikationen mitbringen sollte:

    Design-Kenntnisse: Für einen für einen Webdesigner sind diese selbstredend unabdingbar, während sie bei einem Frontend Developer eher ein nice-to-have wären.

    “Kundenumgang”: Ein Webdesigner muss recht direkt mit den Verantwortlichen in einer Marketingabteilung zusammenarbeiten. Ein Frontend Developer ist oft als Teil eines Entwicklungsteams von dem direkten Kontakt mit Geschäftsseite durch einen Produktmanager abgeschirmt.

    Architektur: Ein Webdesigner, der Landingpages erstellt oder eine vorhandene Webpräsenz pflegt, stellen sich viele architektonische Fragen wie Wartbarkeit oder Performance nicht. Für einen Front Developer sind es aber Kernkriterien, nach denen er Entscheidungen treffen muss.

    Building-/Deployment-Tools: Solche Tools lassen sich aus Webdesigner-Sicht durchaus oft durch ein FTP-Programm ersetzen. Aus Frontend Development Sicht gibt es immer mehr sinnvolle Technologien, die sich nicht ohne Building-Tools nutzen lassen. Und Deployment Tools sprechen für sich selber, denn ohne müsste der Frontend Developer an jedem Deployment beteiligt werden.

    Testing: Für die meisten Webdesigner handelt es sich um ein Nice-To-Have und das wichtigste in dem Bereich wäre wahrscheinlich, ein einfach zu benutzendes Automatic CSS Regression Testing. Ganz anders bei einem Frontend Developer der Tests nicht nur im Sinne eines Test Driven Development nutzen sollte. Viel wichtiger ist, für eine Continous Integration Strategie sind Tests unabdingbar.

    Zur Zeit gibt es allerdings Probleme in dem Bereich bei der Suche von neuen Teammitgliedern. Ich habe viele Leute erlebt, die die Anforderungen an ihre Stelle erfüllt haben. Allerdings gibt es in beiden Fällen Ausreißer. Webdesigner die vor lauter neuen Tools und Overengineering kaum noch produktiv sind. Und Frontend Developer – oft ehemalige Webdesigner – die zwar Javascript schreiben können, dies aber immer noch auf dem Niveau von 2005 tun.

    Diese Entwicklung wird wohl durch die von Gerrit angesprochene Entwicklung befördert. Es dauert wohl noch ein wenig, bis sich die beiden Berufe so stark voneinander abgesetzt haben, dass die Berufsbezeichnungen eindeutig verwendet werden können.

  15. Henry Zeitler am 6. Februar 2015 #

    Mein Gott, müssen wir jetzt anfangen unser Revier zu markieren? Nein! Wer mehr als 10 Jahre im Job ist weiß, dass wir damals als Webdesigner bunte Bilder ins Netz gestellt haben. Da gab es 800×600 und 1024×768. Heute gibt es Media Queries und Drölfzigtausend Ausgabegeräte, Mobile-First, Offline-First, RWD, Adaptive, RESS, Performance(!), SEO
    Da darf man doch wohl mal seinen Workflow anpassen, oder?
    Nenn dich Webdesigner, Frontend- oder Web-Entwickler, Ninja, Evangelist oder Was-auch-immer-du-gerade-willst und benutze die Tools die du persönlich brauchst – Hauptsache du lieferst am Ende ein echt gutes Produkt…

  16. The Artist FKA ... am 8. Februar 2015 #

    Die Tendenz zu Meta-Tools, die Routine Aufgaben übernehmen, gibt es in vielen Bereichen. Leider wird manchmal der Rahmen vergessen, oder nicht angemessen bewertet, für den der Einsatz solcher Tools Sinn macht.
    Es ist ein Unterschied ob eine Domain bei der Google „site“ Abfrage 52.400.000 Einträge liefert (micorsoft.com), oder ein paar Tausend Einträge.

    Und leider gibt es, wie überall, die Einstellung: wir nutzen dieses und jenes (weil wir es können!!!).

    Zum Thema Tools gibt es hier noch etwas nachzulesen.

  17. Uschi Ronnenberg am 8. Februar 2015 #

    Und die alte Frau denkt: nichts bestätigt das beschriebene Problem besser als die Kommentare. Und arbeitet zufrieden weiter – irgendwo zwischen Design und Technik und stets eingedenk des klugen Satzes: Was am Ende zählt, ist das Ergebnis. So sieht das nämlich noch einer – der Kunde.

  18. Gerrit am 10. Februar 2015 #

    Wie mehrfach erwähnt, hätte ich in der Tat stärker unterscheiden müssen zwischen Websites und Webapplikationen, wobei die Grenzen aus meiner Sicht immer stärker verwischen. Und ich beobachte, dass Leute, die es gewohnt sind, Webapps zu bauen, dazu neigen, auch kleine Websites mit der unveränderten Infrastruktur zu bauen. Und dafür müssen wir uns hüten, nämlich dass simpelste Aufgaben unnötig verkompliziert werden, weil wir übertriebene Tools anwenden.

  19. Peter Werde am 11. Februar 2015 #

    Wurden hier gerade Frameworks (Backbone ect.) mit Meta-Sprachen (haml ect) mit Task-Tools (grunt ect.) zusammen geworfen und dann gefragt ob man das alles so braucht?

    Hier zB ist eine Webseite die sich serverseitig in node.js über eine api zusammenbaut und dannach den gleichen js und template code an den client weiter gibt (mit browserify).
    https://github.com/artsy/force-public
    Es wäre komplett unmöglich das ohne die ganze fancy souce zu machen.

    Hier zB eine Webseite die wahrscheinlich mit FTP drag and drop deployed wird:
    http://hochitom.rocks/
    Diese Webseite braucht überhaupt gar nichts.

  20. Sven Dietrich am 11. Februar 2015 #

    Aus Gründen der Zustimmung kopiere ich mal den ersten Kommentar.

    DANKE!
    Ich sehe das genauso wie du und unterschreibe vollkommen. Was hab ich denn davon, x Tools für ein Tool für ein Tool zur Programmierung zu haben, wenn es doch anders genauso geht – und vielleicht sogar noch besser, weil ich einfach die volle Kontrolle darüber habe und weiß, was ich tue?

  21. Michael Preidel am 11. Februar 2015 #

    Das ist die gleiche Scheiße wie 2005, als es 680.000 aberwitzig umständliche GTO-Anwendungen für etwas gab, für das eine fünfzeilige To-Do-Liste gereicht hätte. Da wird der Weg zum Ziel. Aber bitte – jedem seine elektrische Eisenbahn sein Hobby.

  22. Karl am 13. Februar 2015 #

    etc.

  23. Anatol Broder am 14. Februar 2015 #

    Die erste Generation der Gestalter hat Webseiten wie Druckerzeugnisse behandelt. Damit meine ich die Menschen, die bis vor kurzem alles mit Flash und Blocksatz zugekleistert haben.

    Nun hat sich das Medium auf der Konsumentenseite wunderbar entwickelt. Dieser Bandbreite gerecht zu werden ist ohne die Verwendung neuer Werkzeuge gewagt.

  24. Ben am 23. April 2015 #

    Also, ganz ehrlich?

    Manchmal denke ich mir, wieso ich den Sch*** mit einer komplizierten HTML5/CSS3/DIV/CLASS/ID/SPAN Struktur mache + Bootstrap für ein 90% breites Bild welches mittig gesetzt werden soll, anstatt eine einfache, 1-2-zeilige, saubere HTML3.x Tabelle zu verwenden.

    So lange der gewünschte Aufwand bezahlt wird (und es halbwegs sinnvoll ist, weil Google es sonst vielleicht nicht mehr auf Smartphones anzeigt? WTF?!?) , ist es ja kein Problem, aber ansonsten habe ich tatsächlich manchmal den Eindruck mit Steinadlern auf Regenwürmer zu zielen.

  25. fwolf am 5. Mai 2015 #

    Mir geht es da ein bisserl wie Ben – solange der Kunde zahlt; und meistens wollen die das ja auch so. Theme mit Bootstrap reinklatschen, der ganze tolle Ablauf, bei dem sich die Software-Entwickler aufgeilen und ein “Web” zum Profil hinzufügen können.

    Neues altes Web .. <schauder>

    Wobei bei mir persönlich der Trend massiv weggeht vom “oh, guck mal, schönes WordPress, das geht fix …” hin zu: Och, also MEINE Website besteht NICHT aus x-fachem Gegrunze (Grunt? Wer braucht den Schrott auf einem UNIXoiden System?!? :pillepalle: Noch nie was von Anacron gehört??), geLESSe, geSASSe und hyperdupergeilen Mega-Frameworks.

    Weder im Backend noch im Frontend. Da steckt nur noch eine simple HTML-Seite drunter, hübsch normales CSS, mit viel Vanilla JS, klein wenig Pimp mittels RGS, headjs und ki.js .. ja. Sicher, das ist immer noch so “trendy tool shit”, aber mit viel Überlegung dahinter.

    Ansonsten: Sag hallo zu meinem Editor, damit aktualisiere ich meine Website. So wie früher, anno 2000 ;)

    Jetzt bräuchte es halt nur noch ein paar Kunden, denen gute Websites wichtiger sind als tausenderlei Werkzeuge. .. tough.

    cu, w0lf.

Kommentar schreiben

Nutzt Textile zum Strukturieren eures Textes.
SEO-Beiträge werden gelöscht, auch bei thematisch passendem Spam.