Catégories
Astuces et Design

Les meilleures pratiques modernes sont-elles mauvaises pour le Web? – Magazine Smashing

Nous demandons si les meilleures pratiques modernes sont mauvaises pour le Web? Les cadres modernes nous mènent-ils sur la mauvaise voie? Drew McLellan parle à l'expert Lean Web Chris Ferdinandi pour le savoir.

Photo de Chris FerdinandiAujourd'hui, nous nous demandons si les meilleures pratiques modernes sont mauvaises pour le Web? Les cadres modernes nous mènent-ils sur la mauvaise voie? Je parle à l'expert Lean Web Chris Ferdinandi pour le savoir.

Afficher les notes

Mise à jour hebdomadaire

Transcription

Drew McLellan: Il est l'auteur de Vanilla JS Pocket Guide Series, créateur du programme de formation Vanilla JS Academy et animateur du podcast Vanilla JS. Il a élaboré un bulletin d’informations sur les astuces, lu par près de 10 000 développeurs chaque jour de la semaine. Il a enseigné aux développeurs dans des organisations comme Chobani et le Boston Globe. Et ses plugins JavaScript ont été utilisés par des organisations comme Apple et Harvard Business School. Surtout, il aime aider les gens à apprendre le JavaScript vanille. Nous savons donc qu'il préfère choisir Vanilla JavaScript plutôt qu'un framework, mais saviez-vous qu'il a déjà été choisi dans une file de policiers comme étant la personne la moins susceptible d'avoir commis le crime? Mes amis Smashing, veuillez souhaiter la bienvenue à Chris Ferdinandi. Salut Chris. Comment allez-vous?

Chris Ferdinandi: Oh, je fracasse. Merci de m'avoir.

A dessiné: Je voulais vous parler aujourd'hui de ce concept de Lean Web, ce qui est une passion pour vous, n'est-ce pas?

Chris: Oui, tout à fait.

A dessiné: Pourquoi ne nous plantez-vous pas le décor? Quand on parle de Lean Web, quel problème essayons-nous de résoudre?

Chris: Ouais, excellente question. Juste comme une mise en garde pour tous les auditeurs, cet épisode pourrait faire hurler un petit vieil homme au nuage. Je vais essayer d’éviter cela. Quand je regarde la façon dont nous construisons pour le Web aujourd'hui, cela ressemble un peu à un gâchis surchargé d'ingénierie. J'en suis venu à croire que beaucoup de ce que nous considérons comme les meilleures pratiques aujourd'hui pourraient en fait aggraver le Web.

Chris: Le Lean Web est une approche du développement Web qui se concentre sur la simplicité, sur les performances et sur l'expérience des développeurs… Je suis désolé, pas l'expérience des développeurs. L'expérience utilisateur plutôt que l'expérience des développeurs, et la facilité de construire les choses du point de vue de l'équipe, c'est ce que je pense sur lequel nous nous concentrons beaucoup aujourd'hui et comme nous allons probablement entrer dans notre conversation.

Chris: En fait, j’ai découvert que bon nombre de ces éléments que nous considérons comme une amélioration de l’expérience des développeurs le font pour un sous-ensemble de développeurs, mais pas nécessairement pour tous ceux qui travaillent sur ce que vous construisez. Il y a donc tout un tas de problèmes avec cela aussi, que nous pouvons approfondir. 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.

A dessiné: Au fur et à mesure que le Web évolue en tant que plate-forme de développement, il semble y avoir cette tendance de plus en plus grande vers la spécialisation.

Chris: Oui.

A dessiné: Les gens qui couvraient Full Stack, puis nous nous sommes séparés en front-end et en back-end. Et puis ce front-end s'est divisé en personnes qui font du développement CSS ou JavaScript. Et puis de plus en plus au sein de JavaScript, il se spécialise. Quelqu'un peut se considérer et se commercialiser comme un développeur React ou un développeur Angular, et toute son identité et ses perspectives sont basées sur un cadre particulier dans lequel il est hautement qualifié. Cette dépendance aux frameworks, au cœur de notre travail sur le Web, une mauvaise chose?

Chris: C'est nuancé. J'étais très fortement dans le camp du oui, toujours. Je pense que dans l'ensemble, j'ai toujours le sentiment que oui, notre obsession en tant qu'industrie avec les cadres et les outils en général, est potentiellement un peu à notre détriment. Je ne pense pas que les cadres soient intrinsèquement mauvais. Je pense qu'ils sont utiles pour un sous-ensemble très restreint de cas d'utilisation. Et nous finissons par les utiliser pour presque tout, y compris dans de nombreuses situations où ils ne sont vraiment pas nécessairement le meilleur choix pour vous ou pour le projet.

Chris: Quand je pense à un grand nombre de problèmes que nous avons sur le Web aujourd'hui, le cœur de ces problèmes commence vraiment par notre dépendance excessive à l'égard des cadres. Tout le reste qui vient après cela l'est à bien des égards, car nous jetons tellement pas seulement des frameworks qui sont JavaScript en général, sur le Web. Je dis cela en tant que personne qui enseigne professionnellement aux gens comment écrire et utiliser JavaScript. C’est ainsi que je gagne mon argent. Et je dis ici que je pense que nous utilisons trop de JavaScript, ce qui est parfois un peu étrange.

A dessiné: Dans le temps qui a précédé l'apparition des grands frameworks, nous avions l'habitude de créer des interfaces utilisateur et des choses avec jQuery ou autre. Et puis les cadres sont arrivés et ils nous ont donné plus de ce concept d'une interface utilisateur basée sur l'état.

Chris: Oui.

A dessiné: Il s’agit maintenant d’une partie de l’ingénierie assez complexe que vous devez mettre en place. Travailler avec moins de JavaScript exclut-il l'utilisation de quelque chose comme ça, ou devez-vous le réimplémenter vous-même? Êtes-vous simplement en train de créer un passe-partout chargé?

Chris: Cela dépend en grande partie de ce que vous faites. Si vous avez une interface qui ne change pas, vous pouvez créer une interface utilisateur basée sur l’état avec… je ne sais pas, peut-être une douzaine de lignes de code. Si vous avez une interface qui ne change pas, je dirais honnêtement probablement l'interface utilisateur basée sur l'état. Ce n’est pas nécessairement la bonne approche. Vous pouvez probablement faire d’autres choses à la place. Pensez aux générateurs de sites statiques, à certains balisages pré-rendus, même à un site WordPress ou PHP à l'ancienne.

Chris: Mais là où cela commence à devenir intéressant, c'est lorsque vous entrez dans des interfaces plus dynamiques et interactives. Pas seulement des applications. Je sais que les gens aiment tracer cette ligne entre les sites Web et les applications, et je pense qu'il y a ce mélange étrange entre les deux et la ligne n'est pas toujours aussi claire. Lorsque vous commencez à vous intéresser davantage, l'utilisateur fait des choses, quelque chose change. L'interface utilisateur basée sur l'état devient un peu plus importante. Mais vous n’avez toujours pas besoin de tonnes de code pour y parvenir.

Chris: Je regarde quelque chose comme React ou Vue, qui sont des pièces d'ingénierie absolument incroyables. Je ne veux pas priver les gens qui y travaillent. J'ai fini par être un exercice d'apprentissage, en construisant mon propre mini-cadre juste pour avoir une meilleure idée de la façon dont ces choses fonctionnent sous le capot. Il est vraiment difficile de rendre compte de toutes les différentes pièces mobiles. J'ai donc un immense respect pour les personnes qui construisent et travaillent sur ces outils. Mais React et Vue font tous les deux environ 30 kilo-octets après la minification et le gzipping. Donc, une fois que vous les avez déballés, ils sont nettement plus gros que cela.

