Smashing Podcast Episode 32: Bilan de l'année 2020

Dans cet épisode, nous revenons sur 2020. À qui avons-nous parlé dans nos épisodes cette année, et qu'avons-nous appris ? Écoutons quelques extraits pour le savoir.

Afficher les remarques

Vous pouvez trouver tous nos épisodes passés, y compris une transcription complète de chaque interview sur podcast.smashingmagazine.com.

Rendez-vous en 2021, tout le monde !

Transcription

Drew McLellan : En janvier, j'ai parlé à Amy Hupe de son travail sur le système de conception du gouvernement britannique, et en particulier de la façon dont l'équipe a accru l'adoption du système par l'ensemble de l'organisation en encourageant les contributions. Voici Amy.

Amy Hupe : Nous avons commencé très tôt. Donc, bien avant que nous ayons une sorte de système de conception public, nous avons commencé à nous engager avec des personnes qui, selon nous, seraient des contributeurs intéressés. Je dois mentionner ici que nous avions un brillant concepteur de services dans l'équipe. Elle nous a rejoints en… Je ne vais pas avoir les dates correctes pour le moment, mais je pense qu'elle a travaillé avec nous pendant toute l'année 2018, et son nom est Ignacia. Elle a juste fait un travail fantastique en faisant le tour et en engageant les gens. Donc, l'une des choses qu'elle a faites a été d'identifier tous les différents modèles de gouvernement et tous les différents types de variations de ces modèles. Alors sortir et dire en quelque sorte: «D'accord. Il existe 10 façons différentes de demander une adresse au gouvernement. Examinons-les tous ensemble et décidons quelle est selon nous l'approche la plus appropriée. Comment pouvons-nous les regrouper en un seul ? »

Amy Hupe: Elle a dirigé un grand atelier pour essayer d'amener les gens à les regarder et à faire ce genre de consolidation en équipe. Je pense que son approche pour établir une sorte de collaboration bien avant que nous ne publiions quoi que ce soit au public a vraiment aidé à cela, car cela signifiait que les gens en avaient déjà ce genre de prise de conscience, et beaucoup de gens y avaient déjà contribué d'une manière ou d'une autre un autre avant de le rendre public. Nous avions donc quelques longueurs d'avance. Je pense donc que c'était vraiment important et juste de la persévérance, beaucoup de persévérance de la part de toute l'équipe pour aider les gens à contribuer.

Amy Hupe : Je pense qu'il y a une idée que si vous faites contribuer les gens à un système de conception, c'est un travail plutôt sympa, parce que vous pouvez simplement amener les gens à faire tout le travail pour vous, et vous restez assis là, et vous faites vos petites corrections de code, et tout le monde vous donne toutes les bonnes choses. Mais en fait, comme le savent tous ceux qui ont travaillé sur un système de conception, c'est incroyablement complexe. Il est très difficile de créer une solution centralisée qui fonctionne pour plusieurs équipes différentes.

Amy Hupe : Vraiment, à moins d'avoir travaillé sur un système de conception, il n'est pas raisonnable de s'attendre à ce que quelqu'un comprenne vraiment ce que cela demande. Il y a donc beaucoup de types de prise en main. Il y a beaucoup de travail à faire pour aider les contributeurs à contribuer. Je pense que je l'ai déjà dit, mais cela prend probablement plus de temps, je pense, pour aider quelqu'un à contribuer à un système de conception que de simplement créer la chose vous-même et l'équipe centralisée. Mais je pense que reconnaître la valeur que cela apporte et persévérer dans vos efforts pour sensibiliser les gens à la contribution, les aider à le faire, les aider à se sentir un peu motivés pour le faire, je pense que oui, cette persévérance était vraiment si essentielle pour notre succès dans ce domaine.

Drew : Nous avons été rejoints par Stephanie Stimac et Aaron Gustafson de Microsoft pour parler de l'adoption par Edge de Chromium comme moteur de rendu. J'ai interrogé Aaron sur le paysage concurrentiel entre les navigateurs et sur les endroits où la fusion de plusieurs navigateurs sur le même moteur de rendu éliminerait cette concurrence saine et serait donc mauvaise pour le Web ouvert.

Aaron Gustafson : C'est quelque chose avec lequel j'ai certainement été un spécialiste des normes Web de longue date. Je comprends totalement la justification commerciale pour cela. Du point de vue de Microsoft, cela avait beaucoup de sens. Du point de vue du développement frontal, il est agréable de ne pas avoir à répondre à un tas de moteurs différents. Je veux dire, dans l'ensemble, ceux d'entre nous qui travaillent sur le web depuis longtemps ont certainement vu beaucoup de convergence en termes de rendu. Nous n'avons pas eu autant de problèmes que nous en avions, disons dans Netscape pendant sept jours, où nous avions juste comme… Je connaissais des entreprises qui créaient des feuilles de style uniques pour chaque navigateur différent, ce qui était tout simplement intenable.

Aaron Gustafson : Mais je pense que ce qui est un peu différent maintenant, c'est que dans les guerres de navigateurs d'origine, vous aviez tous ces moteurs propriétaires, et tout le monde était en quelque sorte dans un jeu de surenchère en essayant d'expédier de nouvelles fonctionnalités de plate-forme et de nouvelles fonctionnalités JavaScript ou dans le cas de la rétro-ingénierie JavaScript de Microsoft afin de créer JScript et d'essayer de comprendre comment tout assembler.

Aaron Gustafson : Mais maintenant, nous avons la possibilité de travailler ensemble sur des projets open source et d'avoir toujours le dialogue et toujours… Je ne sais pas. Se battre n'est pas le bon mot, mais avoir des discussions sérieuses sur l'impact des différentes approches et être en désaccord les uns avec les autres et vraiment travailler à rendre les spécifications vraiment bonnes et avoir également des approches concurrentes du code sous-jacent dans le contexte de, disons, un Chromium projet ou WebKit ou quelque chose de cette nature ou Missoula dans l'espace Firefox.

Aaron Gustafson : Alors oui. D'une part, nous avons perdu un autre moteur de rendu, et j'ai ressenti la même douleur lorsque l'opéra a décidé de passer à Chromium. Mais je me sens quelque peu réconforté d'être à l'intérieur de Microsoft et de voir à quel point nous sommes déterminés à participer réellement au projet Chromium de manière significative et pas seulement à nous asseoir et à accepter tout ce qui vient en aval de Chromium, mais en fait à vérifier ce qui se passe la plate-forme et participer à ça… Ouais.

Aaron Gustafson : Je suis donc un peu encouragé par cela et j'ai l'impression que nous ne sommes pas seulement là pour tirer parti de ce projet et accepter tout ce qui est transmis par toutes les différentes personnes qui ont un intérêt dans ce projet, mais pour collaborer là-dedans aussi.

Drew : En février, j'ai parlé à Stephanie Walter de travailler avec des frameworks d'interface utilisateur comme Bootstrap et ses amis et d'équilibrer cela avec les besoins personnalisés d'une interface utilisable. J'ai demandé à Stéphanie s'il était possible de créer une interface utilisateur hautement utilisable tout en utilisant un framework prêt à l'emploi ou si cela allait toujours être un compromis un peu gênant.

