Catégories
Astuces et Design

ooooops, je suppose que nous sommes * des développeurs full-stack maintenant

* par "nous sommes", j'entends les développeurs frontaux

Ceci est une version écrite d'une conférence de Jamstack Conf London en 2019 que j'ai préparée pour les participants. Parce que la veille de mon embarquement sur un vol pour ce voyage, j'ai décollé de mon VTT et me suis cassé les deux bras. Je me sentais mal de ne pas pouvoir prononcer le discours, alors je l’ai enregistré et je l'ai fait. Je le propose ici parce que j'aime garder une grande partie de mon écriture sous un même toit et m'amuser un peu avec WordPress Gutenberg.

👋 Hé! J'ai passé toute ma carrière à m'identifier en tant que développeur frontal et essayer d'aider les autres à devenir meilleurs dans ce domaine.

et mon garçon sont mes bras fatigués

Je dirige le site CSS-Tricks (qui a récemment fêté son 12e anniversaire), un site de ressources consacré à la création de sites Web.

J'ai également cofondé le site CodePen, une plate-forme de codage social consacrée à la création d'objets avec la technologie front-end.

Je co-anime également un podcast appelé ShopTalk Show qui comporte 400 épisodes.

Je suis sûr que j’ai parlé à des milliers d’autres développeurs au fil des ans, ce qui m’a aidé à comprendre le secteur et l’éventail du travail nécessaire pour créer des sites Web.

Qu'est-ce qu'un développeur front-end?

✅ C’est un travail et un titre de poste commun.

Ceci est important car ce n’est pas que de la sémantique. C’est un travail pour lequel les gens sont embauchés, et c’est le titre de leur poste au travail. Rien de plus personnel que l'argent.

Comment nous définissons ce qu'est ce travail et quelles sont les attentes est personnel.

Regardez n'importe quel babillard d'offres d'emploi qui contient des emplois technologiques et vous verrez des offres pour développeurs front-end.

Qu'est-ce qu'un développeur front-end?

✅ Il traite très directement le navigateur, les appareils et les utilisateurs.

Tous ceux qui travaillent sur des sites Web ont probablement leur navigateur ouvert toute la journée, mais les développeurs frontaux vivre là-dedans. Ils ont DevTools ouverts. Ils ont plusieurs navigateurs ouverts et testés sur différentes versions et plates-formes.

Fondamentalement, ils se soucient des utilisateurs qui interagissent avec ces navigateurs et technologies d'assistance.

Mina Markham explique ce qu'est un développeur front-end à un niveau élevé:

Il y a une distinction avec les développeurs back-end. Ce n'est pas que les développeurs back-end ne se soucient pas des utilisateurs, c'est juste que la responsabilité est déléguée.

Monica Dinculescu le dit bien:

Le navigateur est au cœur du métier de développement front-end. Quoi que vous fassiez, si vous vous souciez de l’aspect et du fonctionnement des choses dans un navigateur, c’est du développement frontal.

C’est plus difficile qu’on ne le mérite.

Qu'est-ce qu'un développeur front-end?

✅ De nombreux outils sont impliqués, mais en fin de compte, cela se résume à HTML, CSS et JavaScript.

Ce sont les langues que parlent les navigateurs. Oui oui, il y a SVG et PNG et tout le reste aussi, mais vous savez ce que je veux dire.

Quels que soient les autres outils que vous utilisez, tout dépend de ce qui est livré au navigateur, et les développeurs frontaux en sont responsables.

Ils vont venir au travail.

Tous les développeurs frontaux ne connaissent pas tous les langages de la même manière. En fait, il existe de nombreux développeurs qui n'écrivent pratiquement pas de JavaScript, mais qui sont par ailleurs des développeurs frontaux très réussis. Et il y a aussi beaucoup de développeurs front-end qui n'écrivent presque rien mais JavaScript. 🤯

Mon article The Great Divide s'intéresse à la fracture entre les développeurs front-end qui sont profondément dans JavaScript et ceux qui ne le sont pas.