Chris: Pas tout, mais une bonne partie de ce poids est consacrée à cette chose appelée le DOM virtuel. Il existe des alternatives qui utilisent des API ou des approches similaires. Pour React, vous avez Preact, qui fait 2,5 kilo-octets ou environ 3 kilo-octets au lieu de 30. C'est un dixième de la taille. Pour Vue, vous avez plutôt Alpine JS, qui fait environ 7 kilo-octets. Pourtant, beaucoup plus petit. La grande différence entre ceux-ci et leurs homologues grands frères, c'est qu'ils ont abandonné le DOM virtuel. Ils peuvent abandonner une ou deux méthodes. Mais en général, c'est la même approche et le même type d'API dans la manière de travailler avec le code, et ils sont nettement plus petits.

Chris: Je pense que de nombreux outils que nous utilisons sont potentiellement surpuissants pour les choses que nous essayons de faire. Si vous avez besoin d'une interface utilisateur basée sur l'état et que vous avez besoin de données réactives et de ces interfaces dynamiques, c'est parfait. Je pense que l'une des grandes choses dont j'essaie de parler aujourd'hui n'est pas… de ne jamais utiliser d'outils. Pour moi, Vanilla JS n'est pas que vous écrivez à la main chaque ligne de code et chaque projet que vous faites. C’est de la folie. Je ne pourrais pas faire ça, je ne fais pas ça. Mais il est plus sélectif sur les outils que nous utilisons. Nous optons toujours pour le multi-outil, le couteau suisse qui contient toutes ces choses. Et parfois, tout ce dont vous avez vraiment besoin est une paire de ciseaux. Vous n’avez pas besoin de tous les autres éléments, mais nous les avons quand même.

Chris: Ce qui est un très long chemin pour… Je suis désolé, de répondre à votre question. Ce qui est parfois plus de code que ce que vous pourriez ou voudriez écrire vous-même, mais ce n’est pas autant de code que je pense que cela nécessite. Quand je dis que vous n’avez pas besoin d’un cadre, je reçois beaucoup de réticences autour de cette idée: «Eh bien, si vous n’utilisez pas de cadre, vous écrivez essentiellement le vôtre.» Ensuite, cela vient avec ses propres problèmes. Je pense qu'il y a une place entre l'utilisation de React ou Vue et l'écriture de votre propre framework, et c'est peut-être choisir quelque chose qui est un peu plus petit. Il y a parfois des raisons pour lesquelles l'écriture de votre propre framework peut en fait être le bon choix, en fonction de ce que vous essayez de faire. Tout cela est très fluide et subjectif.

A dessiné: Il est assez intéressant qu’en tant qu’exercice d’apprentissage, vous ayez implémenté votre propre cadre basé sur l’état. Je me souviens que dans le passé, je pensais que chaque fois que je cherchais une bibliothèque ou quelque chose comme ça, j'aimais penser que je pouvais l'implémenter moi-même.

Chris: Bien-sûr.

A dessiné: Mais accéder à la bibliothèque m'a évité les tracas de le faire. Je savais que si je devais écrire ce code moi-même, je savais quelle approche je prendrais pour le faire. Et c'était vrai jusqu'à l'utilisation de choses comme jQuery et autres. Ces jours-ci, je pense que si je devais écrire ma propre version de Vue ou de React, je n'ai presque aucune idée de ce qui se passe maintenant dans cette bibliothèque, dans tout ce code.

A dessiné: Pour ceux d'entre nous qui ne sont pas familiers, quand vous dites quelque chose comme Preact laisse tomber le DOM virtuel et rend tout beaucoup plus petit, que nous donne ce DOM virtuel?

Chris: Pour répondre à cette question, je veux juste prendre un peu de recul. L'une des plus belles choses que les frameworks et autres bibliothèques basées sur des états vous offrent est la différence DOM. Si vous ne mettez pas vraiment à jour l'interface utilisateur autant, vous pouvez vous contenter de dire: "Voici une chaîne de ce à quoi le balisage est censé ressembler. En HTML, je vais simplement mettre tout ce balisage dans cet élément. " Lorsque vous avez besoin de changer quelque chose, vous le faites à nouveau. C'est un peu cher pour les navigateurs, car cela déclenche un repeint.

Chris: Mais je pense que potentiellement plus important que cela, l'un des problèmes avec cela est que vous avez une sorte d'élément interactif, un champ de formulaire, un lien sur lequel quelqu'un s'est concentré. Cette focalisation est perdue parce que l'élément… même si vous avez une nouvelle chose qui semble similaire, ce n'est pas le même élément littéral. Donc, si la mise au point est perdue, cela peut créer de la confusion pour les personnes utilisant des lecteurs d'écran. Il y a tout un tas de problèmes avec ça.

Chris: Tout élément d'interface utilisateur basé sur un état qui vaut son poids va en implémenter certains pour des DOM différents, où ils disent: «Voici à quoi devrait ressembler l'interface utilisateur. Voici à quoi cela ressemble actuellement dans le DOM. Qu'est ce qui est different?" Et cela va changer ces choses. Il fait effectivement les choses que vous feriez simplement mettre à jour manuellement l'interface utilisateur vous-même, mais il le fait pour vous sous le capot. Vous pouvez donc simplement dire: "Voici à quoi je veux que cela ressemble." Et puis la bibliothèque ou le framework le comprend.

Chris: Les plus petites choses comme Preact ou Alpine, elles le font en fait directement. Ils convertissent la chaîne que vous leur fournissez de ce à quoi l'interface utilisateur devrait ressembler en éléments HTML. Et puis ils comparent chaque élément à sa pièce correspondante dans le DOM littéral. Au fur et à mesure que vous vous retrouvez avec des interfaces utilisateur de plus en plus volumineuses, cela peut avoir une incidence sur les performances, car interroger le DOM encore et encore devient coûteux. Si vous voulez avoir une idée du type d'interface où cela devient un problème, cliquez avec le bouton droit de la souris et inspectez l'élément sur le bouton «Favoris» sur Twitter, ou sur le bouton «J'aime» sur Facebook. Et jetez un œil à l'imbrication des divs qui vous amène à cet élément. C'est très, très profond. C'est comme une douzaine de divs, imbriqués les uns dans les autres juste pour ce tweet unique.

Chris: Lorsque vous commencez à descendre autant de couches, cela commence à avoir un impact réel sur les performances. Ce que fait le DOM virtuel, c'est au lieu de vérifier le vrai DOM à chaque fois, il crée une carte basée sur des objets de ce à quoi ressemble l'interface utilisateur en JavaScript. Et puis fait la même chose pour l'interface utilisateur avec laquelle vous souhaitez remplacer l'existant, et il compare ces deux. C’est beaucoup plus de performances en théorie que de faire cela dans le vrai DOM. Une fois qu'il a obtenu une liste des choses qu'il doit changer, il s'exécute et effectue ces changements. Mais il n'a qu'à attaquer le DOM une seule fois. Il ne vérifie pas chaque élément, à chaque fois. Si vous avez des interfaces comme Twitters ou Facebook ou QuickBooks ou quelque chose comme ça, le DOM virtuel a probablement beaucoup de sens.