Stéphanie Walter : Oui. Je pense que c'est. Mais cela dépend aussi du niveau de compromis que vous êtes prêt à faire, et cela compromet les deux côtés. Pour le moment, je compromet beaucoup de boutons, par exemple, parce que vous avez des boutons vraiment spécifiques dans une interface utilisateur matérielle. Je n'aime pas vraiment l'effet d'entraînement sur le bouton. Je pense que cela fonctionne très bien sur mobile car sur mobile, vous avez besoin d'une sorte de gros retour lorsque l'utilisateur clique ou touche le bouton. Mais ensuite, ils exécutent ce type d'effet d'entraînement qui va jusqu'au bout du bouton. C'est un peu exagéré, surtout quand il y a beaucoup de boutons. Mais nous allons quand même garder cet effet d'entraînement car il serait super complexe de le supprimer car cela a été intégré au framework React et d'avoir un autre effet de survol sur ce bouton, quelque chose de plus subtil qui ne serait pas ce genre de chose broussailleuse ici. Ce serait hyper complexe. C'est donc le genre de compromis que vous faites.

Drew : Le design éthique était le sujet de ma conversation avec Trina Felber et Martin Michael Fredrickson. J'ai demandé si adopter une approche éthique de la conception et éviter les schémas sombres revenait à penser à long terme à la santé et à la croissance d'une entreprise plutôt qu'aux seuls objectifs de vente à court terme. Voici Martin.

Martin Michael Fredrickson : C'est parfaitement vrai. Je pense que vous devez considérer les affaires que vous faites en ligne comme si vous aviez un magasin dans la rue principale d'une ville de taille moyenne, où vous devez garder votre réputation intacte. Si vous ne traitez pas bien vos clients, alors si vous ne traitez pas bien vos clients, à long terme, vous manquerez d'affaires parce que les gens iront dans un autre magasin ou achèteront en ligne. Donc, quoi que vous fassiez en ligne, vous devez vraiment penser qu'il y a un effet à long terme, et aussi, qu'il y a un coût caché à faire des choses complexes ou des choses qui manipulent. Si vous désencombrez, comme le dit Trina, il y aura une économie à long terme, et cela n'est jamais calculé quand vous parlez de modèle d'affaires. Vous parlez toujours de combien d'argent vous pouvez gagner. Vous ne parlez jamais du coût de gagner cette somme d'argent.

Drew : En mars, j'ai parlé à Eduardo Boucas d'un outil open source appelé Sourcebit qui rassemble le contenu de sources disparates et le met à la disposition de votre générateur de site statique. J'ai demandé à Eduardo si cela pouvait améliorer l'expérience utilisateur d'autorisation d'un SSG en permettant l'intégration avec des outils tels que les CMS sans tête.

Eduardo Boucas : Exactement. Ouais. La façon dont cela pourrait… Je vois en quelque sorte deux façons différentes d'utiliser l'outil qui peut aider les développeurs. La première consiste à intégrer Sourcebit à votre routine de déploiement. Donc, si vous utilisez une plate-forme d'hébergement, comme Netlify, par exemple, et que vous configurez vos commandes de déploiement pour être, je ne sais pas, Hugo build, est-ce, la commande de construction pour Hugo ou quelque chose, le genre de commande qui génère les fichiers statiques pour Hugo. Vous auriez également une autre commande dans le cadre de cette routine. Ce serait quelque chose comme la récupération de Sourcebit. Ainsi, au moment de la construction, Sourcebit va extraire toutes les autres données, générer tous les fichiers dont Hugo a besoin, puis l'ensemble du déploiement utilisera déjà ces fichiers et déploiera tout le contenu provenant du CMS.

Eduardo Boucas : C'est donc une sorte de cas d'utilisation possible pour Sourcebit. L'autre consiste à utiliser Sourcebit comme développement local dans le workflow de développement local. Vous pouvez donc exécuter Sourcebit avec quelque chose que nous appelons le mode montre. Ainsi, Sourcebit continue de rechercher des modifications dans la source de données distante, donc dans ce cas, le CMS sans tête. Ainsi, chaque fois que vous publiez un article ou que vous modifiez une entrée dans le CMS, Sourcebit le reconnaîtra et régénérera tous les fichiers pour vous localement.

Eduardo Boucas : Donc, ce que cela signifie pour les développeurs travaillant localement, c'est que vous pouvez avoir votre fenêtre CMS à côté de votre site Hugo en cours d'exécution localement, et vous pouvez ensuite voir les changements se produire en temps réel. Vous modifiez quelque chose sur le CMS, puis vous pouvez voir ce changement se refléter sur le site local, ce que je trouve très utile. Ce sont donc en quelque sorte les deux façons d'utiliser Sourcebit.

Drew : L'optimisation des conversions était le sujet du jour. Quand j'ai parlé au podcasteur et consultant vétéran, Paul Boag. Nous avons parlé de certaines des techniques utilisées par les sites pour convertir les visiteurs en clients. Mais je voulais demander à Paul comment vous mesurez l'impact des changements que vous apportez. Paul a expliqué.

Paul Boag : Oui. Absolument. Je pense, encore une fois, que c'est quelque chose que beaucoup d'organisations ne savent pas faire, c'est d'être clair sur la façon dont ils vont mesurer le succès. Maintenant, oui, votre taux de conversion est une mesure. Vous devez absolument suivre. Mais même avec la conversion, vous devez en quelque sorte être un peu plus sophistiqué que le nombre de personnes qui achètent. Vous devez également faire attention à la valeur moyenne des commandes. Vous devez accorder une attention particulière à la valeur à vie, n'est-ce pas ? Alors, combien vaut un client sur toute sa vie, car vous pourriez bien constater que vous obtenez un taux de désabonnement assez élevé de clients, si vous utilisez des modèles sombres et des choses comme ça. Mais en réalité, la conversion ne devrait être qu'une des mesures que vous mesurez.

Paul Boag : Il y a aussi des choses comme vous devez faire attention à l'engagement, à quel point les gens sont engagés avec votre contenu, car cela fait une grande différence quant à savoir s'ils finissent par se convertir. Donc, vous regardez des choses comme, combien coûtent vos vidéos, regardent-ils, combien de temps passent-ils sur votre site et ce qu'ils regardent pendant qu'ils le font ? Est-ce qu'ils s'engagent sur les réseaux sociaux et ce genre de choses? Ensuite, l'aspect final est évidemment la convivialité. Vous devez mesurer la rapidité avec laquelle quelqu'un peut accomplir une tâche particulière sur son site Web et la facilité avec laquelle il trouve le système à utiliser et divers autres critères différents.

Paul Boag : Il existe de nombreux mécanismes que vous pouvez utiliser pour mesurer ces différentes choses. Il existe d'excellents outils et de bonnes mesures que vous pouvez adopter. Ainsi, par exemple, avec l'utilisabilité, il y a ce qu'on appelle l'échelle d'utilisabilité du système qui peut être une mesure très utile à mesurer. Mais également, il existe des outils comme maze.design que j'utilise souvent, qui mesureront le temps qu'il faut à quelqu'un pour faire un achat, par exemple, passer la caisse. Donc voilà. Avec ce genre de large éventail de mesures, vous ne vous concentrez pas uniquement sur le nombre de ventes que nous avons réalisées ce trimestre ? Vous devez regarder la situation dans son ensemble.

Drew : En avril, j'ai discuté avec Laura Kalbag de Better Blocker à propos de la confidentialité en ligne. Nous avons parlé des frontières de plus en plus minces entre ce qui est considéré comme public et ce qui est privé et comment les choses que nous considérons comme privées pourraient ne pas être perçues de cette façon par les entreprises auxquelles nous confions nos données. Voici Laure.

Laura Kalbag : J'ai un exemple classique de cela qui m'est arrivé il y a quelques années. J'étais donc sur Facebook, et ma mère venait de mourir, et je recevais des publicités pour des pompes funèbres. J'ai pensé que c'était vraiment étrange parce qu'aucun membre de ma famille n'avait dit quoi que ce soit sur une plateforme de médias sociaux à ce moment-là. Aucun membre de ma famille n'avait rien dit sur Facebook parce que nous avions convenu que personne ne voulait découvrir ce genre de choses sur un ami ou un membre de la famille via Facebook. Donc on n'en avait pas parlé.

