ooooops I guess we’re* full-stack developers now

Ich betreibe die Seite CSS-Tricks (die kürzlich ihr 12. Geburtstag hatte), eine Ressourcenseite rund um die Erstellung von Websites.

Ich habe auch die Seite CodePen mitbegründet, eine Social-Coding-Plattform zum Erstellen von Dingen mit Frontend-Technologie.

Ich bin auch Co-Host eines Podcasts namens ShopTalk Show, der bald 400 Episoden erreicht.

Ich bin sicher, ich habe im Laufe der Jahre mit Tausenden von anderen Entwicklern gesprochen, was mir geholfen hat, die Branche und das Spektrum der Arbeit zu verstehen, die erforderlich ist, um Websites zu erstellen.

Was ist ein Frontend-Entwickler?

✅ Es ist ein Job und ein gängiger Jobtitel.

Das ist wichtig, weil es nicht nur um Semantik geht. Es ist ein Job, für den Leute eingestellt werden, und es ist ihr Jobtitel bei der Arbeit. Nichts Persönlicheres als Geld.

Wie wir definieren, was dieser Job ist und was die Erwartungen sind, ist persönlich.

Schauen Sie auf jedes Jobportal, das Technologiejobs anbietet, und Sie werden Stellenausschreibungen für Frontend-Entwickler sehen.

Was ist ein Frontend-Entwickler?

✅ Es befasst sich sehr direkt mit dem Browser, Geräten und Benutzern.

Jeder, der an Websites arbeitet, hat wahrscheinlich den ganzen Tag seinen Browser geöffnet, aber Frontend-Entwickler leben darin. Sie haben DevTools geöffnet. Sie haben mehrere Browser geöffnet und testen über verschiedene Versionen und Plattformen hinweg.

Entscheidend ist, dass sie sich um die Benutzer kümmern, die mit diesen Browsern und assistiven Technologien interagieren.

Mina Markham erklärt auf hoher Ebene, was ein Frontend-Entwickler ist

Es gibt eine Unterscheidung zu Backend-Entwicklern. Nicht, dass Backend-Entwickler sich nicht um Benutzer kümmern, es ist nur so, dass die Verantwortung delegiert ist.

Monica Dinculescu bringt es gut auf den Punkt

Der Browser steht im Mittelpunkt der Arbeit der Frontend-Entwicklung. Was auch immer Sie tun, wenn Sie sich darum kümmern, wie Dinge letztendlich in einem Browser aussehen und funktionieren, das ist Frontend-Entwicklung.

Es ist schwieriger, als ihm zugestanden wird.

Was ist ein Frontend-Entwickler?

✅ Es gibt unzählige Werkzeuge, aber letztendlich läuft es auf HTML, CSS und JavaScript hinaus.

Das sind die Sprachen, die Browser sprechen. Ja, ja, es gibt auch SVG und PNG und was auch immer, aber Sie wissen, was ich meine.

Welche anderen Werkzeuge Sie auch verwenden, alles läuft darauf hinaus, was an den Browser geliefert wird, und dafür sind Frontend-Entwickler verantwortlich.

Nicht alle Frontend-Entwickler beherrschen alle Sprachen gleich gut. Tatsächlich gibt es viele Entwickler, die kaum JavaScript schreiben, aber ansonsten sehr erfolgreiche Frontend-Entwickler sind. Und es gibt auch viele Frontend-Entwickler, die fast nichts anderes als JavaScript schreiben. 🤯

Mein Artikel The Great Divide befasst sich mit der Spaltung zwischen Frontend-Entwicklern, die sich stark mit JavaScript beschäftigen, und denen, die es nicht tun.

Es sind nicht nur meine Gedanken, sondern eine Sammlung von Zitaten vieler anderer, die die Kluft spüren.

Brad Frost prägt die Begriffe „Front des Fronts“ und „Back des Fronts“, um eine weitere Art von Spaltung zu beschreiben. Er weist darauf hin, dass dies keine Schwäche, sondern eine Stärke ist, diese unterschiedlichen Leute zusammenzubringen.

Bei Google wird die Kluft erkannt und nach Jobtitel aufgeteilt. Außerdem werden diese beiden Karriereleitern gleich bezahlt.

Kein Zweifel daran. Insbesondere seit etwa 2015 ist JavaScript als Sprache explodiert.