Chris: Le défi avec cela est … la différence entre Preact et React est de 27 kilo-octets avant de décompresser le tout dans sa véritable onde de code. Le téléchargement brut et le temps de décompression et de compilation sur cela seul peuvent ajouter un peu de latence à la charge initiale sur une interface utilisateur. Cela devient encore plus prononcé si vos utilisateurs ne sont pas sur les derniers appareils d'Apple. Même un appareil Android d'il y a quelques années ou un téléphone multifonction, ou si vous avez des gens dans des pays en développement, c'est vraiment… le temps de commencer est plus lent. Et puis en plus de cela, le temps interactif réel est plus lent en raison de l'abstraction supplémentaire.

Chris: Donc, ce n’est pas seulement vous le chargez et leur vitesse est comparable. Chaque micro-interaction que quelqu'un fait et les changements qui doivent se produire peuvent également être légèrement plus lents simplement à cause de tout ce code supplémentaire. Si vous avez une interface utilisateur vraiment très complexe avec de nombreux éléments imbriqués et beaucoup de données, les gains de performances du DOM virtuel l'emportent sur ce poids de code supplémentaire. Mais toute interface utilisateur typique pour une application typique pour laquelle la plupart des développeurs utilisent React ou Vue, l'avantage que vous obtenez du DOM virtuel n'est tout simplement pas là et ils seraient mieux lotis. Même si vous souhaitez conserver la même commodité que React, utilisez Preact. C'est une fraction de la taille, cela fonctionnera exactement de la même manière et ce sera plus performant. C'est le genre de chose que j'ai tendance à défendre.

Chris: Nous devons mieux choisir le bon outil pour le travail. Si vous adoptez une approche comme celle-là, si vous arrivez à un point où un DOM virtuel a vraiment du sens, il est beaucoup plus facile de porter Preact dans React que si vous utilisiez le vôtre. Telle est la situation. Si cela vous inquiète vraiment, vous bénéficiez également d'une protection future.

A dessiné: Certains pourraient dire qu'ils pourraient faire valoir que ces frameworks, des choses comme Vue, React sont si hautement optimisés pour les performances que vous en tirez tellement d'avantages qu'il suffit de les coupler avec un gestionnaire de packages dans un bundler pour vous assurer que vous n'êtes que envoyer le code que vous souhaitez. Vous avez sûrement déjà une longueur d'avance rien qu'en faisant cela?

Chris: Ouais. Je ne suis pas d’accord. Je n’ai pas vraiment plus à développer à ce sujet que… je suppose que peut-être, mais pas vraiment. Même avec un bundler, vous avez toujours besoin de ce noyau React. Même avec le regroupement, cela sera toujours plus important que d'utiliser quelque chose comme Preact.

Chris: Drew, j'apprécie vraiment que vous ayez posé la question à ce sujet. Parce qu'une des autres choses dont je parle dans mon livre, The Lean Web, et mon discours du même nom, c'est comment ces outils… Vous avez mentionné le regroupement, par exemple. L'une des choses que nous faisons pour contourner le problème de performance que nous tirons de l'utilisation de tout ce JavaScript est de lancer encore plus de JavaScript au front-end pour en tenir compte. Les gestionnaires de packages et les bundleurs de modules sont l'un des moyens de le faire.

Chris: Comme vous l’avez fait allusion… pour ceux d’entre vous qui ne le savent pas, ce sont des outils qui… ils compileront tous vos petits éléments JavaScript individuels dans un seul gros fichier. Les plus récents et les plus… Je ne veux pas les appeler pensifs. Mais les plus récents utiliseront une fonctionnalité appelée Tree Shaking, où ils se débarrassent de tout code qui n'est pas réellement nécessaire. Si ce code a des dépendances qui ne sont pas utilisées pour ce que vous avez réellement fait, ils supprimeront certaines de ces choses pour rendre vos packages aussi petits que possible. Ce n’est en fait pas une idée terrible, mais cela aboutit à ce que j’appelle généralement la santé des dépendances, où vous avez ce château de cartes vraiment délicat de dépendances en plus des dépendances.

Chris: La configuration de votre processus prend du temps. Et quiconque a déjà exécuté une installation NPM et a ensuite découvert qu'un tas de dépendances étaient obsolètes et a dû passer une heure à essayer de déterminer celles qui devaient être corrigées et oh, c'est en fait une dépendance dans une dépendance et vous ne le faites pas. Je n'ai pas la capacité de le réparer vous-même. C’est un tout. Peut-être que cela fonctionne pour vous, mais je préfère passer mon temps à ne pas déconner à essayer de rassembler mes dépendances.

Chris: J'ai commencé à collecter des tweets de personnes qui se plaignent du temps perdu dans leur flux de travail. L'un de mes favoris, Brad Frost il y a quelques années, parlait de la prise de conscience déprimante que la chose que vous avez traversée dans le JS moderne aurait pu vous prendre 10 minutes dans jQuery. Je ne suis pas vraiment un fan de jQuery, mais je ressens cette douleur quand il s'agit de travailler avec des frameworks.

Chris: L'autre problème avec beaucoup de ces outils est qu'ils commencent à devenir des gardiens. Je ne sais pas à quel point vous voulez vraiment vous plonger dans ça ou pas, Drew. Mais l'un de mes grands obstacles contre JS, toutes les choses dans un flux de travail. Surtout lorsque vous commencez à dire: "Eh bien, si nous utilisons déjà JS pour le HTML, pourquoi ne pas l'utiliser aussi pour le CSS?" Vous commencez à exclure beaucoup de personnes vraiment talentueuses du processus de développement. C'est juste une très grosse perte pour le projet pour la communauté dans son ensemble.

A dessiné: Eh bien, je le suis certainement … J'ai commencé à utiliser React au début de 2020, en ajoutant cela à mes compétences. Je le fais maintenant depuis près de sept mois. Je dois dire qu’une partie dans laquelle je suis le moins confiant est la mise en place des outils permettant de démarrer un projet.

A dessiné: Il semble qu'il y ait énormément de travail pour obtenir quelque chose à Hello World, et il y a encore plus que vous devez savoir pour le préparer à la production. Cela doit rendre le développement plus difficile à démarrer si cela est présenté comme ce que vous devriez faire en 2020 pour apprendre à devenir développeur Web. Quelqu'un qui vient de s'y lancer aura un réel problème. Ce sera une véritable barrière à l’entrée, n’est-ce pas?

Chris: Absolument. L'autre élément ici est que les développeurs JavaScript ne sont pas toujours les seules personnes à travailler sur une base de code ou à contribuer de manière significative à cette base de code. Plus nous faisons de la connaissance de JavaScript une exigence pour travailler avec une base de code, moins ces personnes sont susceptibles de participer réellement au projet.

Chris: Un exemple de cela, dont j'aime parler est WordPress, qui a été récemment … Je ne devrais pas dire récemment à ce stade. Cela fait maintenant deux ans. Mais ils déplacent de plus en plus leur pile back-end vers JavaScript, loin de PHP, ce qui n'est pas intrinsèquement une mauvaise chose. Leur nouvel éditeur, Gutenburg, est basé sur React.

Chris: En 2018, la principale consultante en accessibilité de WordPress, Rian Rietveld, dont j'ai presque certainement abattu le nom … elle a démissionné très publiquement d'elle et a expliqué pourquoi dans un article très détaillé. Le cœur du problème était qu'elle et son équipe étaient chargées d'auditer cet éditeur pour s'assurer qu'il allait être accessible. WordPress représente désormais 30% du Web. Leur objectif est de démocratiser l'édition, donc l'accessibilité en est une partie vraiment importante. Cela devrait être une partie importante de tout projet Web. Mais pour eux en particulier, c'est extrêmement important. Tout le travail de son équipe est de s’assurer que tout le travail de son équipe était de s’assurer que cet éditeur serait accessible. Mais parce que ni elle ni personne dans son équipe n'avait d'expérience React et parce qu'ils ne pouvaient pas trouver de bénévoles dans la communauté de l'accessibilité avec cette expérience, cela a rendu la tâche très difficile pour elle et son équipe.