Laura Kalbag : J'ai donc demandé à mes frères et sœurs : « Oh, est-ce que l'un d'entre eux a dit quelque chose sur Facebook qui pourrait causer cet étrange. Parce que je reçois généralement des publicités pour du maquillage, des robes, des tests de grossesse et toutes ces choses amusantes dont ils aiment parler. Ce sont des femmes d'un certain âge. Au lieu de cela, ma sœur est revenue vers moi. Elle a dit: "Eh bien, oui. Mon ami vit en Australie. Alors je lui ai envoyé un message sur Facebook Messenger et lui ai dit que notre maman était décédée. Bien sûr, Facebook savait que nous étions sœurs. Il a cette connexion relationnelle que vous pouvez choisir d'ajouter là-bas. Je veux dire, il pourrait probablement deviner que nous étions sœurs de toute façon, d'après les endroits où nous avons été ensemble, le fait que nous partagions un nom de famille et que nous ayons décidé : "Oh, c'est une annonce appropriée à mettre dans ses pieds."

Drew : Cela donne à réfléchir, n'est-ce pas, de penser que la technologie prend ces décisions pour nous, ce qui affecte potentiellement les gens dans cet exemple à un moment assez sensible ou vulnérable ?

Laura Kalbag : Oui. On dit que c'est flippant. La plupart du temps, les gens disent : "Oh, c'est presque comme si le microphone de mon téléphone ou de mon ordinateur portable m'écoutait parce que j'étais justement en train d'avoir cette conversation à propos de ce produit en particulier, et tout à coup, il apparaît partout dans mon fil d'actualité." Je pense que ce qui est vraiment effrayant, c'est le fait que la plupart d'entre eux n'ont pas accès à votre microphone. Mais c'est le fait que vos autres comportements, votre recherche, le fait qu'il sache à qui vous parlez en raison de votre proximité les uns des autres et de votre emplacement sur vos appareils. Il peut connecter toutes ces choses que nous ne pourrions pas connecter nous-mêmes afin de dire simplement : "Oh, peut-être qu'ils seront intéressés par ce produit parce qu'ils y ont probablement déjà pensé, en ont déjà parlé."

Drew: Alors que la pandémie de coronavirus a frappé et que de nombreux pays sont entrés dans une forme de verrouillage, j'ai parlé avec Rachel Andrew de la façon dont Smashing adaptait sa conférence en personne qui devait se dérouler en ligne à la place. Ayant juste dû reporter la conférence Smashing à San Francisco, j'ai demandé à Rachel quel était le plan pour déplacer les conférences et ateliers à venir dans le domaine virtuel.

Rachel An Drew: Très, très rapidement, une fois que nous avons réalisé que nous allions devoir reporter San Francisco, évidemment, nous avons des ateliers, moi-même et Vitaly organisons des ateliers à smash et comp, et ils étaient complets à San Francisco, tous les deux de nos ateliers. Évidemment, nous avons beaucoup d'autres personnes qui viennent animer des ateliers pour nous, des gens avec qui nous travaillons depuis longtemps, et ils ont constaté que tous leurs ateliers, et pour ceux d'entre nous qui organisent des ateliers, ils ont en fait un partie essentielle de nos revenus.

Rachel An Drew: Parler en public, vous ne gagnez généralement pas beaucoup d'argent en parlant en public. La plupart des gens ne sont pas beaucoup payés, pas si l'on considère le temps qu'il faut pour écrire des discours, etc. Les ateliers ont tendance à être un bon moyen pour les personnes qui savent bien enseigner ce genre de choses de gagner de l'argent. Ils représentent donc le revenu des gens. Donc non seulement j'avais besoin de moi et Vitaly avait perdu nos ateliers en début d'année. Nous avons également réalisé que beaucoup de nos conférenciers Smashing dépendaient également de ces ateliers.

Rachel An Drew : Nous avons donc pensé : « Eh bien, pourquoi ne pas simplement les mettre en ligne ? » Très, très rapidement, vraiment quelques jours après que cela se soit produit, nous avons décidé que Vitaly et moi serions en quelque sorte les premiers à passer la tête au-dessus du pouvoir, mais étant donné que c'est nous, et nous pourrions en quelque sorte trouver comment le faire. Nous avons aussi des ateliers très différents. Vitaly est beaucoup plus collaboratif. Il a des activités de groupe et des choses. J'enseigne le style de classe. Donc, entre nous, nous avons pensé : "Eh bien, nous couvrons en quelque sorte toutes les bases." Alors nous avons pensé : « Faisons-le. Voyons si cela fonctionne. Nous les annonçons donc. Nous avons en quelque sorte compris combien de temps chacun prenait, puis nous nous sommes assis et avons dit : « Eh bien, à quoi ressemble vraiment un atelier en ligne ? Qu'est-ce que c'est?"

Drew : Je pense que d'un point de vue technique, en tant que développeurs Web qui pensent immédiatement, comment diable allons-nous proposer quelque chose comme ça, je veux dire, il doit y avoir beaucoup de plates-formes différentes que vous avez examinées. Quelles ont été les différentes choses que vous avez examinées et qu'est-ce que Smashing a finalement apporté?

Rachel An Drew: Nous avons donc examiné toutes sortes de choses, et nous sommes toujours en train de le faire. Nous utilisons Zoom pour le moment. La raison pour laquelle nous utilisons Zoom est l'accessibilité. C'était la plus accessible des plates-formes. Évidemment, nous ne voulons pas exclure des personnes à cause de la plateforme que nous avons choisie. Je pense que les autres plateformes s'améliorent et les gens sont… Je pense que beaucoup de plateformes ont eu des gens qui sont venus vers eux et qui ont dit : « Ouais, tu es superbe. Mais nous avons besoin que vous soyez accessible. Le zoom est donc le plus facile à utiliser pour les gens en ce moment. C'est pourquoi nous avons fini par les utiliser. Je ne sais pas si nous ferons pour toujours. Mais c'est ce que nous utilisons en ce moment, et cela a plutôt bien fonctionné comme moyen de faire ce genre de choses.

Drew: Alors que la fatigue de Zoom s'installait et que le monde commençait à s'adapter à ce qu'on appelait rapidement la nouvelle normalité, j'ai parlé à Phil Smith de la façon dont la technologie peut nous aider à répondre à des situations comme COVID-19. Construire l'application React Native, CardMedic en seulement 10 jours. J'ai demandé à Phil comment il s'y prend pour choisir la meilleure technologie pour le travail par rapport aux technologies qu'il connaît et avec lesquelles il peut travailler rapidement.

Phil Smith : C'est une bonne question. Je pense que dès que le projet m'a été évoqué, j'ai cru savoir exactement comment je vais construire tout ça. Si je n'avais pas d'enfants et que j'étais assis dans une pièce sombre, je pense que j'aurais probablement pu tout changer en cinq jours environ si j'avais travaillé dessus solide, solide, solide parce que les exigences étaient très bien conforme à mon expérience de création d'applications. J'ai construit des choses similaires, où il fait appel à une API, stocke les résultats dans l'état et les présente. Je suis maintenant à une position où il y a des moments où je me dis: "D'accord, je dois revenir en arrière et refactoriser cela."