Unsere Jobs sind bereits faszinierend! Wir alle befassen uns mit Browsern, Benutzern und Geräten. Das ist Kern. Aber wir alle wissen unterschiedliche Dinge und setzen dieses Wissen tatsächlich ein.

Einige von uns sind Designer. Einige von uns sind Fotografen. Einige von uns kennen das Gesetz sehr gut. Einige von uns sind sehr auf Leistung bedacht. Einige von uns spezialisieren sich auf Barrierefreiheit. Einige von uns nutzen soziale Medien.

Metaphorisch könnte man uns wie diesen Baum abbilden.

Diese Metapher hält wahrscheinlich nicht ganz stand, aber die Spaltung sieht ungefähr so aus. Wir teilen immer noch einige Grundlagen, und wir verzweigen uns immer noch und wissen viele verschiedene Dinge, aber eine Seite konzentriert sich stark auf JavaScript und die Arbeit vom Typ „Back of the Front“, die andere nicht.

Da dieser Vortrag über die langsame Verwandlung von Frontend-Entwicklern geht, die immer mehr Full-Stack-Arbeit leisten und diese Rolle immer breiter und breiter wird, gehen wir einfach davon aus, dass wir über Frontend-Entwickler sprechen, die den stärkeren JavaScript-Weg einschlagen.

Einige Dinge, die man tun muss, um Websites zu erstellen, sind irgendwie Stacks weitergezogen.

Backend → JavaScript

Das heißt, von einer eher Backend- und Freunde-Fähigkeit hin zu einer Frontend- und Freunde-Fähigkeit.

Es scheint mir, dass Projekte, die nicht auf JavaScript basieren und serverseitig gerendert werden, nie wirklich Komponenten umarmt haben. (Es gibt Beispiele, klagt mich nicht an, aber ich meine die riesige PHP-CMS-Landschaft und Ruby on Rails und große Player davon.) Man hatte Vorlagen und Includes, aber sie sind ein blasser Vergleich zu echtem Component-Driven Development.

Es ist faszinierend zu sehen, dass, obwohl es eine große Vielfalt an JavaScript-basierten Frameworks gibt, die sich alle über viele Dinge uneinig sind, sie sich alle über die Idee von Komponenten einig sind. Selbst native Webkomponenten... es steckt schon im Namen.

Werfen wir einen kurzen Blick auf CodePen, das heutzutage (meistens) eine React-gestützte Seite ist.

Selbst dieses winzige SVG-Symbol? Es ist eine Komponente. Wir nennen es eine <SVGIcon />-Komponente, da sie einige für uns nützliche Dinge schön abstrahiert.

Ein Symbol mit einer Zahl zu koppeln ist eine weitere Komponente, da es sich um ein weiteres wiederkehrendes Muster handelt und zusätzliche Verantwortung haben könnte, wie z. B. das Klicken.

Diese gesamte Reihe von MetaItem-Komponenten könnte eine Komponente werden, zusammen mit anderen Aspekten der Anzeige eines Items.

Daher wird natürlich das gesamte Item selbst zu einer Komponente.

Dies sind visuelle und funktionale Abstraktionen dessen, was wir zum Erstellen von UIs benötigen. Darunter liegt semantisches HTML, aber die Abstraktionen sind Bausteine unserer eigenen Erfindung.

Immer größere Bereiche werden zu Komponenten. In diesem Fall ist es sinnvoll, dass ein Raster von Elementen zu einer Komponente wird, damit es dieses Layout und Dinge wie Paginierung verwalten kann.

Es stimmt! Komponenten sind nicht nur in der Lage, intelligente Bausteine für UIs für Frontend-Entwickler zu sein, sondern Designer arbeiten größtenteils auch bereits so. Tools wie Figma, Sketch und Adobe XD werben mit Dingen wie „Symbolen“, die spirituell verbunden sind.

Ich finde, andere Entwickler sagen: „Cool, Komponenten, ich verstehe.“

Der Umgang mit URLs und der allgemeinen Website-Struktur fühlte sich früher hauptsächlich als Backend-Aufgabe an. Heutzutage wird „Routing“ zunehmend zu einer Frontend-Aufgabe.