Chris: Historiquement, ils pouvaient identifier les erreurs, puis les corriger. Mais avec le nouveau flux de travail basé sur React, ils ont été réduits à l'identification des bogues et au dépôt de tickets. Ils ont été ajoutés à un backlog avec toutes les autres demandes de développement de fonctionnalités sur lesquelles les développeurs JavaScript travaillaient. Beaucoup de choses qui auraient pu être facilement corrigées n'ont pas été incluses dans la première version.

Chris: En mai 2019, environ un an après la démission de Rian, un audit d'accessibilité détaillé a été effectué sur Gutenburg. Le rapport complet comptait 329 pages. Le résumé analytique à lui seul comptait 34 pages. Il a documenté 91 bogues liés à l'accessibilité de manière assez détaillée. Beaucoup d’entre eux étaient vraiment… Je ne veux pas les appeler de simples fruits faciles à manipuler, mais beaucoup d’entre eux étaient des choses de base que l’équipe de Rian aurait pu corriger et cela aurait permis aux développeurs de se concentrer sur le développement de fonctionnalités. C'est finalement ce qu'ils semblent avoir fini par faire, passer beaucoup de temps sur le développement de fonctionnalités et repousser ces choses jusqu'à plus tard. Mais cette équipe est très importante pour le projet, et ils ont soudainement été exclus du processus en raison d'un choix technique.

Chris: Alex Russell est un développeur de l'équipe Chrome. Il a écrit cet article il y a quelques années intitulé The Developer Bait and Switch, où il a parlé de l'argument de l'homme de paille des frameworks. Cette idée que ces outils vous permettent de progresser plus rapidement et de ce fait, vous pouvez itérer plus rapidement et offrir de meilleures expériences. C'est cette idée qu'une meilleure expérience développeur signifie une meilleure expérience utilisateur. Je pense que c’est un exemple très clair de la façon dont cet argument ne se déroule pas toujours comme les gens le croient. C'est peut-être une meilleure expérience pour certaines personnes, pas pour tout le monde.

Chris: Les développeurs CSS, les personnes travaillant sur des systèmes de conception, leur capacité à créer des outils que d'autres peuvent utiliser est parfois limitée par ces choix d'outils. D'après mon expérience, j'étais meilleur en CSS. Cela a beaucoup changé ces dernières années et je suis loin d’être aussi bon qu’avant. D'après mon expérience, les gens qui sont des développeurs CSS vraiment avancés… et je veux dire cela dans le vrai sens du terme. Les personnes qui travaillent sur CSS sont de véritables développeurs Web travaillant sur un langage de programmation. C’est une chose très spéciale ou peut être très spécialisée. Les gens qui sont exceptionnellement bons dans ce domaine, d'après mon expérience, ne sont pas toujours aussi très bons en JavaScript car vous finissez par plonger vraiment profondément dans une chose et vous glissez un peu sur d'autres choses. Leur capacité à travailler avec ces technologies est également entravée, ce qui est dommage, car ce n'était pas le cas auparavant.

Chris: Lorsque la pile était plus simple, il était plus facile pour les personnes de plusieurs disciplines de participer au processus de développement. Je pense que c’est au détriment à la fois des choses que nous construisons et de la communauté dans son ensemble, alors que ce n’est plus le cas.

A dessiné: J'ai trouvé récemment dans un projet de recherche de moyens de résoudre certains des problèmes CSS, des problèmes de flux de travail, nous avons plusieurs travaux sur le projet et la taille du bundle augmente et l'ancien CSS n'est jamais supprimé. C'était un projet React, nous avons donc examiné certaines de ces approches CSS dans JavaScript pour voir ce que nous devrions utiliser de mieux pour résoudre les problèmes que nous avions. Ce qui est devenu très vite évident, c’est qu’il n’existe pas qu’une seule solution pour y parvenir. Il existe des dizaines de façons différentes de procéder.

A dessiné: CSS dans JS est une approche générale, mais vous pouvez passer d'un projet à l'autre et il est complètement influencé d'une manière complètement différente. Même si vous êtes une personne CSS et que vous apprenez une approche particulière sur un projet, ces compétences peuvent ne pas être transférables de toute façon. Il est très difficile de voir comment quelqu'un devrait investir trop de temps pour apprendre cela s'il n'est pas particulièrement à l'aise avec JavaScript.

Chris: Ouais. L'autre chose intéressante que je pense que vous venez de sortir un peu, c'est que lorsque j'en parle, l'un des plus gros rebondissements que je reçois est que les cadres appliquent les conventions. Vous utilisez Vanilla JavaScript, vous avez ce ciel bleu champ vert, vous pouvez faire tout ce que vous voulez, genre de projet. Avec React, il existe une manière React de faire les choses.

Chris: Mais l’une des choses que j’ai constatées, c’est qu’il existe des approches Reacty, mais il n’existe pas de manière stricte de faire les choses avec React. C’est l’une des choses que les gens adorent. C'est un peu plus flexible, vous pouvez faire les choses de différentes manières si vous le souhaitez. Idem avec Vue. Vous pouvez utiliser cette chose basée sur HTML là où vous avez vos propriétés directement dans le HTML et Vue les remplace, mais vous pouvez également utiliser un type de syntaxe de modèle plus JSX si vous préférez.

Chris: J'ai entendu plusieurs personnes se plaindre quand elles apprennent React, l'un des gros problèmes est que vous Google comment faire X dans React et vous obtenez une douzaine d'articles vous indiquant une douzaine de façons différentes de faire cette chose. Cela ne veut pas dire qu’ils ne mettent pas de garde-corps sur un projet. Je ne pense pas que ce soit aussi clair que «j'ai choisi un cadre. Maintenant, c'est ainsi que je construis avec. " Pour être honnête, je ne sais pas que c’est nécessairement quelque chose que je voudrais non plus. Je ne pense pas que vous voudriez que ceux-ci soient étroitement confinés… certaines personnes le font peut-être. Mais si vous vantez cela comme un avantage, je ne pense pas que ce soit aussi prononcé que les gens le prétendent parfois.

Chris: Vous êtes entré dans une chose intéressante juste là, où vous mentionniez le CSS qui n'est plus nécessaire. Je pense que c'est l'une des choses légitimement intéressantes que quelque chose comme CSS et JS… ou lier votre CSS à des composants JavaScript d'une manière ou d'une autre peut vous obtenir, c'est que si ce composant tombe, le CSS aussi en théorie disparaît avec lui. Une bonne partie de cela me donne l'impression de jeter l'ingénierie sur les problèmes des gens. Invariablement, vous êtes toujours dépendant des gens quelque part le long de la ligne. Cela ne veut pas dire ne jamais utiliser ces approches, mais ce n’est certainement pas le seul moyen de résoudre ce problème.

Chris: Il existe des outils que vous pouvez utiliser pour auditer votre HTML et extraire les styles qui ne sont pas utilisés même sans utiliser CSS et JavaScript. Vous pouvez écrire du CSS «à l'ancienne» et toujours faire le linting des styles inutilisés. Il existe des approches de création de CSS qui vous donnent un CSS dans une sortie de type JS et gardent votre feuille de style petite sans cracher ces noms de classe illisibles humains que vous obtenez parfois avec CSS et JS. Comme X2354ABC, ou simplement ces mots absurdes qui sont crachés.