Phil Smith : J'ai parlé de l'étain, mais en fait, les types peuvent être assez lâches dans l'application, et cela doit être resserré. Sur le back-end, il n'y a pas beaucoup de tests et maintenant nous commençons à déployer le back-end parce que beaucoup de gens se sont manifestés et ont dit : « En fait, c'est une excellente ressource. J'aimerais offrir mes services pour traduire ceci dans ma langue maternelle. Les back-ends sont utilisés par plus de gens, donc je pense juste, "Attendez, j'ai besoin de quelques tests supplémentaires ici pour m'assurer que rien ne peut casser car il y a des gens qui l'utilisent en production maintenant." Je pense avoir répondu à votre question. Essentiellement, il n'y avait pas de prise de décision. Je devais juste le sortir le plus rapidement possible.

Drew: Alors que les lieux de travail fermaient et que beaucoup d'entre nous s'adaptaient au travail à domicile, j'ai parlé à Ben Frain de l'optimisation de votre espace de travail à domicile pour qu'il soit un lieu confortable et productif n'entraînera pas de problèmes de santé physique à long terme. Avec des budgets limités disponibles pour s'installer à la maison, j'ai demandé à Ben si une bonne chaise était le meilleur endroit pour commencer.

Ben Frain : Ce serait mon conseil. Ouais. Je veux dire, je ne peux pas prétendre être une autorité sur ces choses, mais il semble que ce soit probablement la chose la plus importante que vous puissiez faire pour vous mettre à l'aise tout au long de la journée. Vous pouvez commencer avec quelque chose d'assez cher. J'ai fait la même erreur, et j'ai fini par obtenir une chaise de bureau de 45 livres d'Amazon, et je n'avais pas réalisé qu'elle n'avait pas d'inclinaison vers l'avant, quel que soit le mot juste pour cette chose, sur l'axe. Donc, ce que j'ai trouvé, c'est qu'il creusait sous mes cuisses, en quelque sorte derrière mes genoux, et je pensais: "Pourquoi mes jambes meurent-elles après 45 minutes assises dans cette chose?"

Ben Frain : Je pense que si vous travaillez pour une entreprise qui fournit des chaises de bureau décentes, vous les tenez pour acquises, et ce n'est que lorsque vous regardez cette marque et cette marque en particulier que vous vous dites : « Oh mon Dieu, c'est une chaise à 700 $. Lorsque vous réalisez ce crikey, les gens y ont pensé et ont fait beaucoup pour vous, puis évidemment vous venez chez vous et vous pensez : « Pourquoi ne pas dépenser X cents dollars pour une chaise ? Mais peut-être que ça vaut le coup. Surtout si vous êtes ici pour le long terme.

Drew: Et le long terme est ce que nous avons. Quelque chose d'autre qui est là pour le long terme est Drupal. En juin, j'ai parlé avec Angie Byron des changements apportés à Drupal 9. 20 ans après sa première version, Drupal a parcouru un long chemin. J'ai demandé à Angie à quoi ressemblait le processus de mise à niveau d'un site Drupal existant lors du passage à Drupal 9 et si cela risquait d'être un gros fardeau pour ceux qui avaient des sites de longue date.

Angie Byron: Je pense qu'il y a essentiellement trois scénarios. Donc, si vous utilisiez Drupal 8, et chaque fois qu'une nouvelle version mineure de Drupal 8 sortait, vous la mettiez immédiatement à niveau et vous commenciez à utiliser les nouveautés. Votre chemin ne sera pratiquement rien. Vous avez déjà fait tout le travail et vous allez bien. Si vous êtes passé à Drupal 8 il y a quelque temps et que vous n'avez pas suivi les changements de BC, il y a un peu de travail pour vous.

Angie Byron : De toute façon, c'est certainement la mise à jour la plus simple de notre logiciel depuis plus d'une décennie, et nous avons une tonne d'outils différents pour vous aider. Il y a un tableau de bord qui montre tous les modules contribués et quelle est leur situation Drupal 9. Il existe des outils automatisés pour parcourir et vérifier votre code et signaler toutes les fonctions obsolètes que vous avez, et il existe des outils pour remonter automatiquement et trouver, « Oh, c'est la dernière version de votre module, et c'est Drupal 9 prêt ? Tu devrais aller le télécharger », ce genre de choses.

Angie Byron : Donc, de Drupal 8 à 9, je dirais que cette partie est assez bien couverte. Si vous venez d'une version antérieure de Drupal, disons Drupal 7 ou moins à Drupal 9, cela commence à paraître un peu plus compliqué. Parmi les changements que nous avons apportés à Drupal 8, où par exemple, nous sommes passés entièrement à PHP orienté objet, et nous avons commencé à utiliser des modèles de conception trouvés dans d'autres projets logiciels, ce qui est une chose vraiment intelligente à faire sur le plan architectural, mais c'est le cas Cela signifie que si vous aviez une tonne de code personnalisé dans votre ancienne vie, cela dans Drupal 9, vous devrez trouver des alternatives pour cela.

Angie Byron : Donc, Acquia est un produit et un développement appelé Acquia Migration Accelerator qui vise à résoudre ce problème, où nous créons une belle application définie par React, qui lit dans vos anciennes données Drupal 7, crée des données équivalentes Drupal 8 pour vous avec tous les modules dont vous aurez besoin, cette carte vers vos anciens modules Drupal 7, si possible, pour essayer d'accélérer un peu ce processus, car nous voulons nous assurer que tous ceux qui utilisent des versions plus anciennes peuvent toujours passer à la nouvel ordre mondial, où tout le monde est sur la même version, et nous travaillons tous ensemble.

Angie Byron : Puis en plus, on a aussi étendu Drupal 7… La communauté open source de Drupal, leur fin de vie dans Drupal 7 à partir de novembre de l'année prochaine. Actuellement, de toute façon, nous devons discuter si COVID a un impact ou non. Mais il existe un certain nombre de sociétés différentes, et Acquia est l'une d'entre elles qui offre un support étendu pour Drupal 7 au-delà de cela, jusqu'en 2024 au moins. Donc, cela fait en sorte que les gens qui ont une mise à niveau facile ont un an et demi pour le faire, les gens ont une mise à niveau moins facile, ont potentiellement trois ans et demi pour le faire ou plus s'ils en ont besoin, et nous nous efforçons de permettre à tout le monde de se déplacer, puis de créer des outils comme Acquia Migrate Accelerator pour aider à accélérer le processus.

Drew : Learning React a fait l'objet d'une conversation avec Mina Markham. Mina et moi étions toutes les deux en position d'apprendre React pour la première fois. En réfléchissant à la charge que les frameworks comme React imposaient au navigateur, j'ai demandé à Mina si mettre autant de contrôle entre les mains du client était une erreur.

Mina Markham: Je veux dire oui avec la mise en garde, encore une fois, mon expérience est très limitée aux sites Web principalement statiques. Je ne fais pas beaucoup de développement de produits. Alors peut-être que dans ce domaine, cela a plus de sens. Mais de mon point de vue, j'ai l'impression que nous utilisons souvent une hachette alors que nous n'avons besoin que d'un couteau à beurre. Je ne sais pas pourquoi nous devons mettre tout cela dans le navigateur, mettre tant de travail et tant de pression sur le client alors que nous pouvons faire beaucoup de choses… J'ai l'impression que nous pourrions faire cela beaucoup plus simplement. L'une des choses qui m'a toujours fait hésiter à utiliser React, ou je dis hésitant, mais ce que je veux dire quand cela m'a mis viscéralement en colère et que je m'y suis activement opposé, c'est quand j'allais sur un site Web, et littéralement rien ne rendrait parce que il y a eu une erreur ou quelque chose comme vraiment la page entière est cassée parce qu'une fonction est tombée en panne.