<Suspense fallback={<Spinner />}>
  <Route
    exact
    path={['/', '/picked-pens']}
    component={anon ? AnonHomepage : Homepage}
  />
  <Route path={['/topics', '/topic']} component={Topics} />
  <Route path={['/challenges']} component={Challenges} />
  <Route path="/instagram" component={Instagram} />
  <Route path="/dashboard" component={Dashboard} />
  <Route
    path={['/profile_new/:username', '/profile_new/team/:teamname']}
    component={Profile}
  />
</Suspense>

Wenn man sich die CodePen-UI ansieht, hören die Komponenten nicht beim Raster auf. Buchstäblich alles wird zu einer Komponente. Die Tabs, die Titel, die Schaltflächen...

... die Formulare, die Menüs, die Seitenleiste...

Letztendlich wird die ganze verdammte Seite zu einer Komponente.

Sobald die gesamte Seite eine Komponente ist, hat man im Grunde die URL in eine Komponente verwandelt.

Sie sind sozusagen zum Architekten der gesamten Website geworden.

Das ist... viel. Denken Sie an all die Arbeit, die Sie als Frontend-Entwickler bereits leisten müssen. Nichts davon verschwindet. Sie sind jetzt nur für viel mehr verantwortlich. Kein Wunder, dass sich Frontend-Entwickler zunehmend wie Full-Stacker fühlen.

Eine weitere Sache, die in die Hände von Frontend-Entwicklern gefallen ist, ist die Zustandsverwaltung. Das ist jetzt im Kern der meisten JavaScript-Frameworks und ein ziemlich tolles Konzept, das viele Frontend-Spaghetti-Probleme der Vergangenheit beseitigt.

Aber der Zustand wird oft aus dem Abrufen von Daten gefüllt, und das liegt jetzt auch oft auf unseren Schultern.

Noch komplizierter ist es, diese Daten bei Bedarf zu ändern und die Daten bei Bedarf an Server zurückzusenden.

GraphQL ist eine ziemlich gute Antwort auf einige dieser Probleme. GraphQL ist vieles und für verschiedene Menschen auf unterschiedliche Weise bedeutungsvoll. Aber für mich geht es um Ermächtigung.

Mit einem starken GraphQL-Endpunkt und Tools wie Apollo, die mir Werkzeuge für mein JavaScript-Framework geben, kann ich als Frontend-Entwickler an alle Daten gelangen, die ich zum Erstellen von Benutzeroberflächen benötige.

import gql from "graphql-tag";
import { Query } from "react-apollo";

const GET_DOGS = gql`
  {
    dogs {
      id
      breed
    }
  }
`;

const Dogs = () => (
  <Query query={GET_DOGS}>
    {({ loading, error, data }) => {
      if (loading) return `Loading...`;
      if (error) return `Error`;

      return (
        {data.dogs.map(dog => (
          <div key={dog.id}>
            {dog.breed}
          </div>
        ))}
      );
    }}
  </Query>
);

Beachten Sie, dass ich nicht nur meine eigenen Daten abrufe, sondern auch die asynchrone Natur der Komponente verwalte. Soll ich sofort ein Skelett anzeigen? Einen Spinner? Soll ich das Rendern verzögern, bis die Daten bereit sind? Was passiert, wenn es eine Zeitüberschreitung gibt oder ein anderer Fehler auftritt?

Ich kann nicht nur Daten abrufen, sondern es liegt an mir, diese Daten zu aktualisieren und in Form von Mutationen über GraphQL zurückzusenden.

mport gql from "graphql-tag";
import { Mutation } from "react-apollo";

const ADD_TODO = gql`
  mutation AddTodo($type: String!) {
    addTodo(type: $type) {
      id
      type
    }
  }
`;

const AddTodo = () => {
  let input;

  return (
    <Mutation mutation={ADD_TODO}>
      {(addTodo, { data }) => (
        <div>
          <form
            onSubmit={e => {
              e.preventDefault();
              addTodo({ variables: { type: input.value } });
              input.value = "";
            }}
          >
            <input
              ref={node => {
                input = node;
              }}
            />
            <button type="submit">Add Todo</button>
          </form>
        </div>
      )}
    </Mutation>
  );
};

Mutationen sind nicht viel komplizierter als Abfragen, aber es ist umso mehr Arbeit, die auf meiner Platte als Frontend-Entwickler liegt. Arbeit, die vorher fast sicher in den Bereich der Backend-Entwicklung fiel.

Beachten Sie, dass die obigen Beispiele illustrativ für GraphQL waren, aber durch Apollo Client in React implementiert wurden.