Ce ne sont pas seulement mes pensées, mais une collection de citations de nombreuses autres personnes qui ressentent le fossé.

Brad Frost invente les termes «avant du front» et «arrière du front» pour décrire une autre sorte de division. Il souligne que ce n’est pas une faiblesse, mais une force pour rassembler ces différentes personnes.

Chez Google, le fossé est reconnu et divisé par titre de poste. De plus, ces deux échelles de carrière être payé de la même manière.

Développeur Front-End est un terme réel et significatif.

Il n'y aucun doute à propos de ça. Particulièrement depuis 2015 environ, JavaScript a explosé en tant que langage.

(Si vous avez besoin de regarder ces plus gros, utilisez DevTools ou autre. Vous êtes des développeurs frontaux, n'est-ce pas?)

Nos métiers sont déjà en plein essor! Nous avons donc tous affaire à des navigateurs, des utilisateurs et des appareils. C’est le noyau. Mais nous connaissons tous des choses différentes et mettons réellement ces connaissances en pratique.

Certains d'entre nous sont des designers. Certains d'entre nous sont des photographes. Certains d'entre nous connaissent très bien la loi. Certains d'entre nous sont bien dans la performance. Certains d'entre nous se spécialisent dans l'accessibilité. Certains d'entre nous adoptent les médias sociaux.

Métaphoriquement, vous pourriez nous cartographier comme cet arbre.

Cette métaphore ne tient probablement pas tout à fait parfaitement, mais la division ressemble un peu à ceci. Nous partageons toujours certains fondamentaux, et nous nous diversifions toujours et connaissons beaucoup de choses différentes, mais un côté est fortement axé sur le travail de type JavaScript et «Back of the Front» et l'autre ne l'est pas.

Étant donné que cette discussion porte sur la lente transformation des développeurs front-end qui commencent à faire plus de travail full-stack et que ce rôle s'élargit de plus en plus, supposons simplement que nous parlons de développeurs front-end qui empruntent la voie la plus lourde de JavaScript.

Un tas de choses que vous devez faire pour créer des sites Web ont en quelque sorte déplacé des piles.

Back End → JavaScript

Autrement dit, d'un ensemble de compétences back-end-and-friends à un ensemble de compétences front-end-and-friends.

Conception et développement axés sur les composants

Merci, Obama JavaScript.

Il me semble que les projets de rendu côté serveur non JavaScript n'ont jamais vraiment intégré les composants. (Il y a des exemples, pas @ me, mais je veux dire à travers le gigantesque paysage de CMS PHP et Ruby on Rails et d'énormes joueurs comme ça.) Vous aviez des modèles et des inclusions, mais ils sont une pâle comparaison avec le développement réel basé sur les composants.

Il est fascinant de voir que s'il existe une grande variété de frameworks basés sur JavaScript qui sont tous en désaccord sur beaucoup de choses, une chose sur laquelle ils sont tous d'accord est l'idée de composants. Même les composants Web natifs… c'est juste dans le nom.

Jetons un coup d'œil à CodePen, qui est un site alimenté par React (principalement) ces jours-ci.

Même cette toute petite icône SVG? C’est un composant. Nous l'appelons un composant parce qu'il résume joliment quelques éléments qui nous sont utiles.

Associer une icône à un nombre est un autre composant, car il s'agit d'un autre motif répété et peut avoir une responsabilité supplémentaire, comme le fait d'être cliqué.

Toute cette rangée de composants MetaItem peut devenir un composant, avec d’autres aspects de l’affichage d’un élément

Alors bien sûr, tout l'élément lui-même devient un composant.

Ce sont des abstractions visuelles et fonctionnelles de ce dont nous avons besoin pour créer les interfaces utilisateur. Il y a du HTML sémantique en dessous, mais les abstractions sont des éléments constitutifs de notre propre conception.