Mina Markham: Cela m'a un peu ennuyé que la plupart du temps, c'était une approche tout ou rien. L'une des conférences que j'ai données à l'AEA dans le passé et à d'autres endroits dans le passé parlait en quelque sorte de la façon d'inclure l'amélioration progressive et pas seulement votre développement, mais aussi une direction artistique et une conception de sites plus larges. Je soulignerais spécifiquement des exemples de sites Web qui n'ont pas fait d'amélioration progressive ou de toute sorte de dégradation gracieuse. C'était soit vous avez le JavaScript en cours d'exécution dans le navigateur, soit vous n'obtenez absolument rien. Ce serait juste un simple site qui représenterait des informations sur l'histoire de la conception Web, qui était l'un des sites dont on parlait réellement, l'histoire de la conception Web de 1990 à aujourd'hui. C'était un beau site Web avec beaucoup de chronologies, d'animations de choses. Mais il aurait également pu être rendu statiquement avec juste une liste. Il y avait des étapes entre ne rien montrer et montrer cette expérience magnifiquement améliorée qui, je pense, s'est perdue à cause de la façon dont nous abordons le développement Web moderne maintenant.

Drew : J'ai parlé à Andy Bell de CUBE CSS, une méthodologie de style à la manière de BEM, SMACSS et OOCSS. De nombreuses approches CSS tentent de travailler contre les propriétés naturelles du CSS comme la cascade. CUBE embrasse très bien ce comportement. Voici Andy.

Andy Bell : Une bonne sorte d'analogie car SCSS, comme Sass, est une extension du langage CSS naturel, n'est-ce pas ? Vous avez encore à peu près raison en CSS. Donc CUBE CSS est comme ça. C'est donc une extension de CSS. Nous devrions donc toujours écrire CSS, comme CSS devrait… eh bien, c'est censé être écrit. Soyons honnêtes, c'est comme ça que c'est censé être écrit. Le nom le révèle, Feuilles de style en cascade. Donc, c'est encore une fois adopté parce que ce que j'ai découvert, c'est que je suis descendu jusqu'au niveau de la micro-optimisation. J'ai parcouru le chemin que j'ai vu beaucoup de gens descendre récemment où… J'ai mentionné cela dans l'article aussi, où je peux voir… Il y a des preuves de cela récemment. J'ai remarqué que des gens créaient des composants d'espacement et des trucs comme ça, et je comprends ce problème. J'ai été dans cette situation.

Andy Bell : La façon dont j'ai résolu le problème était qu'au lieu d'approfondir et d'essayer de micro-optimiser, j'ai plutôt commencé à penser aux choses au niveau de la composition, car peu importe la taille de vos composants. À un moment donné, ce seront des pages. Ce seront des vues. Vous ne pouvez pas éviter cela. C'est comme ça que ça va être. Ainsi, au lieu d'essayer de dire : "Bien, j'ai besoin de ces minuscules assistants pour faire cette mise en page", vous dites : "Bien, j'ai une vue de page de contact ou une vue de page de produit, et c'est une composition de mise en page squelettique. Ensuite, à l'intérieur de cela, je peux insérer tous les composants que je veux là-dedans.

Andy Bell : Nous avons maintenant des choses comme Grid et Flexbox qui rendent cela beaucoup plus réalisable, et vous pouvez essentiellement mettre ce que vous voulez à l'intérieur de la disposition squelettique. Cela n'a pas d'importance. Ensuite, les composants doivent, à ce stade, se comporter comme vous le souhaitez, avec ou sans requêtes de conteneur.

Drew : Gatsby était le sujet de ma conversation avec Marcy Sutton. Alors que la plupart des générateurs de sites statiques sont indépendants du code frontal, Gatsby utilise React, et donc vous vous retrouvez avec le code Gatsby exécuté dans le cadre de votre expérience Web finale. J'ai demandé à Marcy quel était ce code et quelles fonctionnalités il offrait.

Marcy Sutton : Oui. Je dirais que le plus gros élément est le routage côté client. Alors Gatsby utilise actuellement un rechapeur sous le capot. C'est juste une sorte de sa propre implémentation. Mais c'est la pièce que lorsque vous chargez votre site statique pour la première fois, il y a des fichiers HTML là-bas. Donc, si l'utilisateur désactive JavaScript pour une raison quelconque, votre site devrait toujours être là, avoir toujours du contenu. Mais si JavaScript est activé, c'est à ce moment-là que cette étape d'hydratation se produit, où lorsque vous utilisez des liens dans votre site Gatsby, il ira pré-récupérer les ressources de cette page. Il se chargera donc plus rapidement. Tout cela est donc activé avec cette couche JavaScript que Gatsby vous donne.

Marcy Sutton : Au-delà de cela, cela dépend vraiment de ce que vous utilisez sur votre site, de ce qui se retrouvera dans ce bundle JavaScript. Mais pour les choses qui utilisent beaucoup d'interactivité, comme les interfaces accessibles, c'est un bon endroit pour être. Pour moi, j'apprécie vraiment d'avoir JavaScript à ma disposition à tout moment et d'avoir mon balisage juste au bon endroit. Je sais que c'est une question de préférence, si vous voulez que votre HTML, votre JavaScript et votre CSS soient parfaitement couplés, et il y a de la place pour des variations dans la construction de Gatsby. Vous n'avez pas toujours besoin d'utiliser quelque chose comme CSS et JS. Mais il s'agit vraiment de mettre à votre disposition la puissance de cette couche JavaScript dynamique pendant que vous écrivez votre site Web. Ce n'est pas comme cet add-on dans un fichier séparé.

Drew : Quand je pense au fonctionnement habituel d'un générateur de site statique, je pense au contenu dans des fichiers de démarquage et le générateur parcourt ce contenu et le fusionne avec des modèles et crée des dizaines, des centaines, des milliers de fichiers HTML, qui sont les pages de votre site Web. Quand je pense à un site ou à une application React, je pense davantage à l'expérience d'une seule page, où les interfaces sont créées par React à la volée. Alors vous dites que Gatsby fait les deux ? C'est créer toutes les pages et aussi les améliorer avec JavaScript ?

Marcy Sutton : Oui, oui. Gatsby utilisera Node.js au moment de la construction, il passera en revue vos composants React et les compilera dans des fichiers HTML, ce qui, honnêtement, la première fois que j'ai regardé Gatsby, je ne désactiverais pas JavaScript et je me disais : "D'accord, y a-t-il d'autres pages ici? Qu'est-ce que c'est?" J'étais si heureux que Gatsby fonctionne de cette façon par défaut. Il créera des fichiers construits à partir de vos composants React, ce qui est génial.

Marcy Sutton : J'ai exploré des approches d'amélioration plus progressives puisque c'est en JavaScript, comme, que se passe-t-il si vous voulez produire quelque chose d'amélioré progressivement pour les utilisateurs, où s'ils ont désactivé JavaScript, vous ne voulez pas tout ce code cassé qui suppose JavaScript y a-t-il. Il y a donc quelques bizarreries avec cela. Mais vous pouvez contourner ce genre de chose, au moins pour vos flux d'utilisateurs principaux où vous voulez que quelqu'un puisse toujours acheter quelque chose. Vous devrez peut-être ajouter un support et pour ces cas d'utilisation. Mais j'ai été agréablement surpris par la façon dont Gatsby le déploie par défaut.

Marcy Sutton : C'est donc un choix qu'ils ont fait de construire des sites de cette façon, et nous évaluons toujours, est-ce toujours la meilleure façon ? Que devons-nous faire pour donner à nos utilisateurs ce qu'ils demandent ? Nous faisons donc des explorations en interne, en cours juste pour nous assurer que Gatsby fait du mieux qu'il peut pour créer un site Web, donc en gardant de petites tailles de bundles et en veillant à ce que pour faire des compromis pour ce que nous disons, c'est un code performant avec pré -fetching, avons-nous les données pour sauvegarder cela ? En tant que défenseur des développeurs, c'est le genre de chose qui m'intéresse beaucoup, c'est de s'assurer que ce que nous emballons et regroupons sur les sites Web est réellement nécessaire et fera vraiment le meilleur site Gatsby possible.