Während wir über Komponenten, Abfragen und Mutationen sprechen, fügen wir noch etwas hinzu: Styling.

Frontend-Entwickler waren schon immer für das Styling zuständig, aber in einer Welt der Komponenten, die in so vielen anderen Hinsichtenselbsttragend sind, macht es Sinn, die Styling-Informationen auch zusammenzufassen.

Hier verwenden wir CSS-Module, um die Stile auf eine bestimmte Komponente zu beschränken. Wir können und verwenden immer noch globale Stile und verwenden weiterhin Sass für nützliche globale Abstraktionen.

.root {
  display: grid;
}

import styles from './styles.scss';

<NewsItems className={styles.root} />

Das Ergebnis dieser Komponentisierung und Zusammenfassung sind nette kleine Ordner, die alles von Logik über View-Templates bis hin zu Abfragen und Mutationen und Styling zusammen enthalten.

Das ist praktisch, hat aber coole interessante Nebeneffekte. Zum Beispiel können JavaScript-Bundles das enthalten, was sie brauchen (Code Splitting). Das Styling wird nicht aufgebläht, da das Styling mit den Komponenten verschwindet, wenn sie nicht mehr verwendet werden. Ganz zu schweigen davon, dass das Benennen von Dingen weniger stressig ist, da die Benennung dateibezogen ist.

Die GraphQL-Dokumentation ist ganz nett. Ich mag, was Kyle Mathews sagt (ungefähr bei 20:24) über React, das eine ganze Klasse von Frontend-Entwicklungsproblemen beseitigt, und wie GraphQL eine ähnliche Sache tut.

Für jedes Projekt? Natürlich nicht. Aber für die eher großen und komplexen Apps, die wir bauen und warten sollen: ja.

Alle riesigen Verantwortlichkeiten, die Frontend-Entwickler bereits haben

• Umsetzung des Designs
• Gestaltung des Designs als Teil eines Systems
• Sicherstellung der Barrierefreiheit
• Sorgen um die Performance
• Tests über Browser hinweg
• Tests über Geräte hinweg
• Sich um das UX kümmern

Hallo, großer Haufen neuer Verantwortlichkeiten

• Component-Driven Design, Entwerfen unserer eigenen Abstraktionen
• Website-Architektur
• Routing
• Eigene Daten abrufen
• Mit APIs sprechen
• Daten ändern
• Zustandsverwaltung

Der Heuhaufen an Verantwortlichkeiten wächst und wächst und wächst.

Das soll nicht heißen, dass wir alle jeden einzelnen Teil davon kennen und perfekt beherrschen müssen, aber es soll heißen, dass dies Aufgaben sind, die in den Bereich der Frontend-Webentwicklung fallen.

Peggy Rayzis spricht darüber, wie weit der Begriff Frontend-Entwickler geworden ist und dass wir uns wahrscheinlich spezialisieren.

LAMP steht für Linux, Apache, MySQL und PHP. Das ist ein ziemlich alter Stack, aber er ist immer noch sehr wichtig. Er ist die Grundlage für viele CMS. LAMP ist, wie der Stack genannt wird.

Wenn ich ein Frontend-Entwickler in diesem Stack bin, bin ich weit am anderen Ende des Spektrums und berühre nicht viel von der Technologie, auf die sich der Stack bezieht.

MEAN ist ein weiterer Stack, der für MongoDB, Express, Angular und Node steht. Beachten Sie, dass das Betriebssystem nicht mehr erwähnt wird.

Insbesondere Angular ist ein Frontend-Framework, sodass der Stack es bereits einzubeziehen beginnt. Wenn ich ein Frontend-Entwickler bin, überschneidet sich das, woran ich arbeite, mit dem Stack.

Serverless verschiebt den Stack weiter nach rechts. Wir kümmern uns nicht einmal mehr darum, auf welchen Servern der Code läuft, es ist einfach serverseitiger Code, der APIs nutzt und erstellt.

Wenn ich ein Frontend-Entwickler in dieser Welt bin, überschneidet es sich, da ich vielleicht sogar meine JavaScript-Fähigkeiten nutze, um diese Serverless-Funktionen zu schreiben und die APIs zu verdauen.

Shawn Wang nannte Design Systems, TypeScript, Apollo GraphQL und React eine STAR-App.