Chris: C'est là que je commence à entrer vraiment dans le vieil homme hurle à la sorte de nuage. Je montre vraiment mon âge de développeur ici. Mais oui, ce n’est pas nécessairement que ces choses sont mauvaises, et elles sont conçues pour résoudre des problèmes légitimes. J'ai parfois l'impression qu'il y a un peu de… si c'est assez bien pour Facebook, c'est assez bien pour nous, genre de chose qui se passe avec ces derniers. Eh bien, Facebook utilise cet outil. Si nous sommes un vrai programme d’ingénierie… une équipe, un service, une organisation, nous le devrions aussi. Je ne pense pas nécessairement que ce soit la bonne façon d’y penser. C’est parce que Facebook traite des problèmes que vous n’avez pas, et vice-versa. La taille et l’échelle de ce sur quoi ils travaillent sont tout simplement différentes, et ce n’est pas un problème.

A dessiné: Exactement. Je vois que certaines de ces choses comme CSS et JavaScript ressemblent presque à un polyfill. Nous avons des problèmes légitimes, nous avons besoin d’un moyen de les résoudre. La technologie ne nous fournit pas encore un moyen de le résoudre. Peut-être que pendant que nous attendons que la plate-forme Web évolue et que nous résolvions ce problème, ce que nous faisons actuellement avec JavaScript nous aidera à traverser et tout ira bien. Nous savons que c'est mauvais. Nous savons que ce n’est pas une excellente solution, mais cela nous aide en ce moment. Et avec un peu de chance, nous pourrons le retirer et utiliser la solution native.

Chris: C’est vraiment drôle que vous en parliez. Parce que littéralement hier soir, je regardais une conférence de Jeremy Keith de l'année dernière sur les applications Web progressives. Mais il parlait de la façon dont il y a quelques décennies, il essayait de convaincre les gens d'utiliser JavaScript. Ce qui semble ridicule à l'époque, mais JavaScript était cette nouveauté. Il a montré aux gens comment vous pourriez faire des choses intéressantes comme changer la couleur d'un lien en survol avec ce nouveau… Il semble absurde que vous ayez besoin de JavaScript pour cela maintenant, car c'est ce que CSS fait pour vous. Mais des éléments tels que l'attribut ou la propriété de focus n'existaient tout simplement pas à l'époque.

Chris: L'une des choses qu'il a dites dans la conférence qui, je pense, a vraiment résonné avec moi, c'est que JavaScript, à bien des égards, ouvre les voies de ces vaches. C’est ce langage très flexible et ouvert que nous pouvons utiliser pour créer ou intégrer des fonctionnalités qui n’existent pas encore. Et puis finalement, les navigateurs rattrapent et implémentent ces fonctionnalités de manière plus native. Mais cela prend du temps. Je comprends parfaitement ce que vous dites à ce sujet. Ce n’est pas la solution parfaite, mais c’est ce que nous avons actuellement.

Chris: Je pense que pour moi, la plus grande différence entre les polyfills et certaines de ces solutions est que les polyfills sont conçus pour être arrachés. Si j'ai une fonctionnalité que je veux implémenter que le navigateur ne prend pas encore en charge, mais il y a une sorte de spécification pour cela et j'écris un polyfill … une fois que les navigateurs rattrapent, je peux extraire ce polyfill et je n'ai pas à le faire changer quoi que ce soit. Mais lorsque vous utilisez certains de ces outils, les déchirer signifie réécrire toute votre base de code. C’est vraiment coûteux et problématique. Cela ne veut pas dire ne jamais les utiliser, mais je suis convaincu que nous devrions réfléchir à la sélection d’outils qui pourront être facilement retirés plus tard. Si nous n’en avons plus besoin ou si la plate-forme rattrape son retard, il n’est pas nécessaire de procéder à une énorme réécriture pour les retirer.

Chris: Pour arriver à cela, nous avons tout un tas de styles que nous n'utilisons plus, c'est pourquoi je préférerais personnellement une technologie d'outil de construction qui vérifie votre CSS par rapport au balisage rendu et extrait les choses dont vous n'avez pas besoin. Parce que sur la route, si une plate-forme rattrape le retard, vous pouvez retirer cette pièce de l'outil de construction sans avoir à tout changer. Il s'agit simplement d'augmenter ce que vous avez déjà, alors que CSS et JS ne vous offrent pas le même type d'avantages. Je ne fais que choisir celui-là, mais je pense à beaucoup de ces technologies de manière plus générale.

Chris: Je pense que des choses comme React ou Vue ouvrent probablement des chemins de vache que les navigateurs finiront par rattraper et utiliseront probablement des approches similaires sinon les mêmes, donc il y aura peut-être moins de réécriture. Une grande partie des éléments de l'écosystème qui sont branchés le sont peut-être moins.

A dessiné: Je pense qu'il est juste, n'est-ce pas, que la plate-forme Web se déplace lentement et prudemment. Vous pensez qu'il y a cinq ans, nous mettions tous des carrousels JavaScript sur nos pages. Ils étaient partout. Tout le monde implémentait des carrousels JavaScript. Si la plate-forme Web avait sauté et mis en œuvre une solution Carousel pour répondre à ce besoin, elle ne resterait pas là sans que personne ne l'utilise car les gens ne le font plus avec Carousels. Parce que ce n'était qu'une mode, une tendance du design. Pour contrer cela et empêcher la plate-forme elle-même de devenir gonflée et de devenir un problème à résoudre, elle doit évoluer à un rythme beaucoup plus régulier. Le résultat de cela est que le HTML que j'ai écrit en 1999 fonctionne encore aujourd'hui à cause de ce processus lent.

A dessiné: L’un des autres domaines où les choses semblent gonfler sur le Web est… Je suppose que cela est lié à la conversation sur le cadre. Mais c'est le concept d'une application d'une seule page. J'ai l'impression que beaucoup de promesses sont faites autour des applications d'une seule page quant à leurs performances, comme si vous bénéficiez de tous ces avantages parce que vous ne rechargez pas l'ensemble du cadre de page. J'ai l'impression qu'ils ne tiennent pas toujours ces promesses de performance. Serais-tu d'accord avec ça?

Chris: Oui. Bien que j'avoue, malgré un très long chapitre dans mon livre à ce sujet et en parlant beaucoup de cela dans les discussions et les conversations avec les gens, je ne pense pas que les applications d'une seule page soient toujours une chose terrible. Mais je pense que l'idée que vous en avez besoin pour la performance est exagérée. Vous pouvez souvent obtenir le même niveau de performance avec différentes approches.

Chris: Je pense que l’un des plus grands défis des applications à page unique est… Pour quiconque ne les connaît pas. Lorsqu'une application d'une seule page, au lieu d'avoir des fichiers HTML séparés ou si vous utilisez quelque chose comme un site basé sur une base de données comme WordPress, même si vous n'avez pas de fichiers HTML physiques réels pour chaque page de votre site WordPress, WordPress crée Les fichiers HTML à la volée et les renvoyer aux navigateurs lorsque des URL sont demandées. Pour les besoins de cette conversation, au lieu d'avoir des fichiers HTML séparés pour chaque vue de votre application, une application d'une seule page a un seul fichier HTML. C'est ce qui en fait une application d'une seule page. JavaScript gère tout. Rendu du contenu, acheminement vers différents chemins d'URL, récupération du nouveau contenu s'il le faut à partir d'une API ou quelque chose du genre.

Chris: L'un des avantages manifestes de ces derniers ou des avantages déclarés de ceux-ci est que seul le contenu de la page change. Vous n’avez pas besoin de retélécharger tout le JS et le CSS. Oh, et vous pouvez faire ces transitions de page fantaisistes que les concepteurs adorent parfois. En théorie, c'est plus performant que d'avoir à recharger toute la page.