Drew : En discutant avec Chris Ferdinandi en juillet, j'ai demandé si les meilleures pratiques modernes étaient mauvaises pour le Web. Chris backs a movement known as the Lean Web, and I asked him what that entailed. Here's Chris.

Chris Ferdinandi: When I look at the way we build for the web today, it feels a little bit like a bloated over-engineered mess. J'en suis venu à croire qu'une grande partie de ce que nous considérons comme les meilleures pratiques aujourd'hui pourrait en fait aggraver le Web. The Lean Web is an approach to web development that is focused on simplicity, on performance, and the developer experience over… I'm sorry, not the developer experience, the user experience rather, over the developer experience and the ease of building things from a team perspective, which is what I think where we put a lot of focus today.

Chris Ferdinandi: As we'll probably get into in our conversation, I've actually come to find that a lot of these things we think of as improving the developer experience do so for a subset of developers but not necessarily everybody who's working on the thing you're building. So there's a whole bunch of kind of issues with that too that we can kind of dig into. Mais en réalité, le Lean Web consiste à se concentrer sur la simplicité et la performance pour l'utilisateur et à prioriser ou mettre l'accent sur les personnes qui utilisent les choses que nous fabriquons plutôt que sur nous, les personnes qui les fabriquent.

Drew: In August, Chris Coyier joined us to talk about all things serverless. I asked him what sort of the tasks they were putting serverless to over at CodePen?

Chris Coyier: Well, there's a whole bunch of things. One of them is, I think, hopefully fairly obvious is, I need… The point of CodePen is that you write each HTML, CSS, and JavaScript in the browser, and it renders it in front of you, right? Mais vous pouvez également choisir des langages de pré-processeur. Disons que vous aimez Sass. Vous activez Sass dans le CSS et vous écrivez Sass. Eh bien, quelque chose doit traiter le Sass. Ces jours-ci, Sass est écrit en Dart ou quelque chose comme ça. Theoretically, you could do that in the client. Mais ces bibliothèques qui font du pré-traitement sont assez grosses. Je ne pense pas que je veuille vous expédier toute la bibliothèque Sass, juste pour faire fonctionner ce truc. I don't want to. That's not the right architecture for this necessarily. Maybe it is down the road. I mean, we could talk about offline crap, yada, yada, web workers.

Chris Coyier: There's a million architectural things we could do. Mais voici comment cela fonctionne maintenant, s'il y a un lambda. Il traite Sass. Il a un tout petit, tout petit, tout petit, tout petit boulot. You send it this blob of Sass, and it sends you stuff back, which is the processed CSS, maybe a site map, whatever. It has one tiny little job, and we probably pay for that lambda like four cents or something. Because lambdas are just incredibly cheap, and you can hammer it too. Vous n'avez pas à vous soucier de l'échelle. You just hit that thing as much as you want, and your bill will be astonishingly cheap.

Chris Coyier: There is moments where serverless starts to cross that line of being too expensive. I don't know what that is. I'm not that master of stuff like that. But generally, any serverless stuff we do, we basically all nearly count as free, because it's that cheap. Mais il y en a un pour Sass. Il y en a un pour Moins. Il y en a un pour Babbel. Il y en a un pour TypeScript. Il y en a un pour… Ce sont tous des lambdas individuels que nous gérons. Here's some code, give it to the lambda. It comes back, and we do whatever we're going to do with it. Mais nous l'utilisons pour bien plus que cela, même récemment.

Chris Coyier: Here's an example. Chaque stylo sur CodePen a une capture d'écran. C'est plutôt cool, non ? So the people make a thing, and then we need a PNG or a JPEG, or something of it, so that we can… that way when you tweet it, you get the little preview of it. Si vous le partagez dans Slack, vous en obtenez un petit aperçu. We use it on the website itself to render… Instead of an iframe, if we could detect that the Pen isn't animated, because an iframe's image is much lighter, so why not use the image? Ce n'est pas animé de toute façon. Juste des gains de performances comme ça.

Chris Coyier: So each of those screenshots has a URL to it, obviously. We've architected it so that that URL is actually a serverless function. C'est un ouvrier. So if that URL gets hit, we can really quickly check if we've already taken that screenshot or not. That's actually enabled by CloudFlare Workers, because CloudFlare Workers are not just a serverless function, but they have a data store too. They have this thing called key-value store. So the ID of that, we can just check really quick, and it'll be, “True or false, do you have it or not?”

Chris Coyier: If it's got it, it serves it, and it serves it over CloudFlare, which is super fast to begin with and then gives you all this ability too because it's an image CDN, you can say, “Well, serve it in the optimal format. Servez-le comme ces dimensions. Je n'ai pas à faire l'image dans ces dimensions. You just put the dimensions in the URL, and it comes back as that size, magically.

Drew: I talked to Next.js co-creator, Guillermo Rauch about the features on offer in Next.js and asked about its automated code splitting functionality. As the size of our JavaScript bundles can have quite an impact on performance, I was interested to know if Next had ways to tackle that. Here's Guillermo.

Guillermo Rauch: Yeah. Your observation is 100% right. So one of the biggest things with the web and one of the biggest weights on the web is JavaScript. Just like different materials have different densities and weights, irrespective of the actual physical volume, JavaScript tends to be a very dense, heavy element. Even small amounts of JavaScript compared to, for example, images that can be processed asynchronously and off the main thread, JavaScript tends to be particularly bothersome.

Guillermo Rauch: So Next.js has invested a tremendous amount of effort into automatically optimizing your bundles. So the first one that was my first intuition when I first sort of came up with the idea for Next.js was, okay, you're going to define, for example, 10 routes. In the Next.js world you create a pages directory, and you drop your files in there, index.js, about.js, settings.js, dashboard.js, terms-of-service.js, signup.js, login.js. Ceux-ci deviennent des points d'entrée vers votre application que vous pouvez partager sur tous types de supports.

Guillermo Rauch: When you enter those, we want to give you JS that is relevant for that page, first and foremost, and then perhaps a common bundle so that subsequent navigations within the system are very snappy. Next.js également, ce qui est très, très agréable, pré-extrait automatiquement le reste des pages qui sont connectées à ce point d'entrée, de sorte que cela ressemble à une application d'une seule page. So a lot of people say like, “Why not just use Create React app if I know that I have maybe a couple routes?” I always tell them, “Well, look. You can define those as pages, and because Next.js will automatically pre-fetch ones that are connected, you end up getting your single-page application, but it's better optimized with regards to that initial paint, that initial entry point.”

Drew: In September, I had the pleasure of talking to Cassie Evans about SVG animation. We talked about the approachability of SVG for developers who are already familiar with HTML. Here's Cassie.

Cassie Evans: I think that that's what I love the most about SVG is I'm really into creative coding and also teaching people, and I found that teaching people who are more of a creative leaning, they sometimes get a little thrown off when you immediately jump in with JavaScript or Python or something like that for creative coding. But without fail, I've managed to get anyone that I taught on board with SVG because there some really approachable entry points because it does look like HTML.

Cassie Evans: So you can give someone with an understanding of HTML and how to build websites SVG, and it looks the same, but it's the graphics instead of documents, and then you can animate that with CSS to start off with, which is also a little bit more comfortable, and then you can kind of progress to animating it with JavaScript. So it's a really good learning curve.

