Es gibt eine gewisse Stimmung, dass Front-End-Entwicklung keine echte Entwicklung ist. Das ist eine prahlerische, trollige Haltung. Dennoch ist es schön, sich manchmal auf die Brust zu trommeln. Versuchen wir zu verdeutlichen, warum Front-End-Entwicklung genauso schwierig und des Titels würdig ist wie jeder andere Teilbereich.
Dies ist eine Fortsetzung meines Beitrags von letzter Woche über die Schwierigkeit, die erwarteten Fähigkeiten eines Front-End-Entwicklers genau zu definieren und wie unterschiedlich wir alle sein können. Dieser Beitrag fand bei einem guten Teil der Leser Anklang, und die darauf folgenden Kommentare waren voller interessanter Geschichten und Erfahrungen darüber, was Front-End-Entwicklung sowohl im technischen als auch im persönlichen Sinne bedeutet.
Die Praxis der Front-End-Entwicklung ähnelt dem Bassspielen: Es ist leicht zu lernen, aber schwer zu meistern. Es steckt viel mehr dahinter als nur HTML und CSS (die für sich genommen schon schwierig genug sind).
Chris stellte auf Twitter eine Frage in Form einer Lückentextaufgabe:
Front-End-Entwicklung ist schwierig, weil _________.
— Chris Coyier (@chriscoyier) 16. Juli 2015
Und während die Mehrheit der Antworten sicherlich unterhaltsam und zum Brüllen komisch war, gab es auch einige Weisheiten darin. Werfen wir einen Blick auf die gemeinsamen Themen, die die Front-End-Entwicklung zu... Entwicklung machen!
Wir müssen uns mit Browserkompatibilität auseinandersetzen.
Inkonsistentes Browserverhalten
— Nathaniel Flick (@nathanielflick) 16. Juli 2015
Dies war mit Abstand die am häufigsten genannte Beschwerde in der Gruppe. Während Internet Explorer immer noch das Ziel der meisten Witze ist, hat jeder Browser seine eigenen Eigenheiten, die oft spezielle Entwicklungstechniken erfordern, um sie zu überwinden.
Es wird von uns erwartet, dass wir wissen, wie man Websites erstellt, die browserübergreifend funktionieren. Wir sollten wissen, welche Browser was unterstützen und wie man browserspezifische Probleme debuggt und überwindet. Wir sollten wissen, wie man verschiedene Browser emuliert oder anderweitig testet.
Wir sollten Werkzeuge kennen, die uns bei browserübergreifenden Problemen helfen, entweder automatisch oder die es uns ermöglichen, Code zu schreiben, um Situationen mit Unterstützung und Nichtunterstützung von Funktionen zu bewältigen. Wir sollten wissen, wie man Fallbacks macht. Wir sollten über progressive Verbesserung und graceful degradation Bescheid wissen.
Browserkompatibilität ist eine äußerst komplexe Entwicklungsaufgabe.
Oh je, all diese Geräte!
Unterschiedliche Bildschirmgrößen und Browser.
— Nicholas Bumgarner (@NickBumgarner) 16. Juli 2015
Neben der Bewältigung von Browser-Inkonsistenzen sind Front-End-Entwickler auch dafür verantwortlich, für so viele Bildschirmgrößen, Bildschirmausrichtungen, Pixeldichten und Eingabetypen wie möglich zu entwickeln.
Die Last der riesigen Landschaft unterschiedlicher Bildschirme, Browser und Fähigkeiten liegt am schwersten auf den Front-End-Entwicklern.
Frameworks, Bibliotheken, Preprocessing, Abhängigkeiten, Plugins...
So viele neue Dinge jeden Tag und keine Ahnung, was zum Standard werden wird.
— dean (@visualcookie) 16. Juli 2015
All die lahmen Frameworks da draußen
— Rick Blalock (@rblalock) 20. Juli 2015
Früher reichte es aus, ein Stylesheet und vielleicht eine JavaScript-Datei in HTML zu verlinken, um mit der Gestaltung und dem Bau einer Website zu beginnen. Tatsächlich ist das immer noch die Basis.
Die heutige Entwicklung fühlt sich ganz anders an. Die Toolchain ist viel dicker. Wir treffen Entscheidungen über Build-Prozesse, welche Bibliotheken wir verwenden, in welchen Sprachen wir schreiben, wie stark wir in zukünftige Syntaxen investieren wollen, wie sehr wir uns auf Frameworks verlassen wollen, welche Drittanbieter-Tools sinnvoll und sicher zu verwenden sind.
Es ist nicht nur ermüdend, über die Entscheidungen nachzudenken, sondern es wird auch immer schwieriger zu wissen, welche die besten Entscheidungen sind und ob diese Entscheidungen langfristig klug sind.
Es gibt genauso viele, wenn nicht sogar mehr, Entscheidungen auf der Front-End-Ebene der Entwicklung als überall sonst. Ganz zu schweigen davon, dass sich die Landschaft extrem schnell bewegt.
Wir sind die Brücke zwischen visuellen Designern, Back-End-Entwicklern und anderen Disziplinen.
weil es sich nicht mehr ganz nach "Front-End" anfühlt
— Ara Abcarians (@ItsMeAra) 17. Juli 2015
Viele der heutigen Frameworks und CMS's überschneiden sich mit vielen verschiedenen Disziplinen. Front-End-Entwickler stehen mitten drin. Wir sind letztendlich für das Design verantwortlich – wie die Seite aussieht. Wir helfen Content-Erstellern, sicherzustellen, dass sie das haben, was sie brauchen, und uns geben, was wir brauchen. Wir arbeiten in Vorlagen, extrahieren die Daten, die wir brauchen, in den Formaten, die wir brauchen. Wir verarbeiten Benutzereingaben und stellen sicher, dass sie für Back-End-Anliegen weitergeleitet werden.
Man wird verwirrt, wer man ist – Programmierer oder Designer
— Priyanka N Majumder (@PriyankaNM) 17. Juli 2015
Die Kette der Schuld beginnt beim Front-End
— Chris (@chrisdebelen) 16. Juli 2015
Nicht nur sitzen wir am Schnittpunkt vieler Disziplinen, es wird auch erwartet, dass wir genügend Back-End-Sprachen kennen, um nützlich zu sein. Sie wären ein ziemlich schlechter WordPress-Entwickler, wenn Sie kein PHP könnten. Sie wären auf einem Rails-Projekt nicht sehr nützlich, wenn Sie keine Ruby- oder Rails-Konventionen kennen würden. Je mehr Sie wissen, desto agiler und eigenständiger können Sie für Ihr Team sein.
Jeder und sein Zahnarzt denkt, er kann das machen.
Es ist einfach, mach es so... warte - jetzt so... okay, jetzt wo wir fertig sind, können wir alles zu diesem ändern? es ist einfach...
— Andrew League (@aleague888) 16. Juli 2015
Die Eintrittsbarriere für die Front-End-Entwicklung ist ziemlich niedrig. Jeder hat von HTML gehört. Sie "wissen genug, um gefährlich zu sein", wie man so sagt. Da diese Barriere niedrig ist und es so einfach ist, sich damit zu beschäftigen, ist es verständlich, dass Leute annehmen, es gäbe nicht viel zu wissen und dass Front-End-Entwicklung nicht besonders schwierig sei.
Dinge benennen. Und wir müssen viele Dinge benennen.
Man muss Dinge benennen.
— Stuart Robson (@StuRobson) 16. Juli 2015
Ich stelle mir vor, Sie haben das Sprichwort gehört, dass das Benennen von Dingen eines der schwierigsten Probleme in der Informatik ist. Wir Front-End-Entwickler benennen ständig Dinge. Klassennamen und IDs, Datenattribute, Dateinamen, die Kommunikation von Mustern mit Ihrem Team. Es ist endlos. Es fühlt sich an, als gäbe es an einem durchschnittlichen Tag Dutzende von Namensentscheidungen.
Ganz zu schweigen davon, dass die Aufgabe der Texterstellung oft auf uns fällt, was nicht ganz *Benennung* ist, aber in einer ähnlichen Schwierigkeitsdimension liegt.
"Der richtige Weg" und "der falsche Weg" sind nicht so klar definiert wie bei der Back-End-Entwicklung.
Kein standardmäßiger Produktions-Pipeline. Keine Referenz-Browser-Implementierung. Keine richtigen Antworten, aber unzählige falsche.
— Pelle Bjerkestrand (@pcbjerkestrand) 16. Juli 2015
In der Back-End-Entwicklung, wenn das, was Sie erwarten, passiert, haben Sie Erfolg. Sicherlich gibt es verschiedene Wege, um dorthin zu gelangen, einige besser als andere. Aber in der Front-End-Entwicklung scheinen die Wege zur Erledigung einer Aufgabe endlos zu sein. Selbst wenn Sie scheinbar Erfolg hatten, kann es sich so anfühlen, als wäre es nur eine Frage der Zeit, bis ein Fehler in Ihrer Vorgehensweise gefunden wird.
CSS ist sehr schwer zu testen.
Back-End-Sprachen (und sogar JavaScript) können Unit-Tests und Integrationstests verwenden, um sicherzustellen, dass der Code wie erwartet funktioniert. CSS hat eine solche Luxus nicht. Es gibt sicherlich Leute, die es versuchen, und es gibt einige Informationen und Werkzeuge. Aber nichts davon ist besonders gut und es gibt nur sehr wenige Erfolgsgeschichten.
Fehler können subtil, verwirrend und unerwartet sein. Schlimmer noch, eine scheinbar kleine Änderung kann unerwartete negative Auswirkungen haben, die man erst bemerkt, wenn es zu spät ist.
Es gibt Linting-Tools, die ein wenig helfen. Es gibt einige Tools zur Durchsetzung von Styleguides, aber sie helfen nicht wirklich bei der Durchsetzung wichtigerer Dinge wie der Einhaltung von Namenskonventionen.
Front-End-Entwickler müssen ein sehr starkes Verständnis der gesamten Website in ihrem Kopf haben, um am effektivsten und effizientesten zu sein.
JavaScript ist genauso komplex wie jede andere Programmiersprache. Es ist seltsam und schwer.
JavaScript ist Front-End-Entwicklung. JavaScript ist Programmierung. Programmierung ist Teil der Softwareentwicklung. Softwareentwicklung ist schwer.
Performance liegt zu 80% bei uns.
Die Faustregel besagt, dass 20 % des Wartens auf das Laden einer Website auf Back-End-Belange zurückzuführen sind. Sobald das HTML-Dokument angekommen ist, ist der Rest der Ladezeit die Verantwortung der Front-End-Entwickler. Welche Ressourcen geladen werden, wie viele Ressourcen geladen werden, wie optimiert sie sind, in welcher Weise sie geladen werden und wie sich das anfühlt usw.
Hier findet Barrierefreiheit statt.
Das Erstellen von optisch beeindruckenden Websites ist eine Sache, und deren Barrierefreiheit eine andere. Designer legen großen Wert darauf, wie Benutzer mit einer Website interagieren, und das ist nicht immer eine visuelle Interaktion. Das Design und die Entwicklung für Behinderte ist eine eigene Disziplin, aber am engsten mit der Front-End-Entwicklung verbunden. Barrierefreiheit hat eigene Spezifikationen, die leider nicht typischerweise zusammen mit dem traditionellen Front-End-Entwicklungstraining gelehrt werden.
Es ist schwer, Leute dafür einzustellen.
Front-End-Entwickler sind typischerweise die am schwersten zu besetzenden Stellen.
Und, natürlich...
Weil wir es schwierig machen.
— (@mikeyb) 16. Juli 2015
Zusammenfassend
Was denkst du also? Ist Front-End-Entwicklung "echte" Entwicklung? Ich würde sagen ja und glaube, dass das hier vorgelegte Feedback – insbesondere von anderen – ein solider Beweis dafür ist. Gibt es noch mehr Dinge, die es schwierig machen? SEO? Ist das eine Konversation, die es wert ist, geführt zu werden?
Nun, das ist ein erstaunlicher Beitrag. Es gibt einfach so viele Wahrheiten. So viele Möglichkeiten und Optionen und Dinge, Wege, um eine bestimmte Aufgabe zu erfüllen. Die Front-End-Entwicklung hat so viele Werkzeuge zur Verfügung, aber die Wahl der richtigen Werkzeuge und deren Nutzung sind zwei völlig verschiedene Dinge. Wir machen es wirklich schwierig.
Ich bin mir nicht sicher, woher diese Idee "Front-End-Entwicklung ist keine echte Entwicklung" kommt. Es ist fast albern zu versuchen zu "beweisen", dass Front-End-Entwicklung Entwicklung ist. Es gibt nichts zu beweisen, natürlich ist es Entwicklung.
Nichtsdestotrotz, obwohl ich den meisten Punkten in dem Artikel zustimme, ärgern mich einige davon wirklich.
Ein Front-End-Entwickler hat eine Teilmenge der Fähigkeiten eines Full-Stack-Entwicklers. Nach dieser Logik sind Full-Stack-Entwickler unmöglich einzustellen.
Es geht nicht wirklich darum, Front-End- oder Back-End- oder Full-Stack-Entwickler zu finden. Es geht darum, *gute* Entwickler zu finden. *Gute* Entwickler sind die am schwersten zu besetzenden Stellen.
JavaScript ist nicht Front-End-Entwicklung (siehe: Node.js, Spiele-Skript-Engines und -Editoren und unzählige andere gängige Anwendungen). Sicher, JavaScript ist Teil der Front-End-Entwicklung, aber was soll's? Wer versucht zu sagen, dass JavaScript *nicht* so komplex ist wie jede andere Programmiersprache? JavaScript ist *sehr* komplex, unabhängig vom Kontext, in dem es verwendet wird.
Der Front-End-Teil eines Full-Stack-Entwicklers macht etwa 1/3-1/2 der Fähigkeiten eines professionellen Front-End-Entwicklers aus. Spezialisierung ermöglicht es Ihnen, tiefer einzudringen, wo jeder andere davon ausgeht, dass sein oberflächliches Wissen alles ist, was es zu wissen gibt.
Das Problem ist, dass man Leute braucht, die sich um das Back-End und die Middleware kümmern, bevor man sich spezialisieren kann, um ein Front-End-Entwickler zu werden. Um also überhaupt ein Front-End-Entwickler zu werden, braucht man größere Teams.
Da vor dem Front-End-MVC die meiste Entwicklung im Back-End stattfand, findet man dort viel mehr gute Back-End-Entwickler als Front-End-Spezialisten.
Es gibt nicht zu viele größere Front-End-Teams. Diejenigen, die Front-End-Entwickler hervorbringen, wollen sie normalerweise nicht verlieren, daher ist es schwer, sie einzustellen.
Quelle: meine Erfahrung; wir versuchen derzeit, 2 neue fortgeschrittene/leitende Front-End-Entwickler einzustellen.
Hehe, ich bin mir nicht sicher, ob ich zustimmen oder widersprechen soll...
Ich stimme zu – was Sie gesagt haben, beweist meinen anderen Punkt
Ein "Full-Stack"-Entwickler mit nur 1/3 oder 1/2 der Fähigkeiten eines Front-End-Entwicklers ist kein echter Full-Stack-Entwickler – meiner Meinung nach – ich bin sicher, andere mögen das anders sehen.
Es ist die Diskussion "Hansdampf in allen Gassen, Meister in keinem" versus "Hansdampf in allen Gassen, Meister in einigen". Ich mag Full-Stack-Entwickler, die zum zweiten passen.
Front-End-Entwicklung ist schwierig – im Grunde – weil wir alles wissen müssen und jeder denkt, wir wissen nichts. Ich habe die Gehaltsunterschiede zwischen Back-End- und Front-End-Entwicklern bemerkt. Das stört mich wegen der breiten Palette an Technologien (neu und alt), die ich kennen muss, während die meisten Back-End-Entwickler mit zwei, vielleicht drei (je nach Nutzung von Datenbanken etc.) arbeiten. Außerdem mussten wir beide einen Abschluss in Informatik machen, nur dass ich mich dann mit etwas anderem beschäftigt habe.
Von uns wird erwartet, dass wir unsere Daten-/Kontrollstrukturen kennen, aber auch nitpicky Nuancen mit drei oder mehr Sprachen, zusätzlich zu 5 Jahren Erfahrung mit dem neuesten Framework, das letzten Monat debütierte, und uns über das, was in ES8 passiert, freuen (wobei ES6 erst langsam unterstützt wird). Darüber hinaus wird ein Back-End-Entwickler oft versuchen, unseren Workflow nach seinen Vorstellungen zu gestalten, was alle verärgert, weil sie nicht verstehen, warum wir ihnen gesagt haben, dass sie falsch liegen, weil sie nicht verstehen, wie Kaskadierung funktioniert und warum wir denken, dass es so gemacht werden sollte, wie sie es falsch finden.
Dies kann auf Erfahrungen beruhen oder auch nicht.
Wie Sie richtig bemerken, sind Front-End-Entwickler die Brücke zwischen vielen anderen Disziplinen, die ein Webprojekt ausmachen. Ein guter Front-End-Entwickler muss bis zu einem gewissen Grad Projektmanager werden und ein gutes Verständnis für alle Disziplinen haben, die durch sie fließen, um das Endprodukt zu erstellen. Selten berücksichtigen die angebotenen Gehälter für Front-End-Entwickler-Positionen dies.
Ich hatte gerade ein Vorstellungsgespräch mit einem Bewerber für eine fortgeschrittene Front-End-Entwicklerposition – er glaubte tatsächlich, dass nur JavaScript und zumindest ein Teil des Back-Ends ausreichen würden, um es als Entwicklung zu bezeichnen. Unnötig zu sagen, dass mir das genug über seinen gravierenden Mangel an HTML/CSS sagte, um das Gespräch zu beenden.
Außerdem waren viele der früheren Bewerber eher Framework/Toolkit-Nutzer als Front-End-Entwickler; sie konnten nicht einmal eine einfache Tab-Komponente in JS/jQuery schreiben, geschweige denn komplexeren Code.
Stellen Sie in Ohio oder Remote-Entwickler ein?
Erwägen Sie Remote-Arbeit als Option?
Beruhigen Sie sich.
Sie haben einen bestimmten Wissens- und Fähigkeitsbereich. Ich gehe davon aus, dass Sie damit gut genug sind, um Ihre Rechnungen zu bezahlen. Warum kümmern sich die Leute in unserem Beruf um Titel; Ist es nicht schon komplex genug?
"Entwickler" ist kein allzu präziser Begriff, "Klempner" schon. Solange Ihr Profil einem Markt entspricht, sollte alles in Ordnung sein.
Und übrigens, echte Programmierer benutzen Schmetterlinge.
Bedeutet das dann, dass Front-End-Entwickler nur dann "echte Programmierer" sein können, wenn sie eine Abzweigung von HTTP schreiben, die ihre Webpakete über Schmetterlinge liefert?
Außerdem, soweit ich weiß, geht es bei dem hier angesprochenen Problem normalerweise nicht um einen Titel – es geht um eine gewisse Ignoranz bei einigen derjenigen, die einstellen, und mit denen Front-End-Entwickler zusammenarbeiten.
Ein Front-End-Entwickler zu sein bedeutet heute, ein bisschen von allem wissen zu müssen. Neben HTML/CSS/JS sind Sie normalerweise für Designentscheidungen im Bereich Responsive zuständig. Designer erstellen immer noch PSD-Mockups für Desktop-Layouts, und wir übersetzen sie dann. Sie müssen sich um Barrierefreiheit kümmern. Auch die Leistung der Website.
Arbeiten Sie mit WordPress? Dann sind Sie für PHP-, MySQL- und Datenbankprobleme zuständig. Normalerweise migrieren wir die Website von Staging nach Produktion, und obwohl einige verwaltete Hoster dies übernehmen, gibt es viele Fälle, in denen dies immer noch manuell erfolgt.
Natürlich müssen wir Photoshop so gut verstehen, dass wir Farben und Deckkraft interpretieren, Schriftgrößen von pt in px umrechnen und das Linealwerkzeug verwenden, um Abstände und Ränder zu messen.
Wir kümmern uns auch um UX, übersetzen Interaktionen in CSS-Animationen und schreiben oft Texte für Websites.
Aber das kann jeder machen. *lacht*
Auf den Punkt gebracht!
Ganz genau!
Hol mich hier raus.
Dies!
Also gibst du zu, dass dein Job nur wirklich etwa 50 % Entwicklung, 50 % Ausgleich deiner Disziplinen ist. Aha!! Du bist nicht *wirklich* ein Entwickler... *Sarkasmus*
Als Back-End-Entwickler sage ich, Softwareentwicklung ist einfach – zumindest im Vergleich zur Front-End-Entwicklung. Der Umgang mit JS ist bei weitem der einfachste Teil der Front-End-Entwicklung. Alles andere ist viel schwieriger!
:) Das hat mich zum Lächeln gebracht. Danke dafür. Das habe ich auch schon von anderen Back-End-Entwicklern gehört und es überrascht mich. Ich denke, es liegt daran, dass FED und BED einfach unterschiedlich denken – FED denkt in Bezug auf das Visuelle und BED denkt eher in linearen/mathematisch orientierten Begriffen, meiner Meinung nach nicht so sehr visuell. So faszinierend!
In meinem Büro haben wir einen Webentwickler und ich bin der Webmaster. Trotz der alten Titel haben wir uns effektiv in Front-End (ich) und Back-End getrennt. Ich kann Ihnen sagen, dass ich als Verantwortlicher für das Front-End mich in der sich ständig ändernden HTML/CSS/JS-Front erheblich weiterentwickeln musste, aber auch im Back-End (wir sind eine ColdFusion-Werkstatt) und in der Interaktion mit der Datenbank kompetent werden musste. Außerdem bin ich irgendwie der einzige moderne Experte für alles Web auf dem Campus, daher werde ich für weit mehr als meine Fähigkeit, ein Stylesheet zu schreiben, herangezogen.
Es ist ein harter Job, er ist fast sicher (meiner Meinung nach) eine Weiterentwicklung des Jack-of-all-trades Webmasters. Aber ich gebe auch zu, dass einige der (guten) Back-End-Jungs Zauberer sind!
Um ehrlich zu sein, vermisse ich irgendwie den Webmaster.
Natürlich, wenn man "master" an alles anhängt, wird es 100% cooler.
Ich denke, das Vorurteil gegen Front-End-Entwicklung kommt von zwei Enden des Spektrums. Einerseits fangen viele Leute mit ein wenig JS/CSS/HTML an, und es ist verlockend, Front-End-Entwickler als diese Anfänger zu betrachten, die ständig neu anfangen. Am anderen Ende erkennt man die Komplexität der Front-End-Entwicklung und hinterfragt den Verstand der Leute, die in der "feindseligsten Entwicklungsplattform der Welt" leben wollen.
Front-End-Entwicklung ist nicht schwer, weil die Kernelemente der Probleme, die die Leute lösen, schwer sind (essentielle Komplexität). Es liegt daran, dass sich die Umgebung so entwickelt hat, dass selbst einigermaßen einfache Probleme zu einer lästigen Pflicht werden. (Es ist die essentielle vs. akzidentelle Komplexität, wie sie von Brooks beschrieben wird.) Und dann, wenn man versucht, ein Problem zu lösen, das an sich schon kompliziert ist, und die Umgebung all die zusätzlichen Schwierigkeiten hinzufügt, die oben aufgezählt sind, oh, das tut weh!
Ich mag den Artikel und die Begründung dahinter.
Aber was ich gerne denken würde, ist, egal wie viel Front-End-Entwickler Sie sind (Anfänger, Fortgeschrittener, Experte)... behalten Sie auch andere Dinge im Auge... neue Frameworks, neue Syntax, neue JS-Bibliotheken, Entwicklung von mobilen Apps... Datenbankentwicklung.................................
Nur für den Fall, dass die Zeit kommt und Sie aufgefordert werden, Ihre Rolle oder eine bessere Position an einem Ort zu übernehmen... zumindest müssen Sie dann nicht zögern... und es gibt immer die Erfahrung als Front-End-Entwickler, die Ihre Komplexität untermauert... :)
Wahrheit.
Als stolzer FED (und auch als Bassist) – ich könnte es nicht besser formulieren. Ich erinnere mich, dass ich wütend wurde, wenn kluge Back-Endler Front-End-Entwickler und die Entwicklung im Allgemeinen herabwürdigten (nun, vielleicht hatten sie in den 90er Jahren Recht). Wenn ich sah, wie sie frustriert wurden, nachdem sie gebeten wurden, ein paar einfache Dinge auf der Front-End-Seite zu tun, wurde ihnen klar, dass mehr dahintersteckt, als man denkt, und das, denke ich, ist der Grund, warum die Front-End-Entwicklung schwer zu meistern ist; während die meisten Programmiersprachen sehr meinungsstark sind, strenge Dokumentationen haben und meistens Schwarz-Weiß-Lösungen für gängige Probleme bieten, müssen wir Front-Endler es auf die harte Tour lernen und unterwegs, nachdem wir ordentliche Erfahrung und Einblick gewonnen haben, dass wir so viele Verantwortlichkeiten haben, die über das bloße "Zeichnen von Dingen" auf dem Bildschirm hinausgehen.
Es ist eine Sache, Front-End-Entwicklung zu betreiben, es ist eine ganz andere Geschichte, ein Front-End-Entwickler zu sein.
Ein Entwickler ist ein Entwickler ist ein Entwickler. :)
Unterschiedliche Fähigkeiten, gleicher Job.
Ich denke, dass die Fähigkeiten, Erfahrungen und Werkzeuge, die zur Segmentierung der Entwicklung in Front-End, Back-End und Full-Stack verwendet werden können, undurchsichtig waren und sind – für Entwickler und für die Unternehmen, die jemanden wollen. Selbsterklärung ist normalerweise nutzlos, außer für Insider, die sich zunicken und über die "informierte" Ignoranz von Personalvermittlern oder Autoren von Unternehmens Stellenausschreibungen beklagen können.
Entwickler sind nicht von der Mitwirkung an den immer verschwimmenden Linien befreit, denn seien wir ehrlich, wenn wir einen Job brauchen, bewerben wir uns auf alles – insbesondere auf Front-End-Entwickler. Historisch (und mit Geschichte meine ich eine Vergangenheit, die weiter zurückliegt als ein paar Jahre), bedeutete Front-End-Entwicklung die jetzt vulgäre Geschäftstätigkeit, ein Webmaster zu sein. Selbst als sie existierten, waren Webmaster so selten wie Einhörner, weil niemand je das Web gemeistert hat. Der Begriff umfasste eine breite Palette von Fähigkeiten, einschließlich Back-End- und Front-End-Spezialisierungen, und erforderte im Allgemeinen die Fähigkeit, sich an die Lawine des "Neuesten", "Besten" anzupassen, indem man von Bekanntem extrapoliert. Diese Anpassungen wurden im Kontext ihrer Projekte vorgenommen, vielleicht richtig, vielleicht auch nicht. Ohne Zeit zum Abreißen oder Experten zu werden, wurde Erfolg erzielt, wenn es funktionierte und nichts brach. Das nennt man Herumspielen. Webmaster waren Dilettanten.
Erfolgreiches Herumspielen hielt lange an. Es war so erfolgreich, dass der Mythos bis heute fortbesteht, dass eine einzelne Person die Internetpräsenz eines kleinen bis mittelständischen Unternehmens verwalten kann. Er wird weiterhin fortbestehen, solange diese Unternehmen Dilettanten wollen (auch wenn sie nicht verstehen, was sie wollen), während sich jeder Entwickler auf jeder Ebene darauf bewirbt und somit die Vorstellung verstärkt, dass der Markt für Entwickler homogen ist.
Und wir wundern uns, warum Unternehmen Schwierigkeiten haben, einen Entwickler einzustellen. Ein Unternehmen, das einen Front-End-Entwickler sucht, sucht normalerweise jemanden, der ihre spezielle Mischung aus exzentrischen, seltsam verknüpften "man musste dabei gewesen sein, als jemand 'absolut darauf bestand' auf etwas" verwalten kann, was den Abbau von Standards begann, der zu einem Monstrum geführt hat, das nur von einer einzigen Person verstanden wird.
Nach meiner Erfahrung treten bei Nicht-Tech-Unternehmen erst dann radikale strukturelle Veränderungen ein, wenn das Monstrum ausbricht, um das Unternehmen zu terrorisieren, beginnend mit der Erkenntnis, dass ihr Entwickler wahrscheinlich kein großartiger Datenbankadministrator, Programmierer oder Softwareingenieur ist.
Infolgedessen, da ein Bruchpunkt eingetreten ist, werden echte Back-End-Spezialisten ziemlich plötzlich eingeführt, die nach etwa 5 Minuten die für das Chaos verantwortliche Person verfluchen, anstatt im Chaos die Magie eines manischen Genies zu sehen, das darum kämpft, das, was das Produkt eines koordinierten Teams von Stackmastern hätte sein sollen, unterzubringen und zu harmonisieren.
Zum größten Teil können auch heute noch einzelne Entwickler, die eine Multi-Tabellen-Datenbank erstellen und abfragen, PHP, JavaScript, HTML, CSS schreiben, einen Pre(post)prozessor ausführen, den DOM durchqueren, Entwicklerwerkzeuge verwenden, mit Frameworks erstellen, sogar die Grundlagen von On-Page-SEO kennen, Dominanz der Creative Cloud aufweisen, ihre Git-Hubs wie Nodes gestalten, sich selbst, wahrheitsgemäß genug, als das darstellen, was auch immer nötig ist, um den Job zu bekommen.
ALL das, um zu sagen: Wenn Jobsuchende nicht wissen, was sie brauchen, wenn unsere Freunde, Familie und das Finanzamt nicht wissen, wie sie uns nennen sollen oder verstehen, was wir tun, denke ich, liegt das daran, dass wir es auch nicht wissen und nicht genau wissen, was wir wissen sollten.
An all die Full-Stack-Entwickler da draußen: Ihr seid sehr bewundernswert. Genießt euren Herzinfarkt, Nervenzusammenbruch und euren gottgleichen Status – letzteres, weil ihr euren Chefs sagen dürft, wie die Dinge gemacht werden, während natürlich die Entwicklergemeinschaft zwinkert und nickt.
Dieser Beitrag ist so erbärmlich wie die Leute, die ihn provoziert haben.
Es ist völlig in Ordnung, so über den Beitrag und die Leute, die ihn provoziert haben, zu denken, aber das gilt auch für Meinungen ohne Begründungen. Wenn all diese Dinge erbärmlich sind, erkläre zumindest, wie sie es sind, und vielleicht kann daraus ein guter Dialog entstehen.
Front-End-Entwickler hier, mein Team und ich arbeiten an einem großen Ember.js-Projekt. Wir müssen Echtzeitdaten anzeigen (viele Daten!) und ich muss sagen, dass wir wahrscheinlich härtere Zeiten haben als die Jungs im Backend :/
Ich kenne deinen Schmerz und fühle mit dir. War dabei, habe das getan.
Ich stimme allen Aussagen dieses Artikels voll und ganz zu und finde es interessant zu sehen, dass wir die Tendenz haben, immer mehr serverseitige Logik mit JS auf den Client zu verlagern. Das zwingt Backend-Entwickler, sich mehr mit dem Front-End-Teil der Entwicklung zu beschäftigen.
Im Gegensatz zu jedem anderen Job muss man als Front-End-Entwickler immer weiter lernen, sich entwickeln und anpassen. Es ist eine ständig wechselnde, harte Umgebung.
"JavaScript ist Front-End-Entwicklung. JavaScript ist Programmierung. Programmierung ist Teil der Softwareentwicklung. Softwareentwicklung ist schwer."
Mein Lieblingszitat aller Zeiten.
Dein Kommentar veranlasst mich, das Fehlen eines Like-Buttons in den Kommentaren zu bedauern. :D
Danke für den Artikel, ich habe ihn gerne gelesen. Ich muss zustimmen, dass Front-End-Entwicklung ein extrem schwieriger Job ist und ständiges Lernen und ständige Weiterentwicklung erfordert. Das kann hart sein, aber es ist auch Teil des Spaßes, wir drängen ständig voran und streben nach Verbesserung, wir haben Jobs, die das aktiv fördern und uns agil und flexibel machen, wir können nie ruhen oder wir fallen zurück.
Meine einzige Beschwerde ist, dass ich das Gefühl habe, es gibt eine Haltung, die umhergeht und durch so etwas wie dieses angeheizt wird, die einen dazu bringen will, die Brust aufzublähen, den Korridor hinunter zu ihren Kollegen zu schauen und Dinge zu sagen wie: "Ich kann tun, was du tust", "Ich bin eigentlich noch wertvoller für das Team" oder "Warum bist du mehr dran als ich", noch besser "Ich weiß mehr und kann dich ersetzen, du machst nur ein oder zwei Dinge".
Das ist kontraproduktiv für das Team, und wenn wir wirklich großartige Produkte bauen wollen, würden wir uns davor scheuen, der Projekt-Held sein zu wollen, und versuchen, ein besserer Teil des Projektteams zu sein. Entwickler, Front-End-Entwickler, Designer und sogar Projektmanager sind alle Spieler auf derselben Seite, wir haben das gleiche Kernziel: ein Produkt bauen. Jeder von uns denkt, dass sein Bereich der wichtigste ist (vermutlich ist das der Grund, warum wir ihn überhaupt wählen), aber wir brauchen alle, die zusammenarbeiten, um nicht nur ein gutes Produkt, sondern ein großartiges zu bauen.
Ohne einen großartigen Hacker an Bord haben wir langsame Datenaufrufe, schlecht strukturierte APIs und vor allem müssen wir diese Dinge tun (was ich nicht genieße). Ein Front-End-Entwickler, der eine Website gestalten kann, kann das vielleicht tun, aber was weiß er über Branding, weiß er, wie man dieses Produkt tatsächlich verkauft, denn das ist das Ziel, liest er nur Artikel online, schaut sich 2015er Web-Inspirationen an und gestaltet dann die Website, das ergibt kein großartiges Produkt, vielleicht hat es gute Typografie, aber erfüllt es die Konversionsziele, denn das ist es, was gutes Design tun muss. Ebenso wird es ein Designer, der sich nicht die Mühe macht, HTML, CSS, JS zu lernen, wahrscheinlich Schwierigkeiten haben, eine gute Website zu gestalten, und es wird nur noch schlimmer, wenn er dann nur an seinem Schreibtisch sitzt und das Entwicklungsteam nicht fragt, ob das, was er tut, gemacht werden kann oder ob es Hindernisse gibt.
Ich schätze, was ich sage, ist, wir alle haben Überschneidungen, wir alle teilen einige Fähigkeiten, keine ist besser, und anstatt herumzustehen und zu vergleichen, wer die größeren Werkzeuge hat, sollten wir uns darauf konzentrieren, wie wir bessere Teams sein können, wie wir kommunizieren und besser zusammen kommunizieren können, um das Wissen, das wir haben, zu teilen, um nicht gute Produkte, sondern wirklich großartige Produkte gemeinsam zu liefern.
So sehe ich das jedenfalls, nochmals danke für den Artikel, er war eine gute Lektüre.
Tolle Punkte, außer... was hat dich jemals denken lassen, dass alles auf der Back-End-Seite klar und deutlich ist? Bahahahahaha....
Nun, die .NET-Bibliothek und Visual Studio kommen dem sehr nahe ;)
Aber ja, es ist dasselbe wie im Front-End. Es hängt vom Projekt ab.
Habe diese Diskussion noch nie gehört und würde ihr nicht einmal einen ganzen Artikel widmen. Alle Backend-Entwickler um mich herum sind sich einig, dass es im Frontend schwieriger ist zu entwickeln als im Backend, und deshalb mangelt es uns an guten Frontend-Entwicklern. Und Kunden und Designer um mich herum verstehen die Prinzipien der Backend- und Frontend-Entwicklung überhaupt nicht, daher haben sie keinen Grund, dieses Thema anzuprangern. Ich habe das Gefühl, dieser Artikel dient nur dazu, Gegenargumente für die unhöfliche Aussage eines einzelnen "Hacker-Kiddies" zu liefern.
natürlich sagen Front-End-Entwickler, dass ihr Job hart ist. Das liegt daran, dass sie Front-End-Entwickler sind :P
Ich stimme vielen der Kommentare hier zu. Ich glaube nicht, dass irgendein legitimer Back-End-Entwickler bestreiten würde, dass Front-End-Entwicklung echte, harte Entwicklung ist. Besonders jetzt, da Geschäftslogik mit Angular und anderen SPA-Bibliotheken auf das Frontend verlagert wird. Und fangen wir gar nicht erst mit Isomorphic (http://isomorphic.net/) an.
Vielleicht erschreckt das einige traditionelle Entwickler, die eine dogmatische Ansicht von JavaScript als keiner ernsthaften Programmiersprache haben, zu unreiferen Kommentaren, aber diese Art von Leuten ignoriert man am besten. Sie werden ihr eigenes Verderben sein, da sich die Dinge in Richtung einer elastischen Cloud-basierten Anwendungsarchitektur bewegen, die stark auf JS setzt.
Ich bin ein Front-End-Entwickler und teile mir einen Würfel mit einem sehr intelligenten Back-End-Entwickler, der größten Respekt vor Menschen hat, die HTML/CSS/JavaScript und Browserkompatibilität verstehen.
Lasst den Flammenkrieg enden und lasst uns alle wieder unsere ebenso komplexen und wichtigen Jobs machen. ;)
PS – All this back and forth immediately brings this video to mind… https://www.youtube.com/watch?v=2Tvy_Pbe5NA
Als Front-End-Entwickler stimme ich dem von ganzem Herzen zu; ich denke jedoch immer noch, dass eine große Anzahl von Front-End-Entwicklern, denen ich im Laufe der Jahre begegnet bin, nicht ganz für all dies qualifiziert wäre.
Ich bin überrascht, dass niemand die Nicht-Abwärtskompatibilität und die eskalierende Komplexität von HTML5 angesprochen hat.
Das Ändern grundlegender Syntax wie das Nicht-Erfordernis von Tag-Schlüssen und das Zulassen von gemischt-großgeschriebenen Tags erleichtert meine Arbeit nicht. Wer denkt, dass das gut ist?
Ich konnte früher die Zugänglichkeit einer Tabelle verbessern, indem ich ein "summary"-Attribut zur Tabelle hinzufügte. Jetzt muss ich stattdessen die Tabelle mit und eine
<
figcaption> Anweisung hinzufügen – oder... Moment mal... Muss ich jetzt schließen oder nicht?
Und natürlich habe ich jetzt Hunderte von Seiten, die nicht mehr validieren.
(S)CSS/Compass/LESS und JavaScript sind schwer genug, ohne dass man ein sich bewegendes Ziel für die grundlegendste Markup im Auge behalten muss.
Toller Artikel!
An Ihre Mailingliste abonniert.
"Eines Tages werde ich ein echter Junge sein" – Pinocchio
Aber im Ernst, es ist die einzige Form der populären Technologie, die in der Vergangenheit lebt.
CGI-Produktion ist Spitzenklasse,
Videospielentwicklung ist Spitzenklasse,
Audioverarbeitung ist Spitzenklasse,
Chirurgie = Spitzenklasse,
Frontend-Webgrafik & visuelle Gestaltung = 20 Jahre im Rückstand.
Natürlich ist es echte Entwicklung, aber wie kann es als etwas Ernstes angesehen werden, wenn wir Entwickler es durch Sonderinteressen sabotieren lassen?
Frontend-Webgrafik & visuelle Gestaltung = 20 Jahre im Rückstand.
Nun, nicht alles? Wir können bereits erstaunliche Dinge tun, das einzige Problem ist die Browserunterstützung.
Wenn Sie den neuesten Chrome (64bit) haben, probieren Sie meine Seite aus (www.itsleon.com, schwere Website, daher kann das Laden und Rendern einige Zeit dauern, ja rendern, als eine 3D-Karte, in der Sie gehen können).
Ich war auf beiden Seiten des Interviews und ich denke nicht, dass Front-End-Leute schwer einzustellen sind. Ich stimme vielleicht zu, dass viele Entwickler nicht unbedingt gute Interviewer oder gute Interviewte sind, da dies Fähigkeiten sind, aber für mich war es nie einfacher, die Stärke und Erfahrung/Exposition eines Entwicklers zu bewerten als heute. Wenn das Screening richtig gemacht wird, sollte ein persönliches Interview auf kulturelle Passung hinauslaufen und vielleicht einige schnelle Übungen, vielleicht etwas basierend auf ihrem GitHub-Portfolio oder etwas, das sie als kompetent beansprucht haben, sowie eine Übung, bei der Sie ihnen etwas Neues vorstellen und sehen, ob sie wissen, wo sie es anwenden können.
Aber bitte fliegen Sie niemanden ein und geben Sie ihm dann einen schriftlichen Test, das ist ein Warnsignal, niemals einen Kandidaten coden zu lassen, ist auch ein Warnsignal, wenn er mehr ein Entwickler als ein PSD->HTML/CSS ist.
Von Anfang an gab es ein Portfolio, auch solche mit Schulprojekten anstelle von beauftragten, und jetzt gibt es GitHub, egal ob ein Entwickler sein eigenes Repository gestartet, es geforkt und eine Funktion hinzugefügt hat oder einen Fehler in Open Source behoben hat usw.
Die meisten Leute haben Smartphones... also, wenn Sie ein mobiler Webentwickler sind, lassen Sie sie sich Ihre Sachen während des Interviews ansehen und lassen Sie die Links das Interview leiten, was Sie benutzt haben, warum Sie stolz darauf sind... oder Lektionen gelernt, was Sie beim nächsten Mal anders machen würden.
Es gibt großartige Tools, um sie beim Coden aufzunehmen oder ihnen live beim Coden zuzusehen (codepen.io, coderpad.io, collabedit.com, Google Docs ist nicht ideal, funktioniert aber auch) oder den Kandidaten das verwenden zu lassen, womit er am vertrautesten ist, und die Übung zeitlich zu begrenzen.
Es gibt mehr Meetups als je zuvor, von Codepen-Meetups bis zu [Framework hier einfügen].
Es gibt Stack Overflow. Es gibt lokale Hackathons (sowie an Universitäten) und staatliche Code-Challenges und eine wachsende Anzahl von großartigen Front-End-fokussierten Konferenzen.
Das andere, worauf man sich als Interviewer konzentrieren sollte, ist, die "Closer", die Problembesitzer zu finden... Manchmal gibt es wirklich brillante Leute, die entweder apathisch sind oder zu viel nachdenken, oder aus irgendeinem Grund nicht das beitragen, wozu sie fähig sind, sei es beim Mentoring oder beim Abschließen von Stories/Tickets...
Wenn Sie mit Datenstrukturen, Programmablaufsteuerung, Geschäftslogik und Anwendungslogik arbeiten, dann sind Sie ein "echter" Entwickler. Wenn nicht, dann sind Sie eine Konfigurationsperson.
Sobald JavaScript oder eines der JS-Frameworks (z. B. Backbone, Angular) ins Spiel kommen, sind Sie genauso ein Entwickler wie jeder andere. Ich würde sogar sagen mehr, denn ich habe festgestellt, dass die Arbeit als UI-Entwickler mit all den Window-Widgets und der ereignisgesteuerten Natur schwieriger ist als die serverseitige Programmierung.
Ich finde das Schwierigste bei der Entwicklung, wie man den Code strukturiert, um das Problem so zu lösen, dass er sauber, testbar, wartbar und leistungsfähig ist. Was sind Ihre Klassen? Was sind ihre Attribute und Methoden? Wie interagieren diese Klassen mit den anderen Klassen? Darüber hinaus müssen Sie sich mit App-Sicherheit, asynchronen Web-Service-Aufrufen, Ereignisbehandlung, Ausnahmemanagement und Protokollierung befassen.
Mit reinem HTML & CSS (Konfiguration) haben Sie das alles nicht.
Sicher, Sie müssen das Seitenlayout bestimmen und mit CSS, Cross-Browser-Kompatibilität und verschiedenen Bildschirmgrößen umgehen, was schwierig ist, aber es ist nicht dasselbe wie das Erstellen der gesamten Software, die die App zum Laufen bringt.
Wow, die Gefühle. Je mehr man etwas lernt, desto mehr fühlt man sich wie ein Idiot.
Wenn man die Grundlagen kennt, ist jede Entwicklung gleich.
Datenstrukturen, Namenskonventionen, Architektur, Algorithmen usw.
Ich bin schon seit einiger Zeit ein Alleskönner (Kundenbeziehungen, Marketing, Design, Entwicklung (Front- und Back-End)), aber jetzt spezialisiere ich mich auf Front End. JavaScript ist nicht mehr, was es einmal war, es wird viel besser. Es ist auch serverseitig geworden. Wenn jemand sagt, Front-End-Entwicklung sei einfach, dann lasst sie es tun und lernen. Sie werden lernen, dass das Ökosystem schneller ist als Backend-Sprachen (naja, PHP holt endlich zu anderen Sprachen mit DI, Traits usw. auf). CMIIW.
also ja, Front-End-Entwickler sind Entwickler.
Das ist ein toller Aufruf an alle Entwickler da draußen. Ich werde dies auf jeden Fall mit meinen Mitentwicklern in unserer eigenen Webentwicklungsfirma (https://www.createaspectacle.com/) teilen, also vielen Dank!
Meiner Erfahrung nach sind Backend-Entwickler wie Beifahrer und folgen meist dem Weg des geringsten Widerstands. Für sie sind einfache Formulare und Elemente in Ordnung, aber für uns Front-Endler MÜSSEN sie gestylt werden. Warum Backend-Entwickler glauben, den Zug fahren zu müssen, ist jedem ein Rätsel, aber es könnte daran liegen, dass sie eigentlich Künstler sein wollen und sich über die Vorstellung ärgern, dass jemand anderes das Aussehen ihres Codes verändert. Das ist es, was wir wirklich tun: das Aussehen des Voodoo, das sie PHP oder was auch immer sie schreiben nennen, verfeinern. Aber dass sie uns Front-Endlern die Bezeichnung Programmierer absprechen, ist mir egal, denn ich weiß, dass es immer so sein wird.
Kein standardmäßiger Produktions-Pipeline. Keine Referenz-Browser-Implementierung. Keine richtigen Antworten, aber unzählige falsche.
Ja, ja und ja
Endlich ein Ort zum Dampf ablassen!
Traurigerweise bin ich einer dieser Leute, die es lieben zu sehen, was andere durch das Schreiben von Code erreichen können. Irgendwie sieht es aufregend aus! Etwas Code tippen, Fenster durchgehen, seinen Code ausführen und etwas Erstaunliches passiert, man erschafft, löst, entwickelt sich weiter – brillant!
Einer dieser Leute zu sein, ist seit vielen Jahren mein Traum und mein Ziel.
Obwohl ich schlau genug bin, einen Bachelor in Ingenieurwesen und einen Master in IT zu haben. Ich bin noch nicht an dem Punkt angekommen, an dem ich mich wohl fühle, qualitativ hochwertigen Code zu produzieren und mittelgroße bis große Projekte anzugehen – traurig : (
Was ist also falsch? Wie Paul Ford seinen Kampf, ein Entwickler zu werden, in seinem aufschlussreichen Artikel "What is Code" beschreibt:
Nun, ich habe die Magie nicht enthüllt. Es sind 5 Jahre vergangen und es fühlt sich immer noch unnatürlich an... Aber warum? Die Leidenschaft ist da, die Anstrengung ist da, auch die Zeit und die Erfahrung - ich arbeite seit zwei Jahren als Front-End-Entwickler und habe Dutzende von Websites in vielen Frameworks und Formen erstellt.
Ich kämpfe mit PHP, JavaScript, C# und kann immer noch keine vier aufeinanderfolgenden Zeilen schreiben, ohne Stack Overflow, docs.php oder das WordPress Codex zu konsultieren.
Verdammt, was ist los?
Bevor ich also noch weiter abschweife, möchte ich sagen: In einigen Fällen (wie meinem) ist Front-End NICHT Entwicklung. Aber für die Leute, die das Programmieren gemeistert haben, ist es echte Entwicklung und genauso respektabel wie Back-End-, Softwareentwicklung oder jede andere.
An euch alle meine Bewunderung. Denn in dieser Hinsicht SIE Entwickler aller Art sind mir und den meisten Menschen überlegen.
Ich habe eine Idee, wie wäre es, wenn Unternehmen in ihre Mitarbeiter investieren und jemanden einstellen, der die Grundlagen beherrscht und lernfähig ist. Sie trainieren sie zu dem, was das Unternehmen braucht. Jedes Unternehmen hat spezifische Bedürfnisse und arbeitet mit verschiedenen Software- und Hardwareprodukten; es gibt viele Programmiersprachen und Geräte. Eine Person kann nicht alles wissen. Als Auftragnehmer musste ich spezifische Software lernen, die ein Unternehmen verwendet. Ich bin sehr lernfähig; ich möchte eine Festanstellung; ich wünsche mir, dass ein Unternehmen das Potenzial in mir sieht und mich genau zu dem ausbildet, was sie brauchen. Es mangelt nicht an guten Front-End-Entwicklern, es mangelt an Interesse seitens des Unternehmens, in die Schulung seiner Mitarbeiter zu investieren, um außergewöhnliche Entwickler zu werden.