Chris: Le problème avec cette approche de mon point de vue est qu'elle casse également un tas de choses que le navigateur vous donne simplement gratuitement, puis vous devez le recréer avec plus de JS. Vous avez une application lente, car elle contient beaucoup de JS. Donc, vous lancez encore plus de JavaScript pour améliorer ces performances et, ce faisant, vous supprimez un tas de fonctionnalités du navigateur et devez ensuite les réimplémenter avec encore plus de JS.

Chris: Par exemple, certaines choses que le navigateur fera gratuitement avec un site Web traditionnel que vous devez recréer avec JavaScript lorsque vous accédez à l'application d'une seule page. Vous devez intercepter les clics sur les liens et les empêcher de se déclencher, avec votre JavaScript. Vous devez ensuite déterminer ce que vous devez réellement afficher en fonction de cette URL, qui est normalement quelque chose qui serait géré sur le serveur ou en fonction du fichier qui accompagne ce chemin d'URL. Vous devez réellement mettre à jour l'URL dans la barre d'adresse sans déclencher de rechargement de page. Vous devez écouter les clics avant et arrière sur le navigateur et mettre à jour le contenu à nouveau, comme vous le feriez avec des clics sur des liens. Vous devez mettre à jour le titre du document.

Chris: Vous devez également déplacer l'attention de manière à annoncer le changement de page aux personnes qui utilisent des lecteurs d'écran et d'autres appareils afin de ne pas être confuses quant à l'endroit où elles se trouvent ou ce qui se passe. Parce qu'ils ne peuvent pas voir le changement qui se produit, ils l'entendent annoncé. Si vous ne changez d’attention nulle part, cette annonce n’a pas lieu. Ce sont toutes les choses que le navigateur ferait pour vous et qui ne fonctionnent pas avec les applications à page unique.

Chris: En plus de cela, parce que vous avez tout ce JavaScript supplémentaire, c'est compliqué. La plupart des gens utilisent donc des frameworks et des bibliothèques pour gérer ce genre de choses. En raison de tout ce JavaScript supplémentaire pour prendre en charge cette approche, vous vous retrouvez avec un chargement de page initial potentiellement plus lent que vous ne l'auriez autrement. Selon le contenu que vous avez, cette approche, je pense, peut parfois avoir du sens. Si vous possédez une application basée sur des données d'API, vous ne savez pas nécessairement à quoi ressembleront ces chemins d'URL à l'avance.

Chris: Juste un exemple ici. Vous avez un sauvetage d'animaux où vous avez des animaux adoptables, et ces données proviennent de Petfinder, le site Web d'adoption d'animaux. Vous avez un groupe d'animaux là-bas. Petfinder gère cela, mais vous souhaitez les afficher sur votre site avec l'API Petfinder. Lorsque votre site Web est en cours de création, il n'a pas toujours nécessairement une visibilité sur les animaux de compagnie disponibles à ce moment précis et le type de chemins d'URL dont vous aurez besoin. Une application d'une seule page peut vous y aider car elle peut dynamiquement à la volée, créer ces belles URL qui correspondent à chaque chien ou chat.

Chris: Quelque chose comme Instagram avec beaucoup de contenu créé par les utilisateurs, peut-être que cela a également du sens. Mais pour beaucoup de choses, nous savons où ces URL seront à l'avance. La création d'un fichier HTML contenant déjà le contenu sera tout aussi rapide que… parfois même plus rapide que l'approche d'application à page unique basée sur JavaScript, surtout si vous utilisez d'autres techniques pour réduire la taille globale de votre CSS et JavaScript. J'utilise cette approche sur un portail de cours que j'ai. Le chargement de la page est instantané car le rendu HTML est si facile pour les navigateurs par rapport aux autres parties de la pile. Cela ressemble à une application d'une seule page, mais ce n'est pas le cas.

A dessiné: Surtout lorsque vous envisagez des solutions d'hébergement comme une approche Jamstack consistant à placer des fichiers HTML dans un CDN afin qu'ils soient servis à un endroit physiquement proche de l'utilisateur.

Chris: Oui.

A dessiné: Le chargement de ces pages peut être tellement rapide.

Chris: Oui. Absolument. Absolument. Un des autres arguments que je pense que les gens avaient l'habitude de faire en faveur des applications d'une seule page est l'accès hors ligne. Si quelqu'un le charge et que son réseau tombe en panne, l'application est déjà active et toutes les routes sont gérées uniquement avec le fichier déjà présent. Il n'y a donc pas de rechargement, ils ne perdent aucun travail. Cela a été vrai pendant longtemps. Maintenant, avec les travailleurs de service et les applications Web progressives, c'est à mon avis moins un argument convaincant, d'autant plus que les travailleurs de service peuvent récupérer des fichiers HTML complets et les mettre en cache à l'avance si nécessaire.

Chris: Vous pouvez littéralement avoir toute votre application disponible hors connexion avant que quelqu'un n'ait même visité ces pages si vous le souhaitez. Cela se produit simplement en arrière-plan sans que l'utilisateur n'ait à faire quoi que ce soit. C'est encore une de ces technologies qui avait peut-être du sens pour certains cas d'utilisation il y a quelques années un peu moins convaincante maintenant.

A dessiné: Cela me rappelle un peu l'époque où nous construisions des sites Web en Flash.

Chris: Oui.

A dessiné: Et vous auriez juste un rectangle incorporé dans une page HTML qui est votre Flash Player, et vous construiriez votre site entier dans cela. Il fallait absolument tout réinstaller. Il n'y avait pas de bouton de retour. Si vous vouliez un bouton de retour, vous deviez créer un bouton de retour, puis vous deviez créer ce qu'était le concept d'une page. Vous étiez en train d'écrire du code sur du code, sur du code à réimplémenter tout comme vous dites des choses que le navigateur fait déjà pour vous. Est-ce que tout ce JavaScript que nous mettons dans nos pages pour créer cette fonctionnalité… est-ce que cela va provoquer une fragilité dans nos frontaux?

Chris: Oui. C'est presque certainement dans mon esprit l'un des plus gros problèmes liés à notre dépendance excessive à JavaScript. JavaScript est, de par sa nature, un langage de script, la partie la plus fragile de la pile frontale.

Chris: Par exemple, si j'écris un élément HTML qui n'existe pas, j'épelle article comme arcitle au lieu d'article et le navigateur passe dessus, ça va être comme, "Oh, je ne sais pas ce que c'est. Quoi qu'il en soit, je vais simplement le traiter comme un div. " Et ça continue. Si je saisis mal une propriété CSS… Disons que j’oublie le B en gras, donc j’écris plutôt vieux, police bien vieille. Le navigateur va être, "Je ne sais pas ce que c'est. Quoi qu'il en soit, nous allons continuer. " Votre truc ne sera pas audacieux, mais il sera toujours là.

Chris: Avec JavaScript, si vous saisissez mal un nom de variable ou que vous essayez d'utiliser une propriété, vous essayez d'appeler une variable qui n'existe pas ou une myriade d'autres choses se produisent … votre minificateur se trompe et tire une ligne de code vers la précédente sans point-virgule là où il en a besoin, toute l'application se bloque. Tout à partir de cette ligne cesse de fonctionner. Parfois, même les choses qui se produisent avant cela ne se terminent pas, selon la configuration de votre application. Vous pouvez très rapidement vous retrouver avec une application qui, dans une approche différente, où vous comptez beaucoup plus sur HTML et CSS, fonctionnerait. Cela peut ne pas sembler tout à fait correct, mais cela fonctionnerait quand même… pour celui qui ne fonctionne pas du tout.