Drew: Of course, it can be dynamic. It's not just a case of creating motion. You can actually make the properties of it dynamic. So one of the interesting things I've seen SVG used for, and it's a grand term, but data visualization, dataviz, and drawing graphs and charts and of course things like dashboards that we seem to have everywhere these days. SVG is sort of perfect for that, isn't it?

Cassie Evans: Yes, definitely. SVG is great for dataviz. All the way from kind of small dataviz up to D3 which is very well known dataviz library that uses SVG under the hood. But you could also just, if you've got a little bit of data that you wanted to show on a web page, you could create a chart in a graphics editing program, and then you could just use JavaScript to change those values and kind of change how your graph looks. So you don't have to go all in with a massive database library. You can kind of just start off small.

Drew: The Jamstack framework, RedwoodJS was the topic of conversation with Anthony Campolo. I asked Anthony what it meant to be a full-stack Jamstack framework in practical terms.

Anthony Campolo: Yeah, it's pushing the boundaries of what a Jamstack application can be. So by calling it full-stack Jamstack, it's about, how do we go beyond just the front end to having the same sort of deployment paradigm of just get pushed, getting your whole code deployed? How do we get that but also with our back end and have it all connected?

Drew: Vue.js version three was released in October, and I caught up with Natalia Tepluhina from the Vue core team. Discussing the new version, I was curious if the major version bump was just a result of a few backward incompatible modifications or if this was a very clear revisiting of Vue to make deeper changes to the framework.

Natalia Tepluhina: No. I think it was an idea to create a new version due to a few very important things. Donc tout d'abord, il y avait une motivation pour changer la réactivité. Previous one was built upon Object.defineProperty, and it had a few caveats. They're all documented, but still, even if you document something that people shouldn't do, they will do it anyway, and you would need to point them to the documentation. Nobody reads documentation, by the way. For some reason, it just happens. Until you point people out, it doesn't exist in docs, it does. Mais ok. Nous vous apprendrons quand même.

Natalia Tepluhina: So reactivity was one of the things. Performance was the next. Vue 2 still had and has not the worst performance, but we had a few ideas about how to make Vue faster, and also, there was one pain point for a particular part of our, let's say audience, people that use Vue. C'était TypeScript. Vue 2 internally was written in Flow, which is still strongly typed one, but typing with TypeScript were a real nightmare especially if you were working with our state management Vuex.

Natalia Tepluhina : Donc, c'était encore une fois une partie énorme. Le dernier était que nous manquions en quelque sorte la fonctionnalité de la logique abstraite, en termes non pas de composants, mais de parties logiques compossibles, comme les fonctions d'assistance, etc., mais elles devraient également pouvoir inclure l'activité Vue. Un bel exemple ici pourrait être React Hooks, non ? Ils vous permettent d'abstraire les parties de la fonctionnalité, ce qui manquait clairement dans Vue. Je sais qu'en ce moment, cela ressemble à "Vous avez volé la fonctionnalité de React". Pas en fait. Je crois que la pollinisation croisée des idées est une grande et belle partie de notre écosystème, et cela aide également les développeurs à basculer entre les favoris, n'est-ce pas ? Nous avons donc travaillé sur ces fonctionnalités principales pour créer le Vue 3 en version majeure.

Drew : Ensuite, nous nous sommes plongés dans TypeScript avec Stefan Baumgartner pour découvrir comment cela peut nous aider à écrire un meilleur code avec moins de bogues. Observant la tendance des organisations à déplacer entièrement leur base de code vers JavaScript, j'ai demandé à Stefan si TypeScript était quelque chose dont les grandes équipes bénéficieraient plus que les individus.

Stefan Baumgartner : Je suis donc actuellement dans la même transition. Nous avons donc beaucoup de développeurs Java et C++ qui vont écrire beaucoup de JavaScript à l'avenir. TypeScript peut être une sorte de guide pour ces zones effrayantes du nouveau langage de programmation. JavaScript a beaucoup de bizarreries, beaucoup d'histoire et beaucoup de préjugés si vous venez d'un langage de programmation différent. Donc TypeScript peut être un guide car il y a des concepts qui vous sont familiers dans le système de type.

Stefan Baumgartner : Mais aussi, je pense, surtout quand vous avez beaucoup de personnes travaillant dans la même base de code ou beaucoup de personnes qui ont besoin de travailler les unes avec les autres, cela peut être une couche supplémentaire de conseils dans votre projet, où vous ne pas de mauvaises surprises au final. Alors bien sûr, la technologie ne résout aucun problème de communication. Ce n'est pas à cela que TypeScript est destiné. Mais cela peut diminuer, ou cela peut faire beaucoup plus de place pour la bonne discussion, alors si vous n'avez pas à parler, qu'attendez-vous de moi dans votre code, mais plutôt, que devrait faire votre code, ou que devrait votre bibliothèque faire?

Stefan Baumgartner : Je dis toujours que si jamais vous écrivez du code pour d'autres personnes ou si vous écrivez du code avec beaucoup de gens ou si vous écrivez simplement du code pour vous-même, vous devez revoir le lendemain, pensez à TypeScript car cela pourrait vous aider dans le long terme. Ce n'est pas seulement un investissement pour le prochain projet de la semaine prochaine, mais plus pour celui qui dit, d'accord, surtout si vous avez des projets de longue durée pendant un mois, deux ou des années, offrez-le définitivement. Vous ne saurez jamais à quoi vous pensiez lorsque vous avez écrit le petit morceau de code il y a un an, mais les types peuvent vous donner une idée de ce que vous vouliez dire.

Drew : En novembre, j'ai discuté avec David Darnes du générateur de site statique Eleventy. Nous avons parlé des modèles et du nombre de générateurs de sites statiques qui ont une opinion assez forte sur le type de modèles que vous devriez utiliser. Je me demandais si Eleventy avait le même genre de convictions fortes. Voici Dave.

David Darnes : Non, je dois dire que c'est aussi proche que possible. Un point de vue un peu personnel, mais j'ai eu du mal à voir un cadre ou quoi que ce soit qui puisse être sans opinion parce que, pour créer quelque chose, vous devez avoir une opinion sur la façon dont vous voulez faire quelque chose. C'est une sorte d'oxymore. Je suis sûr que les gens pourraient me corriger là-dessus. Mais ouais. Vous pouvez passer à la langue de template avec laquelle vous vous sentez le plus à l'aise. Je veux dire, nous parlions juste des langues avec lesquelles vous êtes à l'aise. Eleventy fait appel à cela dans une sorte de sens avec les langages de modèles utilisés dans votre HTML, ou diable même votre CSS, si vous le souhaitez.

David Darnes : Pour moi, je suis allé directement aux nunjucks parce que nunjucks est le langage de template par défaut dans Eleventy. Cela signifie que je peux utiliser l'extension HTML par points et la laisser telle quelle. Maintenant, je vais juste confondre encore plus les gens et leur dire : « Vous pouvez nommer ça comme vous voulez de toute façon. Vous pouvez vraiment vous amuser avec. Mais vous pouvez utiliser le guidon. Je pense que vous pouvez simplement utiliser des modèles JavaScript réguliers et les parcourir comme ça. Guidons assez populaires et liquides également. Je ne peux pas penser à tous par le haut de ma tête, mais si vous configurez tout dans la configuration, vous pouvez simplement choisir ce que vous voulez.

David Darnes : Je dirais que je suis un vrai grand fan des langages de modèles en général. Il n'y a pas si longtemps, j'ai découvert que vous pouviez utiliser twig dans WordPress, et cela m'a époustouflé. J'étais comme, "Oh, Dieu merci. Je n'ai pas à gérer une boucle for à l'intérieur de PHP. Encore une fois, je pense à quelque chose d'un peu plus confortable et compréhensible, plus lisible aussi. Donc voilà. Eleventy a beaucoup d'options de modèles différentes, et il devrait plaire aux personnes qui sont à l'aise avec ces différentes options.

