Dies ist eine erweiterte Version meines Essays „When front-end means full-stack“, der im wunderbaren Increment Magazin von Stripe veröffentlicht wurde. Es ist auch eine Art Weiterentwicklung einiger meiner anderen Essays, „The Great Divide“ und „Ooops, I guess we’re full-stack developers now.“
Der Moment, in dem ich mich in die Front-End-Entwicklung verliebte, war, als ich die style.css Datei in WordPress-Themes entdeckte. Dort steckte für mich die ganze Magie (ist es immer noch!). Ich konnte (kann!) ein paar Zeilen darin ändern und das Aussehen und Gefühl einer Website komplett verändern. Es ist ein unglaubliches Spiel.
Indem ich mit HTML und CSS herumspiele, kann ich Ihre Gefühle verändern bezüglich eines Textes. Ich kann Ihnen ein besseres Gefühl geben, um Tickets für eine Veranstaltung zu kaufen. Ich kann die Wahrscheinlichkeit erhöhen, dass Sie etwas mit Ihren Freunden teilen.
Das war lange bevor mir jemand Geld für die Arbeit als Front-End-Entwickler zahlte, aber selbst dann spürte ich die berauschende Mischung aus Reizen, die der Job bietet. Front-End-Entwicklung ist diese ausdrucksstarke Kunstform, aber oft eingeschränkt durch Dinge wie die Notwendigkeit, Botschaften direkt zu vermitteln und Geschäftsziele zu erreichen.
Front-End-Entwicklung befindet sich an der Schnittstelle von Kunst und Logik. Eine Kreuzung aus Geschäft und Ausdruck. Sowohl linke als auch rechte Gehirnhälfte. Ein Cocktail aus Design und Nerd-Kram.
Ich liebe es.
Wenn ich zurückdenke an die Kurse, die ich von der Mittelstufe bis zum College belegte, wechselte ich ständig zwischen computerorientierten und kunstorientierten Kursen, daher ist es wohl keine Überraschung, dass ich einen Weg fand, beides als Karriere zu verfolgen.
Der Begriff „Front-End-Entwickler“ ist ziemlich gut definiert und verstanden. Erstens ist es ein Jobtitel. Ich wette, einige von Ihnen haben buchstäblich Visitenkarten, auf denen dies oder eine Variation davon steht: „Front-End Designer“, „UX Developer“ oder „UI Engineer“. Die Debatte darüber, was diese bedeuten, interessiert mich nicht besonders. Ich finde, die Rollen sind von Job zu Job und von Unternehmen zu Unternehmen so unterschiedlich, dass Jobtitel nie ausreichen werden, um Dinge zu beschreiben. Diesen Job zu bekommen, bedeutet mehr, zu beweisen, dass man weiß, was man tut, als alles andere¹.
Chris Coyier
Front-End-Entwickler
Die Titelvariationen sind nur Nuancen. Das Gesamtbild ist, dass Front-End-Entwickler sich auf den Browser konzentrieren, solange der Job den Aufbau von Websites beinhaltet. Ganz wörtlich:
- Front-End = Browser
- Back-End = Server
Auch wenn sich der Job im Laufe der Jahrzehnte verändert hat, gilt diese Unterscheidung immer noch weitgehend.
Als „Browser-Leute“ gibt es bestimmte Wahrheiten, die dazugehören. Eine davon ist, dass es eine ganze Landschaft verschiedener Browser gibt und sie sich trotz bester Bemühungen der Standards-Organisationen immer noch etwas anders verhalten. Allein heute, während ich schreibe, hatte ich mit einem Fehler zu tun, bei dem ein Datumsstring, den ich von einer API hatte, in einem Format vorlag, das Firefox einen Fehler auswarf, als ich versuchte, die .toISOString() JavaScript API darauf anzuwenden, aber in Chrome funktionierte. Das ist einfach das Leben als Front-End-Entwickler. Das ist der Job.
Selbst in dieser Browser-Landschaft gibt es allein auf Desktop-Computern Unterschiede darin, wie Benutzer diesen Browser benutzen. Wie groß haben sie das Fenster geöffnet? Haben sie den Dunkelmodus auf ihrem Betriebssystem aktiviert? Wie ist die Farbskala dieses Monitors? Was ist die Pixeldichte? Wie sieht die Bandbreitensituation aus? Benutzen sie eine Tastatur und eine Maus? Nur das eine? Keines von beiden? All diese Fragen gelten auch für mobile Geräte, wo es eine ebenso, wenn nicht sogar kompliziertere Browser-Landschaft gibt. Und warten Sie nur, bis Sie sich HTML-E-Mails genauer ansehen.
Das sind viele Unbekannte, und die Antworten für die Entwicklung für diese unbekannte Landschaft liegen fest in den Händen von Front-End-Entwicklern.
Der wichtigste Aspekt des Jobs? Die Menschen, die diese Browser benutzen. Deshalb bauen wir überhaupt Dinge. Das sind die Leute, die ich mit meinen verrückten CSS-Skills beeindrucken will. Das sind die Leute, die ich dazu bringen will, mein Widget zu kaufen. Auf wem alle meine Geschäftscharts beruhen. Wessen Reaktion meine Emotionen wie Garn im Wind beeinflussen kann. Diese Benutzer, die wir aus gutem Grund auf ein Podest stellen, haben eine viel größere Landschaft als die Browser. Sie sprechen verschiedene Sprachen. Sie wollen verschiedene Dinge. Sie versuchen, verschiedene Probleme zu lösen. Sie haben unterschiedliche körperliche Fähigkeiten. Sie haben unterschiedliche Dringlichkeitsstufen. Auch hier liegt es fest in den Händen von Front-End-Entwicklern, ihnen zu helfen. Es gibt sehr wenig dazwischen zwischen den Zeichen, die wir in unsere Texteditoren tippen, und den Benutzern, denen wir dienen wollen.
Als Front-End-Entwickler stehen wir an der Frontlinie zwischen dem, was wir bauen, und den Menschen, für die wir es bauen, und das ist ein Ort, an dem einige von uns wirklich gerne sind.
Das ist schon ziemlich Gewichtiges, nicht wahr? Ich habe noch nicht einmal React erwähnt.
Die Sache mit dem „Wir kümmern uns um die Benutzer“ mag ein wenig empfindlich erscheinen. Ich würde denken, in einem gut funktionierenden Unternehmen würden sich alle um die Benutzer kümmern, vom CEO abwärts. Es ist jedoch anders. Wenn wir einen <button> coden, platzieren wir buchstäblich einen Button in einem Browserfenster, mit dem Benutzer direkt interagieren. Wenn wir eine Farbe anpassen, passen wir genau das an, was unsere sehenden Benutzer sehen, wenn sie unsere Arbeit sehen.
Das ist nicht weit entfernt von einem Keramikkünstler, der einen Griff aus Ton für eine Kaffeetasse zieht. Es ist die Anwendung von Handwerkskunst auf eine digitale Erfahrung. Während ein Back-End-Entwickler sich zutiefst um die Benutzer einer Website kümmern mag, „lagern sie diese Verantwortung aus“, wie Monica Dinculescu mir einmal in einem Gespräch darüber sagte.
Wir haben festgestellt, dass Front-End-Entwickler Browser-Leute sind. Der Job ist, Dinge in Browsern gut zum Laufen zu bringen. Also müssen wir die Sprachen verstehen, die Browser sprechen, nämlich: HTML, CSS und JavaScript². Und das ist nicht nur, dass ich ein altmodischer Fundamentalist bin; es ist durch ein paar Jahrzehnte täglicher Front-End-Entwicklungsarbeit, dass das Wissen über diese Basissprachen für uns entscheidend ist, um gute Arbeit zu leisten. Selbst wenn wir nicht direkt mit ihnen arbeiten (HTML kann aus einer Vorlage in einer anderen Sprache stammen, CSS kann aus einem Präprozessor erzeugt werden, JavaScript kann hauptsächlich im Jargon eines Frameworks geschrieben werden), was in den Browser gelangt, ist letztendlich HTML, CSS und JavaScript, und dort findet größtenteils das Debugging statt und die Leistungsfähigkeit des Browsers wird genutzt.
CSS wird immer mein Favorit sein und HTML braucht meiner Meinung nach die meiste Liebe – aber JavaScript ist das, was wir wirklich untersuchen müssen. Das letzte Jahrzehnt hat gesehen, wie JavaScript von einer Sprache für eine Handvoll interaktiver Effekte zur vorherrschenden Sprache im gesamten Stack von Webdesign und -entwicklung erblühte. Es ist möglich, an Websites zu arbeiten und nichts außer JavaScript zu schreiben. Ein echter Umbruch.
JavaScript ist im Browser allmächtig. In gewisser Weise ersetzt es HTML und CSS, da nichts, was diese beiden Sprachen können, was JavaScript nicht kann. HTML wird vom Browser analysiert und in das DOM umgewandelt, das JavaScript ebenfalls vollständig erstellen und manipulieren kann. CSS hat sein eigenes Modell, das CSSOM, das Stile auf Elemente im DOM anwendet, das JavaScript ebenfalls erstellen und manipulieren kann.
Das ist aber nicht ganz fair. HTML ist die allererste Datei, die Browser analysieren, bevor sie den Rest der Arbeit erledigen, die zum Erstellen der Website nötig ist. Diese Erstheit ist einzigartig für HTML und ein wichtiger Teil davon, Websites schnell zu machen.
Tatsächlich sollte, wenn das HTML die einzige Datei wäre, die über das Netzwerk kommt, dies ausreichen, um die grundlegenden Informationen und die Funktionalität einer Website bereitzustellen.
Diese Philosophie nennt sich Progressive Enhancement. Ich bin ein Fan davon, aber ich halte mich nicht immer perfekt daran. Zum Beispiel kann ein <form> in reinem HTML voll funktionsfähig sein, wenn sein action-Attribut auf eine URL verweist, auf der das Formular verarbeitet werden kann. Progressive Enhancement würde uns dazu bringen, es so zu bauen. Wenn dann JavaScript ausgeführt wird, übernimmt es die Übermittlung und lässt das Formular stattdessen über Ajax übermitteln, was eine angenehmere Erfahrung sein mag, da die Seite nicht neu geladen werden muss. Das gefällt mir. Weiter gedacht: Jede <button>, die außerhalb eines Formulars liegt, ist ohne JavaScript völlig nutzlos. Im Sinne von Progressive Enhancement sollte ich also warten, bis JavaScript ausgeführt wird, um diesen Button überhaupt auf die Seite zu setzen (oder ihn zumindest anzuzeigen). Das ist die Art von Dingen, bei denen selbst diejenigen von uns mit den besten Absichten nicht immer perfekt auf der Linie bleiben. Mach einfach den Button rein, Sam. Niemand wird sterben.
Die Allmacht von JavaScript macht es zu einem attraktiven Ziel für uns, die wir im Web arbeiten – insbesondere da sich JavaScript als Sprache weiterentwickelt hat, um noch leistungsfähiger und ergonomischer zu werden, und die Frameworks, die in JavaScript erstellt werden, dies noch mehr. Bereits 2015 war klar, dass JavaScript ein unglaubliches Wachstum in der Nutzung verzeichnete, und Matt Mullenweg, Mitbegründer von WordPress, gab der Entwicklerwelt Hausaufgaben: „Learn JavaScript Deeply“³. Er hätte nicht richtiger liegen können. Ein halbes Jahrzehnt später hat JavaScript gute Arbeit geleistet, die Front-End-Entwicklung zu übernehmen. Insbesondere wenn man sich die Jobs in der Front-End-Entwicklung ansieht.
Während der Web Almanac uns vielleicht zeigt, dass nur 5 % der Top-Zillionen Seiten React im Vergleich zu 85 % einschließlich jQuery verwenden, sind diese Zahlen fast umgekehrt, wenn man sich die Anforderungen an Front-End-Entwicklungsjobs ansieht.
Ich bin sicher, dass es dafür schicke ökonomische Gründe gibt, aber Arbeitsplätze sind für Menschen so wichtig und persönlich wie nur irgendetwas, daher ist es sehr wichtig.
Also sind wir Browser-Leute in einem Meer von JavaScript, die Dinge für Menschen bauen. Wenn wir uns den Job auf der praktischen Ebene der täglichen Aufgaben ansehen, sieht er ein bisschen so aus:
- Designs in Code übersetzen
- Im Sinne von Responsive Design denken, was es uns ermöglicht, über die Geräte-Landschaft hinweg zu gestalten und zu bauen
- Systemisch aufbauen. Komponenten und Muster konstruieren, keine Einzelstücke.
- Semantik auf Inhalte anwenden
- Barrierefreiheit berücksichtigen
- Sich um die Performance der Website kümmern. Alles optimieren. Reduzieren, wiederverwenden, recyceln.
Schon der erste Punkt auf dieser Liste fühlt sich für mich nach einem Hochschulabschluss an. In ihrer Gesamtheit tun das definitiv alle diese Punkte.
Diese ganze Liste ist jedoch etwas abstrakt, also wenden wir sie auf etwas an, das wir uns ansehen können. Was, wenn diese Website unser aktuelles Projekt wäre?
Unsere Gehirne und Finger spielen verrückt!
- Lassen Sie uns das Layout mit CSS Grid aufbauen.
- Welche Schriftarten sind das? Müssen wir sie vollständig laden oder können wir sie subsetten? Was passiert, wenn sie geladen werden? Dieses Layout scheint von Font-Shifting Jank stark betroffen zu sein.
- Es gibt hier einige wiederholte Muster. Wir sollten wahrscheinlich ein Karten-Design-Muster erstellen. Jede Website braucht ein gutes Kartenmuster.
- Das ist eine wunderschöne Farbpalette. Sind die Farben mathematisch miteinander verbunden? Sollen wir Variablen erstellen, die sie einzeln repräsentieren, oder können wir einfach einen einzelnen Farbton nach Bedarf ändern? Werden wir Custom Properties in unserem CSS verwenden? Farben sind jedoch nur Farben, wir brauchen ihre kaskadierende Kraft vielleicht nicht nur dafür. Sollen wir einfach Sass-Variablen verwenden? Werden wir überhaupt einen CSS-Präprozessor verwenden?
- Die Quellreihenfolge ist hier knifflig. Wir müssen die Dinge so ordnen, dass sie für einen Screenreader-Benutzer Sinn ergeben. Wir sollten ein Meeting darüber abhalten, was die erwartete Reihenfolge des Inhalts sein soll, auch wenn wir visuell einiges mit CSS Grid verschieben.
- Die Fotos hier sind wunderschön aufgenommen. Aber einige von ihnen passen zur Hintergrundfarbe der Seite… Können wir hier mit alpha-transparenten PNGs davonkommen? Die sind immer so groß. Können nächste-Generation-Formate helfen? Oder sollen wir versuchen, den Hintergrund eines JPG nahtlos mit dem Hintergrund der Seite abzugleichen. Wer schreibt den
alt-Text dafür? - Hier werden einige Icons verwendet. Inline-SVG, richtig? Sicherlich SVG irgendeiner Art, keine Icon-Fonts, oder? Sollen wir ein ganzes Icon-System aufbauen? Ich schätze, das hängt davon ab, wie wir dieses Ding breiter aufbauen werden. Haben wir überhaupt ein Build-System?
- Was ist der gesamte Front-End-Plan hier? Kann ich dieses Ding in reinem HTML, CSS und JavaScript coden? Nun, ich weiß, dass ich es kann, aber was sind die Erwartungen des Teams? Die Erwartungen des Kunden? Muss es ein React-Ding sein, weil es Teil eines Ökosystems von Dingen ist, die bereits React sind? Oder Vue oder Svelte oder was auch immer? Ist ein CMS involviert?
- Ich bin froh, dass der Designer nicht nur an die „Desktop“- und „Mobile“-Größen gedacht hat, sondern auch eine Zwischengröße bewältigt hat. Die sind immer umständlich. Es gibt hier jedoch keine Interaktivitätsinformationen. Was tun wir, wenn das Suchfeld fokussiert ist? Was wird angezeigt, wenn der Hamburger angetippt wird? Machen wir hier Seitenübergänge?
Ich könnte ewig weitermachen. So denken Front-End-Entwickler, zumindest nach meiner Erfahrung und im Gespräch mit meinen Kollegen.
Viele dieser Dinge waren schon immer unsere Aufgaben. Wir stellen diese Fragen und beantworten sie bei jeder Website, die wir bauen, solange wir damit beschäftigt sind. Es gibt bei jeder Seite unterschiedliche Herausforderungen, was großartig ist und diesen Job spannend hält, aber es gibt auch viel Wiederholung.
Erlauben Sie mir, zum Titel dieses Artikels zu kommen.
Während wir viele dieser Dinge seit Ewigkeiten tun, gibt es einen ganzen Haufen neuer Dinge, die wir tun sollen, besonders wenn wir die Website mit einem modernen JavaScript-Framework bauen. Alle modernen Frameworks, so sehr sie sich auch über Dinge streiten, sind sich über eine große Sache einig: Alles ist eine Komponente. Man verschachtelt und fügt Komponenten nach Bedarf zusammen. Selbst natives JavaScript bewegt sich in Richtung seines eigenen Modells von Web Components.
Ich mag es, diese Idee der Komponenten. Sie ermöglicht es Ihnen und Ihrem Team, die Abstraktionen zu erstellen, die für Sie und das, was Sie bauen, am sinnvollsten sind.
Ihre Card-Komponente erledigt alle Dinge, die Ihre Karte tun muss. Ihre Form-Komponente erledigt Formulare so, wie Ihre Website Formulare erledigen muss. Aber es ist ein neues Konzept für alte Entwickler wie mich. Komponenten in JavaScript haben sich auf eine Weise durchgesetzt, wie Komponenten auf der Serverseite es nie taten. Ich habe an vielen WordPress-Websites gearbeitet, bei denen das Beste, was ich tun konnte, war, Vorlagen in einigermaßen willkürliche include()-Anweisungen aufzuteilen. Ich habe an Ruby on Rails-Sites mit Partials gearbeitet, die eine Handvoll lokaler Variablen akzeptieren. Diese sind nützlich für den Bau wiederverwendbarer Teile, aber sie sind weit entfernt von den robusten Komponentenmodellen, die uns JavaScript-Frameworks heute bieten.
All diese benutzerdefinierten Komponenten erstellen macht mich zu einem Website-Architekten auf eine Weise, wie ich es früher nicht war. Hier ist ein Beispiel. Natürlich habe ich eine Button-Komponente. Natürlich habe ich eine Icon-Komponente. Ich werde sie in meiner Card-Komponente verwenden. Meine Card-Komponente lebt in einer Grid-Komponente, die sie anordnet und paginiert. Die gesamte Seite wird tatsächlich aus Komponenten aufgebaut. Die Header-Komponente hat eine SearchBar-Komponente und eine UserMenu-Komponente. Die Sidebar-Komponente hat eine Navigation-Komponente und eine Ad-Komponente. Die gesamte Seite ist nur eine spezielle Kombination von Komponenten, die wahrscheinlich auf der URL basiert, vorausgesetzt, ich setze voll auf den Aufbau unseres Front-Ends mit JavaScript. Jetzt beschäftige ich mich also selbst mit URLs und bin im Wesentlichen der Architekt der gesamten Website. [Schwitzt heftig]
Wie ich Ihnen schon sagte, ein ganzer Haufen neuer Verantwortung.
Komponenten, die für die Anzeige von Inhalten zuständig sind, sind mit ziemlicher Sicherheit nicht fest mit Daten darin codiert. Sie sind als Vorlagen konzipiert. Sie sind so konzipiert, dass sie Daten akzeptieren und sich basierend auf diesen Daten selbst konstruieren. In alten Zeiten, als wir diese Art von Templating machten, waren die Daten wahrscheinlich schon auf der Seite angekommen, an der wir arbeiteten. In einer JavaScript-gesteuerten App werden die Daten eher von JavaScript abgerufen. Vielleicht rufe ich sie ab, wenn die Komponente gerendert wird. In einem Stack, an dem ich gerade arbeite, ist das Front-End in React, die API in GraphQL und wir verwenden Apollo Client für die Datenarbeit. Wir verwenden einen speziellen „Hook“ in den React-Komponenten, um die Abfragen auszuführen, um die benötigten Daten abzurufen, und einen weiteren speziellen Hook, wenn wir diese Daten ändern müssen. Raten Sie mal, wer diese Arbeit macht? Ist es eine andere Art von Entwickler, der sich auf diese Datenlayer-Arbeit spezialisiert hat? Nein, es ist zur Domäne des Front-End-Entwicklers geworden.
Wenn wir schon von Daten sprechen, gibt es all diese anderen Daten, mit denen eine Website oft umgehen muss, die nicht aus einer Datenbank oder API stammen. Es sind Daten, die für die Website nur zu diesem Zeitpunkt relevant sind.
- Welcher Tab ist gerade aktiv?
- Ist dieses modale Dialogfeld geöffnet oder geschlossen?
- Welcher Abschnitt dieses Akkordeons ist erweitert?
- Befindet sich diese Nachrichtenleiste im Fehler- oder Warnzustand?
- Auf welcher Seite sind Sie paginiert?
- Wie weit ist der Benutzer nach unten auf der Seite gescrollt?
Front-End-Entwickler beschäftigen sich schon lange mit dieser Art von Zustand, aber genau dieser Zustand hat uns schon früher in Schwierigkeiten gebracht. Ein modales Dialogfeld kann mit einer einfachen Modifikator-Klasse geöffnet werden, wie <div class="modal is-open">, und das Umschalten dieser Klasse ist mit .classList.toggle(".is-open"); einfach genug. Aber das ist eine rein visuelle Behandlung. Woher weiß alles andere auf der Seite, ob dieses Modal geöffnet ist oder nicht? Fragt es das DOM? In vielen jQuery-ähnlichen Apps von früher war das der Fall. In gewissem Sinne wurde das DOM zur „Source of Truth“ für unsere Websites. Aus dieser Architektur ergaben sich allerlei Probleme, von einer einfachen Namensänderung, die die Funktionalität auf seltsam heimtückische Weise zerstörte, bis hin zu schwer nachvollziehbarer Anwendungslogik, die die Fehlerbehebung zu einer schwierigen Aufgabe machte.
Front-End-Entwickler dachten kollektiv: Was, wenn wir mit dem Zustand überlegter umgehen? Zustandsverwaltung als Konzept wurde zu einer Sache. JavaScript-Frameworks selbst haben das Konzept direkt integriert, und Drittanbieter-Bibliotheken haben den Weg geebnet und ebnen ihn weiterhin. Dies ist ein weiteres Beispiel für erweiterte Verantwortung. Wer konzipiert die Zustandsverwaltung? Wer setzt sie durch und implementiert sie? Es ist keine andere Rolle, es sind Front-End-Entwickler.
Es gibt eine erweiterte Verantwortung in der Checkliste der zu erledigenden Aufgaben, aber es gibt auch Arbeit, die bei der Zusammenfügung all dieser Dinge zu leisten ist. Wie viel von diesem Zustand kann auf der Ebene einzelner Komponenten behandelt werden und wie viel muss auf einer höheren Ebene liegen? Wie viel dieser Daten kann auf der Ebene einzelner Komponenten abgerufen werden und wie viel sollte von oben nach unten durchsickern? Das Design selbst spielt eine Rolle. Wie viel von der Gestaltung dieser Komponente sollte auf sie selbst beschränkt sein und wie viel sollte von globaleren Stilen kommen?
Kein Wunder, dass Designsysteme in den letzten Jahren an Bedeutung gewonnen haben. Wir bauen sowieso Komponenten, daher ist das systemische Denken eine natürliche Passform.
Schauen wir uns unser Design noch einmal an
Eine Menge neuer Gedanken können beginnen!
- Unter der Annahme, dass wir ein JavaScript-Framework verwenden, welches? Warum?
- Können wir diese Seite statisch rendern, auch wenn wir mit einem JavaScript-Framework bauen? Oder serverseitig rendern?
- Woher kommen diese Rezepte? Können wir eine GraphQL-API erstellen, damit wir anfordern können, was wir brauchen, wann immer wir es brauchen?
- Vielleicht sollten wir ein CMS wählen, das eine API hat, die die Art von Front-End-Entwicklung erleichtert, die wir machen wollen. Vielleicht ein Headless CMS?
- Was machen wir mit Routing? Ist das Framework, das wir gewählt haben, meinungsbildend oder unmeinungsbildend in Bezug auf solche Dinge?
- Welche Komponenten brauchen wir? Eine
Card,Icon,SearchForm,SiteMenu,Img… Können wir diese ausarbeiten? Sollen wir mit einer Art Design-Framework über dem Basis-Framework beginnen? - Was ist der Client-Zustand, den wir möglicherweise benötigen? Aktueller Suchbegriff, aktueller Tab, Hamburger geöffnet oder nicht, zumindest.
- Gibt es ein Login-System für diese Seite oder nicht? Werden eingeloggten Benutzern etwas anderes gezeigt?
- Gibt es von Drittanbietern Komponenten, die wir hier nutzen können?
- Vielleicht finden wir eine dieser schicken Bildkomponenten, die Blur-Up-Loading und Lazy-Loading und all das macht.
Das sind alles Dinge, die heutzutage in den Bereich von Front-End-Entwicklern fallen, zusätzlich zu allem, was wir bereits tun müssen. Die Umsetzung des Designs, Semantik, Barrierefreiheit, Performance… das alles ist immer noch da. Sie müssen immer noch in HTML, CSS, JavaScript und der Funktionsweise des Browsers versiert sein. Ein Front-End-Entwickler zu sein, erfordert einen Kompetenz-Heuhaufen, der immer weiter wächst. Es ist das natürliche Ergebnis der wachsenden Größe des Webs. Mehr Menschen nutzen das Web und der Internetzugang wächst. Die Wirtschaft rund um das Web wächst. Die Leistungsfähigkeit der Browser wächst. Die Erwartungen an das, was im Web möglich ist, wachsen. Hier schrumpft nicht viel.
Wir haben bereits den Punkt erreicht, an dem die meisten Front-End-Entwickler nicht den gesamten Heuhaufen an Verantwortlichkeiten kennen. Es gibt viele Entwickler, die immer noch gut verdienen, indem sie eher designorientiert sind und in kreativem und gut implementiertem HTML und CSS glänzen, auch wenn die Stellenausschreibungen dafür abnehmen.
Es gibt systemorientierte Entwickler und sogar ganze Agenturen, die sich darauf spezialisiert haben, anderen Unternehmen beim Aufbau und der Implementierung von Designsystemen zu helfen. Es gibt datenorientierte Entwickler, die sich am wohlsten fühlen, wenn sie die Daten durch eine Website fließen lassen und sich mit Geschäftslogik beschäftigen. Auch wenn all diese Leute vielleicht „Front-End-Entwickler“ auf ihrer Visitenkarte stehen haben, könnten ihre Verantwortlichkeiten und sogar die Erwartungen an ihre Arbeit ziemlich unterschiedlich sein. Es ist alles gut, wir werden Wege finden, darüber zu sprechen, wenn die Zeit reif ist.
Tatsächlich hat sich die Art und Weise, wie wir über den Aufbau von Websites sprechen, im letzten Jahrzehnt stark verändert. Eine meiner ersten Einführungen in die Webentwicklung erfolgte über WordPress. WordPress benötigt einen Webserver zum Ausführen, ist in PHP geschrieben und speichert seine Daten in einer MySQL-Datenbank. So sehr sich WordPress auch weiterentwickelt hat, all das ist immer noch genau dasselbe. Wir sprechen über diesen „Stack“ mit einem Akronym: LAMP, oder Linux, Apache, MySQL und PHP. Beachten Sie, dass buchstäblich alles im gesamten Stack aus Backend-Technologien besteht. Als Front-End-Entwickler ist nichts an LAMP für mich relevant.
Aber andere Stacks sind seitdem gekommen. Ein beliebter Stack war MEAN (Mongo, Express, Angular und Node). Beachten Sie, wie wir uns allmählich mehr Front-End-Technologien nähern. Angular ist ein JavaScript-Framework, und als dieser Stack an Popularität gewann, wurde auch über das Front-End als wichtigen Teil des Stacks gesprochen. Node und Express sind beide auch JavaScript, wenn auch die serverseitige Variante.
Die Existenz von Node ist ein wichtiger Teil dieser Geschichte. Node ist nicht JavaScript-ähnlich, es ist buchstäblich JavaScript. Es ermöglicht einem Front-End-Entwickler, der bereits in JavaScript versiert ist, serverseitige Arbeit zu leisten, ohne allzu große Anstrengung.
„Serverless“ ist ein viel modernerer Tech-Buzzword, und worüber es größtenteils spricht, ist das Ausführen kleiner Codefragmente auf Cloud-Servern. Meistens sind diese kleinen Codefragmente in Node geschrieben und von JavaScript-Entwicklern geschrieben. Heutzutage schreibt ein JavaScript-fokussierter Front-End-Entwickler möglicherweise seine eigenen Serverless-Funktionen und ist im Wesentlichen sein eigener Back-End-Entwickler. Sie werden sich selbst als Full-Stack-Entwickler betrachten, und sie werden Recht haben.
Shawn Wang prägte dieses Jahr einen Begriff für einen neuen Stack: STAR oder Design System, TypeScript, Apollo und React. Das ist für mich unglaublich, nicht nur, weil ich diesen Stack irgendwie mag, sondern weil es eine Art ist, über den Stack zu sprechen, der eine Website antreibt, und das sind ausschließlich Front-End-Technologien. Ein ziemlicher Wandel.
Ich entschuldige mich, wenn ich Sie beim Lesen dieses Textes etwas beunruhigt habe. Wenn Sie das Gefühl haben, dass Sie hinter dem Verständnis all dieser Dinge zurückliegen, sind Sie nicht allein.
Tatsächlich glaube ich nicht, dass ich mit einem einzigen Entwickler gesprochen habe, der mir sagte, er fühle sich mit der gesamten Welt des Website-Baus vollständig wohl. Jeder hat Schwachstellen oder ganze Bereiche, in denen er einfach keine Ahnung hat. Sie können sich nicht nur spezialisieren, sondern Spezialisierung ist eine ziemlich gute Idee, und ich glaube, Sie werden sich letztendlich bis zu einem gewissen Grad spezialisieren, ob Sie es planen oder nicht. Wenn Sie das Glück haben zu planen, wählen Sie Dinge, die Ihnen gefallen. Sie werden das gut machen.
Das einzige Konstante im Leben ist die Veränderung.
– Heraklit – Motivationsposter – Chris Coyier
¹ Ich bin ein weißer Typ, das hilft auch sehr. ↩️
² Browser sprechen noch viel mehr Sprachen. HTTP, SVG, PNG… Je mehr Sie wissen, desto mehr können Sie einsetzen! ↩️
³ Es ist eine interessante Ironie, dass WordPress-Websites im Allgemeinen nicht mit clientseitigen JavaScript-Komponenten aufgebaut werden. ↩️
Tolle Zusammenfassung, Chris! Danke.
Eine tolle Lektüre. Und danke für die Verabschiedung. Mein Hochstapler-Syndrom begann am Ende einzusetzen.
Was für eine tolle Lektüre, Chris! Ein so gut zusammengestellter Artikel.
Danke Chris für diesen Artikel.
Beim Lesen war ich in einer anderen Welt. Sehr gut geschrieben.
React ist das älteste der großen Frameworks und das merkt man.
Popularität ist Einfachheit. Großartig für Noobs. Aber auf so viele Arten hoffnungslos veraltet im Vergleich zu Angular, Svelte, Vue
Angular ist älter als React.
Vue ist buchstäblich eine Mischung aus Angular und React.
Svelte ist das einzige Framework, das etwas völlig anderes versucht, und das ist wahrscheinlich der Grund, warum es sich nicht durchgesetzt hat.
Was React für Noobs großartig macht, Vue gilt weithin als weitaus einfacher als React, und React ist bereits weitaus einfacher als Angular.
Wie immer ein großartiger Artikel zu diesem Thema. Ich würde sagen, Sicherheit ist eine weitere wachsende Verantwortung, da das Front-End immer komplexer wird.
Ich teile einen ähnlichen Hintergrund, da ich mich schon als Kind für Kunst und Computer interessierte und durch die Kraft und Einfachheit von CSS meine Liebe zu all diesem Web-Kram fand. Als ich meine erste Website baute, erinnere ich mich an die Frustration, bevor ich den Web-Inspector in Chrome entdeckte, der mir half, das CSS-Boxmodell zu verstehen. Damals fand ich auch CSS-Tricks. Ich habe mich mit anderen Programmiersprachen, Design und dann kurz mit Ölmalerei beschäftigt, bevor ich schließlich zum Web zurückkehrte – ich baute Websites mit WordPress. Ich habe mich mit WordPress oder PHP nie wirklich wohlgefühlt – ich habe einfach jede Aufgabe angepackt, wie sie kam, und versucht, alles auf die „richtige“ Weise zu tun. Bis ich wirklich mit JavaScript begann, schien jQuery bereits auf dem Rückzug zu sein, und ich habe es damals immer vorgezogen, Bibliotheken und Frameworks zu meiden.
Das war 2015. Von Node und npm erfuhr ich durch Zell Liews Artikel ‚Gulp for Beginners‘ hier (und ich habe Gulp gerne benutzt!). Dann las ich 2016 über den MEAN-Stack, Meteor, React, ES6, Babel, Webpack, Module usw. usw. und war verwirrter als je zuvor. Ich fand den ShopTalk Show Podcast und fühlte mich etwas besser (was mich daran erinnert, dass ich ihn wieder mehr hören muss!).
Ich habe das Gefühl, die halbe Miete ist das Verständnis dafür, was was tut, welche Probleme es löst und warum oder wann man es einsetzen sollte. Sobald man einige Dinge versteht, die anderen Dingen helfen, fügen sie sich zusammen und man kann auf dem Wissen aufbauen. Ich bin bei vielen dieser Dinge immer noch im Rückstand, und manchmal ist es überwältigend, aber manchmal ist es ermutigend. Ein Front-End-Entwickler kann so viel tun – JAMstack, Progressive Web Apps, SVG-Animationen, die Canvas-API… man kann so ziemlich alles bauen, was man will, und das alles geschieht im Web, das immer bequemer zugänglich geworden ist. Schon als Kind in den frühen 2000er Jahren dachte ich, es sei etwas Magisches, eine Website aufzurufen und festzustellen, dass es sich eigentlich gar nicht um eine Website handelt, sondern um eine Art interaktive Kunst oder ein Spiel.
Manchmal mache ich nur Designarbeit, manchmal nur Code, aber meistens fühle ich mich eher wie ein Front-End-Designer, ein Begriff, der von Brad Frost in diesem fantastischen Artikel ➜ geprägt wurde.
Ich packe immer noch jede Aufgabe an, wie sie kommt, und versuche, alles auf die „richtige“ Weise zu tun, lerne ständig und baue mein Wissen im Laufe der Zeit aus. Und es ist irgendwie tröstlich zu wissen, dass ich nicht allein bin, und am Ende läuft es (irgendwie) alles auf HTML, CSS und JavaScript hinaus.
Es freut mich zu hören, dass jemand anderes sagt, CSS sei sein Favorit, da es auch immer mein Favorit war und das anscheinend nicht üblich ist.
Hier sind Sie in guter Gesellschaft. :)
Einer der besten Posts, die ich je über Front-End gelesen habe. Danke
Absolut fantastisches Stück, Chris. Als Designer mit fast keiner Entwicklungserfahrung hat es mir eine ganz neue Wertschätzung für das Frontend vermittelt.
Mensch, ich versuche, Web-Front-End im Selbststudium zu lernen, und dieser Artikel macht mich seekrank. Wie soll ein freiberuflicher Entwickler mit all dem Schritt halten und Arbeit finden? Es wird lächerlich.
Toller Artikel und fasst meine aktuellen Gefühle zusammen. In einem Wort: müde. Ich bin ein Full-Stack-Entwickler und eines meiner Front-End-Projekte ist eine Single-Page-Webanwendung, die mit AngularJs erstellt wurde. Nach ein paar Jahren, in denen ich ziemlich versiert geworden bin, schlägt mein Chef vor, wir sollten stattdessen Angular2.0 verwenden. Plötzlich soll ich in der Lage sein, in Typescript zu schreiben, mich in Komponenten einzuarbeiten und im Grunde ein völlig neues Framework von Grund auf neu zu lernen, nur um genau die gleiche Web-App zu produzieren. (Ich habe Nein gesagt). Aber von da an habe ich versucht, mit all den neuen Webtechnologien Schritt zu halten (oder besser gesagt, aufzuholen), damit ich mich nicht mehr so hoffnungslos veraltet fühle, aber ehrlich gesagt gibt es einfach keine Zeit. Und jetzt, zusätzlich zu allem anderen, gibt es cloudbasierte Dienste, die eine völlig neue Art der Erstellung von Webanwendungen und alles andere bieten. Es ist fast unmöglich, nur mit dem Schritt zu halten, was da draußen ist und was sie tun, um zu wissen, ob es einen besseren Weg gibt, das Problem zu lösen.
An diesem Punkt als Front-End-Entwickler, Full-Stack-Entwickler? Ich weiß nicht einmal mehr, wie ich beschreiben soll, was wir tun. Alles, was ich sagen kann, ist, dass wir im Grunde alles machen.
Toller Artikel, Chris. Ich könnte nicht mehr zustimmen. Für mich, der mit HTML und CSS angefangen hat und sie liebt, ist die Front-End-Entwicklung scheinbar komplex geworden. Dazu kommen Überlegungen zu CMS-Ansätzen mit Kundenprojekten und die Einrichtung des Zugangs für sie, damit sie selbst bearbeiten können (und dann das Training), und es ist viel, mit dem man Schritt halten muss. Die Verantwortlichkeiten sind stark gewachsen. Ich bin mir nicht sicher, ob der Respekt für das notwendige Wissen in diesen Rollen durch Arbeitgeber mitgewachsen ist, da Titel oft "alles tun" für mittelmäßige Gehälter beinhalten, soweit ich in meiner geografischen Region beobachtet habe. Ich frage mich manchmal, ob all diese Änderungen für grundlegende Website-Projekte wirklich notwendig sind, aber es mangelt nicht an Optionen, was wohl auch gut ist. Ich liebe diese Arbeit immer noch, aber es ist zweifellos oft überwältigend, Schritt zu halten, besonders mit so wenig Zeit zum Lernen.
Wunderbar zu lesen! Es ist so schön zu wissen, dass ich nicht allein bin, wenn ich mich hinterherhinkend oder in bestimmten Bereichen mangelhaft fühle. Ich mag zu denken, dass ich genug weiß, um jede Aufgabe zu bewältigen, die mir gestellt wird, aber ich fühle mich definitiv, dass ich neuere Technologien auffrischen sollte.
Auch das über die PHP include()s hat mich zum Kichern gebracht und mir ein paar Flashbacks zur frühen PHP-Programmierung beschert, also danke dafür, Chris!
Toll zu lesen!
Das ist die Art von mentaler Therapie, die ich brauchte. Danke, Chris, dass du die Fallstricke unseres Berufs in diesem dringend benötigten und unschätzbar wertvollen Beitrag herausgearbeitet hast.
Danke dafür, Chris, es ist beruhigend, von jemandem wie dir zu hören. Ich arbeite fast 10 Jahre in dieser Rolle und bin kürzlich auf Jobsuche. Die lange Liste von Erwartungen und verschiedenen Technologien, die in Stellenbeschreibungen für FED gefragt werden, ist manchmal etwas überwältigend, selbst für einen Praktiker.
Ich habe das Gefühl, dass es sich verwirrt hat, als es sich ausdehnte und traditionellere Programmiererideale aufnahm. Was Interviews angeht, kann ich leidenschaftlich über Design, Benutzer, Browser und all die Dinge sprechen, die Sie oben erwähnen, aber jetzt geht es am Tag darum, Leetcode und Dijkstra zu meistern. Das steht also jetzt auf der Liste.
</Seufz>WOW, einfach WOW. Kann ich diesen Artikel zu meinem Top-Artikel des Jahres 2020 nominieren? Ich liebe ihn, so viel zum Nachdenken. Danke, dass du das in Worte gefasst hast, was schwer auszudrücken ist!
Eine FED-Karriere ist der Rolle eines Nebendarstellers in einem Film sehr ähnlich. Ein Nebendarsteller ist der kritischste Teil eines Films. Seine/ihre schauspielerischen Fähigkeiten und die Leidenschaft für die Verkörperung einer Figur können den Haupthelden übertreffen oder übertreffen. Sie tragen viele Hüte, wie das Anheben des Drehbuchs, das Ermutigen von Co-Darstellern, das Hinterlassen eines bleibenden Eindrucks beim Publikum. In finanzieller Hinsicht kämpfen Charakterdarsteller sehr. Ihr Erfolg beruht meist auf Glück oder guten kommerziellen Drehbüchern. In ihrer Freizeit machen sie Theater, Bühnenarbeit, nur um ihr Handwerk zu verfeinern oder zu schärfen. Auf der anderen Seite ist ein Hauptheld bereits im Bewusstsein des Publikums durch Statussymbol, Kassenschlager usw. etabliert. Ähnlich wie bei ihnen hat ein Backend-Entwickler bereits eine wettbewerbsfähige Ausbildung und Erfahrung hinter sich, um Datenbanksysteme zu entwerfen und zu erstellen. Der Erfolg eines Front-End-Entwicklers basiert auf Ihrem Job, wie erfolgreich Sie Ihre Arbeit erledigen und geschäftliche Anforderungen für Ihr Unternehmen lösen. Andere Dinge, die zu Ihrem Erfolg beitragen, sind Ihr Hunger nach dem Handwerk, manchmal Glück und die Bewahrung der geistigen Gesundheit auf Ihrem Weg, ein FED zu werden. Das Auswendiglernen eines JS-Frameworks wird Sie nirgendwohin bringen. Viele Menschen werden neben Ihnen eine Rolle für Ihren Erfolg in diesem Bereich spielen.
So ein wunderschön geschriebener Artikel
Interessanter Artikel... Ich fühlte mich am Ende definitiv wie ein Hochstapler.
Ich wurde vor fast 15 Jahren zum ersten Mal mit Webentwicklung in Berührung gebracht, aber irgendwie habe ich es geschafft, nichts anderes als HTML, CSS und WordPress zu lernen. Ich hatte oft das Gefühl, ich sollte Javascript und PHP lernen, aber es gab immer Ablenkungen und ich kam damit durch, schicke WordPress-Themes und Plugins für komplexe Funktionalitäten zu verwenden. Ich habe mich schließlich entschieden, keine WordPress-Sites mehr zu erstellen und stattdessen für ein einzelnes Unternehmen zu arbeiten. Es ist gleichzeitig erleichternd und beängstigend, nur einen Kunden zu haben. Ich habe das Gefühl, ich muss alles verstehen, was mit unserer Website zusammenhängt, und alles rationalisieren. Ich weiß nicht, was ich als Nächstes lernen soll.
Über Komponenten und Zustandsverwaltung hinaus haben wir auch die semantische Seite – die zitiert wird –, aber sie könnte auch mit vielen SEO-Techniken kombiniert werden: von der Optimierung des Markup für eine ausgefallene Struktur bis zur Verwendung von Microdata. Ich glaube, das fällt unter das Thema "Performance", denn ein guter Teil der SEO-Optimierungen kommt davon, die Website für den Benutzer blitzschnell zu machen; die Checkliste der Verantwortlichkeiten wächst also jedes Mal, wenn wir darüber nachdenken.
Gute Lektüre übrigens, Chris! Danke für diesen großartigen Text.
Ausgezeichneter Beitrag! Ironischerweise habe ich 6 Wochen gebraucht, um ihn zu lesen, weil er hinter 100 anderen Tabs in meinem Browser vergraben war – ich starte ein neues persönliches Projekt und habe beschlossen, React zu verwenden, obwohl ich die letzten 2 Jahre ausschließlich Vue-Entwicklung gemacht habe, also habe ich mich mit React und Redux und CSS-in-JS und usw. usw. vertraut gemacht.
Der Grund, warum ich React verwende (obwohl ich es im Vergleich zu Vue absolut hasse!), ist, dass ich das Gefühl habe, ich sollte es kennen und dass mir etwas fehlt, wenn ich es nicht kenne.
Dieser Artikel hat mir vielleicht gerade geholfen, das Projekt zu retten – ich bleibe wohl bei React, aber darüber hinaus habe ich gerade angefangen, Go-Tutorials zu lesen, und dachte, ich würde vielleicht das Backend damit erstellen, anstatt bei etwas zu bleiben, das ich bereits kenne, wie Sanity, WordPress oder Keystone. Wenn ich damit weitergemacht hätte, wäre ich wahrscheinlich endgültig im Dickicht verloren gewesen.
Ich kämpfe schon seit einiger Zeit mit ähnlichen Ideen. Die Verantwortlichkeiten von Front-End-Entwicklern steigen von Jahr zu Jahr, während von Designern erwartet wird, dass sie hübsche Bilder in Figma zeichnen. Als UX-Designerin möchte ich meine Fähigkeiten in semantischem HTML, CSS, Animationen und Barrierefreiheit einsetzen, aber nein, ich muss endlose Fehler protokollieren, um sie in Form zu bringen, und auf einem Backlog von Verbesserungen sitzen, für die niemand Zeit hatte.
Ich wäre so glücklich, diese Bereiche zu besitzen, die sich direkt auf das Benutzererlebnis auswirken. Ich würde argumentieren, dass sie das Erlebnis sind! Die Werkzeuge, die Designer zum Erstellen von Benutzeroberflächen haben, fehlen alle Arten von Nuancen, die HTML, CSS und ein wenig grundlegendes Javascript Ihnen bieten.
Ihre Aussage, dass JavaScript HTML und CSS verdrängt hat, gefällt mir nicht, aber ich habe keinen Zweifel daran, dass es wahr ist. Ich habe das Gefühl, wir ertrinken wegen ihm in Komplexität. Ich würde gerne sehen, wie Designer dieser Herausforderung gewachsen sind und den Entwicklern etwas Gewicht abnehmen.