Das ist... äh... alles Frontend-Kram.

Es scheint mir, dass sich die Art und Weise, wie wir über die wichtige Technologie sprechen, die Websites antreibt, immer mehr in Richtung des Frontend-Entwickler-Spektrums verschiebt.

Ich habe eine Website über Serverless-Kram gemacht, weil ich es cool und wichtig finde.

Ich betrachte JAMstack JAMstack als Teil der Serverless-Bewegung. Naheliegend.

JavaScript, APIs und Markup. Obwohl ich, halb im Scherz, sagen würde, dass SHAMstack mehr Sinn ergibt.

Hier ist ein perfektes Beispiel für eine JAMstack-Website, die Serverless-Technologie nutzt, um die Dinge zu tun, die sie tun muss.

Es ist eine Website, die kommende Konferenzen im Bereich Frontend-Entwicklung auflistet.

---
title: JAMstack_conf_ldn
url: 'https://jamstackconf.com/london/'
cocUrl: 'https://jamstackconf.com/london/code-of-conduct'
date: 2019-07-09T08:00:00.000Z
endDate: 2019-07-10T16:00:00.000Z
location: 'London, England'
byline: 'Learn how to design, develop, and deploy fast, modern web projects that run without web servers.'
---

Following the inaugural [JAMstack_conf in San Francisco](https://2018.jamstackconf.com/) in 2018, we're now also bringing an edition to London where we'll have talks about how to design, develop, and deploy fast, modern web projects that run without web servers.

Jede Konferenz ist eine Markdown-Datei mit Front Matter, um Metadaten zu beschreiben, die mit der Konferenz verbunden sind, wie Stadt und Datum.

Ich habe nicht bewusst versucht, eine Datenbank zu vermeiden, aber dies schien die perfekte Art von Website für die Verwendung eines Static Site Generators zu sein, und die Datenanforderungen sind so einfach, dass flache Markdown-Dateien gut passen.

Jede Konferenz ist also eine Markdown-Datei, und es gibt einige grundlegende Vorlagen in Nunjucks, und Eleventy ist wunderbar für die Verarbeitung dieser Art von Einrichtung.

Die Seite ist ein öffentliches Repo auf GitHub. Das scheint offensichtlich, aber ich denke, es ist hier enorm wichtig.

Das bedeutet, dass

1. Die gesamte Website befindet sich im Repo. Um sie auszuführen, zieht man sie herunter und führt einen einzigen Befehl aus.
2. Es gibt kein Herumfummeln mit Logins, Berechtigungen oder Anmeldeinformationen.
3. Es öffnet den Inhalt der Website für öffentliche Beiträge, ebenso wie für Design und Funktionalität. Dies war enorm.

Da die Website auf GitHub ist, könnte ich sie einfach auf GitHub Pages lassen, aber es ist ein 2-Sekunden-Prozess, sie auf Netlify zu bringen, was eine massive Verbesserung darstellt. Hier sind ein paar Gründe

• Deploy-Vorschauen. Wenn ich einen Pull Request erhalte, kann ich mir eine Live-URL ansehen, wie die Website nach dem Zusammenführen dieses Pull Requests aussehen wird. Erstaunlich.
• Ich kann Analysen für die Website aktivieren und die bestmöglichen Zahlen erhalten.
• Ich kann mit meinen Bildern programmatisch spielen.

Es gibt aber noch ein paar andere wichtige Punkte...

Mit Netlify CMS erhalte ich eine Benutzeroberfläche, um Inhalte direkt auf der Website zu bearbeiten. Kein Code-Editing oder Git erforderlich, sobald es eingerichtet ist.

Ich brauche nicht einmal Netlify, um Netlify CMS zu verwenden, aber Netlify Identity macht die Authentifizierung millionenfach einfacher.

Schauen Sie sich dieses Feature der Konferenz-Website an. Für jede Konferenz können Sie auf eine Schaltfläche klicken, die ein E-Mail-Eingabeformular anzeigt. Geben Sie eine E-Mail ein und senden Sie sie ab, und die Website sendet eine E-Mail mit Details zur Konferenz.

Das ist eine Backend-Aufgabe. Sie können nicht wirklich E-Mails nur mit Client-seitiger Technologie senden. Sie können mit APIs kommunizieren, die E-Mails senden, aber selbst das erfordert API-Schlüssel, die über Backend-Code geheim gehalten werden müssen.

const SparkPost = require('sparkpost');
const client = new SparkPost(process.env.SPARKPOST);

exports.handler = function(event, context, callback) {
  client.transmissions
    .send({
      content: {
        from: '[email protected]',
        subject: `Conference!`,
        html: `
          <html>
            <body>
              <h1>Hello, World!</h1>
            </body>
          </html>`
      },
      recipients: [{ address: email }]
    })
    .then(data => {
      callback(null, {
        statusCode: 200,
        body: `Message sent!`
      });
    });
};

Ich werde Sparkpost verwenden, um die E-Mail zu senden. Sie bieten APIs zum Senden von E-Mails (das ist der ganze Sinn). Sie bieten auch eine Node.js-Bibliothek, um dies sehr einfach zu machen. Letztendlich nur ein paar Zeilen Code.

Und dieser Code? Es ist JavaScript. Ich bin ein JavaScript-Entwickler. Das ist kein großer Sprung.

Wie führe ich das aus?

Das ist das Fleisch und die Kartoffeln von Serverless: Cloud-Funktionen. Ich spreche von AWS Lambda, Azure Functions, Google Cloud Functions usw.

Die Netlify-Version, die im Grunde AWS Lambda ist, sind Netlify Functions. Es ist wahnsinnig einfach. Sie werfen Ihre Funktionen einfach in einen Ordner namens „/functions/“ und führen sie aus, indem Sie eine relative URL aufrufen.

Ich fühle mich also schon ziemlich full-stackig. Aber wenn man das alles nimmt und noch hinzufügt

• Ich kenne Git
• Ich kann Tests schreiben
• Ich entwerfe
• Ich kenne die Build-Prozesse
• Ich kümmere mich um die Performance
• Ich kann Websites barrierefrei machen
• Ich kann eine grundlegende Deploy-Pipeline aufsetzen

Du kannst dich definitiv spezialisieren. Wahrscheinlich wirst du es sowieso tun. Das ist gut.

„Echte“ Einhörner, diese Leute, die bei jeder Aufgabe im gesamten Spektrum der Website-Erstellung sehr gut sind: so selten wie echte Einhörner.

Ich versuche auch nicht anzudeuten, dass Backend-Entwickler obsolet werden. Tatsächlich sind sie angesichts der Komplexität der Website-Erstellung wichtiger denn je.

Im Moment kann ich den CodePen-Issue-Tracker öffnen und sehe 89 Probleme, die ich nicht allein lösen kann. Ich brauche die Hilfe eines Backend-Entwicklers, um sie zu untersuchen und zu beheben. Ich kann mich als Full-Stacker betrachten, wenn ich will, aber ich weiß, dass Backend-Sachen meine rauen Kanten sind.

Die Dinge enden tendenziell eher so.

Oder in meinem Fall eher so

Das soll niemanden verspotten. Ich meine, vielleicht ein bisschen, aber es zeichnet eine schöne Metapher, die perfekt zu diesem Vortrag passt. Wir sind das ganze Pferd! Der ganze Drache! Aber wir haben raue Kanten. Na und?

Es ist cool zu sehen, wie sich die Technologie rund um unseren Job entwickelt hat, bis zu dem Punkt, dass wir ihn mit unseren Armen umfassen können. Es ist Anlass zur Sorge, wenn wir das Gefühl haben, dass die Komplexität der Webtechnologie die Einstiegshürde erhöht. Das passiert manchmal und es ist nicht gut. Aber es ist auch Anlass zum Jubel, wenn die Webtechnologie so einfach wird, dass Leute Dinge von Anfang bis Ende selbst bauen können. Das ist ziemlich cool.

Während wir produktiv und erstaunlich sind, vergessen wir nicht, dass eine gute Arbeit zu leisten jedermanns Aufgabe ist.

• Gutes UX ist jedermanns Aufgabe
• Gute Performance ist jedermanns Aufgabe
• Gute Sicherheit ist jedermanns Aufgabe
• Gute Barrierefreiheit ist jedermanns Aufgabe
• Mit den Leuten, die Ihre Website nutzen, gut umgehen ist jedermanns Aufgabe

Auch wenn Sie nicht den Code schreiben, der direkt diese Dinge beeinflusst, kümmern Sie sich darum und kämpfen dafür, dass sie gut gehandhabt werden.