Chris: Il y a un argument à faire valoir qu'en 2020, JavaScript est une partie intégrante et importante du Web et que la plupart des gens ne le désactivent pas et que la plupart des gens utilisent des appareils qui peuvent réellement gérer le JavaScript moderne. C’est vrai, mais ce n’est pas la seule raison pour laquelle JavaScript ne fonctionne pas correctement, même si vous avez un linter par exemple et que vous détectez les bogues à l’avance et tout. Il existe de nombreuses raisons pour lesquelles JavaScript peut mal tourner sur vous. Les CDN échouent.

Chris: En juillet dernier, il y a un an ce mois-ci… du moins, lorsque nous enregistrons cela… un mauvais déploiement a détruit Cloudflare. Fait intéressant, alors que nous enregistrons cela, je pense qu'il y a une semaine ou deux, Cloudflare a eu une autre panne massive qui a cassé tout un tas de choses, ce qui n'est pas un coup sur Cloudflare. Il s’agit d’un service extrêmement important qui alimente une multitude de sites Web. Mais les CDN diminuent parfois. Ils sont un fournisseur utilisé par 10% des entreprises Fortune 1,000. Si votre JS est servi par ce CDN et qu'il se brise, le fichier JavaScript ne se charge jamais. Et si votre contenu dépend de ce JS, vos utilisateurs n'obtiennent rien au lieu d'obtenir quelque chose qui ne soit tout simplement pas stylé comme vous le souhaitez.

Chris: Les pare-feu et les bloqueurs de publicités deviennent trop agressifs avec ce qu'ils bloquent. J'avais l'habitude de travailler dans une entreprise qui avait une liste blanche JavaScript parce qu'elle était extrêmement soucieuse de la sécurité, elle travaillait avec des contrats gouvernementaux. Ils avaient une liste de JavaScript autorisés, et si votre site ou si votre URL ne faisait pas partie de cela, pas de JavaScript. Vous avez ces sites. Je me souviens être allé sur un site où il y avait l'un des menus de style hamburger sur chaque vue, que ce soit pour ordinateur de bureau ou mobile, et je ne pouvais accéder à aucune page autre que la page d'accueil car pas de JavaScript, pas de hamburger, c'était tout.

Chris: Parfois, les connexions expirent simplement pour des raisons. Soit le fichier prend un certain temps, soit la connexion de quelqu'un est irrégulière ou lente. Ian Feather, ingénieur chez BuzzFeed, a partagé qu'environ 1% des demandes de JavaScript sur le site échouent, soit 13 millions de demandes par mois. Ou c'était l'année dernière, c'est probablement encore plus maintenant. C'est beaucoup de JavaScript qui a échoué. Les gens qui font la navette passent par des tunnels et perdent Internet. Il y a toutes sortes de raisons pour lesquelles JavaScript peut échouer et quand il le fait, c'est tellement catastrophique.

Chris: Et nous avons donc construit ce Web qui devrait être plus rapide que jamais. Nous sommes en 2020, la 5G commence à devenir une chose. Je pensais que la 4G était incroyable. La 4G est à peu près aussi rapide que mon réseau wifi domestique. La 5G est encore plus rapide, ce qui est juste dingue. Pourtant, d'une manière ou d'une autre, nous avons des sites Web plus lents et moins performants qu'il y a 5 ou 10 ans, et cela n'a aucun sens pour moi. Il n’est pas nécessaire qu’il en soit ainsi.

A dessiné: Comment sortir de ce bordel, Chris?

Chris: Excellente question. Je veux être vraiment clair. Je sais que j’ai insisté là-dessus plusieurs fois. Je ne dis pas que toutes les nouveautés sont mauvaises, ne les utilisez jamais. Mais ce que je veux encourager, c'est un peu plus de réflexion sur la façon dont nous construisons pour le Web.

Chris: Je pense que le thème sous-jacent ici est que vieux ne veut pas dire obsolète. Cela ne signifie pas ne jamais adopter de nouvelles choses, mais ne soyez pas si rapide à sauter sur toutes les nouvelles choses brillantes simplement parce qu'elles sont là. Je sais que c’est l’une des choses qui rend cette industrie vraiment excitante et la rend agréable à travailler, il y a toujours quelque chose de nouveau à apprendre. Mais lorsque vous choisissez ces nouvelles choses, faites-le parce que c'est le bon outil pour le travail et pas seulement parce que c'est la nouvelle chose brillante.

Chris: L’une des autres choses dans lesquelles nous n’avons pas abordé autant que je l’aurais souhaité, mais je pense que c’est vraiment important, c’est que la plate-forme a pris un très grand retard ces dernières années. Accepter cela autant que possible se traduira par une expérience Web pour les gens plus rapide, moins fragile, plus facile à créer et à maintenir pour vous car cela nécessite moins de dépendances, comme l'utilisation de ce que le navigateur vous offre. -la boîte. Nous avions besoin de jQuery pour sélectionner des éléments tels que des classes. Les navigateurs ont désormais des moyens natifs de le faire. Les gens aiment JSX car il vous permet d'écrire du HTML en JavaScript de manière plus transparente. Mais nous avons également des modèles littéraux dans Vanilla JavaScript qui vous offrent le même niveau de facilité sans dépendance supplémentaire. Le HTML lui-même peut maintenant remplacer beaucoup de choses qui nécessitaient auparavant du JavaScript, ce qui est absolument incroyable.

Chris: Nous avons parlé un peu de… c'est une chose CSS, mais survole les liens et comment cela nécessitait JavaScript. Mais en utilisant des éléments tels que les détails et les éléments de résumé, vous pouvez créer une divulgation, comme développer et réduire ou des éléments d'accordéon de manière native, sans script nécessaire. Vous pouvez faire des entrées de saisie semi-automatique en utilisant juste un… Je ne devrais pas dire simplement, je déteste ce mot. Mais en utilisant un élément d'entrée modeste, puis un élément de liste de données qui lui est associé, avec quelques options. Si vous êtes curieux de savoir comment ces choses fonctionnent sur vanillajstoolkit.com, j'ai un tas de trucs JavaScript que la plate-forme vous offre. Mais j'en ai aussi utilisé pour exiger JavaScript et maintenant je ne fais plus de choses qui pourraient être intéressantes si vous voulez que des exemples de code accompagnent cela.

Chris: Du côté CSS des choses, mon plugin Vanilla JS le plus populaire est cette bibliothèque qui vous permet d'animer le défilement vers le bas pour ancrer les liens. C'est très grand. C’est le morceau de code le plus difficile que j’ai jamais eu à écrire. Et il est maintenant complètement remplacé par une seule ligne de CSS, comportement de défilement lisse. C'est plus performant. C’est plus facile d’écrire. Il est plus facile de modifier son comportement. C’est simplement une meilleure solution globale.

Chris: L'une des autres choses que j'aurais souhaité que nous fassions davantage est de s'appuyer sur des applications multi-pages. Je me sens un peu justifié ici, car j'ai récemment vu un article de quelqu'un chez Google qui plaide également pour cette approche maintenant. J'ai trouvé que c'était assez intéressant, étant donné cet énorme cadre angulaire puis… toutes les choses, boum, que Google a commencé il y a quelques années. C'est plutôt cool de les voir revenir là-dessus. En utilisant des éléments tels que des générateurs de sites statiques et des services impressionnants tels que Netlify et la mise en cache CDN, vous pouvez créer des expériences Web incroyablement rapides pour les personnes utilisant des fichiers HTML individuels pour toutes vos différentes vues. Donc, en quelque sorte, s'appuyer sur certains de ces trucs prêts à l'emploi.