Des zones de plus en plus grandes deviennent des composants. Dans ce cas, il est logique qu'une grille d'éléments devienne un composant, de sorte qu'elle puisse gérer cette disposition et des choses comme la pagination.

C'est vrai! Non seulement les composants peuvent être des abstractions intelligentes de blocs de construction pour les interfaces utilisateur pour les développeurs frontaux, mais les concepteurs travaillent déjà en grande partie de cette manière. Des outils comme Figma, Sketch et Adobe XD vantent des choses comme des «symboles» qui sont spirituellement connectés.

Je trouve que d'autres développeurs sont comme «Cool, composants, je comprends».

Architecture / routage au niveau du site

Back End → JavaScript

OK, je suppose que c'est mon travail maintenant. Cela a du sens et j'aime le contrôle, mais c'est un gros travail sérieux.

La gestion des URL et de la structure globale du site se sentait principalement comme une préoccupation principale. Ces jours-ci, le «routage» devient de plus en plus une préoccupation frontale.

}>
  
  
  
  
  
  

En regardant l'interface utilisateur de CodePen, les composants ne s'arrêtent pas à la grille. Littéralement, tout devient un composant. Les onglets, les titres, les boutons…

… Les formulaires, les menus, la barre latérale…

En fin de compte, toute la page maudite devient un composant.

Une fois que la page entière est un composant, ce que vous avez réellement fait est de transformer l'URL en un composant.

Et maintenant que l'URL est un composant, toutes les URL sont des composants et vous contrôlez l'ensemble du site.

Vous êtes devenu l’architecte de l’ensemble du site, en un sens.

C'est beaucoup. Pensez à tout le travail que vous avez déjà à faire en tant que développeur front-end. Rien de tout cela ne disparaît. Vous êtes simplement responsable de beaucoup plus maintenant. Il n’est pas étonnant que les développeurs frontaux se sentent de plus en plus complets.

Gestion de l'état + obtention et mutation des données

Back End → JavaScript

Une autre chose qui est tombée entre les mains des développeurs frontaux est la gestion de l'état. C'est en quelque sorte au cœur de la plupart des frameworks JavaScript et c'est un très bon concept qui efface de nombreux problèmes de spaghetti frontaux du passé.

Mais l'état est souvent rempli de obtenir données, et cela est maintenant souvent sur nos épaules aussi.

Il est encore plus compliqué de modifier ces données si nécessaire et de renvoyer les données aux serveurs si nécessaire.

GraphQL est une très bonne réponse à certains de ces problèmes. GraphQL est beaucoup de choses et a un sens pour différentes personnes de différentes manières. Mais pour moi, c'est une question d'autonomisation.

Avec un point de terminaison GraphQL solide en place et des outils comme Apollo me donnant des outils à utiliser dans mon framework JavaScript, je peux, en tant que développeur front-end, mettre la main sur toutes les données dont j'ai besoin pour créer une interface utilisateur.

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

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

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

      return (
        {data.dogs.map(dog => (
          
{dog.breed}
))} ); }}
);

Notez que non seulement j'obtiens toutes mes propres données, mais je gère également la nature asynchrone du composant. Dois-je montrer un squelette tout de suite? Un spinner? Dois-je retarder le rendu jusqu'à ce que les données soient prêtes? Que se passe-t-il s'il expire ou s'il y a une autre erreur?

Non seulement je peux avoir données, mais c'est sur moi mettre à jour ces données et les renvoyer via GraphQL sous forme de mutations.

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 (
    
      {(addTodo, { data }) => (
        
{ e.preventDefault(); addTodo({ variables: { type: input.value } }); input.value = ""; }} > { input = node; }} />
)}
); };

Les mutations ne sont pas terriblement plus compliquées que les requêtes, mais c'est d'autant plus de travail que je dois faire en tant que développeur front-end. Un travail qui relevait presque sûrement du domaine du développement back-end auparavant.

Notez que les exemples ci-dessus illustrent GraphQL, mais sont réalisés via Apollo Client implémenté dans React.

