Nehmen wir an, es gibt eine Kluft in der Frontend-Entwicklung. Ich spüre sie, aber es ist nicht nur ein Gefühl. Basierend auf sehr vielen schriftlichen Entwickler-Statements, Interviews, die Dave Rupert und ich bei ShopTalk geführt haben, und persönlichen Diskussionen ist es, wie man so schön sagt... ein Ding.
Die Kluft besteht zwischen Menschen, die sich als (oder den Jobtitel) Frontend-Entwickler bezeichnen, aber unterschiedliche Fähigkeiten besitzen.
Auf der einen Seite eine Armee von Entwicklern, deren Interessen, Verantwortlichkeiten und Fähigkeiten sich stark um JavaScript drehen.
Auf der anderen Seite eine Armee von Entwicklern, deren Interessen, Verantwortlichkeiten und Fähigkeiten sich auf andere Bereiche des Frontends konzentrieren, wie HTML, CSS, Design, Interaktion, Muster, Barrierefreiheit usw.
Hören wir von Leuten, die diese Kluft spüren.
Als Antwort auf unseren Beitrag „Was macht einen guten Frontend-Entwickler aus?“ schrieb Steven Davis :
Ich denke, wir müssen vom Begriff selbst wegkommen. Wir sollten uns in UX Engineers und JavaScript Engineers aufteilen. Das sind unterschiedliche Denkweisen. Die meisten Leute sind nicht in beidem, JavaScript und CSS, erstaunlich gut. Lasst UX Engineers eng mit UX/Design zusammenarbeiten, um großartige Designs, Interaktionen, Prototypen usw. zu erstellen, und lasst JavaScript Engineers alle Datenteile handhaben.
Ich habe es so satt, großartig in CSS zu sein, aber zu JavaScript gezwungen zu werden. Ich bin kein Programmierer!
Dieses Schisma passiert nicht unter unseren Füßen. Wir fordern es.
Ich hörte zum ersten Mal von einer Identitätskrise in Vernon Joyces Artikel „Hat die Frontend-Entwicklung eine Identitätskrise?“ Er verweist auf die großen JavaScript-Frameworks:
Frameworks wie Angular oder Bibliotheken wie React erfordern von Entwicklern ein viel tieferes Verständnis von Programmierkonzepten; Konzepte, die historisch vielleicht nur mit dem Backend verbunden waren. MVC, funktionale Programmierung, Higher-Order Functions, Hoisting… schwierige Konzepte, wenn Ihr Hintergrund in HTML, CSS und grundlegendem interaktiven JavaScript liegt.
Das trifft auf mich zu. Ich arbeite gerne mit modernen Frameworks, schicken Build-Tools und interessanten Datenlayer-Strategien und lese darüber. Im Moment arbeite ich gerne mit React als UI-Bibliothek, Apollo GraphQL für Daten, Cypress für Integrationstests und webpack als Build-Tool. Ich schiele ständig auf CSS-in-JS-Bibliotheken. Doch während ich diese Dinge durchaus als Teil der Frontend-Entwicklung betrachte, fühlen sie sich kosmisch weit entfernt an von Artikeln und Gesprächen über Barrierefreiheit, semantisches Markup, CSS-Möglichkeiten, UX-Aspekte und UI-Feinschliff, um nur einige zu nennen. Es fühlt sich an wie zwei verschiedene Welten.
Wenn Unternehmen Stellenangebote für „Front-End-Entwickler“ ausschreiben, wonach fragen sie wirklich? Angenommen, sie wissen es tatsächlich (lolz), reicht der Titel Front-End-Entwickler allein nicht aus. Es ist wahrscheinlich hilfreicher zu wissen, welche Seite der Kluft sie am meisten benötigen.
Meine Hoffnung ist, dass die Lösung darin besteht, aussagekräftigere Stellenausschreibungen zu verfassen. Wenn klar definierte und vereinbarte Berufsbezeichnungen für die Branche insgesamt zu viel verlangt sind (und ich fürchte, das ist der Fall), können wir immer noch unsere Worte nutzen. Corey Ginnivan hat es gut ausgedrückt:
Ich würde mir wünschen, dass Stellenbeschreibungen verletzlicher und offener sind – lassen Sie die Leute wissen, was Sie erreichen wollen, spezifizieren Sie, woran sie arbeiten werden, aber öffnen Sie es als Wachstumschance für beide Parteien.
„Front-End-Entwickler“ ist immer noch ein nützlicher Begriff. Wie Mina Markham uns kürzlich beschrieb, sind es die Leute, die hauptsächlich mit Browsern und Menschen, die diese Browser benutzen, arbeiten. Aber es ist eine generische Abkürzung, sagt Miriam Suzanne:
Frontend-Entwickler ist eine Kurzform für Situationen, in denen die Details keine Rolle spielen. So wie in einer Indie-Rock-Band – wer weiß, was das ist, aber ich sage es ständig. Kurzformen sind großartig, bis man eine Stellenbeschreibung postet. Wenn die Details wichtig sind, haben wir bereits eine detailliertere Sprache – wir müssen sie nur benutzen.
Um diese Kluft etwas genauer zu beleuchten, betrachten Sie diesen Artikel von Trey Huffine, „Ein Rückblick auf die Frontend-Entwicklung im Jahr 2018“. Er ist sehr gut gemacht! Er verweist auf große Momente dieses Jahres, zeigt interessante Daten und macht Vorhersagen darüber, was wir nächstes Jahr sehen könnten. Aber er basiert ausschließlich auf dem JavaScript-Ökosystem. HTML wird nur im Kontext von JavaScript-betriebenen statischen Site-Generatoren erwähnt und CSS nur im Kontext von CSS-in-JS. Es ist Frontend-Entwicklung, aber vielleicht eine Hälfte davon: die JavaScript-Hälfte. Wenn Sie diese Zusammenfassung lesen und sich nicht mit viel darin identifizieren können, dann wäre mein Rat:
Das ist OK. Sie können immer noch ein Frontend-Entwickler sein. 🙏
Sie könnten Layout-Möglichkeiten erkunden, ein CSS- oder Design-System architektonisch gestalten, tief in UX eintauchen, interessante Animationen erstellen, sich mit Barrierefreiheit beschäftigen oder eine beliebige Anzahl anderer fester Frontend-Entwicklungsjobs erledigen. Es gibt mehr als genug zu tun.
Erinnern Sie sich noch daran, wie Frank Chimero, der unglaublich gute Websites für sich und seine Kunden erstellt, letztes Jahr völlig verwirrt war, wohin die Frontend-Entwicklung gegangen ist? Zusammenfassend:
... die Toolchains anderer Leute sind von außen absolut undurchschaubar. Selbst der Einstieg ist heikel. Letzten Monat musste ich einen Paketmanager installieren, um einen Paketmanager zu installieren. Da klappte ich meinen Laptop zu und zog mich langsam zurück. Wir sind weit entfernt vom CSS Zen Garden, wo ich angefangen habe.
In der Tat ein langer Weg. Ich könnte argumentieren, dass Sie sich nicht darum kümmern müssen. Wenn Sie erfolgreich waren und weiterhin erfolgreich sind, indem Sie Websites auf jede Ihnen bekannte Weise für sich selbst und Ihre Kunden erstellen, Halleluja! Betrachten Sie all dieses neue Toolchain-Zeug einfach als eine optionale Sache, die andere Probleme löst als Ihre.
Und doch drängt diese Toolchain-Undurchsichtigkeit selbst die Menschen, die notwendigerweise darin eingebettet sind. Dave Rupert dokumentiert einen echten Fehler mit einer Lösung, die so tief vergraben ist, dass es ein Wunder ist, dass sie gefunden wurde. Dann beklagt er sich:
Wenn Toolchains wachsen und komplexer werden, ist es, wenn man nicht bestens damit vertraut ist, sehr unklar, welche Transformationen in unserem Code stattfinden. Die Verfolgung der Unterschiede zwischen Input und Output und der Prozesse, die der Code durchlaufen hat, kann überwältigend sein.
Wer braucht diese großen Toolchains? Im Allgemeinen sind es die großen Websites. Es ist etwas schwierig zu definieren, was groß bedeutet, aber ich wette, Sie haben ein gutes Gefühl dafür. Ironischerweise, während eine Menge Tools Komplexität hinzufügen, ist der Grund, warum sie verwendet werden, um Komplexität zu bekämpfen. Manchmal fühlt es sich an, als würde man Pumas in den Wald entlassen, um sein Schlangenproblem zu lösen. Jetzt hat man ein Puma-Problem.
Die sichtbarsten Diskussionen darüber werden von Leuten in Unternehmen dominiert, die an diesen großen und komplexen Websites arbeiten. Bastian Allgeier schrieb:
Großes Team braucht „x“, deshalb ist „x“ die beste Lösung für alle. Ich denke, das ist hochgradig toxisch für kleinere Teams mit unterschiedlichen Anforderungen und Definitionen von „wartbar“ oder „nachhaltig“. Ich komme mit vielen kleineren Agenturen und Freelancern aus der ganzen Welt in Kontakt und es ist interessant, wie ihre Arbeit oft völlig losgelöst vom VIP-Zirkus des Webs ist.
Was ist hier los? Was ist passiert? Woher kommt diese Kluft? Die Antwort ist für mich ziemlich klar:
So groß
- Es ist überall im Frontend von Websites präsent. Die großen JavaScript-Frontend-Frameworks erleben ein explosives Wachstum und dominieren die Stellenausschreibungen. Diese Frameworks werden von zahlreichen Teams eingesetzt, um zahlreiche Websites zu betreiben. Auch natives JavaScript entwickelt sich schnell weiter, was viele Menschen begeistert.
- Es betreibt auch Backends. Ihre Website könnte von einem Node.js-Server betrieben werden oder diesen beinhalten. Ihr Build-Prozess wird wahrscheinlich von JavaScript angetrieben.
- Drittanbieter-JavaScript versorgt so viele Frontend-Funktionen, vom Anzeigennetzwerk und der Analyse einer Website bis hin zu vollwertigen Funktionen wie Bewertungen, Kommentaren und verwandten Inhalten.
- Konzepte wie Node-gestützte Cloud-Funktionen, Speicher und Authentifizierung, kombiniert mit kostengünstigem und einfach zu skalierendem Hosting, haben JavaScript-fokussierte Frontend-Entwickler enorm gestärkt. Sie können ihre Fähigkeiten ausschließlich nutzen, um ganze funktionale Produkte auszuliefern.
Ein Frontend-Entwickler mit starken JavaScript-Kenntnissen ist heutzutage enorm mächtig. Ich nenne ihn den allmächtigen Frontend-Entwickler und habe einen ganzen Vortrag darüber gehalten:
Durch all die Möglichkeiten, die sich um die Idee von Serverless in Kombination mit vorgefertigten UI-Frameworks ranken, kann ein Frontend-Entwickler so ziemlich alles bauen, ohne viel, wenn überhaupt, Hilfe von anderen Disziplinen zu benötigen. Ich finde das spannend und verlockend, aber auch nachdenkenswert. Es ist durchaus möglich, dass man auf diesem Weg so framework-gesteuert wird, dass die breiteren Problemlösungsfähigkeiten darunter leiden. Diese Einschätzung hörte ich von Estelle Weyl, die sogar so weit geht zu sagen, dass sie Entwickler eher als „Framework-Implementierer“ betrachtet und den Titel „Ingenieur“ tool-agnostischen Problemlösern vorbehält.
Diese Frontend-Empowerment ist sehr real. Besonders in den letzten Jahren sind Frontend-Entwickler besonders mächtig geworden. So mächtig, dass Michael Scharnagl sagt, er habe gesehen, wie Unternehmen ihre Einstellungen in diese Richtung verlagert haben:
Was ich sehe, ist, dass sich viele Entwickler heutzutage ausschließlich auf JavaScript konzentrieren und ich sehe Unternehmen, wo Backend-Entwickler durch JavaScript-Entwickler ersetzt werden.
Was manche nicht verstehen, ist, dass ein JavaScript-Entwickler nicht per se ein Frontend-Entwickler ist. Ein JavaScript-Entwickler mag es vielleicht nicht, CSS zu schreiben oder sich um Semantik zu kümmern. Das ist dasselbe, wie ich es vorziehe, nicht direkt mit Datenbanken zu arbeiten oder einen Server zu konfigurieren. Das ist in Ordnung. Was nicht in Ordnung ist, ist, wenn man etwas nicht nutzen möchte und gleichzeitig anderen erzählt, was sie tun, sei einfach oder nutzlos. Noch schlimmer ist es, wenn man versucht, Experten auf ihrem Gebiet zu erzählen, dass sie alles falsch machen und dass sie es auf Ihre Weise tun sollten.
Und Jay Freestone versucht zu erklären, warum:
In den letzten Jahren hat sich die Rolle des Frontend-Entwicklers erheblich verändert. Da Anwendungen zunehmend JavaScript-lastig geworden sind, ist es für Frontend-Ingenieure notwendig geworden, architektonische Prinzipien zu verstehen und anzuwenden, die traditionell in den Bereich der Backend-Entwickler fielen, wie z.B. API-Design und Datenmodellierung.
Es ist sogar bei meiner eigenen, kleinen Arbeit passiert. Wir suchten einen Backend-Go-Entwickler, um unsere Webservices bei CodePen weiterzuentwickeln. Als wir nicht viel Glück hatten, die perfekte Person zu finden, entschieden wir uns für eine andere Richtung. Wir sahen, dass sich unser Stack zu etwas entwickelte, das JavaScript-fokussierte Frontend-Entwickler extrem willkommen heißt, so dass wir problemlos mehr von ihnen sofort einsetzen konnten. Also haben wir das getan.
Es mag hier auch eine zyklische Natur geben. Wir sehen, wie Coding Schools explosionsartig anwachsen und in weniger als einem Jahr recht talentierte Entwickler hervorbringen. Diese Absolventen von Coding Schools füllen Arbeitskräftelücken, aber noch wichtiger, wie Brad Westfall mir sagt, beginnen sie, Industrie-Diskussionen zu führen, anstatt passive Follower zu sein. Und täuschen Sie sich nicht: Diese Schulen produzieren Entwickler auf der JavaScript-Seite der Kluft. Jeder einzelne Webentwicklungscurriculum einer Coding School, das ich je gesehen habe, behandelt HTML/CSS/UI/UX/A11Y-Themen als frühe Grundlagen, die Studenten schnell durchlaufen, oder sie werden als Nebenaspekte eingestreut, während JavaScript den späteren Lehrplan dominiert. Können Sie kommen und unseren Studenten alle Layoutkonzepte in drei Stunden beibringen?
Wenn JavaScript die Gespräche über das Frontend dominiert, führt das dazu, dass sich manche Entwickler unzureichend fühlen. In einem Kommentar zu Robin Rendles „Frontend-Entwicklung ist kein Problem, das gelöst werden muss“ schreibt Nils :
Vielleicht muss der Begriff Frontend-Entwickler überdacht werden. Als ich anfing zu arbeiten, war Frontend hauptsächlich HTML, CSS und etwas JavaScript. Ein guter Frontend-Entwickler musste in der Lage sein, ein Photoshop-Layout in eine pixelgenaue Website zu übersetzen. Frontend ist heute viel, viel mehr. Wenn man Frontend-Entwicklung lernen möchte, fangen die Leute anscheinend an, Git, npm, Angular, React, Vue und all das zu lernen, und das alles wird Frontend-Entwicklung genannt.
Ich bin Designer und ich denke, ich bin ziemlich gut in HTML und CSS, aber das reicht nicht mehr aus, um ein Frontend-Entwickler zu sein.
Robin selbst gab sich den Jobtitel Erwachsener Junge, der sich zu sehr um Barrierefreiheit, CSS und Komponentendesign kümmert, aber sich kein bisschen um GraphQL, Rails oder Redux schert, obwohl ich mich wirklich schlecht fühle, dass ich mich nicht um dieses andere Zeug kümmere.
Es frustriert Menschen auch auf andere Weisen. Erinnern Sie sich an Lara Schencks Geschichte eines Vorstellungsgesprächs? Sie erfüllte 90 % der gelisteten Qualifikationen, nur um dann im Interview mit JavaScript-Algorithmen konfrontiert zu werden. Deswegen bekam sie den Job letztendlich nicht. Nicht jeder muss jeden Job bekommen, für den er sich bewirbt, aber das Problem hier ist, dass Front-End-Entwickler nicht das kommuniziert, was es als effektiver Jobtitel tun müsste.
Manchmal fühlt es sich an wie ein Paralleluniversum.
Zwei „Frontend-Webentwickler“ können direkt nebeneinander stehen und haben kaum oder gar keine gemeinsamen Fähigkeiten. Das ist für mich bei einer so spezifischen und allgegenwärtigen Berufsbezeichnung geradezu bizarr. Ich bin sicher, das ist bei einem Jobtitel wie Designer bereits der Fall, aber Frontend-Webentwickler ist bereits eine Nische innerhalb einer Nische.
Jina Anne ist eine Frontend-Entwicklerin und Designerin, die ich bewundere. Doch in einer Podiumsdiskussion, an der ich vor einigen Jahren mit ihr teilnahm, gibt sie zu, dass sie sich selbst nicht mit diesem Titel bezeichnet:
Als ich bei Apple anfing, war mein Jobtitel Frontend-Entwickler. Würde ich mich jetzt so nennen? Nein, weil es sich so stark verändert hat. Ich habe HTML/CSS gelernt, ich habe nie JavaScript gelernt, aber ich wusste genug, um damit umzugehen. Jetzt – wir reden über Jobtitel – wenn ich „Frontend-Entwickler“ höre, gehe ich davon aus, dass Sie viel mehr wissen als ich.
Es scheint, als hätte dieser Mangel an JavaScript-Fokus Jina damals das Gefühl gegeben, weniger qualifiziert zu sein als jemand mit dem offiziellen Titel eines Frontend-Entwicklers. Ich denke, die Leute hätten Glück, die Fähigkeiten zu besitzen, die Jina in ihrem linken kleinen Finger hat, aber das bin ich eben. Als ich kürzlich mit Jina sprach, sagte sie, sie vermeide den Titel immer noch speziell, weil er zu falschen Annahmen über ihre Fähigkeiten führt.
Mandy Michael brachte dies in ihrem Artikel „Gibt es einen Wert in Menschen, die kein JavaScript schreiben können?“ besser auf den Punkt als jeder andere:
Was ich nicht verstehe, ist, warum es in Ordnung ist, wenn man „nur JS schreiben“ kann, aber irgendwie nicht gut genug ist, wenn man „nur HTML und CSS schreibt“.
Wenn jede neue Website im Internet perfektes, semantisches, zugängliches HTML und außergewöhnlich ausgeführtes, zugängliches CSS hat, das auf jedem Gerät und Browser funktioniert, dann können Sie mir sagen, dass diese Sprachen für sich genommen nicht wertvoll sind. Bis dahin müssen wir aufhören, CSS und HTML abzuwerten.
Mandy nutzt ihren Beitrag zur Friedensstiftung. Sie sagt uns: Ja, es gibt eine Kluft, aber nein, keine Seite ist wertvoller als die andere.
Eine weitere Quelle der Frustration ist, wenn die große Kluft zu schlechter Handwerkskunst führt. Dies sehe ich als Ursache für die meisten Sticheleien und Hänseleien, die über die Lager hinweg auftreten. Brad Frost verweist auf den Begriff „Full-Stack-Entwickler“ als etwas irreführend:
Meiner Erfahrung nach übersetzt sich „Full-Stack-Entwickler“ immer in „Programmierer, die Frontend-Code schreiben können, weil sie müssen und es ‚einfach‘ ist.“ Es ist nie umgekehrt. Der Begriff „Full-Stack-Entwickler“ impliziert, dass ein Entwickler gleichermaßen in Frontend-Code und Backend-Code versiert ist, aber ich habe in meiner persönlichen Erfahrung noch niemanden erlebt, der dieser Beschreibung wirklich entspricht.
Heydon Pickering sagt etwas Ähnliches. Wenn Sie auf diesem mythisch hohen Niveau eingestellt werden, ist etwas wie HTML unwahrscheinlich eine Stärke.
... eines der auffälligsten Probleme bei der Ernennung von Full-Stack-Entwicklern zu Gatekeepern aller Code-Dinge ist die erbärmliche Qualität der HTML-Ausgabe. Die meisten kommen aus der Informatik und die Dokumentenstruktur wird einfach nicht zusammen mit der Kontrollstruktur gelehrt. Es ist nicht ihre Kompetenz, aber wir machen es trotzdem zu ihrer Aufgabe.
So wie es vielleicht nicht meine Aufgabe ist, unsere Deployment-Pipeline zu konfigurieren und unsere Datenbankskalierung zu handhaben (ich würde eine schreckliche Arbeit leisten, wenn diese Aufgabe an mich fiele), ist es vielleicht am besten, die Aufgabe von HTML und CSS denen zu überlassen, die es gut können. Vielleicht ist es einfacher zu sagen: Auch wenn es eine Kluft gibt, entbindet uns das nicht davon, gute Arbeit zu leisten.
So wie Architektur und Entwickler-Ergonomie unser aller Aufgabe sind, sollten wir Performance, Barrierefreiheit und Benutzererfahrung in unserem Arbeitsbereich betrachten. Wenn wir einen bestimmten Teil davon nicht gut machen können, stellen Sie sicher, dass jemand anderes diesen Teil kann. Niemandem ist es erlaubt, schlechte Arbeit zu leisten.
Es sei erwähnt, dass es viele Entwickler gibt, deren Fähigkeiten die Kluft überbrücken und dies mit Anmut tun. Ich denke an unsere eigene Sarah Drasner, die als unglaubliche Animatorin, SVG-Expertin und Kernteammitglied von Vue bekannt ist und auch bei Microsoft an Azure arbeitet. Full-Stack, in der Tat.
Ich erweitere viele dieser Themen in einem weiteren kürzlich gehaltenen Konferenzvortrag bei WordCamp US.
Gibt es eine Lösung für diese Probleme von mangelhafter Handwerkskunst und Entwertung von Fähigkeiten? Sind die Probleme systemisch und tief verwurzelt, oder sind sie oberflächlich und ohne schwerwiegende Konsequenzen? Ist die Kluft real oder eine vorübergehende Spaltung? Beruhigt sich die Reibung oder heizt sie sich auf? Wird sich die Fähigkeiten des Frontend-Entwicklers mit den Jahren erweitern oder verengen? Lasst uns weiter darüber reden!
Auch wenn JavaScript immer heißer wird, erzählt mir Rachel Andrew, dass es früher schwierig war, einen CSS-Workshop zu füllen, aber heutzutage fragen Konferenzorganisatoren danach, da sie sehr gefragt sind. Eines ist sicher, wie der alte Heraklit zu sagen pflegte: Die einzige Konstante ist die Veränderung.
✌️
Ich habe viele Gefühle zu diesem Thema, aber das unmittelbarste Gefühl ist ein künstlerisch gestalteter Blogbeitrag
intensive künstlerisch gestaltete Blog-Gefühle intensivieren sich
100% einverstanden
Auch meine Gefühle.
Sehr interessanter Artikel. Als Neuling in dieser Branche hat er mir tatsächlich ein besseres Gefühl gegeben, noch nicht alles zu wissen. In den letzten sechs Monaten habe ich mich mit allen möglichen Dingen beschäftigt, um meinen Weg nach vorne zu finden und herauszufinden, womit ich mich langfristig wirklich beschäftigen sollte, und alles scheint wie eine Büchse der Pandora. Und jede Büchse der Pandora ist gefüllt mit Büchsen der Pandora :)
Vor ein paar Monaten schien es ein vernünftiges Ziel zu sein, ein „Full-Stack“-Entwickler zu werden, aber jetzt sehe ich, dass das nicht wirklich eine Sache ist, zumindest nicht für mich und zumindest nicht für die nächsten paar Jahre. Ich werde versuchen, mich darauf zu konzentrieren, der JavaScript-orientierte Frontend-Entwickler zu sein, der sich auch wirklich Mühe mit Design und CSS gibt, aber sich an diejenigen wendet, die wissen, was sie tun.
Übrigens, diese Seite sieht fantastisch aus. Dieser Artikel wäre so oder so eine nette Lektüre, aber mit den Zitaten und Abschnitten usw., die alle so geschmeidig aussehen, macht es ihn zu einer noch angenehmeren Lektüre.
Full Stack Developer gibt es aber doch. Die Branche hat sich nur so schnell entwickelt, dass die Definitionen dieser Positionen nicht mithalten konnten. Man kann Full-Stack sein in dem Sinne, dass man die Programmierlogik über den gesamten Anwendungs-Stack hinweg versteht. Man benötigt nicht unbedingt Spezialwissen in einem bestimmten Bereich des Stacks, aber man weiß genug, um alles zu verbinden und funktionsfähig zu machen. Man hat in der Regel auch eine Neigung, man könnte mehr Backend- oder programmierungsorientiert sein oder ist stärker in traditionellen Frontend-Skills wie HTML und CSS. ABER man hat in der Regel immer ein ordentliches Verständnis des gesamten Stacks und dessen, was das impliziert, und ist in der Lage, eine VOLLSTÄNDIGE Anwendung zu verbinden und zu erstellen, aber was fehlt, ist die singuläre Spezialisierung und Verfeinerung in einem der Bereiche des Stacks. Mit all den neuen Bibliotheken und Frameworks, die es gibt, ist Full-Stack-Entwicklung nicht unsinnig. Dinge wie Vue und React machen es so, dass man im Grunde im Backend programmiert.
Heiliger Strohsack, das brauchte ich. Bitte schickt das als Ketten-E-Mail an jeden technischen/digitalen Recruiter ÜBERHAUPT.
Das ist eine großartige Lektüre.
Ich kenne mich mit „fortgeschrittenem“ JS, Node, React und all dem Kram aus, aber ich betrachte mich immer noch hauptsächlich als Teil der anderen „Armee“.
Vielleicht hat es mehr mit meiner Ausbildung zu tun, da ich seit über 10 Jahren arbeite und damals alles um gute Semantik und herausragende CSS-Fähigkeiten ging. JavaScript war in den ganz alten Zeiten kaum mehr als etwas, um den Benutzer mit Popups und auffälligen Spielereien zu nerven.
Ich gebe zu, es hat lange gedauert, bis ich in den JS-Zug einstieg, ich hasste die Sprache zuerst wirklich. Dann brachten uns Ajax-Techniken dazu, sie zu lieben, und dann machten jQuery (und Mootools!) es viel einfacher, mit JS zu arbeiten und gute Dinge damit zu bauen. Und schließlich kamen die modularen SPA-Frameworks / Bibliotheken heraus und die JS-Seite der Dinge explodierte in Popularität.
Gleichzeitig begannen viele Entwickler aus Backend-Sprachen, sich dem Frontend zuzuwenden, ebenso wie Teile der Verantwortlichkeiten. Auch viele Entwickler kamen überhaupt nicht aus einem „Webentwickler“-Hintergrund ins Frontend, sondern lösten sich von primär „Desktop“-Sprachen. Und da ging die Barrierefreiheit den Bach runter, und wir sahen überall „CSS ist Mist“-Tiraden. Ich frage mich, wie viel des Trends für TypeScript damit zu tun hat, JS in etwas Java-ähnlicheres zu verwandeln…)
Jedenfalls bin ich glücklich genug, beide Seiten des Arguments zu verstehen, aber ich glaube wirklich, dass die Branche auf einer Seite etwas verpasst. Die Stellenangebote (und Gehälter) für primär JS-basierte Entwickler sind überzogen, und das geht auf Kosten der Markup-Qualität, während die Aussage „Ich bin primär ein CSS-Spezialist“ wahrscheinlich überhaupt keinen Job einbringt (und etwas Mobbing dazu)
Und das führt dazu, dass neue Leute sich stark auf die JS-Seite der Dinge konzentrieren, und das gilt auch für Kurse und Bootcamps. FreeCodeCamp bietet ein extrem tolles JS-Curriculum an, während CSS in einem einzigen Kapitel, aus einer „angewandten visuellen Designperspektive“ (die in den meisten Lektionen sogar Semantik und Visuelles verwechselt), kaum berührt wird.
Das lässt es wie eine „Old School“ vs. „New School“-Diskussion erscheinen, obwohl es wirklich als zwei verschiedene und sehr wichtige Spezialisierungen betrachtet werden sollte. Ich nenne es gerne „JS Engineer“ für den JS-Spezialisten und „UI Engineer“ für den Markup/A11Y/CSS-Spezialisten… aber ich habe Stellenangebote mit dem Titel „UI Engineer“ gesehen, die zu 100 % das JS-lastige Profil sind. Wir müssen uns auf die Titel einigen.
Leider ist der Trend ziemlich klar: JS wird unweigerlich alles im Frontend übernehmen. Wirklich meine einzige Hoffnung, dass die Branche die Bedeutung der anderen Rolle anerkennt, liegt in den Barrierefreiheitsproblemen. Vielleicht wird 2019 das A11Y-Jahr, angeheizt durch Bußgelder und Forderungen, beginnend mit dem Beyoncé-Problem letzte Woche, was die Branche dazu bringen wird, verzweifelt jemanden zu suchen, der ihren Mist repariert. Genau der gegenteilige Grund für A11Y, den ich mir wünschen würde, aber wie auch immer….
.
Das neue Design gefällt mir übrigens jeden Tag ein bisschen besser.
Nein, das wird niemals passieren.
Weil 1KB JS > 1KB Bilder > 1KB CSS > 1KB HTML
daher werden hochoptimierte HTML/CSS-only-Seiten immer schneller sein als JS-basierte Seiten.
Ich stimme Markus hier zu. Meine Hoffnung ist, dass die Branche erkennt, dass es genauso absurd ist, wenn eine Webseite JavaScript enthält, um ihren Inhalt zu rendern, wie es wäre, wenn ein Word-Makro den Rest eines Word-Dokuments produzieren würde. Es ist ein bisschen heuchlerisch, auf das Word-Beispiel mit „Ugh, warum sollte jemand DAS tun?“ zu reagieren, aber auf das Web-Beispiel mit „Meh, es ist 2019, passt euch der Zeit an.“
Ich schreibe gerne JavaScript, und es ist zum Beispiel entscheidend für Dinge wie Formularfeldvalidierung, um die Serverlast zu reduzieren, aber ich habe viele clientseitige Plattformen aufkommen und wieder untergehen sehen, z.B. Flash, jQuery, Bootstrap, Angular… und ich bin nicht überzeugt, dass React oder Vue anders sind. Wenn etwas keine Zukunft hat, dann hat es keinen Sinn, dass es überhaupt existiert. Klingt hart, ich weiß, aber das ist das Web. Ich meine, ich würde nichts, was ich erstelle, mit einem Produkt ohne Zukunft verbinden, das ist einfach keine gute Investition.
Eine JavaScript-abhängige Lösung eignet sich zum Schreiben eines Spiels oder einer Desktop-ähnlichen Anwendung, aber das würde bedeuten, dass Sie etwas haben, das IM Web ist, aber nicht wirklich EIN TEIL des Webs. Benutzer benötigen keine Pseudo-Web-Rendering-Engine, um Inhalte zu genießen. Es gibt so viel Verkaufs-Hype und Marketing-Unsinn, der diese neuen Frameworks vorantreibt, dass es mich sehr an Des Kaisers neue Kleider erinnert.
Es ist seltsam, dass dies bei der Frontend-Entwicklung ein so großes Problem zu sein scheint, aber ich sehe es bei anderen Disziplinen nicht so sehr. Man würde keinen Anwalt für Personenschäden bei einem Immobilienstreit anrufen. Selbst in den Ingenieurwissenschaften würde man keinen Bauingenieur beauftragen, einen Satelliten zu entwerfen. Liegt es an der mangelnden Spezifität des Wortes „Frontend“? Liegt es nur an der Neuheit der Branche oder am mangelnden Verständnis von außerhalb der Branche?
Danke, Chris. „Wenn ich mich an die Namen dieser Partikel erinnern könnte, wäre ich Botaniker geworden“ – – Enrico Fermi in einem Brief an Lederman.
Einfach. Bringt einfach „Web Designer“ zurück. Dann können wir die Dichotomie als „Web Designer“ und „Web Developer“ beschreiben. Vielleicht auch nicht.
Ich würde "Front-End-Designer" vorschlagen, um ihn von der Rolle des Grafikdesigners zu unterscheiden.
„aber irgendwie bist du nicht gut genug, wenn du ‚nur HTML und CSS schreibst‘.“
Dafür gebe ich Bootstrap die Schuld. Bootstrap ist „gut genug“ für Leute, die kein HTML und CSS schreiben müssen oder wollen. (ca. 80% laut Pareto)
Ich liebe diesen Artikel! Stimme dem CSS/HTML/UX-Aspekt des Artikels zu 100% zu. Das Einzige, was ich ändern würde, ist, jemanden einen JavaScript-Entwickler zu nennen.
Lassen Sie mich meine Gedanken erklären… Ja, natürlich ist es super wichtig, zwischen einem UX-Entwickler und dem JS-Ingenieur zu unterscheiden. Ich würde jedoch dazu ermutigen, die Leute, die sich für Code/Frameworks/etc. begeistern, nicht als JavaScript-Ingenieure zu bezeichnen. Ja, wir müssen Erfahrung mit JavaScript haben, aber FE ist viel mehr als nur JS. Es geht darum, Muster, OO, funktionale Programmierung, Architektur, Modul-Bundler usw. zu kennen. Als Beispiel stört Typescript den Markt (unabhängig davon, wie Sie darüber denken). Am wichtigsten ist, dass Wasm (https://www.youtube.com/watch?v=DKHuEkmsx3M) große Fortschritte macht, bis zu dem Punkt, dass wir nicht unbedingt JavaScript kennen müssen, und Browser Bytecode lesen können.
Ich denke, was ich damit sagen will, ist, dass ein Ingenieur viel mehr ist als nur eine bestimmte Sprache zu kennen. So wie man einen Backend-Ingenieur niemals einen Java-/C#-/C++-/etc.-Ingenieur nennt, sollte es einen besseren Begriff für Ingenieure geben, die das „Backend“ des Frontends mögen. Ich persönlich mag: Front-End-Ingenieure, UX-Ingenieure und BE-Ingenieure.
Vielen Dank! Toller Artikel!
Ich bin der Typ auf der rechten Seite der Stellenausschreibung. Runde Brille, aber weniger Haare.
Die Arbeitsteilung bei großen Projekten hat die Notwendigkeit separater Rollen geschaffen. Aber die Trennlinien sind an den falschen Stellen.
In der Marketingwelt sind wir alle damit beschäftigt, Inhalte zu entwickeln, zu veröffentlichen und zu verwalten – und das nicht nur für Websites, sondern für alle Ziele.
Die klareren und besser handhabbaren Trennungen finden sich dort, wo wir traditionelle Trennungen zwischen Struktur (HTML), Stilen (CSS) und Logik (JS) haben. Die von Ihnen verwendete Toolchain mag das erleichtern oder auch nicht.
Langsamer Applaus. Danke!
Bemerkenswerte Twitter-Konversation
https://twitter.com/cssgrogneugneu/status/1087442576842678273
https://twitter.com/ryanflorence/status/1087473420412112902
Der Artikel trifft den Nagel auf den Kopf. Es gibt einfach so viel zu lernen, um mich jetzt Frontend-Entwickler nennen zu können. Ich bin eher ein UI/UX-Engineer.
Das war großartig, als jemand, der HTML/CSS/JS und Photoshop (wie im Artikel erwähnt) gelernt und sich darauf konzentriert hat, mit dem Titel „Front End Developer“ – ich fand mich in einer völlig neuen Welt wieder, als ich nach anderen Entwicklungsmöglichkeiten suchte. Ein Begriff, den ich häufiger gesehen habe, der gut mit A11Y, HTML-Semantik und insgesamt guter UX harmoniert, ist der Titel „UI Developer“. Er passt viel besser zu dem, was der Begriff „Front End Developer“ früher bedeutete.
Ich bin ein wenig verärgert über die Zitate, die andeuten, dass Full-Stack-Entwickler nicht sowohl guten Front- als auch Backend-Code sowie Design beherrschen können. Das ist eine sehr elitäre Denkweise, paradoxerweise…
Oft kümmert man sich entweder nicht um Design oder (in meinem Fall) hat nicht genug Zeit, es zu perfektionieren. Design braucht Zeit, Tests und Input von mehreren Personen aus verschiedenen Teilen des Ökosystems. APIs auch.
Wir haben diese beiden Arten von Leuten in der Firma, für die ich arbeite. Ich bin ein „Webdesigner“, der… Achtung… Dinge für das Web entwirft. Ich benutze HTML/CSS/etwas JS, um Dinge zu entwerfen. Wir haben auch einen Frontend-Entwickler, der sich um die „Dev“-Seite des Frontends kümmert. Wir arbeiten beide im Engineering-Team. Es funktioniert sehr gut, seit zwei Jahren schon.
TL;DR wir müssen den „Webdesigner“ zurückbringen.
Ich persönlich bin froh, dass dies entstanden ist. Ich bin ursprünglich ein „Backend“-Entwickler, der ins Frontend geworfen wurde, weil die Designer dort die komplexere Logik einer modernen Anwendung nicht bewältigen konnten. Die Trennung erlaubt es mir, das zu sein, was ich bin: ein Ingenieur. Ich bin nicht auf die Kunstschule gegangen, ich kenne Farbtheorie nur als Mathematik, ich kümmere mich nicht um Ästhetik und ziehe ein Terminal vor. Und Frontend-Designer brauchen mich, das ist offensichtlich, da ich der Frontend-Entwicklung nicht zu entkommen scheine. Dieser Bedarf ist ein Hinweis darauf, dass wir tatsächlich zwei verschiedene Disziplinen im Frontend definieren müssen.
Ingenieure und Designer. Wie wir sie früher nannten.
Ich glaube jedoch nicht, dass das ganz richtig ist. Ich würde sagen, dass ich auf der HTML/CSS-Seite der Dinge begabter/leidenschaftlicher bin, aber das macht mich nicht zu einem Designer. Ich habe keinen echten Designhintergrund oder -ausbildung. Und ich arbeite mit einem Designer zusammen, der überhaupt nicht programmieren kann.
Mein Jobtitel ist Front End Engineer, aber ich stelle mich immer als Front End Developer vor, denn obwohl ich mit React ziemlich solide bin und viel Zeit mit JS verbringe, denke ich nicht, dass ich ein Ingenieur im Sinne eines größeren architektonischen Verständnisses bin.
Ich denke, es ist einfach ein Spektrum, und bis zu einem gewissen Grad werden die meisten von uns irgendwo in der Mitte leben.
Meine beste Vermutung zur Asymmetrie ist, dass eine Seite besser in der Lage ist, Aufzählungspunkte zu erfüllen. Ein JavaScript-Entwickler kann „es tun lassen“, ein HTML/CSS-Experte kann es gut tun lassen. Aber wenn ein Geschäftsmann die Projektanforderungen formuliert, beziehen sich die Punkte in dieser Liste direkter auf das, was der JavaScript-Entwickler tut. Die Details, all die Verzierungen und Dinge, die es zugänglicher und kohärenter machen, sind „weiche“ Funktionen, die schwerer zu quantifizieren sind und daher dazu neigen, als Hilfsfunktionen behandelt zu werden. Einige nicht-technische Manager merken vielleicht nicht einmal, dass sie etwas sind, das getan werden muss.
Dies soll die UX-Seite nicht schmälern, um es klarzustellen. Ich bin persönlich detailversessen, und CSS ist eine meiner Lieblingssprachen. Ich spreche nur von der Wahrnehmung, die Außenstehende (diejenigen, die im Allgemeinen die Entscheidungen treffen) haben könnten.
Ja. Auf den Punkt gebracht. Das nenne ich „das Backend ist ins Frontend gewandert“.
Die aktuellen Jobtitel und das Wissen der Recruiter, wer was macht, wird auch ziemlich schlecht. Es ist ein Dschungel da draußen.
Hey, apropos Frontend, warum hat Ihr Kommentar-E-Mail-Textfeld keinen type=email? Bäm.
Die Kluft ist auch monetär – viel Glück, wenn Sie eine 100.000-Dollar-Position als Experte für HTML und CSS finden.
Diese grundlegenden Sprachen werden als Einstiegswissen behandelt, aber wie andere gesagt haben, hat die Qualität des Codes darunter gelitten. Ich konnte erkennen, dass CSS zu einem „Mittel zum Zweck“ wurde, in dem Moment, als ich erfuhr, dass es eine Sache war, Stile direkt in React-Komponenten zu schreiben.
Jetzt muss ich React lernen, damit meine ganze Karriere nicht eingeschränkt wird, lol. Ich habe ein Jahrzehnt Erfahrung anzubieten, aber nichts davon zählt, weil ich kein Experte in diesen Bibliotheken bin, die vor 5 Jahren niemand brauchte. Ich habe nichts gegen die Bibliotheken selbst – sie sind manchmal super nützlich – aber ich mag nicht, wie sie die Leute effektiv 66 % dessen ignorieren lassen, was das Web ausmacht.
Ich stimme absolut zu, dass CSS und HTML unterschätzt werden und der Code darunter leidet. Als jemand, der Webentwicklung aus einer Designposition heraus und durch HTML und CSS gelernt hat, kann ich sofort erkennen, wenn ein Backend-Entwickler oder JavaScript-Entwickler das Stylesheet geschrieben hat. Es ist furchtbar, und die Leute scheinen sich nicht darum zu kümmern. Die Leute denken, dass CSS und HTML einfach keine Rolle spielen, dass sie keine Optimierung oder Wartbarkeit benötigen.
Ich sehe es auch auf Stack Overflow; einfache CSS-Lösungen für Probleme werden oft ignoriert, während die Leute bereitwillig empfehlen, jQuery zu verwenden, um ein Layout-Problem zu lösen. JavaScript zur Behebung eines Layout-Problems sollte ein absolutes letztes Mittel sein, und eine ganze Bibliothek hinzuzuziehen, um ein Problem zu lösen, das mit CSS oder einer besseren HTML-Struktur gelöst werden kann, ist absolut absurd!
Schlimmer noch, Entwickler, die Programmierung verstehen, ignorieren es, weil JavaScript „lukrativer“ ist, wodurch CSS und HTML ausschließlich von Nicht-Programmierern geschrieben werden, was unweigerlich zu weniger wartbarem Code und weniger Fokus auf Codeprinzipien, Wiederverwendbarkeit, Optimierung und andere wichtige Grundsätze der Programmierung führt.
Es ist leicht, CSS und HTML als „keine echte Sprache“ abzutun, und es scheint, als würden zu viele Menschen es so behandeln. Das bedeutet, dass der richtigen Gestaltung des Dokuments so wenig Aufmerksamkeit geschenkt wird und das Markup darunter leidet. Websites werden klobig und übermäßig auf JavaScript angewiesen – sogar abhängig – und die responsive Seite einiger Websites ist ein absoluter Albtraum. Die Wartbarkeit ist manchmal völlig mangelhaft, und das Hinzufügen zusätzlicher Inhalte zu Layouts kann diese vollständig zerstören, da das Layout nicht richtig strukturiert war, um sich an seinen Kontext anzupassen und darauf zu reagieren.
Es ist durchaus wichtig, die Entwicklung so zu trennen, dass die Talente der Menschen nicht zu stark zwischen syntaktisch sehr unterschiedlichen Programmierkonventionen aufgeteilt werden. Aber wir müssen auch HTML und CSS viel mehr respektieren und sie als wichtige Sprachen an sich betrachten. Wir müssen diejenigen, die sie schreiben, als Entwickler behandeln und die (bereits vorhandenen und leicht verfügbaren) Prinzipien in unsere Projekte integrieren. Kurz gesagt, wir müssen weniger besessen und ausschließlich auf JS fokussiert sein.
Sicher, JS kann viele Probleme lösen. Aber das bedeutet nicht, dass es die beste oder einzige Lösung für jedes Problem ist. Manchmal ist JS unerlässlich, aber manchmal – wenn das Dokument von vornherein sinnvoller strukturiert werden kann – kleben wir mit JS einfach Pflaster auf eine klaffende Wunde.
In einem solchen Fall sollten wir überlegen, ob es nicht eine gute Idee gewesen wäre, von Anfang an mehr in die HTML/CSS-Seite zu investieren. Aber dann ist es fast schon zu spät.
Ich selbst bin viel mehr auf der HTML- und CSS-Seite der Dinge, und ich spüre diese große Kluft allzu oft. Ich sehe beide Seiten als gleichermaßen wichtig an, und aus meiner Sicht, nachdem ich auf beiden Seiten getüftelt habe, ist es unendlich wertvoller, ein Experte/Künstler in HTML und CSS zu sein, als ein mäßig versierter JS-Framework-orientierter Entwickler, ABER es sollte nicht dabei bleiben.
Wenn Sie sich auf die HTML- und CSS-Seite der Frontend-Entwicklung konzentrieren möchten, stellen Sie sicher, dass Sie ein Meister Ihres Handwerks sind; erweitern Sie Ihren Horizont ein wenig. Wenn Sie CSS lieben, lernen Sie SCSS. Es ist keine Notwendigkeit, aber damit können Sie mehr und viel einfacher tun, und Sie werden letztendlich wertvoller sein, ganz zu schweigen davon, dass es Sie im Frontend-Bereich der „semantischen“ Entwicklung und Community viel relevanter machen wird.
Darüber hinaus gibt es, als Antwort auf Keiths Punkt, eine erhebliche monetäre Kluft, wenn es um Arten von Frontend-Entwicklern geht, hauptsächlich aufgrund von Angebot und Nachfrage, und das zu Recht. HTML und CSS mögen für einige Rollen ausreichen, aber es ist einfach nicht genug, wenn Sie erwarten, mit Ihren JS-lastigen Kollegen gleich bewertet zu werden. Bilden Sie sich weiter. Werden Sie ein außergewöhnlicher Designer in Photoshop und Illustrator oder beherrschen Sie UI/UX-Design mit Sketch/Adobe XD/InVision Studio/etc. Oder praktischer: werden Sie zumindest mäßig versiert in PHP und grundlegendem jQuery. Diese Fähigkeiten sind beide leicht zu erlernen. Grundlegendes Verständnis von jQuery wird typischerweise in klassischen Frontend-Rollen erwartet, und PHP-Entwickler verdienen weitaus mehr als Nicht-PHP-Entwickler, obwohl PHP Ihnen in vielerlei Hinsicht mehr Vorteile als nur Einkommen bringen kann und Sie sogar dazu inspirieren kann, weitere Sprachen zu lernen.
Soweit ich das beurteilen kann, besteht der Unterschied zwischen HTML/CSS und JavaScript darin, dass HTML einfacher zu lernen ist. Das bedeutet, dass es viel mehr HTML/CSS-Entwickler als JavaScript-Entwickler gibt. Das drückt den Preis phänomenal niedrig. Man landet bei https://www.psd2html.com/. Ich wurde bereits von einem Frontend/UX-Job abgelehnt, weil ich etwas mit schön gemachtem HTML/CSS produziert hatte, obwohl es ihnen nur um JavaScript ging. Ich werde mich nie wieder als HTML/CSS-Entwickler verkaufen, egal wie sehr sie mir am Herzen liegen.
Das ist so ziemlich mein Leben der letzten 3 Jahre. Ich musste das meiste von dem, was ich eigentlich gerne getan habe, aufgeben, um den Job zu behalten, den ich bekommen habe, der völlig anders war, als ich dachte, wofür ich mich beworben hatte. Wenn man bedenkt, dass ich dafür quer durchs Land gezogen bin, wollte ich eine solide Amazon-Position nicht aufgeben, um auf etwas Angenehmeres zu hoffen, besonders angesichts des Feedbacks, das ich bekam, als ich nach nicht-javascript-framework-Arbeit suchte…
Die Division Bell im Hintergrund.
Hallo. Ich bin Designer & Mathematiker. Im Laufe eines Tages wechsle ich vielleicht vom visuellen Prototyping zum Codieren oder umgekehrt. Javascript ermöglicht es mir, sehr individuelle Erlebnisse durch Funktionen und Kontinuität des Raumes zu schaffen. Ich finde CSS eine großartige Ergänzung und eine Art Lineal, um die diskrete Existenz und Beziehungen auf der Seite zu verwalten. Ich glaube, die Trennung liegt nicht an den Werkzeugen, sondern an den zwei Arten von Menschen: Digitaldesignern, die den Code/Kontext nicht kennen, und Ingenieuren, die die Designsprache nicht kennen. Die erste Gruppe sucht oft, aus Angst vor komplexer Programmierung, Zuflucht und Sicherheit in grundlegenden Werkzeugen mit der Ausrede, die Dinge einfach zu halten. Einfach ist großartig, aber Einfachheit durch ein Werkzeug oder einen Prozess zu erreichen, der die Kraft hat, komplexe Schönheit zu schaffen, ist die wahre Kunst. Die zweite Gruppe versteht es einfach nicht. Sie sind oft Ingenieurtypen, die viel weniger Erfahrung und Übung im Design Thinking haben. Ich persönlich habe die Zusammenarbeit mit einem Alpha-Coder in Bezug auf UX oder visuelle Ästhetik oder Ausführungsstile aufgegeben. Übrigens gibt es die gleiche Frustration auch in anderen Bereichen, zum Beispiel bei Architekten vs. Statikern. Viele Ingenieure, nur weil sie die Fähigkeiten haben, Dinge auszuführen, liefern den Mist ab, den wir alle live sehen. Die Natur freier Märkte und des aktuellen Wirtschaftssystems macht es den wahren Denkern und Machern schwer, die Machtdynamik umzukehren. Wenn eine Nachfrage nach Produktion und mehr Dingen besteht, wird die Crew, die die herausragenden Fähigkeiten zur schnellen und skalierbaren Produktentwicklung besitzt, zum Vorreiter. Das System kümmert sich weniger um den besten Weg, es zu tun, oder wer es richtig macht, weil keine Belohnungen an die Ausübung solcher Werte geknüpft sind. Optimistisch abschließend stelle ich mir vor, dass wir in naher Zukunft, mit vielen Umbrüchen in der klassischen Bildung, eine Generation von Talenten haben werden, die weniger voreingenommen gegenüber ihren Abschlüssen oder Titeln sind und ein Spektrum an Fähigkeiten und Interessen beim Bau von Dingen haben, die wichtig sind. Ich habe nie wirklich verstanden, warum Designer im Allgemeinen Programmieren & Mathe hassen sollten oder warum Ingenieure so stolz monochrom sind. Sie sind alle dieselben Kinder auf dem Spielplatz. Die Angst und die Trennung sind in Bildung, Arbeitsplatz, Jobtiteln, Stellenausschreibungen usw. konditioniert.
Tolle Lektüre. Auch als Neuling wirklich motiviert von all dem. Bei so vielen verschiedenen Wegen kann es manchmal einschüchternd sein, weiterzumachen.
Habe diese Seite erst kürzlich auf meiner Suche nach dem Entwicklerstatus gefunden und den Inhalt genossen!
Chris, danke, dass du diesen Artikel zusammengestellt hast, es war eine kathartische Lektüre. Ich habe Glück, dass das Team, in dem ich bin, das schätzt, was ich einbringe, dass wir alle die Stärken des anderen nutzen und dass wir zusammen erstaunliche Dinge gebaut haben, aber das hindert mich nicht daran, innerlich mit meiner eigenen Relevanz und meinen Fähigkeiten zu kämpfen. Und obwohl es mich nicht wirklich näher daran bringt, meine eigenen Vorurteile und mentalen Blockaden zu überwinden, ist es etwas tröstlich zu wissen, dass ich nicht allein bin.
Ich sehe kein Problem oder eine tatsächliche Kluft, abgesehen von den gelegentlichen Tweets hier und da. Meiner Meinung nach ist das so gut wie kein Problem. Für mich war ein Frontend-Entwickler immer jemand, der HTML, CSS und JavaScript schreibt.
Ein JavaScript-Entwickler ist jemand, der sich ausschließlich auf den JavaScript-Aspekt der Dinge konzentriert. Man könnte keinen CSS-Entwickler haben, weil man HTML braucht, um sein CSS zu begleiten, sonst tut es nichts. JavaScript ist heutzutage zu einer völlig eigenständigen Sprache geworden.
Ähnlich wie ein Backend-Entwickler, der Code in PHP oder Ruby schreibt und dann auch etwas mit Datenbanken und Servern macht. Ich würde jemanden als PHP-Entwickler einstufen, wenn er sich nur auf PHP konzentriert. Ich verstehe nicht, woher diese sogenannte „Identitätskrise“ kommt.
Es ist fast so, als hätten die Leute eines Tages beschlossen, dass ihnen ihr Jobtitel nicht gefällt und sie etwas Neues und Einzigartiges finden müssen, um anders und interessant zu klingen. Ingenieur, Entwickler, Programmierer… es ist immer noch nur Code schreiben. Können wir uns auf Entwickler einigen?
Toller Beitrag. Was mich beim Lesen am meisten überrascht hat, ist, dass viele Menschen eine „Wir gegen Die“-Trennung empfinden.
Dieses Jahr habe ich meine erste Full-Stack-Rolle begonnen; davor hatte ich etwa 7 Jahre in verschiedenen Frontend-Rollen gearbeitet. Ich würde gerne denken, dass ich mir meine „Sporen verdient“ habe, indem ich die grundlegenden Aspekte des Frontends gemeistert habe. Ich weiß, das war nicht die Absicht, aber ein bestimmtes Zitat in diesem Artikel gab mir das Gefühl, als Full-Stack-Entwickler ein wenig ausgegrenzt zu werden, dass ich CSS oder Ähnliches wahrscheinlich nicht anfassen sollte, weil meine Ergebnisse im Vergleich zu jemandem, der ausschließlich mit solchen Sprachen arbeitet, „erbärmlich“ sein könnten.
Noch wichtiger ist, dass ich nicht glaube, dass „Full-Stack-Entwickler“ notwendigerweise implizieren sollte, dass ein Entwickler gleichermaßen in Frontend-Code und Backend-Code versiert ist. Wer sagt, dass jemand ein Junior Full-Stack-Entwickler sein könnte? Dürfen wir keine Full-Stack-Entwickler haben, die beide Seiten der Medaille lernen wollen, aber vorerst nur ein kompetentes Niveau haben? Es ist jedoch offensichtlich, besonders nach dem Lesen dieses Artikels, dass einige Full-Stack-Entwickler ein kleines „God Complex“-Problem haben, und das ist leider der Grund, warum Full-Stack mit „Meister aller“ assoziiert wird.
Es ist keine Schande, unsere Grenzen und Wissenslücken zuzugeben. Wenn Sie ein Full-Stack-Entwickler werden möchten oder gerade beides lernen, aber vielleicht seit ein paar Jahren kein CSS mehr aufgefrischt haben, wenden Sie sich an diejenigen, die dies getan haben, um Rat zu erhalten. Spielen Sie nicht die Situation herunter und nehmen Sie nicht an, dass das, was Sie produzieren können, „gut genug“ ist – Sie geben uns anderen einen schlechten Ruf.
Wir zwängen zu viele Aspekte eines sehr komplexen Mediums in eine Berufsbezeichnung, und es ist kein Wunder, dass die Leute den Druck spüren; gezwungen, sich anzupassen, Niederlagen zu akzeptieren oder leider in einigen Fällen Dinge, die sie nicht vollständig verstehen, zu ignorieren und „weiterzuwursteln“, indem sie schlechten Code produzieren.
Ich glaube, wir brauchen mehr Jobtitel, aber auch einen Satz, der in der gesamten Branche universell identifizierbar ist. Sonst riskieren wir, dass Leute als „Half-Stack UX Interaction Designer“ bezeichnet werden … und das will niemand.
Predigt!
Ich denke, ein großer Teil des Problems bei der Frontend-Entwicklung ist, dass die meisten Leute alles, was im Browser passiert, als „Frontend“ betrachten, obwohl das nicht stimmt.
Frontend und Backend sind nicht dasselbe wie Client-Side und Server-Side. Nur weil Ihr Code im Browser (Client-Side) läuft, macht ihn das nicht zu Frontend-Code.
Einfach ausgedrückt: Das Frontend kümmert sich darum, wie es aussieht und sich anfühlt und wie man damit interagieren kann, das Backend kümmert sich um die Geschäftslogik Ihrer Anwendung. Das sind zwei völlig unterschiedliche Dinge, die sehr unterschiedliche Fähigkeiten erfordern. Nur weil wir eine Sprache (JavaScript) haben, die sowohl Backend- als auch Frontend-Aufgaben übernehmen kann, macht das nicht automatisch alles, was Sie damit machen, zu Frontend.
Wenn Sie die gesamte Geschäftslogik Ihrer Anwendung in JavaScript schreiben, das im Browser läuft, benötigen Sie keinen Frontend-Entwickler, sondern einen Backend-Entwickler.
Wo Ihr Code läuft, macht ihn nicht zum Frontend oder Backend, sondern was er tut, das tut er!
Die eine Seite dieser „großen Kluft“, deren Interessen und Fähigkeiten sich stark um JavaScript drehen, sind keine Frontend-Entwickler. Sie sind Backend-Entwickler, die JavaScript als ihre Hauptsprache wählen. So wie einige Backend-Entwickler PHP oder Go verwenden.
Heiliger Bimbam, Batman! JavaScript und ich waren noch nie Freunde. Sicher, ich kann es mir ansehen, herausfinden, was los ist und ein bisschen davon und etwas jQuery verwenden, um Browser zu coolen Dingen zu bringen, aber ich bin in keiner Weise ein Programmierer. War ich nie. Ich habe versucht, und versucht, und versucht, Programmierung und JavaScript zu lernen und ein „richtiger“ Frontend-Entwickler zu werden, aber ich glaube, du hast mir gerade das Licht gezeigt! Ich bin ein Frontend-Entwickler, nur der Typ, der sich mit HTML und CSS auszeichnet, der Design und UX mag, der gerne Animationen und digitale Inhalte erstellt! Nur nicht Programmierung! Als Nächstes muss ich nur noch das Selbstvertrauen haben, es zu besitzen! Danke dafür!
Als jemand, der alles macht (Design bis JavaScript), sage ich Ihnen:
Ich liebe es, wenn ein UX/Frontend-Entwickler mir ein fertiges Layout mit Bildern, Abständen und Hex/RGBA-Werten für Farben übergibt.
Ich weiß, dass Layout nicht meine Stärke ist (sie werden „gerade noch so“), und ich schätze es zutiefst, jemanden zu haben, der das für mich erledigt, denn ich weiß, es wird um Meilen besser sein.
Du musst nicht einmal das HTML und CSS schreiben.
Allein das Layout lässt mich Sie schon wie einen Helden/eine Heldin ansehen, also nehmen Sie Ihren Job nicht als selbstverständlich hin.
Ich liebe dich.
Vielen Dank, Chris, für diesen großartigen Artikel und das Video. (Und ich liebe das neue Aussehen Ihrer CSS-Tricks-Website)
Das Web begann mit statischen Webseiten. Damals war das UI/UX-Design viel weniger dynamisch (d.h. plan vanilla CSS1/2)… weniger Animationen und weniger Interaktivität auf einer einzigen Seite/einem einzigen Bildschirm.
Aber jetzt sehen wir hier Konvergenzen, wie CSS-Variablen und Keyframe-Animationen (so etwas wie eine deklarative Sprache für dynamisches CSS), die mit jedem Element auf der Seite interagieren...
Auch bei dynamischen Layouts/Mobile-First – nehmen Sie zum Beispiel neue CSS Grids und Flexbox… es geht nicht nur um das Layout… es geht auch darum, das Grid dynamisch auf netzwerk- und seitenrendering-performante Weise zu füllen. Hier müssen Sie SOWOHL JavaScript als auch HTML/CSS und wahrscheinlich ein gewisses Verständnis von serverseitigen Technologien (z.B. das Abrufen von Abschnitten großer Daten in separaten Anfragen, während der Benutzer scrollt) kennen.
Mein Punkt ist also, dass, wenn jemand Sie einstellt, um eine moderne (Web-)App/Seite zu erstellen, er von Ihnen erwartet, dass Sie mehr Fähigkeiten beherrschen, als Webentwickler in den frühen Web-Tagen benötigten. Genauso wie, wenn Sie Ihr aktuelles Auto zur Reparatur in die Werkstatt bringen, Sie sich ziemlich Sorgen machen würden, wenn Ihnen gesagt würde, dass sie nur wissen, wie man Autos von 1970 und früher repariert… Sie erwarten von ihnen, dass sie wissen, wie man alle Aspekte Ihres modernen Autos (Elektronik/Motor/Computerchips) repariert oder bei Bedarf einen Spezialisten hinzuzieht.
Ich denke, Arbeitgeber/Recruiter müssen dieses Problem am besten verstehen… Arbeitgeber müssen ihren Mitarbeitern Zeit/Aufgaben geben, um sie zu vielseitigen „Entwicklern“ auszubilden… Und wenn Sie selbstständig sind (oder Ihr Arbeitgeber sich nicht darum kümmert), müssen Sie versuchen, sich selbst weiterzubilden.
Ich habe mich in letzter Zeit so überfordert gefühlt von der Kluft in der Front-End-Entwicklung. Alles begann vor ein paar Jahren, als ich mich auf eine Position als UI Developer bewarb, die HTML/CSS/JS und TDD als Kernkompetenzen angab. Sobald sie TDD in die Stellenausschreibung aufnahmen, bemerkte ich, dass dies auch auf andere größere Organisationen in der Stadt überging. Als Nächstes stand Angular 2+ in der Stellenausschreibung, dann war es React… Ich fange an zu denken, dass Entwickler einfach Elstern sind, die immer nach dem neuesten glänzenden Ding schielen.
Um mein eigenes Argument zu widerlegen, habe ich letzte Woche eine kleine Broschüren-Website erstellt und Gatsby und WordPress verwendet. Die Entwicklung dauerte viel länger, aber sie erreichte in einem Lighthouse-Bericht durchweg über 95 Punkte und fühlt sich blitzschnell an.
Dies ist ein großartiger Artikel, der einen hervorragenden Überblick über die Webentwicklung über 25 Jahre gibt und erklärt, warum sich die Dinge weiterentwickelt haben – https://hackernoon.com/modern-web-development-bf0b2ef0e22e
Ich glaube wirklich, dass sich die Rolle in Fachgebiete aufteilen wird, aber die Kernkompetenzen, eine Seite in HTML/CSS/JS zu gestalten und zu erstellen, werden immer noch im Mittelpunkt stehen.
Dies ist so ein wunderschöner Beitrag und er trifft so gut auf die meisten anderen Rollen (Titel?) in Produktteams zu.
Zum Beispiel sagte Ann Rockley es für Content Strategen unter: https://contentmarketinginstitute.com/2016/02/types-content-strategist/ Ebenso für UX Designer. Ich werde diesen Beitrag als Referenz in meinem Team verwenden!
Dieser Artikel verkörpert den Kampf in meiner Karriere. Umfangreiches JS-Wissen war für mich immer schwer fassbar. Ich erwarb meine Fähigkeiten und Kenntnisse im Übergang zum semantischen Web und verfeinere diese Fähigkeiten weiterhin. Allerdings war ich schon immer ein „Hybrid“-Designer. Ich werde oft von einigen designorientierten Unternehmen zu den Entwicklern verstoßen, und dann bin ich nicht „technikaffin“ oder „Entwickler“ genug für Entwicklerteams, obwohl die Entwickler sagen, sie bräuchten meine Hilfe beim Frontend. Das ist an manchen Tagen wirklich hart.
Vielen Dank, dass Sie darüber gesprochen haben <3
Zur Orientierung: Ich bin Anfänger, lerne gerade JavaScript-Entwicklung und versuche mein Bestes, auch das richtige Markup & Design zu lernen. Laut diesem Artikel sollte ich der Typ sein, der sich auf die SPA-Bibliotheken und voreingestelltes UI-Design durch zusätzliche Bibliotheken (z.B. Material-UI) konzentriert, aber auch auf das Schreiben von semantischem Markup, SEO und CSS (alles, was mir aufrichtig Spaß macht!).
Ich finde es ehrlich gesagt schade, dass Entwickler auf der Markup- und Designseite diskriminiert werden, weil sie „nicht JavaScript-orientiert“ sind. JavaScript ist, nach dem, was ich darin geschrieben und online gelesen habe, bereits eine sehr geheimnisvolle Sprache, und viele Entwickler rühren sie aus diesem Grund nicht einmal an. Es ist für mich ziemlich traurig zu sehen, wie sich die Frontend-Seite aufspaltet, besonders wenn Dinge wie JavaScript Fortschritte gemacht haben. Stattdessen glaube ich, dass das Frontend in eine Reihe separater Rollen aufgeteilt werden sollte, die ich unten beschreiben werde.
Es scheint jetzt sinnvoller, die Titel anders aufzuteilen. Anstatt „Front-End-Entwickler“ (meistens) nur auf JavaScript zu beziehen, stelle ich mir so etwas vor:
Frontend-Markup-Entwickler
Verantwortlich für HTML, Markup und Semantik
Frontend-UI-Designer
CSS-Kenntnisse mit guten Design-Fähigkeiten
Frontend-UX-Designer
Wie Nr. 2, aber mit UX-Fähigkeiten
Frontend-React-Entwickler
Kompetenz in React und seinen Schwesterbibliotheken (wie z.B. react-router)
Frontend-Vue-Entwickler
Kompetenz in der Erstellung von UIs mit Vue
Frontend-Angular-Entwickler
Kompetenz in der Erstellung von UIs mit Angular
Frontend-JavaScript-Entwickler
Entwickler mit Kompetenz in modernem JavaScript, React, Vue und Angular
Front-End-Design-Experte
CSS-Kenntnisse mit UI + UX-Fähigkeiten
Full Stack Frontend-Entwickler
HTML-, CSS-, JavaScript-Kenntnisse. Kann semantisches Markup schreiben, CSS Grid & Flexbox richtig und effizient verwenden und SPAs in React, Vue und Angular schreiben. Verfügt über grundlegende Kenntnisse von GraphQL und dem Schreiben von APIs. Ist mit NodeJS vertraut.
Wie Sie sehen, gibt es viele Nischen im Begriff „Front-End-Entwickler“, was zu viel Vorurteilen und Verwirrung führt. Ich denke, dass eine Aufteilung in besser überschaubare, Frontend-bezogene Rollen die Dinge klärt. Der Begriff „Front-End-Entwickler“ sollte dem seltenen Diamanten vorbehalten sein, der all diese Nischen auf einmal ausfüllen kann.
Großartiger Schnappschuss des aktuellen Stands der Frontend-Webentwicklung im Jahr 2019, Chris. Ich versuche weiterhin, in beiden Bereichen zu lernen und mich zu übertreffen (weil ich sie gleichermaßen mag), aber ich habe das Gefühl, dass das Zentrum nicht mehr lange halten wird, und frage mich, wie das Feld in ein paar Jahren aussehen wird. Eines wissen wir: Langweilig wird es nicht. Machen Sie weiter so mit Ihren Artikeln und Podcasts, wir brauchen weise Stimmen, die uns helfen, diesen massiven Wandel mit Mitgefühl und Intelligenz zu bewältigen. Vorwärts.
Ich denke, das illustriert ein größeres Problem in der Wirtschaft und bei diesen konvergierenden Disziplinen. Es betrifft nicht nur „Front-End“, sondern auch „Full-Stack“ und sogar Begriffe wie „Performance“.
Ich habe den Begriff „Full-Stack“ verwendet gesehen, um einen Entwickler zu beschreiben, der auch testet. Ich habe auch Performance-Tests gesehen, die zu 100% auf das Backend fokussiert waren (URL- oder App-Stresstests), ohne jegliche Berücksichtigung des Clients.
Hier spielen wahrscheinlich mehrere Faktoren eine Rolle, aber es ist sicherlich besorgniserregend zu sehen. Es unterstreicht nur die Bedeutung, sich für die vernachlässigten (aber notwendigen) Elemente einzusetzen, bevor Organisationen auf die harte Tour lernen.
Middleware, erinnern Sie sich an diesen Begriff? Wenn Sie serverseitiges JavaScript sagen (rofl), haben Sie sich von der Display-Schicht/GUI/UI entfernt und Sie haben kein „Front“-End mehr. Das Front ist, wo der Gummi die Straße berührt.
In meinen 25 Jahren, in denen ich das mache, hatten wir zuerst Webdesigner, Webentwickler, Webmaster. Dann begannen wir, es mit Backoffice vs. Designer zu formalisieren. Eine Zeit lang hatten wir dann DBA, Middleware und Designer. Die kundenorientierte (Front) Seite der Dinge wurde sehr, sehr, sehr lange hauptsächlich als Designer behandelt.
Ein paar Schritte zum aktuellen Status überspringend, sind UX/UI und Frontend-Designer sogar separate Rollen. Frontend-Designer und Frontend-Ingenieur trennen uns jetzt.
Dies wird überhaupt nicht dadurch verbessert, dass billige Kunden versuchen, uns unter dem Deckmantel von „Full Stack“ zu überarbeiten. Cool, Sie kennen also AAA-Level ADA-Compliance, Datenbanken, zeitgenössisches Design, CORS, Tests, D3, 3D, Jenkins und den Box-Model-Hack? Erwarten Sie eine erschöpfende, zeitlich begrenzte Code-Challenge, um kaum genug bezahlt zu werden, was ein Spezialist in einer der oben genannten Disziplinen verdienen würde.
„Front End“-Leute haben der Gemeinschaft insgesamt keinen Gefallen getan.
Dies ist eine häufige Diskussion an unserem Arbeitsplatz. Wir haben vorgeschlagen, dass diejenigen mit den „traditionellen“ HTML- und CSS-Fähigkeiten den Titel „UI/UX Developer“ erhalten, während der Titel „Front-End Developer“ für JavaScript-intensive Positionen, gemäß neuer Branchentrends, verwendet werden darf.
Das spricht mich wirklich an.
Ich hatte das Glück, dass ich ein lustiges Hobby, das ich 1996 angefangen habe, in einen Beruf verwandeln konnte. Sogar in eine Karriere. Aber ich habe diese Spaltung sicherlich bemerkt. Die Dinge, die es anfangs lustig und lohnenswert machten, wurden abgewertet zugunsten einer vollständigen Betonung von Fähigkeiten, die einst nur ein kleiner Teil davon waren.
Die einzige Möglichkeit, den Job weiter zu machen, bestand darin, so viel Spaß wie möglich daraus zu nehmen, bis es im Grunde etwas anderes wurde. Der unausgesprochene Teil davon ist, dass es praktisch keinen Karriereweg gibt, wenn man ständig neues Fachwissen, Fähigkeiten und Verantwortlichkeiten hinzufügen muss, nur um den Job zu behalten, den man bereits hat.
Ich bin in falsch geführten, IT-zentrierten Organisationen gefangen, die den Wert von UX, CSS, Barrierefreiheit, Interaktionen und Ähnlichem niemals erkennen konnten. Sie werden zu Kontrollkästchen, die ein „echter Entwickler“ erledigen kann, nachdem er mit dem Programmieren fertig ist. Für sie beginnt und endet CSS als Fähigkeit mit dem Verständnis der Syntax. Für Organisationen wie diese spielt es keine Rolle, ob Ihre Website der einzige Kontaktpunkt mit Ihren Benutzern und Kunden ist – wenn es um Code geht, ist es einfach etwas, womit die IT-Abteilung umgehen kann.
Ich wurde müde dieser Denkweise von Code über Empathie für den Benutzer, aber ich passte mich an. Ich erlernte neue Fähigkeiten, die ich ehrlich gesagt nicht wollte, nur um angestellt zu bleiben, aber hauptsächlich wusste ich, dass ich da raus musste. Das ist seit Jahren klar. Ich wusste, der einzige Ausweg war der Wechsel ins Management, aber das ist nicht einfach in einer kleinen Organisation mit wenig Raum für Wachstum. Ich arbeitete 60-Stunden-Wochen, meldete mich in Besprechungen zu Wort und ergriff im Grunde wann immer möglich die Initiative, um eine Veränderung herbeizuführen. Hauptsächlich hatte ich jedoch Glück.
Für kurze Zeit hatte ich einen Chef, der tatsächlich Empathie für die Nutzer verstand und den Wert dieser Dinge sah. Als diese sehr seltene Gelegenheit auftauchte, konnte ich sie ergreifen. Und es war eine Weile gut. Ich hatte das beste Team, das man sich wünschen konnte. Aber schließlich ging dieser Chef in Rente, und die Dinge nahmen eine Wendung. Sie setzten einen IT-Typen ein – die Art von Typ, der denkt, es gäbe kein Problem, das man nicht mit Javascript und Python lösen könnte.
Obwohl ich ein hochfunktionales kleines Team leitete, viele erfolgreiche Projekte abgeschlossen und wichtige Ergebnisse erzielt hatte, wusste ich, dass die Dinge toxisch werden würden und es Zeit war zu gehen. Nun, weniger als ein Jahr später, hat mein gesamtes Team diese Organisation verlassen oder wurde entlassen – weitere Opfer der Denkweise, die das Schreiben von Code über die Empathie für den Benutzer stellt.
Ich hasse es, pessimistisch zu sein, aber ein FE-Entwickler, der keine starken JS- (oder Programmier-) Fähigkeiten (Datenstrukturen, Algorithmen, skalierbare Architektur usw.) besitzt, wird in den kommenden Jahren wahrscheinlich rar werden.
Tools wie Webflow etc. und eine bessere Compliance der Browser haben den HTML/CSS-fokussierten FE-Entwickler weniger unverzichtbar gemacht. Sicher, Webflow ist nicht perfekt, aber in vielen, vielen Fällen ist es gut genug und es wird besser werden.
Absolut fantastischer Beitrag. Ich liebe den individuellen, künstlerisch gestalteten Stil.
Ich bin Dozent in einem Kurzzeit-Webentwicklungsprogramm, das sich auf die Front-End-Seite konzentriert. Ich würde uns nicht als Bootcamp-Schule bezeichnen, da das Programm an einer öffentlich finanzierten postsekundären Einrichtung durchgeführt wird, aber unsere Konkurrenz sind sicherlich die verschiedenen Bootcamp-Schulen in der Nähe. Wir versuchen, unser Programm so zu strukturieren, dass HTML/CSS und Design als gleichwertig mit JavaScript angesehen werden.
Sie haben es auf den Punkt gebracht, als Sie sagten, dass viele Bootcamp-Schulen sich fast ausschließlich auf JavaScript konzentrieren, mit nur ein oder zwei Tagen für HTML und CSS. Das ist so wahr und sehr traurig.
Wir als Kursdesigner spüren ständig den Druck von potenziellen Studenten, Arbeitgebern unserer Absolventen, Absolventen und sogar von uns selbst, immer mehr JavaScript hinzuzufügen.
Die Studierenden fragen immer: „Werden wir dieses oder jenes Framework lernen?“, sie fragen nie: „Werden wir semantisches HTML lernen?“. Früher hatte ich das Gefühl, wir sollten dem Druck einfach nachgeben und immer mehr JavaScript hinzufügen und vielleicht den HTML- und CSS-Anteil unseres Programms verkleinern, aber es fühlte sich nie richtig an.
In den letzten Jahren habe ich mir Sorgen gemacht, dass es einfach zu einer JavaScript-Framework-Welt geworden ist, in der JavaScript als die Lösung für alles im Web angesehen wird. Die Leute schreiben HTML in JavaScript und jetzt schreiben sie CSS in JavaScript. Warum sich mit CSS beschäftigen... CSS ist dumm... JS den ganzen Tag, die ganze Zeit... Nicht meine Worte, aber so hat es sich in den letzten paar Jahren angefühlt.
Wir brauchen HTML, wir brauchen CSS und ja, wir brauchen JavaScript. Wir als Pädagogen haben die Pflicht, Absolventen hervorzubringen, die die Bedeutung von gut kodiertem, semantischem und zugänglichem HTML verstehen und die die volle Kraft und Schönheit von CSS begreifen. JavaScript hat seinen Platz, aber nicht jedes Dokument im Web muss mit JavaScript erstellt werden. Es liegt eine Schönheit in der Einfachheit eines reinen Dokuments, das in HTML und CSS geschrieben ist.
Vielen Dank, Chris, für diesen Artikel. CSS-Tricks ist eine einflussreiche Seite in unserem Bereich, und ich bin sicher, dieser Beitrag wird von vielen in unserem Bereich geteilt und gelesen werden. Das gibt mir Trost, denn ich hoffe, wir haben hier eine Wende genommen und können hoffentlich zu einem gewissen Gleichgewicht in der Webentwicklung zurückkehren, wo JavaScript seinen Platz hat, aber Fähigkeiten in HTML, CSS, Barrierefreiheit, UX, Design und Informationsarchitektur als gleichermaßen wertvoll für die Erstellung einer nutzbaren, zugänglichen und visuell ansprechenden Webanwendung oder Website angesehen werden.
Ich gehöre zur HTML/CSS-Seite der Dinge. Ich würde meine HTML/CSS-Entwicklerkollegen jedoch herausfordern, die Zeit zu investieren, um etwas wie React zu lernen. React mit JSX fühlt sich ehrlich gesagt am ehesten so an, wie ich SCSS für mein Markup mit einfacher Logik verwende, was meinen Workflow wirklich beschleunigt.
Zum Beispiel eine `Button`-Komponente, die ein `a`-Tag rendert, wenn `href` übergeben wird, und ein `button`-Tag sonst. Dieser `Button` ist im Wesentlichen ein Markup-Mixin.
So viel ja. Das habe ich in den letzten ~5-10 Jahren jeden Tag mehr und mehr gespürt.
Guter Artikel, er bestätigt, was ich bereits weiß… jeder Front-End-Entwickler, der heutzutage arbeitet und sich mit den neuen Technologien in diesem Bereich auf dem Laufenden hält, weiß all das oder zumindest das meiste davon… JavaScript kontrolliert und dominiert die Webentwicklung nicht nur für das Web, sondern wir sehen bereits Frameworks, die auf JavaScript basieren, um Desktop- und mobile Anwendungen zu erstellen.
Als Front-End-Webentwickler müssen Sie mit den Kernbereichen HTML, CSS, JavaScript vertraut sein, aber Sie müssen auch PHP, SQL, Node.js, MongoDB und GraphQL kennen. NATÜRLICH ist der Front-End-Entwickler das Glied in der Kette, das den Benutzer mit dem Server (echte Benutzerdaten / Website-Daten) verbindet und alle möglichen Interaktionsszenarien festlegt, die der Benutzer ausführen kann, und im Gegenzug das visuelle Ergebnis bestimmt (nicht welche Daten empfangen werden, sondern das Aussehen dieser Daten und wie sie dem Benutzer angezeigt werden), unabhängig von Daten-„Get“- oder „Post“-Anfragen an den Server oder erforderlichen Validierungen.
Guter Artikel, aber ich hinterlasse nur einen Kommentar, um das Design und die Gliederung dieses Blogs zu würdigen.
Ich verabscheue zutiefst Menschen, die dies anderen, auch mir selbst, antun.
Ich schätze die Zeit und Mühe in diesem Artikel. Eines möchte ich noch stärker betonen: die wirtschaftliche Perspektive. Ich denke, viele Unternehmen hoffen, dass es billiger ist, einen Full-Stack-Entwickler einzustellen, anstatt mehrere Personen für mehrere Rollen zu besetzen. Das erinnert mich an die Zeit, als Unternehmen auf der Suche nach „Einhörnern“ waren, basierend auf der gleichen Idee – Geld sparen durch die Einstellung weniger Leute mit breiteren Fähigkeiten.
Ich kann nicht anders, als zu scherzen, dass der nächste beliebte Jobtitel „Einhorn Full-Stack-Entwickler“ sein wird…
Hey Frida,
Es stimmt, dass die meisten Unternehmen Full-Stack-Entwickler suchen, aber in ihren Stellenausschreibungen „Front-End-Entwickler“ schreiben. Als ich in den letzten Monaten oder so auf Jobsuche war, rollte ich oft mit den Augen, wenn ich gefragt wurde: „Und können Sie auch mit [hier durch ein beliebiges Backend-/JS-Framework ersetzen] arbeiten?“ – Natürlich kann ich mit diesen Frameworks arbeiten, aber zu diesem Zeitpunkt wollte ich es nicht! In der Stellenausschreibung stand eindeutig „Front-End-Entwickler“ und es ging um Templating für CMS oder E-Commerce-Systeme, also warum zum Teufel haben sie mich das gefragt? Wie Sie sagten: einfach um Geld zu sparen und den perfekten Alleskönner zu bekommen.
Leider befürchte ich, dass diese Diskussion diese Praxis nicht beenden wird. Es ist für Unternehmen völlig verständlich, Geld zu sparen, aber warum müssen sie jemanden mit irreführenden Stellenausschreibungen auf den Arm nehmen, während die betreffende Person einen neuen Job sucht? :)
Danke Chris!
So viele dieser Zitate hallen laut und deutlich wider.
Vor 5-10 Jahren war ich ein „Einhorn“, das recherchieren, gestalten, HTML/CSS erstellen, genug JS beherrschen und alles in die CMS-Template-Sprache des Tages einbinden konnte. Heute besteht mein Team aus mir und einem CMS/SysAdmin, und ich habe das Gefühl, ständig im Rückstand zu sein. Ich verbringe viel Zeit damit, herauszufinden, worüber ich mir Sorgen machen und was ich zurücklassen soll. In meiner E-Mail steht „Front End Developer“, aber eigentlich bin ich nur ein Front-End-Technologie-Wrangler, der versucht, eine große(ish) Website aktuell und im optimalen Bereich für die uns zur Verfügung stehenden Ressourcen zu halten. Viel Planung und Roadmapping nimmt viel meiner Zeit in Anspruch.
Ich hatte kürzlich die Erfahrung „Node-Manager, um einen Node-Manager zu installieren“ und beschloss sofort, mich für einen Kurs zum Bau von Fahrradrahmen anzumelden. Ich bin zu alt, um ständig meinem eigenen Schwanz hinterherzujagen. Die ständige Flut neuer Tools ist einfach zu kompliziert, um noch viel Spaß zu machen. Die Branche entwickelt sich schneller als ihre Bezeichnungen. Vielleicht ist es an der Zeit, diese abzulegen? Sagen wir „Ich bin ein JS-Ingenieur“ „Ich bin ein HTML/SCSS-Entwickler.“
Das ist unglaublich zu lesen. Ich verstehe mich als Designerin mit sehr guten HTML/CSS-Kenntnissen und kann mich ein bisschen durch Javascript wurschteln. Ich kann es lesen/ändern, aber nicht von Grund auf neu schreiben.
Ich habe auch einige Erfahrungen mit PHP / WordPress-Entwicklung, aber JS-Frameworks interessieren mich ehrlich gesagt nicht. Ich habe es versucht und es klickt einfach nicht.
Ich bin sehr stark diese „Auf der anderen Seite, eine Armee von Entwicklern, deren Interessen, Verantwortlichkeiten und Fähigkeiten sich auf andere Bereiche des Frontends konzentrieren, wie HTML, CSS, Design, Interaktion, Muster, Barrierefreiheit, etc.“
Wenn ich also Stellen für Front-End-Entwickler sehe, steht in der Beschreibung meistens viel Javascript, und das passt mir nicht. Ich frage mich, was ich bin, und habe das Impostor-Syndrom, weil ich das Gefühl habe, viel mehr wissen zu müssen.
Es ist wirklich gut, so etwas zu lesen, damit ich weiß, dass ich nicht allein bin!
Großartiger Artikel Chris, tatsächlich einer deiner besten. Weil er ein Gefühl beschreibt, das immer mehr „alte“ Frontend-Entwickler teilen: Es gibt tatsächlich eine Art Kluft. JavaScript scheint heutzutage der Weg zu sein, aber ich kenne viele JS-Entwickler, die tatsächlich nicht in der Lage sind, gutes CSS zu schreiben. Sie sind an Frameworks gebunden, schreiben nicht-semantischen Code, können die grafische Kohärenz in Anwendungen nicht aufrechterhalten. Die meisten Arbeitgeber sind sich dessen aufgrund ihres mangelnden Verständnisses des Frontend-Bereichs nicht bewusst. Sie ehren Frontend-JavaScript-Entwickler, weil sie funktionale Lösungen haben, die Geld bringen, der „alte“ Frontend-Entwickler oder Webdesigner fühlt sich oft wie eine zweitrangige Rolle.
Ich kenne jetzt viel JavaScript, weil ich an einem großen Projekt mit viel Daten und Angular arbeite. Aber ich bevorzuge es immer noch, Dinge zu gestalten. Ich wünschte, ich könnte auf dieser Seite ein besserer Front-End-Entwickler sein: tieferes Verständnis und Beherrschung von CSS, SVG, Animationen… Das ist nicht das, wonach die meisten Arbeitgeber dringend suchen.
Als Printlayout-Designer, der zum „Webdesign“ wechselte (was ich später lernte, kein schöner Begriff mehr war), fühle ich mich von diesem Beitrag gut getroffen. Jetzt, wo ich als Frontend-Entwickler (ha!) bei einer der größten Zeitungen Lateinamerikas arbeite, frage ich mich, wie ich von der Branche wahrgenommen werde. Ich habe Journalismus* studiert und nicht Informatik (oder Ähnliches).
Aber für den Markt
Ich bin kein Journalist (obwohl mein Abschluss das besagt). Ich bin kein Designer (obwohl ich jahrelang Zeitungen und Zeitschriften gestaltet habe). Ich bin kein 'HTML- und CSS'-Mensch (obwohl ich vieles ohne eine Prise Javascript gemacht habe). Ich bin kein Programmierer (obwohl ich heutzutage hauptsächlich Javascript schreibe).
Ich muss jedes Produkt, das ich anfasse, layouten, gestalten, strukturieren und programmieren, und jetzt lerne ich Backend-Entwicklung (gegen das, was Sie über Full-Stack sagten, der vom Programmieren zum Design kommt. Ich gehe den umgekehrten Weg).
Es ist wirklich schwierig zu wissen, was ich in meinen Lebenslauf schreiben soll.
(das klingt seltsam, Englisch ist nicht meine Muttersprache)
Eine der Bildunterschriften erwähnte: „Ist das Gehalt für diese Fähigkeiten dasselbe?“ Der Rest des Artikels ging darauf überhaupt nicht ein. Ich bin sehr neugierig auf Ihre detaillierteren Gedanken zu dieser Angelegenheit.
Ich selbst und meine Karriereausrichtung steckten mitten in dieser Kluft fest, als ich Anfang 2017 meine Stelle verlor. Ich bewarb mich auf FED-Positionen, deren Beschreibung dem entsprach, was ich zu wollen glaubte. In den Vorstellungsgesprächen oder Tests ging es dann aber nur um JS-Frameworks, Node und andere Dinge, in die ich wirklich wenig Lust hatte, mich zu vertiefen.
Da ich diese „Kluft“ online wachsen und in Podcasts gehört habe, hat sie mich dazu gebracht, darüber nachzudenken, wer ich als Entwickler bin, damit ich wirklich mit Menschen darüber sprechen kann, was ich tue und WARUM es mir gefällt.
Ich war das Kind, und ich bin der Erwachsene, der es LIEBT, Legos zu bauen, aber eines der Dinge, die ich an Legos mag, ist, den Anweisungen zu folgen. Ich erschaffe etwas, aber ich musste es nicht entwerfen. Das sagte mir, dass ich wusste, dass ich gerne erschaffe, aber nicht immer entwerfe. Ich nehme sehr selten einen Haufen Legos und baue einfach etwas Zufälliges. Ich habe diese Veranlagung nicht.
Was ich an meiner Kreativität jedoch liebe, ist die Zusammenarbeit und Problemlösung. Ich mag die Aufgabe, mit einem Team von Leuten zusammenzuarbeiten, die das Beste für das anstehende Problem schaffen wollen. Jeder von uns hat seine Fähigkeiten, aber wir wissen auch, dass die Zusammenarbeit ein besseres Produkt hervorbringt, als nur einen Designer in einen Raum zu stecken.
Auf der JS-Seite der Dinge kämpfe ich. Das ist einfach meine ehrliche Meinung. Ich habe hart gearbeitet, um dorthin zu gelangen, wo ich jetzt bin. Ich weiß, dass ich noch so viel vor mir habe und mich aktiv dazu zwingen muss, dorthin zu gelangen, weil es mich nicht sehr antreibt. Allerdings ist JS wichtiger geworden als vor 15 Jahren, als ich tabellenbasierte Layouts erstellte. Also weiß ich, dass ich mich reinknien, mich unwohl fühlen und einen Weg finden muss, um zu lernen, zu verstehen und zu wachsen.
Ich komme aus Brasilien und habe in kleinen Unternehmen (ca. 10 Leute im Entwicklungsbereich) gearbeitet, hier ist meine Erfahrung
In meinem Fall mache ich alles. Vom Wireframing über das Layout, ein bisschen UX bis hin zur eigentlichen HTML-, CSS-, JavaScript- und Vue-Implementierung (derzeit lerne ich React, Redux und React Native).
Ich empfinde jedoch eine große Erleichterung, wenn ein UX-Designer den Layout-Teil übernimmt. Er nimmt mir diese Last von den Schultern, weil ich weiß, dass ich darin nicht gut bin. Die Layouts, die ich mache, sind „gerade noch in Ordnung“. Dieser UX-Mensch muss HTML und CSS nicht schreiben, denn ich bin sehr gut darin und schreibe es gerne.
Und dieser UX-Typ? Er ist auch für die Content-Erstellung für soziale Medien und manchmal sogar für die Anzeigen dafür verantwortlich!
Zumindest in kleinen Unternehmen hier in Brasilien verschmelzen diese Funktionen zu einer Jobbezeichnung, weil die Leute wirklich alles machen. Zugegeben, sie sind nicht in jedem Aspekt perfekt, aber in der Regel sind sie in einem ziemlich gut und in den anderen in Ordnung.
Obwohl ich dem Artikel zustimme, verwenden wir letztendlich die Begriffe „Front-End Designer“ und „Javascript Engineer“.
Das Problem ist der massive Zustrom von JavaScript-Entwicklern, die den Titel Frontend erhalten. Jemand braucht einen neuen Titel. Vielleicht sollten JS-Leute JavaScript-Entwickler genannt werden? Oder sollten HTML/CSS-Leute UI-Entwickler genannt werden?
Großartiger Beitrag, Chris, du hast die wichtigsten Punkte der letzten Jahre wirklich gut zusammengefasst. Ich würde auch einen Gruß an Rachel Manning für ihre jüngsten Gedanken zu diesem Thema (und großartigen Grafiken!) einbeziehen: https://blog.prototypr.io/dissecting-front-end-job-titles-7f72a0ef0bc5
Ich habe eine mögliche Lösung für das Problem mit den Stellenbezeichnungen/Stellenausschreibungen angeboten: https://twitter.com/withinsight/status/1086271812835729408
Könnten wir die Leute, die sich speziell auf React, Vue, GraphQL, Styled-Components, Node.js usw. spezialisieren, mit Nebenfächern wie CSS/SCSS, HTML, Interaction Design, SVG, WP Theming usw., einfach Front-End Developers nennen? Und diejenigen, die sich auf CSS/SCSS, HTML, Interaction Design, SVG, WP Theming usw. spezialisieren und Nebenfächer wie JS-Bibliotheken, Node.js usw. haben, Front-End Designers? Das scheint auszureichen und wir können den Tag beenden.
Wow, ich denke, das war eine der besten Lektüren zu diesem Thema. Als jemand, der vom Webdesigner zum Webentwickler, zum UX-Ingenieur, zum UI-Entwickler, zum Senior Front-End-Entwickler gewechselt ist und Interaktionsdesign studiert, hat dieser Artikel in mir so viele Gefühle ausgelöst. Ich habe brillante Front-End-Entwickler getroffen, die CSS-Grundlagen wie Spezifität nicht verstanden, und ich bin jetzt an einem Punkt, an dem ich denke, dass das völlig in Ordnung ist. Was jedoch NICHT in Ordnung ist, ist, dass derjenige, der CSS-Spezifität versteht und eine gut wartbare UI-Architektur aufbauen kann, als Junior-Front-End-Entwickler angesehen wird. Ich schätze, wir müssen akzeptieren, dass ‚Front-End‘ immer komplexer wird, was nicht negativ ist, aber es bedeutet, dass wir nicht jedes Thema sehr gut verfolgen können, was zu spezialisierteren Rollen führt. Ich denke, ein Problem ist, dass Unternehmen oder CTOs oft nicht genug Verständnis für die Detailanforderungen des tatsächlichen Jobs haben, so dass sie nur nach einem Front-End-Entwickler suchen, der alles kann. Aber billig.
So viel dazu zu sagen!
Gut geschrieben, aber ich denke, Sie umkreisen die Antwort, ohne darauf einzugehen.
Zunächst ist der Vergleich eines Titels wie „Front-End-Entwickler“ mit „JavaScript-Entwickler“ Teil des Missverständnisses. Sie vergleichen ein Ziel/eine Domäne mit einer Sprache. JavaScript ist nur ein Werkzeug, um beispielsweise dynamische Websites zu erstellen.
Aber es ermöglicht viel mehr.
Wenn ich einen Begriff wählen müsste, und ich meine es nicht negativ, auch wenn es für manche eine negative Konnotation haben mag, würde ich stattdessen „Front-End-Entwickler“ dem „Web-Integrator“ gegenüberstellen.
Für mich ist ein Front-End-Entwickler genau das, was in der CodePen-Stellenanzeige beschrieben wird
„Sie haben an mittelgroßen bis großen Webanwendungen gearbeitet, die in JavaScript geschrieben sind. Sie setzen Unit-Tests ein. Sie sind kompetent in HTML, CSS und Design.“
Während ein Web-Integrator eher dem ähnelt
„Übersetzen Sie ein Photoshop-Layout in eine pixelgenaue Website.“
Dies liegt auch teilweise daran, dass eine Website heutzutage meistens eine Webanwendung ist, daher benötigt sie eine Programmiersprache und nicht „nur“ HTML/CSS (auch das ist nicht negativ). Ich denke, die meisten JavaScript-Entwickler würden enorm profitieren, wenn sie gut in HTML/CSS wären, und dasselbe gilt für Web-Integratoren.
Was einen FullStack-Entwickler angeht, so gibt es sie einfach nicht.
Es scheint, als würde die Komplikation daher rühren, Designer als Entwickler zu bezeichnen.
Guter Punkt… Ich habe mich dazu entschieden, mich selbst einen Front-End-Designer zu nennen. Ich denke, das passt besser zu meinem Fachgebiet.
Großartiger Artikel, Chris! Du hast in Worte gefasst, was ich seit 2011, als ich einen Job als Programmierer für nicht-responsive Websites in reinem HTML & CSS annahm, beobachtet habe.
Kürzlich musste ich zum ersten Mal seit 8 Jahren auf Jobsuche gehen. Ich betrachte mich als CSS- und HTML-Experte, bin aber auf so viele Stellenanzeigen für „Front-End-Entwickler“ gestoßen, die nicht einmal HTML oder CSS erwähnen! Sie alle wollen, dass man React, oder Angular, oder Vue kennt, erwähnen aber keine CSS-Formatierungstechniken, Barrierefreiheit, semantisches HTML, UX… Das kann super frustrierend sein.
Als jemand, der hauptsächlich an Websites für gemeinnützige Organisationen und kleine Unternehmen gearbeitet hat, gab es nie einen Bedarf für mich, eines dieser JavaScript-Frameworks zu lernen, da diese auf Web-Apps ausgerichtet sind. Die durchschnittliche Website muss keine Web-App sein.
Ich finde selbst den Begriff „Web-App“ etwas seltsam und verwirrend, was angesichts des Inhalts des Artikels passend ist.
JavaScript-Entwickler rühmen sich immer damit, schnell und effizient eine „Single-Page Web-App“ erstellen zu können, und in vielen Fällen stimmt das auch. Aber kurz gesagt, eine „Web-App“ kann auch einfach eine Website sein, die ein paar Favicons hinzugefügt hat und eine manifest.json-Datei eingerichtet ist (was selbst nur ein Dutzend Zeilen sind, die leicht einmal generiert und auf einer Reihe von Websites wiederverwendet werden können, indem man ein paar Variablen manuell aktualisiert). Diese App (die eigentlich nur eine Website ist) wird auf dem Smartphone oder Tablet des Benutzers gespeichert und ist verfügbar, wenn dieser eine Internetverbindung hat.
Eine „Web-App“ hat eigentlich nichts damit zu tun, eine „Single-Page“-App zu sein (was wiederum nur eine Single-Page-Website ist) – das sind eigenständige Dinge.
Ein Vorteil von JavaScript ist, dass man etwas namens „Service Worker“ erstellen kann, das es ermöglicht, Dateien lokal zu speichern, so dass ein Benutzer die Website auch dann nutzen kann, wenn er nicht mit dem Internet verbunden ist. Darüber hinaus bedeutet eine One-Page-Website, dass verschiedene „Zustände“ (die als analog zu verschiedenen Seiten oder Seiten mit unterschiedlichem Inhalt angesehen werden können) nicht durch das Aufrufen einer neuen Seite über einen Link (zum Beispiel) erzeugt werden, sondern einfach durch das Laden neuer Inhalte in die vorhandene Seite über JavaScript und das Speichern dieser Inhalte als „Zustand“, so dass ein Benutzer zwischen Inhalten hin- und herspringen und immer wissen kann, wo er sich befindet. Da Service Worker erfordern, dass Sie explizit angeben, welche Dateien der Benutzer speichern soll, und es nicht viele verschiedene Seiten gibt, sondern eine Seite, die Inhalte je nach dem, was ein Benutzer tut, austauscht, kann dies die Entscheidung oder sogar die Automatisierung des lokalen Speicherns von Dateien erleichtern. Viele dieser Frameworks handhaben diese ganze Situation daher automatisch. Dennoch ist es nicht zwingend erforderlich, eine Web-App zu erstellen – man kann es auch manuell tun.
Kurz gesagt, eine Web-App kann ohne JavaScript sehr einfach und sogar nachträglich erstellt werden. Und eine Web-App, die offline funktionieren kann, lässt sich mit sehr einfachen Plugins erstellen, deren Implementierung nur grundlegendes Wissen erfordert.
Die Verwendung von Frameworks zur Erstellung von Web-Apps kann die Konfiguration dieses Prozesses erheblich vereinfachen, indem vieles davon automatisiert wird und ein Großteil des „State-Managements“ übernommen wird (für riesige Projekte mit einer wirklich komplexen Codebasis und Dutzenden von gleichzeitig arbeitenden Personen ist ein festes System, das alle dazu zwingt, im gleichen Stil zu schreiben, hilfreich, und die Verwaltung des Projektstatus – der groß genug sein kann, dass niemand die gesamte Sache bearbeitet – kann die Website wiederum besser handhabbar machen), aber letztendlich, wenn die Komplexität der Einrichtung eines solchen Systems größer ist als die Komplexität der Verwaltung eines solchen Systems ohne JavaScript (was in vielen Fällen zutrifft), dann sind die Leute nicht vernünftig oder effizient, indem sie Frameworks verwenden, sondern folgen eher einem „coolen Trend“.
Frameworks haben ihren Platz. Aber wie dieser Artikel andeutet, sind sie nicht die Allheilmittel. Manchmal erhöhen sie die Komplexität, anstatt sie zu reduzieren. Ein guter Programmierer – auch einer, der sich auf JavaScript spezialisiert hat – weiß nicht unbedingt nur, wie man jedes JavaScript-Framework unter der Sonne benutzt… er weiß auch, wann man keines verwenden und stattdessen reines HTML und CSS verwenden sollte.
Ich stimme zu – allein aufgrund der Stellenanzeigen könnte man meinen, dass jede Website da draußen eine Single-Page-Web-App ist, die von APIs und reaktivem Javascript angetrieben wird. Aber die meisten Unternehmen, Menschen und Organisationen brauchen einfach eine verdammte Website. Und diese Websites sollten schnell laden, zugänglich, responsiv, schön und effektiv sein – und das ist eine Aufgabe für einen Frontend-Entwickler.
Ich spüre die Identitätskrise als „Frontend-Entwickler“ sehr stark.
Kürzlich hatte ich ein deprimierendes Lachen, als ich ein Angel List-Profil erstellte und Fähigkeiten aus der vorgeschriebenen Liste auswählte. Jede Sprache, die man sich vorstellen konnte, einschließlich 3 JS-Frameworks, aber kein CSS oder HTML. Fühlt sich an wie unbeabsichtigtes „Gatekeeping“.
Ich vermute, dass, wenn HTML und CSS zur Auswahl stünden, absolut jeder sie auswählen würde, was sie (wörtlich!) sinnlos machen würde.
Das soll nicht heißen, dass sie sinnlos sind. Vielmehr deutet es auf eine massive Lücke in der Wahrnehmung dessen hin, was es bedeutet, sie zu „können“.
CSS, das ist doch, wenn man ein Stilattribut anstelle eines Tags zur Formatierung verwendet, oder? Cool, ich kann CSS. Außer ich kann es nicht.
Können wirklich alle guten CSS-Entwickler SASS? Vielleicht ist das die Antwort. SASS als Anforderung aufzuführen, würde „echte“ CSS-Entwickler von denen trennen, die nur wissen, was es ist. (Außer ich weiß nicht, ob die Prämisse richtig ist.)
Meiner Erfahrung nach (über 20 Jahre), wenn man nicht sehr gut in JavaScript ist, wird man Schwierigkeiten haben, Jobs zu finden. Tatsächlich wurden ich und ein weiterer sogenannter „CSS-Experte“ bei [großes Softwareunternehmen in Seattle] abgewertet und schließlich verdrängt.
Da JavaScript-Frameworks immer populärer wurden, haben wir gesehen, wie Backend-Geschäftslogik ins Frontend verlagert wurde, was komplexere/formellere Programmierkenntnisse in einem Bereich erforderte, der früher hauptsächlich für das Layout und die Interaktivität der Benutzeroberfläche reserviert war.
Ich fühle mich alt, nur wenn ich das lese. Ich weiß nicht warum, aber ich habe das Gefühl, dass die HTML/CSS-Seite hauptsächlich von einer älteren Generation von Frontends kommt. Die, die in der Zen-Garden-Ära angefangen haben, wie ich selbst. Und die andere Seite sind hauptsächlich die jüngeren Entwickler.
Ich fühle mich alt, weil ich mich auch erinnere, als Flash dieselbe Trennung hatte. Auf der einen Seite waren die Animatoren und auf der anderen die ActionScript-Entwickler.
Ich begann, HTML und dann CSS zu schreiben und lernte schließlich jQuery. Ich erinnere mich an die Herausforderungen, die jede dieser Technologien mit sich brachte, damit ich mich in jeder von ihnen kompetent fühlen konnte. HTML war ein Kopfzerbrechen, Tabellen, Verschachtelungen und all diese Tags auswendig lernen, OMG! Dann CSS, das Boxmodell, Floats und deren Löschen für Layouts, OMG! JavaScript, beginnend mit jQuery, nicht zu verstehen, wie man einen Wert als Funktion übergeben kann oder überhaupt irgendetwas, es war so schwer!
Es ist Jahre her, und ich denke, es braucht Jahre, um ehrlich zu sein. Diese Branche ist nicht einfach zu beherrschen, das Ziel bewegt sich ständig. Und jetzt kann ich Server schreiben, Docker-Build-Prozesse konfigurieren und wirklich Full-Stack-Anwendungen erstellen. Ich weiß nicht, ob ich einfach den schlechtesten möglichen Weg zu diesem Ziel gewählt habe. Ich weiß, dass die Leute wirklich gerne mit mir zusammenarbeiten, ich weiß auch, dass ich die UI/UX-Entwicklung liebe, und die Zusammenarbeit mit Designern ist immer noch eines meiner Lieblingsbeschäftigungen.
Ich habe mich sogar dafür eingesetzt, dass bei meinem jetzigen Arbeitgeber die Titel abgeschafft werden und alle Entwickler, ob Backend oder Frontend, einfach nur Ingenieure sind. Die ganze Zeit war mein Bestreben, einfach die bestmögliche Arbeit zu leisten, das, was mich leitete. Aber selbst mit über einem Jahrzehnt Erfahrung habe ich immer noch das Gefühl, so viel lernen zu müssen. Es ist immer noch aufregend und ich möchte immer noch das visuell flüssigste und zugänglichste Meisterwerk meines Herzenswunsches schaffen. Vielleicht werde ich das eines Tages tun.
Ich entdeckte die Frontend-Entwicklung (zumindest wurde sie so genannt), als CSS 3 auf die Bühne kam. Das war eine gute Zeit, Dinge wie Border-Radius, Verläufe und Animationen kamen in die Spezifikation.
Inzwischen befand sich das iPhone in der zweiten oder dritten Generation. Die Leute waren bereits an dieses kleine Bildschirmgerät gefesselt. Also wollten Browser oder Website-Hersteller ihren Anteil an der Bildschirmzeit der Leute haben. Daher wurden Browser leistungsfähiger. Mit dieser Leistung hatten sie nun mehr Raum, JavaScript zu kompensieren. Ein eher komplexes JavaScript und der Rest wird von Chris in diesem Artikel gut beschrieben.
Obwohl dieser Artikel über Frontend-Entwickler handelt, hat diese Verschiebung auch Backend-Entwickler betroffen?
Halleluja!
Die Notwendigkeit, das Frontend in drei überlappende Bereiche aufzuteilen, ist seit Jahren eine Tatsache.
Die Frontend-Ingenieure, Entwickler und Designer konzentrieren sich auf JS, Markup/CSS bzw. Design/UX, wobei ein Schwerpunkt auf einem dieser Bereiche liegt und das Wissen in die anderen Bereiche überfließt.
Die komplette Sammlung ist ein seltenes Tier, das sich Full-Stack-Front-End-Entwickler nennt. Ganz zu schweigen vom mythologischen Full-Stack-Entwickler, obwohl es sie gibt, aber sie wollen meist in Ruhe gelassen werden und sich auf jeweils einen Schwerpunkt konzentrieren.
Stellenbeschreibungen, die „Full-Stack-Entwickler“ enthalten, bedeuten normalerweise, dass das Unternehmen entweder nach einem unterbezahlten Wunderheiler sucht oder seine eigenen Bedürfnisse nicht kennt, was eine Chance sein kann… Oder ein Alptraum.
Oh, was für eine wundervolle Welt wir weben
Als ehemaliger (!) Full-Stack-Entwickler (vor etwa 10 Jahren, als es nur Webentwickler gab, keine Backend-, Frontend- usw. Rollen), der zu einem primär Frontend-Entwickler wechselte und jetzt darum kämpft, mit dem fast jährlichen Ansturm neuer JS-Bibliotheken und Frameworks Schritt zu halten, und erneut vor einer Karriereentscheidung steht (JS-Entwickler werden oder sich als UI/UX-Entwickler niederlassen), da die „große Kluft“ immer deutlicher wird, spricht dieser Artikel zutiefst mit dem, was ich auch schon seit einiger Zeit empfinde. Ich bin so froh, dass ich in diesem Dilemma nicht allein bin.
Ich habe schon eine Weile versucht, diese Kluft zu benennen, und dieser Beitrag hat es ziemlich gut zusammengefasst.
Ich habe vor nicht allzu langer Zeit tatsächlich eine Stellenbeschreibung für eine Front-End-Rolle gesehen, die einen „HTML- & CSS-Experten“ suchte, der dann die Bedeutung dieser Rolle in ihrem Unternehmen im Zusammenhang mit der Aufrechterhaltung der Dokumentstruktur, Benennungskonventionen, BEM, Codeoptimierung/-debugging, UX usw. beschrieb. Ich dachte mir: „Was für ein Traumjob!“.
Leider scheint es so zu sein, dass die meisten Unternehmen Front-End-Entwickler mit Erfahrung in Angular, React oder Vue bevorzugen und diese Kandidaten wiederum höhere Gehälter erhalten.
Wow wow wow! Vielen Dank Chris für diese Diskussion. Ich bin wirklich froh, sie gefunden und gelesen zu haben. Nach dem Lesen dieses Artikels habe ich eine große Erleichterung von Frustration und Angst gespürt. Ich war schon immer ein Fan der Front-End-Entwicklung, aber es wird für mich immer schwieriger, einen anderen Job mit dem Titel „Front-End-Entwickler“ zu finden. Ich mache diese Arbeit seit über einem Jahrzehnt und betrachtete mich wirklich als „Profi“. Es degradiert einen wirklich, wenn man zum zweiten Vorstellungsgespräch für einen „Front-End-Entwickler“ geht und eine Aufgabe bekommt, die Dinge wie „Websockets“ zum Verbinden mit einem „Echo-Server“ enthält, um all diese Daten abzurufen und dynamische Inhalte zu rendern, während man das gesamte Layout innerhalb weniger Stunden erstellt. Nicht, dass ich es nicht könnte, aber ich persönlich betrachte dies eher als „Back-End“-bezogene Arbeit. Ich war so frustriert, dass ich einfach meinen Laptop zuklappte und das Gebäude verließ. Ich denke, dieser Artikel sollte verbreitet werden, und das werde ich tun, wenn ich nächste Woche meinen Artikel veröffentliche. Vielen Dank!
Ich stimme zu, dass wir Fachleute brauchen, die in allen Bereichen qualitativ hochwertige Arbeit leisten können, um großartige Websites zu erstellen – dass wir keine schlechten bauen sollten… aber wie?
Im Allgemeinen werden Unternehmen nicht dazu angeregt, großartige Websites zu erstellen, wenn eine schlechte ausreicht – und mit schlecht meine ich nicht eine, die schlecht gestaltet und ausgeführt ist, sondern eine, der es an Barrierefreiheit mangelt, die minderwertiges HTML verwendet, CSS dupliziert und missbraucht und vielleicht kilometerweit Sicherheitslücken aufweist.
Ich habe eine ganze Reihe von DotNetRocks-Podcasts gehört, und sie erwähnen ziemlich regelmäßig ihre Überzeugung, dass eine professionelle Zertifizierungsorganisation, ähnlich der in anderen Berufen, für die Softwareentwicklungsbranche notwendig ist. Es gibt eine Episode mit Uncle Bob von vor einigen Jahren, die dies detailliert untersucht und das healthcare.gov-Fiasko von Obamacare als ein enormes Beispiel dafür hervorhebt, warum Software-Qualitätsstandards benötigt werden.
Ich bin mir nicht sicher, ob diese Art der Zertifizierung die Antwort ist… und ich bin Autodidakt, daher sträube ich mich etwas gegen die Idee, da ich Bedenken habe, wie sich dies auf Hobbyisten und diejenigen auswirken würde, die an Nebenprojekten arbeiten… aber mein Punkt ist, dass Unternehmen (ohne einen kulturellen Wandel weit über die Webbranche hinaus) (im Allgemeinen) nicht das Geld ausgeben werden, um ein gutes/großartiges Produkt zu erstellen, wenn ein schlechtes/akzeptables Projekt akzeptable Gewinnspannen liefert.
(meiner Meinung nach gibt es in vielen Fällen einen erheblichen ROI, der durch die Investition in ein besseres Produkt erzielt werden kann – aber ein großer Prozentsatz der Unternehmen scheint dieses Potenzial nicht zu erkennen… es ist häufig ein Kampf, eine Organisation davon zu überzeugen, dass eine bestimmte Änderung sich auszahlt)
Ich schweife ab…
Sehr schöner Artikel! Ich erinnere mich, als ich als Anfänger in der Frontend-Entwicklung HTML- und CSS-Arbeiten für ein Startup erledigte, fragte mich ein Senior: „Wann lernst du JavaScript? Willst du nicht in bessere IT-Firmen?“ Ich war verwirrt von seiner Aussage und begann mich sogar zu schämen, kein JavaScript zu können. Heute habe ich genug JavaScript für DOM-Manipulation und -Traversierung gelernt. Ziemlich lustig übrigens! :)
Ich bin ein Neuling in all dem, Autodidakt, und meine Leidenschaft sind HTML und CSS. Ich habe mich jetzt seit etwa 5 Jahren damit beschäftigt und nach etwa 3 Jahren wurde mir klar, dass ich mehr als die Grundlagen von JavaScript lernen musste… ich spreche von reinem JavaScript, kein React oder ähnliches… Als ich beschloss, Websites bauen zu wollen, war mein Ziel, ein Front-End-Entwickler zu werden – so wie ich es als HTML, CSS und grundlegendes JavaScript verstand. Natürlich, je weiter ich in diese Welt eintauche (und ich bin verliebt in diese Welt, Baby), desto verwirrter bin ich. Jetzt nenne ich mich Front-End-Designer. Immer noch nicht sicher, wie ich mich vermarkten soll und überhaupt nicht selbstbewusst genug, um mich für Front-End-Entwickler-Jobs zu bewerben. Außerhalb von Frameworks möchte ich eigentlich kein Full-Stack-Entwickler sein. Das ist viel zu viel für mein kleines Gehirn. Ich sage das alles, weil es gut ist, diese Themen in den Vordergrund gerückt zu sehen. Es bedeutet, dass sie angegangen werden und dass Veränderungen angenommen werden sollten. Ich glaube, es gibt Raum für uns alle und wir alle haben eine Rolle zu spielen. Die Branche verändert sich ständig, und zwar schnell, und es ist an der Zeit, die Rollen und die Art und Weise, wie wir alle die leistungsstarken neuen Tools nutzen, die entwickelt werden, neu zu bewerten. Dieser Artikel gibt mir Hoffnung. Ich glaube, ich bin endlich im richtigen Beruf. Und ich sehe einen Platz für mich… Das ist eine gute Sache!
Ich glaube und hoffe, es wird viel einfacher. Die nahe Zukunft wird das Frontend im guten Sinne dumm machen. Javascript im Frontend wird lediglich eine Reflexion von Daten sein, die von einem Backend von Microservices gesteuert werden, die von einer Zwischenschicht orchestriert werden. Ich sehe keine Rolle für Frontend-Leute, die nur HTML und CSS können, man muss mehr mitbringen.
Ich mache das seit 2001, als wir noch kein CSS hatten und JS nur zur Validierung von Formularen verwendet wurde. Ich will kein falsches Gefühl von Seniorität erzeugen, ich sage nur: Ich habe mehrere Änderungen von Jobtiteln und Erwartungen durchgemacht.
2001-2005: Webentwickler. Ich habe klassisches ASP (Visual Basic 6.0), XML, XSLT, JavaScript, MsSQL, Serverwartung, DNS, CI/CD, Backups, E-Mail gemacht. Im Grunde alles. Heute würde man das einen „Full Stack Engineer“ nennen.
2005-2011: Front-End-Entwickler. Ich spezialisierte mich auf das Frontend, weil CSS da war, und ich liebte ehrlich gesagt die riesigen Unterschiede zwischen den Browsern. Ich war sehr gut darin. Javascript war im Grunde nur jQuery, um Modalfenster anzuzeigen. Ich schrieb HTML in Templates, die von serverseitigem Code (Java, .Net, Ruby) weitergereicht wurden.
2011-2015: Frontend-Ingenieur. Die ersten größeren Frontend-Frameworks traten in Erscheinung. Ich hatte vergessen, wie man sich bezüglich des Schreibens von gutem Code auf dem Laufenden hält, also musste ich es neu lernen. Ich benutzte Backbone JS, Ember JS und einige andere. Im Grunde war ich gut in HTML, CSS und – mit der Zeit – auch in Javascript.
2015-heute: Frontend-Ingenieur, immer noch, nur mit neueren Spielzeugen. Aber ehrlich gesagt, ich sehe TypeScript aufkommen und sein ROI ist entsetzlich, außer dass alle Backend-Entwickler, die in die Frontend-Welt eindringen (danke Angular), sehr unwohl sind, ihren Code nicht stark zu typisieren. Also schlägt TypeScript große Wellen, und ich hasse es.
Zukunft: Ich hoffe, dass ich mit React oder Vue.js einen starken Fokus auf die Benutzererfahrung in einem relativ „dummen“ Frontend legen kann. Lassen Sie mich die Benutzeroberfläche und die Komponenten schreiben, sie mit dem Browser verbinden, responsiv machen, internationalisieren (i18n), Barrierefreiheit (a11y) hinzufügen, Semantik wertschätzen und SEO bearbeiten.
Und ja, das bedeutet, dass ich weiß, wie man ein FizzBuzz schreibt. JS-Array-Funktionen und ES6-Erweiterungen und all der Kram: Ich glaube nicht, dass jemand in diesem Bereich mehr ohne all das auskommt. Auf dem Laufenden zu bleiben ist keine Option, es ist Pflicht, und dieses Arbeitsfeld ändert sich SCHNELL.
Wenn du HTML und CSS magst, aber kein Javascript lernen willst: Bitte, um alles in der Welt, verfeinere deine UX- oder UI-Designer-Talente, wenn du welche hast, und mach das. Die Welt hat nicht genug von Leuten, die wissen, was sie nicht wissen.
Vielleicht ist die große Kluft nur eine natürliche Folge der Tatsache, dass qualitative Fähigkeiten Zeit und Mühe erfordern und es keinen praktischen Weg gibt, in allem großartig zu sein. Erinnern wir uns daran, dass großartige UI-Fähigkeiten nutzlos sind, es sei denn, sie implementieren eine großartige Lösung. Diese binäre Klassifizierung wird sicherlich noch fragmentierter werden, wenn in naher Zukunft eine neue UI-Technologie entwickelt wird, um komplexere reale Probleme zu lösen. Vorerst benötigen Unternehmen beide Arten von UI-Entwicklern und müssen sie dazu zwingen, miteinander zu sprechen, oder riskieren, suboptimale Lösungen zu schaffen.
Wirklich schöner Artikel!
Ich glaube, eines der Probleme, die dazu führten, ist, dass einige Leute CSS und HTML als Programmierung betrachteten, was es streng genommen nicht ist.
So wurden Leute, die hauptsächlich CSS und HTML machten, „Front-End-Entwickler“ genannt, was eigentlich eine Fehlbezeichnung war.
Nun, ich versuche nicht, ihre Arbeit zu schmälern, aber ich denke, es ist ein leicht verwirrender Titel, wenn man hauptsächlich in CSS und HTML arbeitet.
Ich denke, es sollte vielleicht eine Art „Front-End-Design/UX“-Rolle geben, die für Dinge wie Markup, CSS, A11y, UX usw. zuständig ist.
Grundsätzlich denke ich, dass „Front-End-Entwickler“ sich mehr in Richtung Backend erweitern sollten, und dass „Front-End-CSS/HTML“-Leute sich mehr in Richtung Designer/AD/UX-Rolle erweitern sollten.
Alle drei Rollen (Backend, Frontend, Design/UX) müssen ihre Verantwortlichkeiten/Fähigkeiten erweitern, um effektiver zusammenzuarbeiten.
Ich bin sicher, viele Leute sind anderer Meinung, aber das ist nur meine Überlegung. Ich sage nicht, dass es die einzige und wahre Wahrheit ist.
Wir alle arbeiten zusammen, um ein Produkt zu erstellen, all diese Rollen werden benötigt.
Ich sehe eine andere Kluft
Seite 1: Menschen, die sich in einem Aspekt der (Web-)Entwicklung auszeichnen/spezialisieren und immer im Team arbeiten: CSS / HTML / UX-Design / Frontend-Codierung / Backend-Codierung / Datenbankdesign / DBA / API-Programmierung / Projektmanagement / Anforderungsdefinition / System-Engineering / Testen / Schulung / Support-Desk / DevOps.
Seite 2: Menschen, die (fast) alles selbst machen und nicht von Teammitgliedern abhängig sind
Die Unternehmensstruktur und die Erfahrung einer Person bestimmen, ob man in Seite 1 oder 2 ist.
Schöner langer Artikel. Habe vergessen zu erwähnen, dass React/Angular/etc. von US-Regierungsbehörden und einigen ausländischen Staaten zur Verkehrsanalyse verwendet werden. Die Illusion, dass das Marketing dieser Technologien eine kontinuierliche Verbesserung der Software bewirken wird, wird verschwinden, sobald die neue Generation von Technologen eintrifft. Computer laufen aufgrund schlecht vorbereiteter Entwickler fast mit den gleichen Geschwindigkeiten wie vor 10 Jahren. Denken Sie darüber nach! Lassen Sie sich nicht vom Medienrummel und alten Narrativen Ihre Zukunft vernebeln!
Wow. Das war ein erstaunlicher Beitrag.
Ich befinde mich in der Nische des „Full-Stack-Designers“. Eine Position, die ich nach 8 Jahren Sklaverei „erstell dieses .gif-Banner“, „wir brauchen einen Flyer“, „gestalte diese Landingpage“, „schreib diesen Inhalt“, „wir brauchen eine Lightbox in dieser Galerie“, „wir brauchen ein benutzerdefiniertes WordPress-Template“, „kannst du eine Joomla-Website einrichten?“ … einnehmen musste.
So finde ich mich mit Kenntnissen in „grafischen Tools“ und Codierung (sogar fortgeschrittenen hybriden Sprachen wie Twig und ähnlichen) wieder.
Meine wahre Liebe war und ist immer alles, was mit HTML und CSS zu tun hat (mit einem Spritzer jQuery), und ich denke demütig, dass ich sauberen, schlanken, schönen, kohärenten und gut kommentierten Code schreibe. Während ich ringsum HORROR-Code sehe, besonders von Leuten/Apps, die versuchen, die Notwendigkeit von Frontend-Entwicklern zu zerstören (Adobe Muse, Squarespace, Wix’s Code lässt mir vor Angst die Haut krabbeln).
Offensichtlich musste ich mich mit diesen Sprachen auseinandersetzen, ich habe LESS und SASS gelernt, ich kenne etwas Vanilla JavaScript, ich musste ein paar Grundlagen von PHP lernen und ich weiß auch, wie man sich in einer Datenbank zurechtfindet. Verdammt, ich musste sogar Webpack und Gulp lernen, um mit einigen der neuen Open-CMS-Theming-Kits zu arbeiten.
Aber ich habe den Begriff „Front-End“ immer mit dem „Gesicht“ eines Projekts assoziiert, daher bin ich verwirrt, wenn ich Stellenanzeigen für „Front-End-Entwickler“ sehe, die React, Angular oder Vue kennen sollten. Warum um alles in der Welt sollte ich diese kennen? Was haben die mit Frontend zu tun…?
Ich hatte ein paar Vorstellungsgespräche bei einem großen Unternehmen in Amsterdam, das einen Front-End-Entwickler suchte. Alles lief gut, ich wurde abgelehnt, weil ich keine Fähigkeiten in „Big Data Analysis“ hatte. Was hat das mit Frontend zu tun?…
Ich denke, die Kluft ist erschreckend groß geworden und es gibt einen dringenden Bedarf an einer neuen, spezifischen Figur, um diese JavaScript-Schwerarbeiter zu gruppieren. Ich weiß nicht, „Logik-Entwickler“, ich fange an zu befürchten, dass unsere „Seniorität“ als Front-End-Entwickler erheblich leiden könnte.
Zu fragen, ob jemand JS, HTML oder CSS beherrscht, ist wie zu fragen, ob ein Koch ein Messer, einen Ofen oder einen Spatel benutzen kann. Solange Personalvermittler „nur eine Webseite“ wollen, können sie jeden Front-End-Entwickler einstellen, den sie wollen, und sie bekommen einen. Wenn sie mehr als „nur eine Webseite“ wollen, sollten sie genauer sein, was sie wollen.
Hallo, ich habe den Artikel sehr gut gelesen.
In verschiedenen Vorstellungsgesprächen habe ich festgestellt, dass jedes Unternehmen den Teil des Frontends sehr unterschiedlich interpretiert. Darüber habe ich nachgedacht.
Darf ich diesen Artikel in meinem Blog ins Koreanische übersetzen? Das wird vielen koreanischen Frontend-Engines, einschließlich mir, sehr helfen. Ich werde auf jeden Fall eine Referenz hinzufügen.
Ich habe Ende letzten Jahres einen ähnlichen (aber viel kürzeren und weniger recherchierten) Blogbeitrag geschrieben.
https://opc.com.au/blog/no-longer-just-developer
Ich arbeite derzeit an einer kleinen Regierungswebsite mit etwa 30 Seiten und 20 Dokumenten.
Und alles läuft über Docker, Container, Lagoon, speziell angefertigte Admin-Interfaces, benutzerdefinierte Distribution…
Ehrlich gesagt, könnte dieses Ding statisches HTML sein, das auf einem smarten Kühlschrank gehostet wird, aber nein… wir müssen Komplexität hinzufügen, um Komplexität zu reduzieren.
Chris, du hast es mit diesem Artikel wirklich geschafft. Großartiger, fantastischer Artikel. Gültiger Punkt, gut formuliert und stilvoll erzählt. Der Artikel, der für den Abschnitt „JavaScript Don Got Big“ ROT wird, ist großartiges Storytelling. Die Zitate bringen die Geschichte auf den Punkt. Chris, deine Persönlichkeit und dein Herz strahlen hier wirklich. Mach weiter so!
DANKE!
Ich arbeite an einer Website mit über 150.000 Seiten. Wir haben mehr als 1 Million Nutzer und 3,5 Millionen Seitenaufrufe pro Monat. Unser Team besteht aus 9 Personen, darunter ein Vorgesetzter und ein engagierter Designer. Unsere Website muss sowohl responsiv als auch zugänglich sein.
Wir haben kein CMS und brauchen eigentlich auch keins. Unsere Seiten sind HTML/CSS mit etwas PHP. Zum größten Teil laden sie schnell.
Wir verwenden das Foundation-Framework mit SASS.
Ich muss Ihnen sagen, dass der schmerzhafteste Teil bei der Entwicklung dieser Website die Einrichtung des Entwicklungs-Stacks für das Framework war. Ursprünglich war es SASS/HTML/JQuery. Dann war die nächste Hauptversion Node, Bower, Mustache, Grunt. Jetzt, innerhalb derselben Version, gibt es kein Bower mehr, keinen Hinweis auf Mustache (was sollte das überhaupt?), und Gulp statt Grunt.
Nur vier von uns nutzen das alles, und eigentlich brauchen wir nur SASS zu kompilieren und CSS und Javascript zu minimieren. Doch jedes Mal, wenn wir das Framework aktualisieren wollen, müssen wir uns in das Kaninchenloch eines völlig neuen Entwicklungs-Stacks begeben. Das ist lächerlich.
Ich sage nicht, dass es keine Situationen gibt, in denen man all das braucht, aber ich schätze, dass viele Websites komplexe Entwicklungs-Stacks verwenden, die das wirklich nicht brauchen.
Als eher Backend-Entwickler mit JavaScript-Kenntnissen finde ich es entsetzlich, wie das Frontend heutzutage gemacht wird. Ein Großteil der Arbeit kann mit HTML/CSS und ein wenig JS erledigt werden. Alles ist einfach übermäßig kompliziert, ohne wirklichen Grund. Ich bin wirklich begeistert von der Eleganz des Basecamp-Modells von Web-Apps, bei dem HTML-Snippets/Seiten die Arbeit erledigen. Supersimple und es bietet viele Vorteile eines JS-Frontends für einen Bruchteil der Arbeit. Sie können es sogar für mobile Apps nutzen, was mich wirklich überrascht hat.
Ich habe mit Intercooler.js für ein Projekt, an dem ich arbeite, herumgespielt und bin sehr zufrieden, wie einfach es ist. Es zwingt einen zwar, etwas anders über das Schreiben einer Web-App nachzudenken, aber sobald man den Dreh raus hat, ist es ziemlich unkompliziert.
Mir ist aufgefallen, wie komplex die Geschäfts-Apps sind, die wir bei der Arbeit erstellen, obwohl es sich eigentlich nur um eine Seite mit vielen Formularen handelt, und doch verwenden wir oft nicht einmal ein Formular!
Hier gibt es viel zu sagen und zu besprechen. Es ist großartig, dass wunderbare Leute wie Chris in der Lage sind, mehrere Seiten solcher Themen mit Mitgefühl zu teilen.
Ich denke an „Front-End“ wie an „Sportler“. Das ist alles. Okay, vielleicht eher wie „Footballspieler“ (Fußball oder American Football, Sie wählen). Wir können uns alle vorstellen, dass ein Football-Quarterback ganz andere Fähigkeiten hat als ein Kicker.
Wenn ein Sportteam sagt: „Wir brauchen noch einen Footballspieler“, ist das offensichtlich nicht spezifisch genug. Wenn sie sagen: „Du musst Touchdowns werfen, Field Goals treten und den Ball fangen, als wären deine Hände Klettverschluss UND das im Rollstuhl“, dann hat ihr Recruiter oder Einstellungsmanager ein paar zu viele Gehirnerschütterungen erlitten. (Denn wenn man im Rollstuhl sitzt, hat man schon viel mehr Fähigkeiten als die meisten Leute, die ich kenne!)
Ich hoffe, dass Spieler A Spieler B nicht respektlos behandeln wird, da sie unterschiedliche Positionen im Team spielen. Andernfalls sprechen wir über ein Respekt- und/oder Reifeproblem, nicht über ein Technik- oder Kategorieproblem. Dasselbe gilt meiner Meinung nach für jeden, der diejenigen herabwürdigt, die sich auf HTML & CSS konzentrieren. Respekt & Reife.
Bei Jobs müssen sie einfach spezifisch und ehrlich sein. Für Jobsuchende gilt: Wenn eine Stellenbeschreibung nicht klar ist und dieser unschöne Moment während eines Vorstellungsgesprächs auftaucht, ist das eine Lernerfahrung für Sie (und Sie können die Firma dafür verantwortlich machen, dass sie nicht klar war oder übertrieben hat), so unangenehm es auch sein mag. Das ist der harte Teil, der nicht immer vermeidbar ist.
Ich glaube, es wäre alles reibungslos, wenn wir anfingen, Begriffe wie Front-End-Designer und Front-End-Ingenieur zu verwenden. Ich persönlich definiere mich als Ersteres, finde aber leider meistens keine passenden Jobs.
Die Kluft ist ein Mythos. Effektive Frontend-Entwicklung erfordert die Identifizierung des Ziels und die fallweise Priorisierung der damit verbundenen Aufgaben. Wenn ein Design angepasst werden muss, ist das Ihr Ziel. Wenn nicht (Sie schreiben beispielsweise ein JS-Dienstprogramm), dann hat die JavaScript-Qualität Priorität.
Die Identitätskrise rührt aus der Erkenntnis her, dass man entweder seine JS- oder seine Beobachtungsfähigkeiten verbessern muss. Nichts ist verloren, im Gegenteil, Sie sollten nun eine Richtung haben, was Sie als Nächstes lernen müssen.
Ich teile die gleiche Frustration. Ich war Webdesigner, Webentwickler und Frontend-Entwickler, hauptsächlich mit Designs und HTML/CSS sowie grundlegendem Präsentations-JavaScript/Jquery. Ich habe gesehen, dass es heute viele Frontend-Entwickler gibt, die im Grunde Angular/React-Experten sind, und viele Stellenanzeigen, die genau das für einen Frontend-Entwickler verlangen. Ich bin mir nicht sicher, ob ich ein Angular-Mensch sein möchte, ich mag Design, Semantik, Usability, SEO, Barrierefreiheit usw. Und ich habe gesehen, dass gute Angular/React-Leute sich nicht viel um diese Dinge kümmern, zum Beispiel nicht mit Bildern arbeiten können, keine künstlerischen Fähigkeiten haben und dazu neigen, komplizierte Dinge zu tun, die leicht nur mit CSS gemacht werden könnten… Ich denke also, das ganze Problem ist die Abwesenheit einer klaren Rolle/Bezeichnung für diese Entwickler. Sie sind nicht genau Backend-Entwickler. Sie sind auch nicht genau Frontend-Entwickler. Es läuft alles darauf hinaus: Die ganze Idee eines Frontend-Entwicklers ist eine Person, die Code schreiben kann, der direkt mit dem Design verbunden ist, nämlich HTML, CSS (Sass/Less) und Präsentations-Javascript (Jquery/Bootstrap) usw. Diese Leute haben ein großartiges Auge für Details, verstehen Farben, können mit Bildern arbeiten, kümmern sich um Semantik und SEO und jetzt immer mehr um Barrierefreiheit. Gleichzeitig ist die Idee der Backend-Entwicklung für Entwickler, die an serverseitigem Code, Datenbanken usw. arbeiten. Die Ingenieurleistung hinter einer Anwendung. Diese Leute sind großartig in Mathematik. Aber sie mögen normalerweise kein HTML und neigen dazu, sich nicht darum zu kümmern, wie Dinge aussehen… Nicht einmal ihre Haare… Für mich fehlt hier also eindeutig eine Rolle. Wir müssen eine neue Rolle für Entwickler definieren, die zwischen diesen beiden liegen. Und ich nenne das den „Middle Layer Developer“. Da haben Sie es! Drei verschiedene Rollen, die alles verbinden! Keine Identitätskrise mehr. Und die Kluft ist geschlossen. Zusammenfassend
Frontend-Entwickler – HTML (Semantik, Barrierefreiheit, SEO), CSS (Sass/Less), Präsentations-Javascript (Jquery, Bootstrap und andere), Bildbearbeitung, Verbindung mit Designern.
Middle Layer Developer – Angular, React, Vue, Node, Go, sowie HTML und Javascript (die Verbindung).
Backend-Entwickler – serverseitige Sprachen wie C#, Java, PHP, Datenbank, Webserver, APIs (hier die Verbindung) usw.
Macht das jetzt Sinn? :-) Lasst mich eure Gedanken wissen!
Ich stimme zu, dass dort eine Rolle fehlt, aber Middle Layer Developer ist etwas zu generisch. Ist er auch für Middleware verantwortlich? Nicht nur in der mittleren Schicht, sondern auch im Backend?
Sehen Sie, es fängt sofort an, verwirrend zu werden.
Vielleicht wären Frontend-Designer und Frontend-Entwickler/Ingenieur besser.
Im Wesentlichen verbinden Sie das Backend mit dem Frontend, wenn Sie in der mittleren Schicht sind.
Vielleicht etwas bezüglich Implementierung/Systembindung. Bridge-End Developer. Connection-End Developer.
Ich weiß nicht, der Name braucht VIEL Arbeit xD
Das…! ^
Dieser Trend hat auch Backend-Entwickler betroffen. Als ich anfing, war PHP die erste Wahl für die meisten Anwendungen. Deshalb gab es eine solche Explosion zahlreicher PHP-Frameworks, und ein fundiertes Wissen über mindestens 2 Frameworks war wichtig. Viele Frameworks sind seitdem gestorben oder stagniert, da der neue bevorzugte Standard Node.js geworden ist. Laut Indeed.com ist PHP zur siebthäufigsten Backend-Sprache geworden, wobei JavaScript den dritten Platz einnimmt. Alles bewegt sich so schnell, dass es sich oft unmöglich anfühlt, Schritt zu halten.
Vielen Dank für Ihren Beitrag, Jason, bezüglich „es fühlt sich oft unmöglich an, Schritt zu halten.“ Ich war einer der ersten, die online Websites erstellten – in Vanilla-Editoren mit CGI-Skripten und unverschlüsselten Zahlungen. Ich kann kaum glauben, wie weit wir online seitdem gekommen sind. Letzte Woche hörte ich auf, an React zu lernen, und fragte mich nicht, ob ich versuchen sollte, Schritt zu halten, sondern ob ich es kann. Ich jongliere mit zu vielen Dingen, um alles im Griff zu haben, und Dinge, die ich gelernt habe, wurden nicht weiterentwickelt, sondern sind verschwunden. Ich dachte, die Welt sei voller Menschen, die weitaus fähiger sind als ich, und dass es endlich Zeit sei, einfach aufzugeben. Es hilft zu wissen, dass andere die Schwierigkeit spüren, Schritt zu halten. Danke.
Dies ist ein fantastischer, gut durchdachter Artikel. Ich habe in den letzten Jahren ein ähnliches Gefühl gehabt. So viele großartige Punkte!
Dieser Artikel beleuchtet ein Problem, das ich (glaube ich) erst kürzlich zu verstehen begonnen habe, enorm. Als ehemaliger Frontend-Entwickler, aber jetzt als Barrierefreiheitsberater, bin ich ständig erstaunt, wie viele meiner Barrierefreiheitsaudits von den Entwicklern zur erneuten Überprüfung zurückkommen, wobei nur die Hälfte der Mängel behoben ist. Manchmal kommen sie dreimal zur erneuten Überprüfung zurück, bevor alles korrekt ist! – obwohl ich sehr detaillierte Lösungen gebe, die oft das genaue Markup enthalten, das sie verwenden müssen.
Zuerst dachte ich, es läge daran, dass Entwickler einfach kein Interesse an der Barrierefreiheit hatten – aber das sind oft IT-Teams bei großen Banken und anderen Organisationen, die, wie ich weiß, eine entschlossene Anforderung haben, aus regulatorischen Gründen die vollständige WCAG-Konformität zu erreichen. (Und bedenken Sie auch, dass der Kunde jede erneute Überprüfung bezahlt.) Für mich, als Frontend-Entwickler, erscheinen die Lösungen im Allgemeinen absurd einfach (das für die Barrierefreiheit benötigte Markup ist es normalerweise auch) – warum verstehen sie es also nicht? Manchmal erlaubt ein Framework physisch nicht, zusätzliche Markup-Teile einzuführen, aber das ist nicht das Hauptproblem.
In jüngster Zeit habe ich begonnen, mich zu fragen, ob eine zu starke Abhängigkeit von JavaScript-Frameworks und -Bibliotheken dazu führte, dass die heutigen Entwickler HTML und CSS einfach nicht mehr so gut kannten, wie wir alle es taten und für selbstverständlich hielten, als ich das Handwerk lernte. Ihr Artikel bestätigt diese Idee als wahrscheinliche Ursache. Leider leidet darunter die Barrierefreiheitskonformität, neben schlechter Codierung und CSS.
Ich habe diese Kluft/diesen Trend seit einigen Jahren bemerkt und es ist sehr bestätigend, diesen Artikel zu lesen. Ich bin sehr stark auf der HTML-, CSS-, A11Y-, Design- und UX-Seite der Frontend-Entwicklerrolle. Es ist kein Witz, dass mein Fähigkeitssatz in meiner Firma unterbewertet wird, weil ich kein Experte in Javascript bin. (Ich weiß nur genug, um zurechtzukommen.) Wenn jedoch meine „Full-Stack“-Entwicklerkollegen Hilfe beim Debuggen dieser Dinge benötigen, bin ich die erste Person, die sie um Hilfe bitten… und es passiert öfter, als man erwarten würde, weil ich der Experte bin. Oder sie übergehen diese Teile einfach und lassen mich ihren Schlamassel später aufräumen. Ich bin nicht Ihr HTML- und CSS-Hausmeister!
Die monetäre Kluft ist real und völlig ungerecht. Wie kann eine Sprache die entscheidende Linie für das Gehalt sein?
Als es letztes Jahr darum ging, eine Gehaltserhöhung mit meinem Chef zu besprechen, bekam ich keine, weil mir JavaScript-Kenntnisse fehlten. Es tut mir leid, es war mein Fehler, meine Zeit mit Code-Reviews, Refactoring von HTML und CSS und dem Unterrichten unserer „Full-Stack“-Entwickler, wie man richtiges HTML, CSS und A11Y schreibt, ausgefüllt zu haben, so dass ich keine Zeit hatte, das Erlernen der JavaScript-Frameworks des Unternehmens zu priorisieren.
Julie. Ich kann das absolut nachvollziehen. Gut gesagt!
@Julie Perfekt, gut erklärt, ein alltägliches Szenario aus der realen Welt. Bravo. Sie sind besser in HTML- und CSS-Arbeiten, und Entwickler sind besser in ihren Codierungsbereichen. Sie beide brauchen einander (meistens brauchen Entwickler Designer mehr). Die meisten Entwickler tun es so: „Sie übergehen einfach ihre Codierungsbereiche und lassen den Webdesigner später ihren Schlamassel aufräumen“. Ich bin auch ein Webentwickler und am Anfang habe ich es so gemacht. Dann, nachdem ich sah, welche Probleme Webdesigner haben, erkannte ich meinen Fehler. Dann versuchte ich, die meisten CSS-Probleme selbst zu lösen oder mit Online-Hilfe (Quellen lesen usw.). Jetzt bin ich es gewohnt, perfekt formatierten Code zu schreiben, und ich mag keinen unordentlichen Code, der hier und da liegt… (obwohl es mehr Zeit in Anspruch nimmt, aber ich ZIEHE es vor). Meiner Meinung nach sollten Webentwickler und Webdesigner Ideen, Probleme und Fähigkeiten gemeinsam besprechen, um am Ende ein perfektes Produkt zu liefern.
Das alles wurde von Google mit Dart, Go und Angular initiiert. Sie wollten schon lange das Web kontrollieren, sich von Standards, von HTML-, CSS-, JS-Konventionen abwenden und hin zu einer kompilierten Sprachumgebung bewegen, die schließlich überhaupt nicht mehr wie HTML aussehen wird. Facebook stieg ein, als Google aussah, als würde es dominieren, möglicherweise aus guten Gründen, aber mit Transpilern, Babel, Webpack, Grunt, Gulp beschleunigten sie uns nur weg von Standards und hin zum Compiler (Transpiler). Die offensichtliche Kritik an jQuery-Sites (wo HTML, CSS und JS sauber getrennt waren, serverseitiges Rendering nicht benötigt wurde, SEO einfach funktionierte, Designer und Entwickler Seite an Seite arbeiteten usw.) war, dass sie Spaghetti-Code erzeugten. Aber wo dies auftrat, war dies eine Funktion schlechter technischer Leiter oder schlechter Entwickler. Das Code-Layout mit jQuery konnte immer modularisiert, wartbar und selbstdokumentierend sein. Jetzt mit React und Redux/Mobx usw. erhält man Datei-Spaghetti, einen riesigen globalen Speicher für globale Daten, komplexe Zustandsverwaltung, volle Abhängigkeit von JS und einen vollständigen Kompilier-(Transpilier-)Prozess. Das ist der Google-Traum. Es ist ein gefährlicher Ort. Wenn man gut verdienen will, ist man gezwungen, es zu übernehmen, aber es macht die Systementwicklung schwieriger, nicht einfacher. Und ich spreche von großen Systemen (was ein weiterer Irrtum ist – kein Frontend ist so groß. Kein Frontend braucht die Komplexität von React oder Angular). Also gewinnt Google….
Ich denke, Sie haben die Dinge dort hervorragend zusammengefasst!
Toller Artikel und Diskussionsfaden mit Ideen und Kommentaren.
Da ich hauptsächlich aus dem Designbereich in die Frontend-Entwicklung gekommen bin, weiß ich, dass eine meiner größten Stärken darin liegt, die Sprache von Design und Entwicklung zu sprechen und die Konzepte und Einschränkungen auf beiden Seiten zu verstehen. Persönlich denke ich, dass eine Aufteilung der Welt des "Front Ends" in zwei verschiedene Lager den meisten zugute kommen würde, da von den HTML/CSS-Experten in mehr Fällen auch ein gutes Auge für Design und eine Art Designausbildung verlangt werden könnte, und die funktionalen Frontend-Programmierer sich mehr auf ihr eigenes Fachwissen konzentrieren könnten, ohne sich so sehr in der Designwelt aufhalten zu müssen.
Das heißt, es würde nicht nur den Entwicklern zugute kommen, die weniger Verständnis für schwerere JS-Codierung und Frameworks haben, sondern auch den Entwicklern, die wirklich Schwierigkeiten haben, Designs und gebaute Websites so zu sehen, wie es ein Designer tut, und am Ende Websites mit 10 oder 100 kleinen designbezogenen Fehlern erstellen.
Sehr interessant und relevant!
Ein paar Gedanken
1. Wenn Menschen über Technologie murren, ist mein erster Gedanke immer: „Als die Druckerpresse erfunden wurde – murrten Menschen, die ihren Wert nicht sahen. Ist das dasselbe?“ Wenn Sie Cobol früh in Ihrer Karriere gelernt haben und nie eine andere Sprache gelernt haben, ist das cool, aber beschweren Sie sich nicht, wenn Ihre Jobaussichten begrenzt sind und die Leute die nächste Technologie übernehmen. Wessen Fähigkeiten sind von Veränderungen ausgenommen? Widerstand gegen Anpassung funktioniert, wenn Sie ein Alligator oder eine Kakerlake sind, aber es ist selten eine gute Strategie für Menschen.
Menschen sind von Natur aus kreative Problemlöser. Die aktuelle Kommunikationstechnologie, wohl ein Paradigmenwechsel, der noch in den Kinderschuhen steckt, bietet uns Fähigkeiten, die in der jüngeren Vergangenheit unvorstellbar waren (leicht zu vergessen). Meiner Meinung nach ist die JS-Revolution die zweite große, relativ universelle Entwicklung, die uns Massen mit Werkzeugen zur Verfügung stellt, um Inhalte zu erstellen, die diese Fähigkeiten nutzen. Natürlich müssen Sie die neuen Tools nicht lernen, aber wenn Sie sich beschweren, bedenken Sie, dass Sie ein Luddit sein könnten und sehen Sie #1.
Es gibt viele schlecht handcodierte HTML- und CSS-Dateien aus den guten alten Zeiten (ich habe meinen Teil dazu beigetragen), vielleicht entspricht der Großteil des Codes im Web dieser Beschreibung. Die Qualität hängt von den Bemühungen und Fähigkeiten der Person ab, die den Code schreibt – egal welche Tools sie verwendet.
Nach über 20 Jahren in der Frontend-Entwicklung klingt das sehr wahr. Aber ich teile die pessimistischen Ansichten, die der Untertitel „Zwei Frontend-Entwickler sitzen in einer Bar. Sie haben nichts zu reden“ zu implizieren scheint, nicht.
Wir haben seit Beginn dieses Handwerks immer Disziplinen überbrückt! Wir haben Design mit Code, Dokumentstrukturen, Semantik und einem verteilten Medium abgeglichen. Wir haben Barrierefreiheit durchgesetzt und die Struktur von der Präsentation entkoppelt, während wir immer mehr mit Interaktivität experimentierten. Wir haben Geschäftsbedürfnisse und -ziele dank Web-Performance, responsivem Design, konsistenten und wiederverwendbaren UI-Implementierungen in gute Konversionsraten umgesetzt.
Und wir haben daraus eine Branche gemacht.
Im Laufe der Jahre sind wir zuversichtlich geworden, dass CSS und HTML Code sind. Ich sehe den Aufstieg von JavaScript und strukturierten Programmierpraktiken nicht als Bedrohung, sondern als willkommene Ergänzung. Eine Disziplin, die wir wieder überbrücken müssen, insbesondere für die meisten von uns, die sich mit JS beschäftigten, als es noch eine einfachere browserbasierte Sprache war.
Wenn wir mit Designern zusammenarbeiten können, sehe ich nicht, warum wir nicht auch mit Frontend-Ingenieuren zusammenarbeiten können.
Wir haben so viel zu besprechen, die Bar wird schließen, während wir noch drin sind…
Ich bin so froh, dass Sie diesen Artikel geschrieben haben. Ich begann mich mit React und höheren JS-Ebenen zu beschäftigen, als WP und sogar Drupal anfingen, über Blöcke zu sprechen. Ich begann mit HTML zu arbeiten, als die allerersten Sites online gingen und die Online-Welt ein unbesiedeltes Wildwest-Grenzland war. Trotz jahrelanger Erfahrung habe ich zunehmend das Gefühl gehabt, dass ich zurückfalle, nicht alles beherrschen kann, was ich beherrschen muss, und etwas desillusioniert über meine Fähigkeiten werde. Ich genieße es tatsächlich, tiefer in JS einzutauchen und React zu lernen, aber verdammt, zu versuchen, in allem gut zu sein, ist eine Herausforderung. Aber noch schlimmer ist dieses nagende Gefühl, dass all die Mühe, die ich im Laufe der Jahre aufgewendet habe, dazu geführt hat, dass meine Fähigkeiten zweitklassig sind… das ist erschütternd. Ich bin so beschäftigt, dass ich dies mit niemandem besprochen habe, aber ich habe gespürt, wie meine Unsicherheit wuchs, als die JS-Abhängigkeit zunahm. Diesen Artikel zu sehen und die Antworten zu lesen, hat mich um 4 Uhr morgens aus dem Bett geholt! Ich bin nicht allein. Ich wusste es nicht. Vielen Dank, dass Sie dies beleuchtet haben… wohin gehen wir jetzt?
Ich war früher ein „Full-Stack-Entwickler“, aber das lag einfach daran, dass niemand da war, der das Backend übernehmen konnte. Ich verbrachte all meine Zeit damit, über Dinge nachzudenken und mir Sorgen zu machen, die ich über Sicherheit und Server und so weiter lernen musste, so dass ich mit HTML/CSS nicht Schritt hielt. Derzeit arbeite ich ausschließlich an der Benutzeroberfläche und überlasse all das ausgezeichneten Backend-Entwicklern. Sie sind gleichermaßen glücklich, das Frontend nicht bauen zu müssen. JavaScript ist der Punkt, an dem wir uns treffen.
Leute, die HTML, CSS und jQuery können, nennen wir Layout-Designer. Das sind Anfänger, die JS noch nicht gelernt haben. Und wenn Sie seit 20 Jahren in der Branche sind und es nicht getan haben, habe ich schlechte Nachrichten für Sie – entweder sind Sie inkompetent, oder Sie sind Ihrer Arbeit müde, und Sie sollten sich woanders versuchen.
Tatsächlich könnte ich nicht mehr widersprechen.
Ich denke, jeder beginnt mit HTML und CSS, und diese Person wählt einen von zwei Wegen.
Pfad 1: Diese Person beginnt, sich mit Benutzerinteraktion und Benutzererfahrung zu beschäftigen und wird dann ein UI/UX-Designer. Diese Person verfügt in der Regel über tiefe Kenntnisse in JavaScript, konzentriert sich aber auf DOM-Interaktion und Design.
Pfad 2: Diese Person beginnt, sich mit Frameworks und Implementierung zu beschäftigen und bewegt sich irgendwie am Rande von Frontend und Backend. Diese Person verfügt in der Regel über tiefe Kenntnisse in JavaScript, konzentriert sich aber auf Funktionalität, nicht auf Design.
Beide haben einen sehr starken Anspruch auf ihre Titel.
Man kann keine gute Website/App haben, ohne seine Zielgruppe zu kennen und ihr ein gutes Erlebnis zu bieten, genauso wenig wie man keine gute Website/App haben kann, wenn sie fehlschlägt, langsam ist oder unerwartetes Verhalten zeigt.
Übrigens, warum so mürrisch?
(Anmerkung des Herausgebers: Ich habe den Kommentar, auf den dies geantwortet hat, gelöscht, weil er nicht nur mürrisch, sondern wütend und unhöflich war.)
Ich bin neugierig, wo genau diese Kluft innerhalb von JS liegt. Die meisten FEDs können, so nehme ich an, zumindest grundlegende JS-Events und DOM-Manipulationen verwenden, zusammen mit einem gewissen Verständnis von Datenstrukturen wie Arrays und Hash-Maps. Aber was genau ist die Kluft?
Wie wäre es mit diesem vorläufigen Vorschlag?
Geltungsbereich
Closures
Prototypen
Lineare Algorithmen
…
— hier teilen —
Partials & Curry
Bäume, Graphen
OOP
TDD
…
Ich sehe viele neue FEDs, die die neuesten und besten APIs verwenden, um intelligente Chats, Bilderkennung usw. zu erstellen, aber offensichtlich bietet dieser Artikel eine nüchternere Einschätzung des Zustands von FED.
Wow! Was für ein großartiger Beitrag, der zusammenfasst, was mich seit einigen Jahren beschäftigt. Meine HTML/CSS-Fähigkeiten haben mir keine nennenswerte Position eingebracht, nur weil die meisten Stellenanzeigen da draußen sich nur um JS drehen. Und ich lerne JavaScript seit mehr als zwei Jahren. Bitte helfen Sie uns, die Überschneidungen in diesem Bereich zu lösen, damit wir, die in diesem Bereich aufsteigen, unsere Fähigkeiten über Grenzen hinaus entwickeln können.
Ich habe jahrzehntelange Erfahrung sowohl in JavaScript als auch in CSS, aber ich bin absolut nicht auf der JavaScript-Seite dieser großen Kluft.
JavaScript ist großartig, es ist meine Lieblingssprache. Ich würde jedoch niemals eine Website erstellen, die von JavaScript gerendert wird. Ich meine, wenn es keine Website ohne JavaScript gibt, d.h. clientseitiges Rendering.
Clientseitiges Rendering ist fehlerhaft. Das haben wir 2004 für einen Kunden gemacht, nie wieder! Ich glaube, wir sind auf jedes einzelne Problem von Jeder hat JavaScript, richtig? gestoßen. Es hat sich einfach nicht gelohnt.
Für gewöhnliche Websites wird kein Benutzerbedürfnis durch clientseitiges Rendering erfüllt. Man müsste an einem Spiel oder etwas Ähnlichem arbeiten, um es zu rechtfertigen, aber nicht an einer gewöhnlichen Website.
Ich finde auch Barrierefreiheit großartig. Es gibt eine Dreifaltigkeit von Richtlinien für Barrierefreiheit: Webinhalte (WCAG), Web-Benutzeragenten (UAAG) und Web-Autorentools (ATAG).
Die meisten Website-Autoren (die sich um Barrierefreiheit kümmern) folgen nur WCAG, aber UAAG besagt, dass es eine Barrierefreiheitsanforderung ist, Benutzern das Deaktivieren von Skripten zu ermöglichen. Kann also clientseitiges Rendering als barrierefrei betrachtet werden oder nicht? Sie sind sicherlich nicht barrierefrei, wenn das JavaScript nicht ausgeführt wird.
Mein Dilemma ist, wenn Sie clientseitiges Rendering verwenden, ob Sie sich dann immer noch nur mit WCAG befassen oder ob Sie jetzt auch der Gerichtsbarkeit von UAAG unterliegen?
UAAG besagt: „Ein Benutzeragent ist jede Software, die Webinhalte abruft, rendert und die Interaktion des Endbenutzers mit diesen erleichtert.“ Wenn Ihre Website also clientseitig gerendert wird, ist sie auch ein Benutzeragent, aber einer, der UAAG niemals erfüllen kann. Sie haben Ihren eigenen eingebetteten unzugänglichen Benutzeragenten unnötigerweise in den Browser gescriptet.
Jemand hat mich auf diesen Artikel aufmerksam gemacht, nachdem er meinen gelesen hatte. Dies ist ein Problem, das ich seit über 5 Jahren beobachte, wie es wächst…
Die „Backendifizierung“ der Frontend-Entwicklung
https://hackernoon.com/the-backendification-of-frontend-development-62f218a773d4
Bitte verstehen Sie, ich bin wahrscheinlich das, was dem Mythos des Fullstack-Entwicklers am nächsten kommt (mit einem Business-Hintergrund noch dazu). Ich jubelte Angular und React zu, bevor sie cool waren. Aber was im Konzept großartig schien, brach bei der Implementierung zusammen.
Ich habe die Zukunft schon einmal genau vorhergesagt und mein derzeitiges Gefühl ist, voll auf Vue zu setzen. Lesen Sie meinen Artikel, um herauszufinden, warum.
Toller Artikel, etwas, das mich seit 5 Jahren beschäftigt.
Ich habe eine praktische Frage an alle, die das lesen. Wie würde ein Frontend-Entwickler, der mehr die „Design“-Seite der Dinge macht, nach einem Job suchen? Welche Titel / Themen / Wörter sollte man suchen?
Diese Aufteilung ist in den Frontend-fokussierten Newslettern offensichtlich.
„Frontend Weekly“ wird von den Leuten von JavaScript Weekly geschrieben, daher ist es verständlicherweise voreingenommen. Die Schlagzeilen dort basieren alle auf Frameworks. (https://frontendfoc.us/issues/380)
Verwaltung von Bild-Breakpoints mit Angular
Animation in React
Arbeiten mit der React Context API
Neue JavaScript-Funktionen, die die Art und Weise, wie Sie reguläre Ausdrücke schreiben, ändern werden
„Frontend Focus“ ist ausgewogener. (https://frontendweekly.co/)
Erforschung eines Vor-/Zurück-Caches für Chrome
Wann ist ein Button kein Button?
Was sollten Entwickler bei der Planung einer React-Anwendung beachten?
Die dunkle Seite des Grids
„CSS Tricks Newsletter“ ist tatsächlicher Journalismus, nicht nur ein Index, und meiner Meinung nach der beste der Gruppe. (https://css-tricks.de/newsletters/)
wie man CSS Grid richtig verwendet
einige Dienste, die Cross-Browser-Tests ermöglichen
Social Cards als Dienstleistung
Animationen schreiben, die Ihre Website zum Leben erwecken
Ich musste wirklich etwas Derartiges von einem Experten lesen.
Ich bin Informatikstudent und habe einen technischen Abschluss in Programmierung. Als Student habe ich Konzepte über Datenbanken, objektorientierte Programmierung, Datenstrukturen und so weiter gelernt.
Als ich beschloss, mich ernsthaft auf die Frontend-Entwicklung zu spezialisieren (ich hatte bereits einige CSS/HTML-Kenntnisse), begann ich AngularJS zu lernen und war begeistert, es in einem realen Projekt einzusetzen. Aber als ich meinen ersten Job bekam, waren meine Aufgaben als Frontend-Entwickler fast ausschließlich darauf ausgerichtet, pixelgenaue Websites mit nur ein wenig jQuery zu erstellen. Ich hatte nie (und habe immer noch nicht) die Chance, MVC-Frontend-Frameworks zu verwenden, da sie nicht benötigt wurden. Ich schätze, sie sind nur für wirklich große Projekte erforderlich.
Es ist zu einem Problem für mich geworden, da sich einerseits das JavaScript-Ökosystem zu schnell ändert und es schwierig ist, selbst die Namen aller Bibliotheken da draußen zu lernen, während andererseits mein praktisches Wissen dem eines UI-Webentwicklers entsprach, so dass es noch schwieriger wird, auf die JavaScript-Seite zu wechseln, ohne das Gefühl zu haben, meine Zeit auf der Design-Seite verschwendet zu haben (ich mag CSS/HTML und UI insgesamt, aber es fühlt sich seltsam an, in dieser besonderen Position zu sein).
Brad Frost hat bereits ein schönes Wort für dieses… semantische Problem geprägt. Ich benutze es seitdem: Frontend Design
Um aus seinem Beitrag zu zitieren: „Frontend-Design umfasst das Erstellen von HTML-, CSS- und präsentationsbezogenem JavaScript-Code, der eine Benutzeroberfläche bildet.“ – Also, genau darum geht es in diesem Artikel, oder? Die große Kluft zwischen Javascript-Frontend-Entwicklern und Frontend-Designern (früher nannten wir es einfach Webdesign, aber heutzutage denken die Leute, es sei etwas, was Grafikdesigner tun… ugh).
Diese Diskussion ist wirklich nett und notwendig, daher ist es großartig, dass jemand wie Chris Coyier darüber schreibt. Ich arbeite derzeit als HTML/CSS-Frontend-Entwickler. Wenn ich mir die Stellenangebote in den Niederlanden ansehe, gibt es eine leichte Verschiebung, die zwischen diesen beiden Disziplinen trennt. Nichtsdestotrotz stimme ich vollkommen zu, dass das Schreiben von korrektem HTML/CSS keine leichte Aufgabe ist und besonders in großen Projekten eine große Herausforderung darstellt, wartbares CSS zu organisieren und zu schreiben. Ich selbst habe in diesem Bereich immer noch viele Herausforderungen und lerne jeden Tag dazu. Aber ich denke, wir sollten ehrlich sein, das Gehalt und die Jobmöglichkeiten sind für JS-Ingenieure viel besser, und deshalb wollen Unternehmen Frontend-Entwickler, die in beiden Bereichen gut sind, und das verstehe ich vollkommen. Ich denke sogar, dass ein HTML/CSS-Frontend-Entwickler sich selbst schulen sollte, um JavaScript zu lernen, weil man besser mit seinen Ingenieuren kommunizieren kann, wenn man einige grundlegende Konzepte versteht. Dies gilt auch für JavaScript-Ingenieure, die etwas über HTML/CSS, grundlegende Kenntnisse über das Box-Modell, CSS-Layout (Grid, Flexbox usw.) lesen sollten.
Meine Meinung ist, dass wir diese Disziplinen nicht trennen und von HTML/CSS-Designern sowie JavaScript-Ingenieuren verlangen sollten, anständiges HTML/CSS und anständiges JavaScript zu schreiben.
Ich bin neugierig; ist „Webdesigner“ heutzutage kein ausreichender Begriff mehr für diejenigen, die Web designen? Für mich ist „Developer“ gleichbedeutend mit „Programmierer“.
Danke für diesen Artikel. Der Schmerz ist real.
Ich war früher ein Frontend-Entwickler, als man nur HTML, CSS und jQuery und/oder JavaScript brauchte. Aber ohne eine solide Grundlage in React, Vue oder Angular fühle ich mich wie im Niemandsland.
Um ehrlich zu sein, bin ich jedoch so angewidert von der Abhängigkeitshölle, die die JS-Entwicklung darstellt, dass ich fertig bin und weiterziehe.
Es tut mir leid, solche Dinge zu hören. Ich habe Bruce Lawsons Vortrag „Accessibility – Back to the Future“ (https://youtu.be/T2CjuAwrAq8) gesehen, in dem er ziemlich überzeugend argumentiert, dass unsere JS-lastigen Toolsets die Nutzer teuer zu stehen kommen und ihnen einen schlechten Dienst erweisen. Das geht einfach nicht!!
Ich verwende solche JS-basierten Dinge nicht, ich könnte es, ich habe sogar schon Full-Stack-JS-Desktop-Anwendungen geschrieben, aber im Moment arbeite ich auf einer riesigen Plattform, die mit Scala+Play+Twirl gebaut wurde, es gibt wenig Spielraum für JS im Browser, da Progressive-Enhancement für diesen riesigen Kunden obligatorisch ist.
Besorgniserregend ist die Vorstellung, dass alle Webentwickler JS-Entwickler sind oder sein sollten. Ich mag den Mangel an Unterscheidung nicht, also nachdem ich Bruces großartigen Vortrag gesehen habe, denke ich, ich werde mich als Worldwide Web Developer vermarkten, nur damit die Leute wissen, dass es einen Unterschied gibt zwischen etwas, das „aus dem Web“ gemacht ist, und nicht nur irgendeiner JS-abhängigen Anwendung, die zufällig „im Web“ ist.
Heute gelernt: Ich bin ein Einhorn unter Einhörnern – ich bin nicht nur ein kompetenter Full-Stack-Entwickler, sondern habe auch mit HTML/CSS angefangen. Das sage ich nicht, um anzugeben, sondern um zu sagen, dass ich etwas überrascht bin, dass es so selten ist, dass es für unmöglich gehalten wird. Es gibt sicherlich Tage, an denen ich das Gefühl habe, dass die Tiefe beider Fähigkeiten meine Fähigkeit, Schritt zu halten, übersteigt (Barrierefreiheit kommt mir bemerkenswerterweise nicht so natürlich, wie ich es mir inzwischen erhofft hatte), aber im Allgemeinen habe ich alles, was ich brauche, um Ihr PSD zu zerlegen, einen Pixel auf einen Zehner zu setzen und dann den Rest der Website um den Pixel herumzudrehen, ohne seine Ränder zu verwischen und dann Ihnen eine API zu bauen, um das Drehen zu steuern. Aber ich bin hierher durch Wachstum in einer Karriere gekommen, die 1999 als Hobby begann. Es fühlt sich jetzt mit all der Komplexität viel entmutigender an, aber ich betrachte die beiden immer noch nicht als gegenseitig ausschließend.