Dieser Titel stammt aus dem Eröffnungstweet eines Threads von Benjamin De Cock. Ich selbst würde nicht so weit gehen. Was ich an dem Begriff mag, ist, dass „Front-End“ wörtlich übersetzt *den Browser* bedeutet, und obwohl sich die Arbeit stark verändert hat – und vielleicht vor unseren Augen zerfällt – ist die Tatsache, dass die Arbeit im Browser stattfindet, immer noch wahr. Wir sind Browser-Leute. Diesen Punkt habe ich in meinem Vortrag „Ooooops I guess we’re full-stack developers now“ versucht zu machen.
Ich mag aber Benjamins Haltung sehr. Es gibt eine Plage von Implementierungen von Dingen im Web, die sowohl *umständlicher* als auch *schlechter* sind, weil sie etwas neu implementieren, das der Browser besser und „kostenlos“ anbietet. Denken Sie an Slider: Scrollverhalten, Snap-Punkte, feste/klebrige Positionierung, Formularsteuerelemente, Animationen usw.
Unsere Branche scheint anerkannt zu haben, dass Backend- und Frontend-Entwickler sehr unterschiedliche Fähigkeiten benötigen (auch wenn sie oft die exakt gleiche Sprache verwenden), und doch kämpft sie damit zu erkennen, dass zu viel in den Begriff „Front-End-Entwickler“ gebündelt ist.
Das ist der knifflige Teil. Das ist das Herzstück von The Great Divide. Es gibt eine Menge von Front-End-Entwicklern, deren Arbeit sich ausschließlich auf JavaScript konzentriert. Man könnte sie „JavaScript Engineers“ oder „JavaScript Developers“ nennen, und das fühlt sich richtig an. Ich bin mir jedoch nicht sicher, wie man jemanden nennt, der ein großartiger Front-End-Entwickler ist, sich nicht besonders auf JavaScript konzentriert, aber auf andere Aspekte des Front-Ends achtet.
Der moderne Frontend-Entwickler ist meistens ein „Multitalent“, das JS (oder sogar nur ein Framework) beherrscht und HTML/CSS kaum als notwendiges Übel toleriert. Das ist verständlich. Ich glaube fest daran, dass dies eine andere Spezialisierung ist und zu viel für eine einzige Person.
Ja, das ist in Ordnung! Die Spaltung ist nichts Schlechtes; sie ist einfach da. Frontend-Teams brauchen JavaScript-Spezialisten *und* CSS-Spezialisten *und* Barrierefreiheits-Spezialisten *und* Performance-Spezialisten *und* Animations-Spezialisten *und* Internationalisierungs-Spezialisten und, und, und, und. Sie müssen nicht alle separate Personen sein. Leute können in mehreren Dingen gut sein. Es ist nur außergewöhnlich selten, dass Leute in allem gut sind, selbst wenn sie sich nur auf Frontend-Fähigkeiten beschränken.
Sehr lustig vom Frontend-Meister
Danke. Und was ist mit dem Full-Stack Developer?
E-Mail, die ich gerade erhalten habe
Also möchte ich fragen: Bin ich ein Front-End-Entwickler oder etwas anderes?
Seltsamerweise haben wir in der französischen Branche einen Titel genau dafür, aber er scheint auf Englisch nicht zu existieren. Wir nennen das einen „intégrateur“, der eine PSD-Vorlage nimmt und sie in HTML, CSS und JavaScript integriert. Das gibt es schon so lange ich denken kann, lange bevor wir die Vorstellung von „Front-End-Entwickler“ hatten, die mit dem Aufkommen von Frameworks wie Backbone und AngularJS aufkam.
Ja, das bist du. Weil du an der Vorderseite arbeitest.
Ich denke, er ist ein User Interface Developer.
Hallo!
Mein Name ist Igor, ich komme aus Brasilien!
Meiner Meinung nach
Ja
Er schrieb über Kenntnisse „Effekte“. Ich habe gerade den Titel „Creative Front-end Developer“ gesehen.
Es gibt ein Diagramm aus den Jahren 2012/2013, wenn ich mich nicht irre, das ich als Grundlage nehme.
https://i2.wp.com/alexandremagno.net/wp-content/uploads/2012/12/ux-vs-ui-dev-skills-simple.png
Ein Beitrag von dir aus dem Jahr 2017 (https://css-tricks.de/getting-nowhere-job-titles/), den ich sehr mag und der auch Sinn ergibt.
Ehrlich gesagt mag ich den Titel „Full Stack“ nicht, aber er muss verwendet werden, so wie Brad Frost ihn beschreibt.
Liebe Grüße!
Ich habe das Gefühl, wir befinden uns im Wilden Westen des UI-Aufbaus im Web. Ich mag eine der Antworten auf Benjamins Tweet.
Schauen Sie sich nur an, wie viel Code ein einfaches Auf- und Zuklappmenü erfordert (Artikel / Demo / Code). Wenn jedes benutzerdefinierte UI-Element von Grund auf neu erstellt werden muss, ist es kein Wunder, dass es nicht performant oder zugänglich ist. Die Zunahme der Komplexität, wenn man von einem Standard-HTML-Element (wie einem `select`) zu einer benutzerdefinierten Implementierung eines `select` übergeht, ist atemberaubend.
Das ist ein bisschen ein Rant, aber das schicke neue CSS ist nicht immer einfach zu implementieren, wenn man IE11 unterstützen muss, also greifen viele Entwickler zu weniger idealen JS-Implementierungen. Web-Entwickler, die viel weniger bezahlt werden als „Software-Ingenieure“, werden gebeten, immer komplexere UIs schnell zu erstellen, und man kann nicht nein sagen, weil sie einem immer ein Beispiel für eine Website zeigen können, die eine Reihe von 2011er jQuery-Plugins verwendet, die das tun, was sie wollen.
Ja, dem stimme ich vollkommen zu, und aus meiner Sicht denke ich auch, dass HTML/CSS und ein wenig JS von „Frontend“ in Richtung „Designer“ verschoben werden. Die wir derzeit in der Branche haben.
Ich glaube auch, dass in den nächsten 5 Jahren die Branche von Designern mindestens HTML/CSS & geringe JS-Kenntnisse erwarten wird. Und das wird die Norm sein. Was denkt ihr darüber?
CSS und HTML können meistens in eine interne oder Drittanbieter-Bibliothek ausgelagert und unendlich wiederverwendet werden. Dies gilt insbesondere für Unternehmen, bei denen Designs dazu neigen, sich strikt an eine Styleguide über mehrere Websites und Seiten hinweg zu halten und das Design nicht allzu radikal ausfällt.
Daher ist es zu diesem Zeitpunkt praktisch ein nachträglicher Gedanke. Wir haben vor Jahren unseren eigenen Styleguide und unsere eigene CSS-Bibliothek erstellt und müssen sie nicht aktualisieren. Daher verbringe ich etwa 98% meiner Zeit mit TypeScript.
DANKE! Ich fühle das so sehr.