Pendant que nous parlons de composants, de requêtes et de mutations, jetons une dernière chose sur la pile: le style.

Les développeurs front-end ont toujours été en charge du style, mais dans un pays de composants autonomes de tant d'autres manières, il commence à être logique de co-localiser également les informations de style.

Ici, nous utilisons des modules CSS pour étendre les styles à un composant spécifique. Nous pouvons et avons toujours des styles globaux, et nous continuons même à utiliser Sass pour des abstractions globales utiles.

.root {
  display: grid;
}
import styles from './styles.scss';

Le résultat de cette mise en composants et de cette colocalisation est de jolis petits dossiers qui ont tout, de la logique, aux modèles d'affichage, aux requêtes et aux mutations, en passant par le style.

C'est pratique, mais cela a des effets secondaires intéressants. Par exemple, les bundles JavaScript peuvent contenir ce dont ils ont besoin (partage de code). Le style ne se gonfle pas, car lorsque les composants cessent d’être utilisés, leurs styles partent avec eux. Sans parler de nommer les choses est beaucoup moins stressant car le nommage est limité à un fichier.

Le documentaire GraphQL est plutôt amusant. J'aime ce que Kyle Mathews dit (environ 20:24) à propos de React qui efface toute une classe de problèmes de développement front-end, et comment GraphQL fait une sorte de chose similaire.

Pour chaque projet? Bien sûr que non. Mais pour les applications quelque peu volumineuses et complexes que l'on attend si souvent de créer et de maintenir: oui.

Toutes les très grandes responsabilités des développeurs front-end ont déjà:

  • Tirage du dessin
  • Intégrer la conception à un système
  • S'assurer qu'il est accessible
  • Se soucier de la performance
  • Tester des éléments sur différents navigateurs
  • Tester des éléments sur plusieurs appareils
  • Transpirer l'UX

Oh bonjour, gros tas de nouvelles responsabilités

  • Conception axée sur les composants, conception de nos propres abstractions
  • Architecture au niveau du site
  • Routage
  • Récupérer nos propres données
  • Parler aux API
  • Mutation des données
  • Gestion d'état

La botte de foin des responsabilités grandit et grandit et grandit.

Cela ne veut pas dire que nous devons tous connaître chaque partie de cela et le faire parfaitement bien, mais cela signifie que ce sont des tâches qui relèvent du domaine du développement Web frontal.

Peggy Rayzis parle de l'ampleur du terme développeur front-end et du fait qu'il est probable que nous nous spécialisions.

Encore une fois, un tas de tâches ont en quelque sorte des piles déplacées. De ce qui était autrefois des jobs back-end à être dans le domaine JavaScript.

Trouvons un spectre et voyons comment cela s'est transformé au fil du temps.

LAMP est Linux, Apache, MySQL et PHP. C’est une pile assez ancienne, mais elle est toujours très énorme. C’est une quantité incroyable d’exécutions de CMS. LAMP est la façon dont on parle de la pile.

Si je suis un développeur front-end travaillant dans cette pile, je suis bien de l’autre côté du spectre, sans toucher à une grande partie de la technologie à laquelle la pile fait référence.

MEAN est une autre pile, faisant référence à MongoDB, Express, Angular et Node. Notez que le système d'exploitation n'est plus mentionné.

Notamment, Angular est un framework frontal, donc la pile commence à l'inclure. Si je suis un développeur front-end, ce sur quoi je travaille chevauche la pile.

Serverless déplace la pile plus à droite. Nous ne nous soucions même plus des serveurs sur lesquels le code s'exécute, il s'agit simplement d'un code côté serveur utilisant et créant des API.

Si je suis un développeur front-end travaillant dans ce monde, je me chevauche en ce sens que je pourrais même utiliser mes capacités JavaScript pour écrire ces fonctions sans serveur et assimiler les API.

Shawn Wang a appelé Design Systems, TypeScript, Apollo GraphQL et React une application STAR.

C'est… comme… tout trucs frontaux.