Drew : J'ai parlé avec Leslie Cohn-Wein de la façon dont Netlify utilise sa propre plate-forme pour construire Netlify et comment leur fonctionnalité Deploy Preview devient une plate-forme de mise en scène efficace pour les modifications frontales.

Leslie Cohn-Wein : Peut-être que ma partie préférée de tout ce processus est la magie des aperçus de déploiement, que nous obtenons via Netlify. Donc, ce qui se passe, c'est que vous travaillez dans GitHub, vous augmentez vos relations publiques. Donc, vous ouvrez votre PR dans GitHub, et cela va créer automatiquement une version de votre aperçu de déploiement de l'application. Nous utilisons donc en fait Deploy Previews de l'application elle-même pour tester, pour nous assurer que tout fonctionne comme il se doit. Nous effectuons nos tests. C'est ce que nous utilisons en quelque sorte pour vérifier manuellement lors de la révision du code. Nous avons donc en quelque sorte tout ce déploiement continu configuré directement depuis GitHub.

Leslie Cohn-Wein : Ensuite, l'une des autres choses intéressantes que nous avons mises en place est que nous avons en fait quelques sites Netlify différents qui tirent du même référentiel où se trouve notre application. Nous avons donc tous les deux notre application. Nous avons une instance de Storybook qui contient en quelque sorte nos composants d'interface utilisateur pour l'application. Nous avons donc à la fois notre application elle-même. Nous avons les composants de l'interface utilisateur Storybook, et nous avons essentiellement un site Netlify qui affiche notre interface utilisateur Storybook, puis nous avons également un troisième site qui exécute un analyseur de bundle Webpack. C'est donc une sorte d'interface utilisateur visuelle qui vous donne une visualisation arborescente de tous les ensembles d'applications, et nous pouvons en quelque sorte évaluer leur taille, et c'est juste un rappel pour nous de revérifier en quelque sorte à chaque déploiement de l'application va dehors, nous pouvons vérifier et nous assurer que nous ne faisons rien de bizarre avec notre taille de paquet là-bas.

Leslie Cohn-Wein : Donc, ces trois sites sont générés en une seule demande d'extraction de l'application. Ainsi, vous obtiendrez des liens pour prévisualiser, vos aperçus de déploiement essentiellement, à la fois de l'application Storybook et de ce profil d'application pour que nous puissions vérifier.

Drew : En décembre, j'ai parlé avec Chris Murphy de la conception de produits et de ce que cela signifie pour une entreprise d'être axée sur la conception. Nous avons discuté de la question de savoir si un fondateur individuel se concentre sur la conception, cela se répercute-t-il sur l'entreprise et si un produit est naturellement une extension de la personne qui l'a créé.

Chris Murphy : Je pense que c'est une très bonne question, Drew, et je pense que la réponse est que cela dépend. Je pense que cela dépend de cette personne, et cela dépend de la taille de l'entreprise. Si vous jetez un coup d'œil à Hiut Denim, et j'utilise beaucoup Hiut dans mon enseignement, c'est un très bon exemple d'une entreprise qui fait bien une chose, et c'est leur genre de jeans à bretelles. Je pense que si vous regardez le passé de David… David et Clare, parce qu'ils forment un partenariat. Si vous regardez la société précédente de David Hieatt et Clare Hieatt, qui était Howies, cette société était devenue si grande qu'il y avait tellement de personnes impliquées.

Chris Murphy : Une fois que l'échelle commence à s'infiltrer, il devient très difficile de garder un œil sur tous les petits points de contact qui comptent dans le parcours client. Je pense que c'est très révélateur quand ils ont quitté Howies, parce que Howies avait été racheté par… C'est compliqué. Allez le lire sur internet. Mais c'était Timberland, et Timberland a été acheté, et il y a toute cette histoire.

Chris Murphy : Je pense que c'est vraiment intéressant qu'ils se concentrent maintenant sur les jeans. C'est ça. Ils racontent une histoire incroyablement bonne autour des jeans. Ils emballent également tout très, très bien, et les jeans sont comme un véhicule pour des histoires, vraiment. C'est quelque chose que je pense, Drew, va devenir plus important à mesure que nous sortirons de l'autre bout de COVID, dont j'espère que nous sortirons de l'autre bout. Tous ceux qui fabriquent ces jeans reçoivent un salaire convenable. L'un des problèmes que j'ai à la minute où je regarde le monde, c'est que tout le monde ne reçoit pas un salaire convenable, et je trouve cela un peu inquiétant, en tant que quelqu'un… Écoutez, j'ai 51 ans. Mon fils a 25, 24 ans. , 25 ans, quelque chose comme ça. C'est terrible. Je devrais savoir tout ça. C'est un photographe de mariage. Il est photographe de mariage depuis environ un an et un peu. Son entreprise est complètement décimée parce que personne ne se marie vraiment à la minute parce que c'est juste difficile. Il n'a pas de salaire parce qu'il n'avait pas assez de livres indépendants pour obtenir le soutien.

Chris Murphy : Il est tombé entre les mailles du filet, et il y a beaucoup d'autres personnes qui sont tombées entre les mailles du filet. Je dirais que c'est un problème de conception, que nous devons considérer cela comme un problème de conception. Mais si je regarde aussi cette question plus large de COVID et du gouvernement et de toutes ces choses sans devenir trop politique, j'ai lu un article dans le Guardian hier sur le voisin de Matt Hancock, et quiconque écoute qui n'est pas du Royaume-Uni, Matt Hancock est le secrétaire à la santé. Son voisin, qui dirigeait une entreprise, lui envoyait un texto et lui demandait des conseils sur : « Comment puis-je fournir des produits pour ce truc COVID ? Il y a énormément de rumeurs autour de la chumocratie, c'est comme ça que les journaux l'appellent, des amis d'amis de ministres du gouvernement qui semblent obtenir des emplois parce qu'ils connaissent les bonnes personnes.

Chris Murphy : J'ai l'impression que nous allons arriver à l'autre bout et voir cela… Les individus voient cela, et ils pensent : « Eh bien, où va cet argent, et les gens sont-ils payés correctement ? Quel est le prix de ce t-shirt d'une livre de la boutique X ? » Je ne veux citer aucune marque. Mais tout doit être payé, et tout ce qui est fait, les gens doivent être payés pour le faire. Je pense que les gens s'intéressent de plus en plus à la question de savoir si les gens sont payés équitablement ?

Drew: GraphQL était le sujet de notre dernier épisode complet de l'année, et j'ai eu une conversation avec Eve Porcello et demandé où GraphQL s'intègre dans la pile de développement.

Eve Porcello : Oui. GraphQL s'intègre en quelque sorte entre le front-end et le backend. C'est donc en quelque sorte un milieu entre les deux et cela donne beaucoup d'avantages aux développeurs front-end et aux développeurs back-end. Si vous êtes un développeur front-end, vous pouvez définir toutes les exigences de données de votre front-end. Donc, si vous avez une grande liste de composants React, par exemple, vous pouvez écrire une requête, et cela va définir tous les champs dont vous auriez besoin pour remplir les données de cette page.

Eve Porcello : Maintenant, avec le backend, c'est vraiment propre, parce que nous pouvons collecter beaucoup de données à partir de nombreuses sources différentes. Nous avons donc des données dans les API REST et les bases de données et tous ces différents endroits, et GraphQL nous fournit cette jolie petite couche d'orchestration pour vraiment donner un sens au chaos de l'endroit où se trouvent toutes nos données. C'est donc vraiment utile pour tout le monde partout dans la pile.