Chris: Dans les situations où cela n'est pas réaliste pour vous, où vous avez besoin de plus de JavaScript, vous avez besoin d'une sorte de bibliothèque, peut-être en regardant d'abord les approches plus petites et plus modulaires au lieu de vous contenter des mastodontes de l'industrie. Au lieu de React, Preact fonctionnerait-il? Au lieu d'angulaire… je veux dire, au lieu de Vue plutôt, Alpine JS fonctionnerait-il? Il y a aussi ce précompilateur vraiment intéressant maintenant appelé Svelt, qui vous donne une expérience semblable à un framework, puis compile tout votre code en JavaScript Vanilla. Vous obtenez donc ces très petits ensembles qui contiennent exactement ce dont vous avez besoin et rien d'autre. Au lieu de CSS et de JavaScript, pourriez-vous ajouter un linter CSS tiers qui comparera votre HTML à votre CSS et en extraira les éléments qui y sont restés par accident? Une manière différente de créer votre CSS, comme le CSS orienté objet de Nicole Sullivan, fonctionnerait-elle à la place? Nous n'avons pas vraiment pu en parler, mais c'est une chose vraiment cool que les gens devraient vérifier.

Chris: Et puis je pense que la troisième et la plus importante pièce ici, même si c'est moins une approche spécifique et plus juste une chose que je souhaite que plus de gens gardent à l'esprit, est que le Web est pour tout le monde. De nombreux outils que nous utilisons aujourd'hui fonctionnent pour des personnes disposant de bonnes connexions Internet et d'appareils puissants. Mais ils ne fonctionnent pas pour les personnes qui utilisent des appareils plus anciens, ont des connexions Internet irrégulières. Ce ne sont pas seulement les gens des régions en développement. Ce sont également des gens au Royaume-Uni, dans certaines régions des États-Unis où nous avons des connexions Internet absolument épouvantables. Le centre de notre pays a un Internet très lent. Je sais qu'il y a des endroits dans une partie de Londres où ils ne peuvent pas câbler un nouveau haut débit pour des raisons historiques. Il vous reste donc ces anciennes connexions Internet qui sont vraiment mauvaises. Il y a des endroits comme ça partout dans le monde. La dernière fois que j'étais en Italie, même chose. L'Internet était horrible. Je ne sais pas si cela a changé depuis.

Chris: Les choses que nous construisons aujourd'hui ne fonctionnent pas toujours pour tout le monde, et c'est dommage. Parce que la vision du Web, ce que j'aime, c'est que c'est une plateforme pour absolument tout le monde.

A dessiné: Si les auditeurs veulent en savoir plus sur cette approche, vous en avez beaucoup parlé dans votre livre, The Lean Web. Et c'est disponible en ligne. Est-ce un livre physique ou un livre numérique?

Chris: C’est un peu des deux. Et bien non. Ce n’est certainement pas un livre physique. Vous allez sur leanweb.dev. Vous pouvez lire le tout gratuitement en ligne. Vous pouvez aussi si vous le souhaitez, il existe des versions EPUB et PDF disponibles pour un très petit montant, j'oublie combien maintenant. Je ne l'ai pas regardé depuis un moment. Le tout est gratuit en ligne si vous le souhaitez. Vous pouvez également regarder une conférence sur ce sujet où j'entrerai plus en détail si vous le souhaitez.

Chris: Mais j’ai également créé une page spéciale uniquement pour les auditeurs de Smashing Podcast sur gomakethings.com/smashingpodcast, car je suis très créatif avec les noms. Cela inclut un tas de ressources en plus du livre, autour de choses dont nous avons parlé aujourd'hui. Il renvoie à de nombreuses techniques que nous avons couvertes, à d’autres articles que j’ai écrits qui approfondissent certains de ces sujets et élargissent un peu ma réflexion. Si les gens veulent en savoir plus, ce serait probablement le meilleur point de départ.

A dessiné: C’est formidable. Je vous remercie. J'ai tout appris sur le Lean Web. Qu'est-ce que tu as appris dernièrement, Chris?

Chris: Ouais, deux ou trois choses. J'y ai fait allusion un peu plus tôt en regardant la vidéo de Jeremy sur des applications Web progressives. J'attends depuis quelques années comment écrire ma propre application Web progressive parce que je n'avais pas de besoin spécifique sur tout ce avec quoi je travaillais. J'ai récemment appris d'un de mes étudiants qui est en Afrique du Sud, qu'ils ont été confrontés à des pannes de courant continuelles à cause de certaines choses qui se passent là-bas. En conséquence, elle n'est pas en mesure de travailler sur certains des projets que nous menons ensemble régulièrement, car le courant est coupé et elle ne peut pas accéder au portail d'apprentissage et suivre.

Chris: Pour moi, construire maintenant une expérience où cela fonctionne même si quelqu'un n'a pas Internet est devenu une priorité plus élevée que… J'ai réalisé que c'était peut-être avant, alors j'ai juste commencé à creuser cela et j'espère le mettre en place dans la prochaine quelques semaines. Nous verrons. Les ressources de Jeremy Keith à ce sujet ont cependant été une bouée de sauvetage absolue. Je suis content qu’ils existent.

Chris: Je sais, Drew, vous avez mentionné que l'une des raisons pour lesquelles vous aimez poser cette question est de montrer que les gens, peu importe leur niveau d'expérience, apprennent toujours. Juste une petite anecdote liée. Je suis développeur web depuis je pense, environ huit ans maintenant. Je dois encore chercher sur Google la propriété CSS à utiliser pour rendre les choses en italique, littéralement à chaque fois que je l'utilise. Pour une raison quelconque, mon cerveau utilise par défaut la décoration de texte même si ce n'est pas la bonne. J’essaierai plusieurs combinaisons de choses différentes, et j’ai toujours un mot erroné à chaque fois. J'écris aussi parfois des italiques au lieu de l'italique. Ouais. Si quelqu'un a déjà l'impression que, oh, je n'apprendrai jamais ce genre de choses… sachez simplement que, peu importe votre niveau d'expérience, il y a toujours quelque chose de vraiment basique que vous recherchez encore et encore.

A dessiné: Je suis développeur Web depuis 22, 23 ans et je dois toujours consulter sur Google les différentes propriétés de Flexbox, à chaque fois. Bien que j'utilise ça depuis 23 ans. Mais oui, certaines choses juste… il y en aura probablement plus en vieillissant.

Chris: Ouais. Honnêtement, j'ai fini par créer tout un site Web de choses que je Google encore et encore, juste pour avoir une référence copier-coller plus facile parce que c'était plus facile que Google.

A dessiné: Ce n’est pas une mauvaise idée.

Chris: C’est le genre de paresseux que je suis. Je vais créer un site Web complet pour me sauver comme trois secondes de googler.

A dessiné: Si vous, l'auditeur, souhaitez en savoir plus sur Chris, vous pouvez trouver son livre sur le Web à leanweb.dev, et sa newsletter Developer Tips et plus encore sur gomakethings.com. Chris est sur Twitter chez Chris Ferdinandi. Et vous pouvez consulter son podcast sur vanillajspodcast.com ou partout où vous obtenez habituellement vos podcasts. Merci de vous joindre à nous aujourd'hui, Chris. Avez-vous des mots d'adieu?

Chris: Merci beaucoup de m'avoir invité, Drew. J'ai passé un moment absolument formidable. C'était très amusant. J'apprécie vraiment l'opportunité de venir discuter.

Éditorial fracassant(il)

Laisser un commentaire

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