Il me semble que la façon dont nous parlons de la technologie importante qui alimente les sites Web se déplace de plus en plus vers le spectre des développeurs frontaux.

Voyons rapidement comment sans serveur élargit nos pouvoirs frontaux.

Je considère JAMstack comme faisant essentiellement partie du mouvement sans serveur. Natch.

Javascript, API et balisage. Bien que je dirais, à moitié ironique, que SHAMstack a un peu plus de sens.

Voici un exemple parfait de site JAMstack qui exploite la technologie sans serveur pour faire les choses dont elle a besoin.

C’est un site qui répertorie les conférences à venir liées au développement front-end.

---
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.

Chaque conférence est un fichier Markdown avec Front Matter pour décrire les métadonnées associées à la conférence, comme la ville et les dates.

Je n’essayais pas délibérément d’éviter une base de données, mais cela me semblait être le type de site idéal pour utiliser un générateur de site statique et les besoins en données sont si basiques que les fichiers Markdown plats conviennent parfaitement.

Ainsi, chaque conférence est un fichier Markdown, et il existe des modèles de base dans Nunjucks, et Eleventy est parfait pour traiter ce type de configuration.

Le site est un dépôt public sur GitHub. Cela semble peut-être évident, mais je pense que c'est extrêmement important ici.

Cela signifie que:

  1. L'ensemble du site est dans le repo. Pour l'exécuter, vous le tirez vers le bas et exécutez une seule commande.
  2. Il n'y a pas de tripotage avec les connexions, les autorisations ou les informations d'identification.
  3. Il ouvre le contenu du site pour les contributions publiques, ainsi que la conception et la fonctionnalité. Cela a été énorme.

Le site étant sur GitHub signifie que je pourrais simplement le laisser sur les pages GitHub, mais c'est comme un processus de 2 secondes à mettre en place sur Netlify, ce qui est une amélioration considérable. Voici quelques raisons:

  • Déployez des aperçus. Lorsque je reçois une Pull Request, je peux jeter un œil à une URL en direct de ce à quoi ressemblera le site avec cette Pull Request fusionnée. Incroyable.
  • Je peux activer Analytics sur le site et obtenir les chiffres les plus précis possibles.
  • Je peux manipuler mes images par programmation.

Il y en a cependant quelques autres gros …

Avec Netlify CMS, j'obtiens une interface utilisateur pour modifier le contenu directement sur le site lui-même. Aucune modification de code ou Git n'est impliqué une fois qu'il est configuré.

Je n’ai même pas besoin de Netlify pour utiliser Netlify CMS, mais Netlify Identity rend la partie authentification un million de fois plus facile.

Découvrez cette fonctionnalité du site de la conférence. Pour chaque conférence, vous pouvez cliquer sur un bouton qui révèle un formulaire de saisie par e-mail. Entrez un e-mail et soumettez-le, et le site déclenche un e-mail avec des détails sur la conférence.

C'est une chose d'arrière-plan. Vous ne pouvez pas vraiment envoyer des e-mails avec la seule technologie côté client. Vous pouvez communiquer avec des API qui enverront des e-mails, mais même cela nécessite des clés API qui doivent être gardées secrètes via un code back-end.

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: `
          
            
              

Hello, World!

` }, recipients: ({ address: email }) }) .then(data => { callback(null, { statusCode: 200, body: `Message sent!` }); }); };

J'utiliserai Sparkpost pour envoyer l'e-mail. Ils proposent des API pour envoyer des e-mails (c'est tout l'intérêt). Ils offrent également une bibliothèque Node.js pour le rendre très facile. En fin de compte, quelques lignes de code.

Et ce code? C’est du JavaScript. Je suis un développeur JavaScript. Ce n’est pas un étirement.

Comment puis-je courir cette?

C’est la viande et les pommes de terre des fonctions cloud sans serveur. Je parle d'AWS Lambda, d'Azure Functions, de Google Cloud Functions, etc.

La version Netlify, qui est AWS Lamba sous le capot, est Netlify Functions. C’est stupide et facile. Il vous suffit de jeter vos fonctions dans un dossier `/ functions /` et de les exécuter en cliquant sur une URL relative.

C'est très puissant de pouvoir construire le site entier de l'avant vers l'arrière comme ça.

Revoyons à nouveau le spectre de la technologie en gardant à l’esprit ces éléments modernes.

Je n’ai pas vraiment à me soucier des systèmes d’exploitation et des serveurs. Des produits entiers peuvent être construits sans avoir à s'en soucier.

Je n’ai probablement pas non plus besoin de me soucier beaucoup des bases de données. Ce n’est pas que les bases de données ne sont pas importantes, c’est simplement que mon traitement des données est susceptible de se faire via des API. Peut-être un CMS Headless (par exemple Contentful). Peut-être un outil de stockage de données conçu pour fonctionner via des API (par exemple FaunaDB) ou des bibliothèques sur page (par exemple Firestore).

Il me reste donc maintenant un éventail de technologies dans lesquelles je peux travailler avec toutes ses parties.

Donc je me sens déjà assez complet. Mais vous prenez tout cela et ajoutez:

  • Je connais Git
  • Je peux écrire des tests
  • Je conçois
  • Je connais les processus de construction
  • Je me soucie de la performance
  • Je peux rendre les sites accessibles
  • Je peux configurer un pipeline de déploiement de base

🎉
Tu es Gosh
Danged Right
Je suis un Full-Stack
Développeur!

butttttt

La botte de foin de compétences ici devient extrêmement importante.

Vous pouvez totalement vous spécialiser. Vous le ferez probablement de toute façon. C'est bon.

Des licornes «réelles», ces personnes qui sont très douées pour toutes les tâches sur tout le spectre de la création de sites Web: aussi rares que les vraies licornes.

Je n’essaie pas non plus d’insinuer que les développeurs back-end deviennent obsolètes. En fait, le fait que la création de sites Web soit devenue si complexe, ils sont plus importants que jamais.

Pour le moment, je peux ouvrir l'outil de suivi des problèmes CodePen et voir 89 problèmes que je ne peux pas résoudre seul. J'ai besoin de l'aide d'un développeur back-end pour les explorer et les réparer. Je peux me considérer comme une pile complète si je veux, mais je sais que les trucs d'arrière-plan sont là où se trouvent mes aspérités.

Les choses ont tendance à se terminer un peu plus comme ça.

Ou dans mon cas, plus comme ceci:

Ce n’est pas pour se moquer de personne. Je veux dire, peut-être un peu, mais cela dessine une belle métaphore qui est un peu parfaite pour cette conférence. Nous sommes le cheval entier! Le dragon entier! Mais nous avons des aspérités. Et alors.

C'est cool de voir la technologie autour de notre travail évoluer au point que nous pouvez atteindre nos bras autour de tout. Cela vaut la peine de s’inquiéter lorsque nous avons le sentiment que la complication de la technologie Web donne l’impression qu’elle élève la barrière à l’entrée. Cela arrive parfois et ce n’est pas génial. Mais c'est également digne d'être encouragé lorsque la technologie Web devient suffisamment simple pour que les utilisateurs puissent créer des éléments du début à la fin par eux-mêmes. C'est plutôt cool.

Bien que nous soyons tous productifs et incroyables, rappelons-nous simplement que faire du bon travail est le travail de tout le monde.

  • Un bon UX est le travail de tout le monde
  • Les bonnes performances sont le travail de tous
  • Une bonne sécurité est le travail de tous
  • Une bonne accessibilité est le travail de tous
  • Faire bien par les personnes qui utilisent votre site Web est le travail de tous

Même si vous n’écrivez pas le code qui affecte directement l’une de ces choses, vous vous en souciez et vous battez pour qu’elles soient bien gérées.

CodePen PRO (soutenez vos produits logiciels d'artisanat local avec de l'argent)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *