Smashing Podcast Épisode 21 Avec Chris Ferdinandi : Les meilleures pratiques modernes sont-elles mauvaises pour le Web ?
Publié: 2022-03-10Aujourd'hui, nous nous demandons si les meilleures pratiques modernes sont mauvaises pour le Web ? Les frameworks modernes nous conduisent-ils sur la mauvaise voie ? Je parle à l'expert du Lean Web Chris Ferdinandi pour le savoir.
Afficher les remarques
- La page de Chris avec des liens et des notes pour le podcast
- Le livre Lean Web
- Chris Ferdinandi sur le web
- Chris sur Twitter
- Le podcast Vanilla JavaScript
Mise à jour hebdomadaire
- "Traduire les wireframes de conception en HTML/CSS accessibles"
par Harris Schneiderman - "Création d'applications de bureau avec Electron et Vue"
par Timi Omoyeni - "Techniques CSS modernes pour améliorer la lisibilité"
par Edoardo Cavazza - "Comment utiliser les composants stylés dans React"
par Adebiyi Adedotun Lukman - "Comment créer une Porsche 911 avec Sketch"
par Nikola Lazarević
Transcription
Drew McLellan : Il est l'auteur de la série de guides de poche Vanilla JS, créateur du programme de formation Vanilla JS Academy et hôte du podcast Vanilla JS. Il a développé une newsletter Tips, elle est lue 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 The Boston Globe. Et ses plugins JavaScript ont été utilisés par des organisations comme Apple et la Harvard Business School. Par-dessus tout, il aime aider les gens à apprendre le JavaScript Vanilla. Nous savons donc qu'il préférerait choisir Vanilla JavaScript plutôt qu'un cadre, mais saviez-vous qu'il a déjà été désigné dans une file d'attente de la police comme étant la personne la moins susceptible d'avoir commis le crime ? Mes amis Smashing, veuillez accueillir Chris Ferdinandi. Salut Chris. Comment vas-tu?
Chris Ferdinandi : Oh, je suis fracassant. Merci de m'avoir.
Drew : Je voulais vous parler aujourd'hui de ce concept de Lean Web, qui vous passionne, n'est-ce pas ?
Chris : Oui, tout à fait.
Drew : Pourquoi ne nous préparez-vous pas le terrain ? Lorsque nous parlons de Lean Web, quel est le problème que nous essayons de résoudre ?
Chris : Oui, excellente question. Tout comme une mise en garde pour tous les auditeurs, cet épisode pourrait faire crier un petit vieil homme au nuage. Je vais essayer d'éviter ça. Quand je regarde la façon dont nous construisons pour le Web aujourd'hui, cela ressemble un peu à un gâchis gonflé et sur-conçu. 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.
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 du développeur… je suis désolé, pas sur l'expérience du développeur. L'expérience utilisateur plutôt, par rapport à l'expérience du développeur, et la facilité de construire des choses du point de vue de l'équipe, ce sur quoi je pense que nous mettons beaucoup d'accent aujourd'hui et que nous aborderons probablement dans notre conversation.
Chris : J'ai en fait découvert que beaucoup de ces choses que nous considérons comme améliorant 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 ça aussi, que nous pouvons creuser. 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 : À mesure que le Web mûrit en tant que plate-forme de développement, il semble y avoir une tendance croissante à la spécialisation.
Cris : Oui.
Drew : Les gens qui couvraient Full Stack, puis nous nous sommes séparés en front-end et 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 devient plus spécialisé. Quelqu'un peut se considérer et se vendre comme un développeur React ou un développeur Angular, et toute son identité et sa vision sont basées sur un framework particulier dans lequel il est hautement qualifié. Cette dépendance aux frameworks est-elle 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 de manière générale, j'ai toujours l'impression que oui, notre obsession en tant qu'industrie avec des frameworks et des outils en général, est potentiellement un peu à notre détriment. Je ne pense pas que les frameworks 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 à beaucoup 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 aux frameworks. Tout le reste qui vient après cela est à bien des égards, car nous lançons tellement et pas seulement des frameworks, c'est-à-dire 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 comme ça que je gagne mon argent. Et je dis ici que je pense que nous utilisons trop de JavaScript, ce qui est parfois un peu bizarre.
Drew : À l'époque où les grands frameworks n'ont pas vu le jour, nous avions l'habitude de créer des interfaces utilisateur et des choses avec jQuery ou autre. Et puis les frameworks sont arrivés et ils nous ont donné plus de ce concept d'interface utilisateur basée sur l'état.
Cris : Oui.
Drew : Maintenant, c'est une 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 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 une interface utilisateur basée sur l'état. Ce n'est pas forcément la bonne approche. Il y a probablement d'autres choses que vous pouvez faire à la place. Pensez aux générateurs de sites statiques, à certains balisages pré-rendus, voire à un site piloté par 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, 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 arriver.
Chris : Je regarde quelque chose comme React ou Vue, qui sont des pièces d'ingénierie absolument incroyables. Je ne veux rien enlever aux gens qui y travaillent. J'ai fini comme un exercice d'apprentissage, en construisant mon propre mini-framework 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 minification et gzipping. Donc, une fois que vous les avez déballés, ils sont beaucoup plus gros que cela.
Chris : Pas tout, mais une bonne partie de ce poids est consacrée à ce qu'on appelle 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. Toujours sensiblement plus petit. La grande différence entre ceux-ci et leurs homologues grands frères, c'est qu'ils se sont débarrassés du DOM virtuel. Ils peuvent laisser tomber une méthode ou deux. Mais généralement, c'est la même approche et le même type d'API dans la façon de travailler avec le code, et ils sont considérablement plus petits.
Chris : Je pense que beaucoup des 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 très bien. Je pense que l'une des grandes choses dont j'essaie de parler aujourd'hui est de ne pas… 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 c'est être 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 toutes les autres choses, mais nous les avons quand même.
Chris : Ce qui est très long pour… Je suis désolé de répondre à votre question. C'est parfois plus de code que vous ne pourriez ou ne voudriez écrire vous-même, mais ce n'est pas autant de code que je pense que nous pensons que cela nécessite. Quand je dis que vous n'avez pas besoin d'un framework, je reçois beaucoup de réactions autour de cette idée : "Eh bien, si vous n'utilisez pas de framework, 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 il s'agit peut-être de choisir quelque chose d'un peu plus petit. Il y a parfois des raisons pour lesquelles écrire votre propre framework peut être la bonne décision, selon ce que vous essayez de faire. Tout est très fluide et subjectif.
Drew : Il est assez intéressant de constater qu'en tant qu'exercice d'apprentissage, vous avez implémenté votre propre cadre basé sur l'état. Je me souviens que dans le passé, je pensais qu'à 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, bien sûr.
Drew : Mais atteindre la bibliothèque m'a évité d'avoir à le faire. Je savais que si je devais écrire ce code moi-même, je savais quelle approche j'adopterais 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 React, je n'ai presque aucune idée de ce qui se passe maintenant dans cette bibliothèque, dans tout ce code.
Drew : Pour ceux d'entre nous qui ne sont pas familiers, quand vous dites quelque chose comme Preact supprime le DOM virtuel et rend tout beaucoup plus petit, qu'est-ce que ce DOM virtuel nous donne ?
Chris : Pour répondre à cette question, je veux prendre un peu de recul. L'une des plus belles choses que les frameworks et autres bibliothèques basées sur l'état vous offrent est la différence DOM. Si vous ne mettez pas vraiment beaucoup à jour l'interface utilisateur, vous pouvez vous contenter de dire : « Voici une chaîne de ce à quoi le balisage est censé ressembler. En HTML, je vais juste 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 repaint.
Chris : Mais je pense que ce qui est potentiellement plus important que cela, l'un des problèmes avec cela est que vous avez n'importe quel type d'élément interactif là-dedans, un champ de formulaire, un lien sur lequel quelqu'un s'est concentré. Cette concentration est perdue parce que l'élément… même si vous avez une nouvelle chose qui ressemble, ce n'est pas le même élément littéral. Donc, si la concentration 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 : Toute chose d'interface utilisateur basée sur l'état valant son poids va en implémenter pour différencier DOM, où ils disent : « Voici à quoi devrait ressembler l'interface utilisateur. Voici à quoi cela ressemble en ce moment dans le DOM. Qu'est ce qui est different?" Et cela va changer ces choses. Il fait effectivement ce que vous feriez en mettant à 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 ça ressemble." Et puis la bibliothèque ou le framework le comprend.
Chris : Les petites choses comme Preact ou Alpine, elles le font 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 à son élément correspondant dans le DOM littéral. Au fur et à mesure que vous vous retrouvez avec des interfaces utilisateur qui deviennent de plus en plus grandes, cela peut avoir une implication 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, faites un clic droit et inspectez l'élément sur le bouton "Favori" sur Twitter, ou 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 seul tweet.
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 qu'au lieu de vérifier le DOM réel à 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 celle existante, et il compare ces deux. C'est beaucoup plus performant en théorie que de le faire dans le vrai DOM. Une fois qu'il obtient une liste des choses qu'il doit changer, il s'exécute simplement et apporte ces modifications. Mais il n'a qu'à attaquer le DOM une seule fois. Il ne s'agit pas de vérifier chaque élément, à chaque fois. Si vous avez des interfaces comme Twitters ou Facebooks 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 à eux seuls 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 polyvalent, ou si vous avez des gens dans des pays en développement, c'est vraiment… le temps de démarrage est plus lent. Et en plus de cela, le temps d'interaction réel est plus lent à cause de l'abstraction supplémentaire.
Chris : Il n'y a pas que vous qui chargez et ils sont comparables en termes de vitesse. 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 qu'il contient. Si vous avez une interface utilisateur vraiment très complexe avec beaucoup d'é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 je vois la plupart des développeurs utiliser 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é de React, utilisez Preact. C'est une fraction de la taille, ça 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 être meilleurs pour choisir le bon outil pour le travail. Si vous optez pour une approche comme celle-là, si vous arrivez à un point où un DOM virtuel a réellement du sens, il est beaucoup plus facile de porter Preact dans React que si vous rouliez le vôtre. C'est la situation. Si cela vous inquiète vraiment, vous bénéficiez également d'une protection pour l'avenir.
Drew: 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 sûrement de les associer à un gestionnaire de packages dans un bundler pour vous assurer que vous ' n'envoyez que le code que vous voulez. Sûrement, vous êtes déjà en avance rien qu'en faisant cela ?
Cris : Ouais. Je ne suis pas d'accord. Je n'ai pas vraiment grand-chose d'autre à développer là-dessus 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 posiez la question à ce sujet. Parce que l'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 l'impact sur les performances que nous tirons de l'utilisation de tout ce JavaScript est que nous lançons encore plus de JavaScript à l'avant pour en tenir compte. L'une des façons dont nous le faisons est les gestionnaires de packages et les bundlers de modules.
Chris : Comme vous y 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 gros fichier. Les plus récents et les plus… Je ne veux pas les qualifier de réfléchis. Mais les plus récents utiliseront une fonctionnalité appelée tree shaking, où ils se débarrasseront 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 mauvaise idée, mais il en résulte ce que j'appelle généralement la santé des dépendances où vous avez ce château de cartes très délicat de dépendances en plus des dépendances en plus des dépendances.
Chris : La mise en place 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 't avoir la possibilité d'aller 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 en essayant 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 réalisation déprimante que ce que vous avez parcouru dans 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, c'est qu'ils commencent à devenir des gardiens. Je ne sais pas à quel point tu veux vraiment plonger là-dedans ou pas, Drew. Mais l'un de mes gros reproches contre JS, toutes les choses dans un flux de travail. Surtout quand 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.
Drew: Eh bien, je le suis certainement… J'ai commencé à apprendre React au début de 2020, 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 de l'outillage pour démarrer un projet.
Drew: Il semble qu'il y ait énormément de travail pour obtenir quelque chose dans Hello World, et il y a encore plus que vous devez savoir pour qu'il soit prêt pour 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 à être un développeur Web. Quelqu'un qui vient d'y entrer va avoir un vrai problème. Ça va être une vraie barrière à l'entrée, n'est-ce pas ?
Cris : 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 pouvoir réellement participer 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 quelques années maintenant. Mais ils ont de plus en plus déplacé leur pile back-end vers JavaScript, loin de PHP, ce qui n'est pas une mauvaise chose en soi. Leur nouvel éditeur, Gutenburg, est construit sur React.
Chris : En 2018, le consultant principal en accessibilité de WordPress, Rian Rietveld, dont j'ai presque certainement massacré le nom… elle a très publiquement démissionné de son poste et documenté 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é est une partie très importante de cela. 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 était de s'assurer… 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, il était vraiment difficile pour elle et son équipe de faire leur travail.
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 à identifier les bogues, puis à classer les tickets. Ils ont été ajoutés à un backlog avec toutes les autres demandes de développement de fonctionnalités sur lesquelles travaillaient les développeurs JavaScript. Beaucoup de choses qui auraient pu être facilement corrigées n'ont pas été intégrées à la première version.
Chris : En mai 2019, environ un an après la démission de Rian, un audit détaillé de l'accessibilité a été effectué sur Gutenburg. Le rapport complet comptait 329 pages. Le résumé analytique à lui seul faisait 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 à portée de main, mais beaucoup d'entre eux étaient des choses de base que l'équipe de Rian aurait pu corriger et cela aurait libéré les développeurs pour se concentrer sur le développement de fonctionnalités. C'est finalement ce qu'il semble qu'ils ont fini par faire, passer beaucoup de temps sur le développement de fonctionnalités et repousser ce truc jusqu'à plus tard. Mais cette équipe est super importante pour le projet, et ils se sont soudainement retrouvés exclus du processus à cause d'un choix technique.
Chris : Alex Russell est développeur dans 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 d'aller plus vite 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 également. 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 personnes qui sont des développeurs CSS vraiment avancés… et je le dis 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 une chose très spécialisée. D'après mon expérience, les personnes qui y sont exceptionnellement douées ne sont pas toujours aussi douées pour JavaScript, car vous finissez par plonger très 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.
Drew : J'ai récemment trouvé dans un projet des moyens de résoudre certains des problèmes de 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 qu'il serait préférable pour nous d'utiliser pour résoudre les problèmes que nous avions. Ce qui est devenu très vite évident, c'est qu'il n'y a pas qu'une seule solution pour ce faire. Il existe des dizaines de façons différentes de le faire.
Drew : 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 dans cet apprentissage s'il n'est pas particulièrement à l'aise avec JavaScript.
Cris : Ouais. L'autre chose intéressante que je pense que vous venez de faire ressortir un peu, c'est que lorsque j'en parle, l'une des plus grosses réactions que je reçois est que les frameworks appliquent les conventions. Vous allez avec Vanilla JavaScript, vous avez ce champ vert-ciel bleu, vous pouvez faire tout ce que vous voulez comme projet. Avec React, il existe une façon React de faire les choses.
Chris : Mais l'une des choses que j'ai trouvées est qu'il existe des approches Reacty, mais il n'y a pas de bonne façon stricte de faire les choses avec React. C'est l'une des choses que les gens aiment à ce sujet. 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 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 semblable à JSX si vous préférez.
Chris : J'ai entendu plusieurs personnes se plaindre de l'apprentissage de React. L'un des gros problèmes est que vous recherchez sur Google comment faire X dans React et que vous obtenez une douzaine d'articles vous expliquant une douzaine de façons différentes de faire cette chose. Cela ne veut pas dire qu'ils ne mettent pas de garde-fous sur un projet. Je ne pense pas que ce soit aussi clair que « J'ai choisi un cadre. Maintenant, c'est comme ça que je construis avec ça. Pour être honnête, je ne sais pas si c'est nécessairement quelque chose que je voudrais non plus. Je ne pense pas que vous voudriez que ces personnes soient étroitement confinées… certaines personnes le souhaitent, 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 aux composants JavaScript d'une manière ou d'une autre peut vous apporter si ce composant tombe, le CSS aussi en théorie, disparaît avec lui. Pour moi, cela revient en grande partie à jeter l'ingénierie sur les problèmes des gens. Invariablement, vous dépendez toujours de personnes quelque part le long de la ligne. Cela ne veut pas dire qu'il ne faut 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 peluchage des styles inutilisés. Il existe des approches de création de CSS qui vous donnent une sortie de type CSS dans JS et gardent votre feuille de style petite sans cracher ces noms de classe illisibles pour l'homme charabia que vous obtenez parfois avec CSS et JS. Comme X2354ABC, ou juste ces mots absurdes qui se font cracher.
Chris: C'est là que je commence à vraiment entrer dans le genre de chose que le vieil homme crie au 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 bon pour Facebook, c'est assez bon pour nous. Eh bien, Facebook utilise cet outil. Si nous sommes un vrai programme d'ingénierie… équipe, département, organisation, nous 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 ne traitez pas, et vice-versa. La taille et l'échelle de ce sur quoi ils travaillent sont simplement différentes, et ce n'est pas grave.
Drew : Exactement. Je vois certaines de ces choses comme CSS et JavaScript comme étant presque comme 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 résolve ce problème, ce que nous faisons en ce moment avec JavaScript nous permettra de nous en sortir et tout ira bien. Nous savons que c'est mauvais. Nous savons que ce n'est pas une bonne solution, mais cela nous aide en ce moment. Et j'espère qu'entre-temps nous pourrons le retirer et utiliser la solution native.
Chris : C'est vraiment drôle que tu en parles. 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 pouviez faire des choses sympas comme changer la couleur d'un lien au 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 choses comme l'attribut ou la propriété focus n'existaient tout simplement pas à l'époque.
Chris : L'une des choses qu'il a dites dans la conférence et qui, je pense, m'ont vraiment touché, c'est que JavaScript, à bien des égards, ouvre ces chemins de vache. 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 tout à fait ce que vous dites à ce sujet. Ce n'est pas la solution parfaite, mais c'est ce que nous avons en ce moment.
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 déchirer ce polyfill et je n'ai pas à changer quoi que ce soit. Mais lorsque vous utilisez certains de ces outils, les extraire signifie réécrire toute votre base de code. C'est vraiment cher et problématique. Cela ne veut pas dire ne jamais les utiliser, mais je pense vraiment que nous devrions réfléchir à des outils de cueillette qui peuvent facilement être retirés plus tard. Si nous n'en avons plus besoin ou si la plate-forme rattrape son retard, cela ne nécessite pas une énorme réécriture pour les retirer.
Chris : Pour en arriver là, 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 audite 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 son retard, vous pouvez retirer cette partie de l'outil de construction sans avoir à tout changer. Cela ne fait qu'augmenter ce que vous avez déjà, alors que CSS et JS ne vous offrent pas le même type d'avantage. Je ne fais que reprendre celle-là, mais je pense à beaucoup de ces technologies de manière plus générale.
Chris : J'ai l'impression 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 autour de cela peuvent l'être moins.
Drew : Je pense qu'il est juste, n'est-ce pas, que la plate-forme Web évolue 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 de carrousel pour répondre à ce besoin, elle ne serait pas restée là sans que personne ne l'utilise, car les gens ne le font plus avec les carrousels. Parce que ce n'était qu'une mode, une tendance design. Pour contrer cela et empêcher que la plate-forme elle-même ne devienne gonflée et ne devienne un problème à résoudre, elle doit évoluer à un rythme beaucoup plus régulier. The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.
Drew: One of the other areas where things seem to be bloating out on the web is… I guess it's related to the framework conversation. But it's the concept of a single-page app. I feel like that a lot of promises are made around single-page apps as to their performance, like you're getting all this benefit because you're not reloading the entire page framework. I feel like they don't always make good on those performance promises. Serais-tu d'accord avec ça?
Chris: Yes. Although I will confess, despite having a very lengthy chapter in my book on this and talking about that a lot in talks and conversations with people, I don't think single-page apps are always a terrible thing. But I do think this idea that you need one for performance is overstated. You can oftentimes get that same level of performance with different approaches.
Chris: I think one of the bigger challenges with single-page apps is… For anybody who's unfamiliar with those. When a single-page app, instead of having separate HTML files or if you're using something like a database driven site like WordPress, even though you don't have actual physical HTML files for each page in your WordPress site, WordPress is creating HTML files on the fly and sending them back to browsers when URLs are requested. For purposes of this conversation, instead of having separate HTML files for every view in your app, a single-page app has a single HTML file. That's what makes it a single-page app. JavaScript handles everything. Rendering the content, routing to different URL paths, fetching new content if it needs to from an API or something like that.
Chris: One of the spoken benefits of these or stated benefits of these is that only the content on the page changes. You don't have to re-download all the JS and the CSS. Oh, and you can do those fancy page transitions that designers sometimes love. In theory, this is more performant than having to reload the whole page.
Chris: The problem with this approach from my perspective is that it also breaks a bunch of stuff that the browser just gives you for free out-of-the-box, and then you need to recreate it with more JS. You have an app that's slow because it has a lot of JS. So you throw even more JavaScript at it to improve that performance and in doing so, you break a bunch of browser features and then have to re-implement those with even more JS too.
Chris: For example, some things that the browser will do for free with a traditional website that you need to recreate with JavaScript when you go the single-page app. You need to intercept clicks on links and suppress them from actually firing, with your JavaScript. You then need to figure out what you actually need to show based on that URL, which is normally something that would get handled on the server or based on the file that goes with that URL path. You need to actually update the URL in the address bar without triggering a page reload. You need to listen for forward and back clicks on the browser and update content again, just like you would with clicks on links. You need to update the document title.
Chris: You also need to shift focus in a way that announces the change in page to people who are using screen readers and other devices so that they're not confused about where they are or what's going on. Because they can't see the change that's happening, they're hearing it announced. If you don't actually shift focus anywhere, that announcement doesn't happen. These are all things that the browser would do for you that get broken with single-page apps.
Chris: On top of that, because you have all this extra JavaScript, this is complicated. So most people use frameworks and libraries to handle this sort of thing. Because of all this extra JavaScript to support this approach, you end up with potentially slower initial page load than you would have otherwise. Depending on the content you have, this approach I think sometimes can make sense. If you have an app that is driven by API data where you don't necessarily know what those URL paths are going to look like ahead of time.
Chris: Just an example here. You have an animal rescue where you have some adoptable animals, and that data comes from Petfinder, the animal adoption website. You have a bunch of animals there. Petfinder manages that, but you want to display them on your site with the Petfinder API. When your website's being built, it doesn't always necessarily have visibility to what pets are available in this exact moment and what kind of URL paths you're going to need. A single-page app can help you there because it can dynamically on the fly, create these nice URLs that map with each dog or cat.
Chris: Something like Instagram with lots of user created content, maybe that also makes sense. But for a lot of things, we do know where those URLs are going to be ahead of time. Creating an HTML file that has the content on it already is going to be just as fast as… sometimes even faster than the JavaScript based single-page app approach, especially if you use some other techniques to keep your overall CSS and JavaScript size down. I use this approach on a course portal that I have. The page loads feel instantaneous because HTML is so easy for browsers to render compared to other parts of the stack. It feels like a single-page app, but it's not.
Drew: Especially when you consider hosting solutions like a Jamstack approach of putting HTML files out in a CDN so it's being served somewhere physically close to the user.
Chris: Yep.
Drew: Loading those pages can just be so, so quick.
Chris: Yes. Absolument. Absolument. One of the other arguments I think people used to make in favor of single-page apps is offline access. If someone loads it and then their network goes down, the app is already up and all the routes are handled just with the file that's already there. So there's no reloading, they don't lose any work. That was true for a long time. Now with service workers and progressive web apps, that is I think less of a compelling argument, especially since service workers can fetch full HTML files and cache them ahead of time if needed.
Chris: You can literally have your whole app available offline before someone has even visited those pages if you want. It just happens in the background without the user having to do anything. It's again, one of those technologies that maybe made sense for certain use cases a few years ago a little less compelling now.
Drew: It reminds me slightly of when we used to build websites in Flash.
Chris: Yes.
Drew: And you'd have just a rectangle embedded in an HTML page which is your Flash Player, and you'd build your entire site in that. You had to reimplement absolutely everything. There was no back button. If you wanted a back button, you had to create a back button, and then you had to create what the concept of a page was. You were writing code upon code, upon code to reimplement just as you are saying things that the browser already does for you. Does all this JavaScript that we're putting into our pages to create this functionality… is this going to cause fragility in our front-ends?
Chris: Yes. This is almost certainly from my mind, one of the biggest issues with our over-reliance on JavaScript. JavaScript is just by its nature, is a scripting language, the most fragile part of the front-end stack.
Chris: For example, if I write an HTML element that doesn't exist, I spell article like arcitle instead of article and the browser runs across that, it's going to be like, “Oh, I don't know what this is. Whatever, I'll just treat it like a div.” And it keeps going. If I mistype a CSS property… Let's say I forget the B in bold, so I write old instead, font way old. The browser's going to be, “I don't know what this is. Whatever, we'll just keep going.” Your thing won't be bold, but it will still be there.
Chris: With JavaScript, if you mistype a variable name or you try to use a property, you try to call a variable that doesn't exist or a myriad of other things happen… your minifier messes up and pulls one line of code to the one before it without a semicolon where it needs one, the whole app crashes. Everything from that line on stop working. Sometimes even stuff that happens before that doesn't complete, depending on how your app is set up. You can very quickly end up with an app that in a different approach, one where you rely a lot more on HTML and CSS, it would work. It might not look exactly right, but it would still work… to one that doesn't work at all.
Chris: There's an argument to be made that in 2020, JavaScript is an integral and important part of the web and most people don't disable it and most people are using devices that can actually handle modern JavaScript. That's true, but that's not the only reason why JavaScript doesn't work right, even if you have a linter there for example and you catch bugs ahead of time and things. There's plenty of reasons why JavaScript can go horribly awry on you. CDNs fail.
Chris: Back in July of last, a year ago this month… at least, when we're recording this… a bad deploy took down Cloudflare. Interestingly as we're recording this, I think a week or two ago, Cloudflare had another massive outage that broke a whole bunch of things, which is not a knock on Cloudflare. They're an incredibly important service that powers a ton of the web. But CDNs do sometimes go down. They are a provider used by 10% of Fortune 1,000 companies. If your JS is served by that CDN and it breaks, the JavaScript file never loads. And if your content is dependent on that JS, your users get nothing instead of getting something just not styled the way you'd like.
Chris: Firewalls and ad blockers get overly aggressive with what they block. I used to work at a company that had a JavaScript white list because they were extremely security conscious, they worked with some government contract stuff. They had a list of allowed JavaScript, and if your site or if your URL wasn't part of that, no JavaScript. You have these sites. I remember going to a site where it had one of the hamburger kind of style menus on every view whether it was desktop or mobile, and I could not access any page other than the homepage because no JavaScript, no hamburger, that was it.
Chris: Sometimes connections just timeout for reasons. Either the file takes a while or someone's in a spotty or slow connection. Ian Feather, an engineer at BuzzFeed, shared that about 1% of requests for JavaScript on the site fail which is 13 million requests a month. Or it was last year, it's probably even more now. That's a lot of failed JavaScript. People commuting go through tunnels and lose the internet. There's just all sorts of reasons why JavaScript can fail and when it does, it's so catastrophic.
Chris: And so we built this web that should be faster than ever. It's 2020, 5G is starting to become a thing. I thought 4G was amazing. 4G is about as fast as my home wifi network. 5G is even faster, which is just bonkers. Yet somehow, we have websites that are slower and less performant than they were 5 or 10 years ago, and that makes no sense to me. It doesn't have to be that way.
Drew: How do we get out of this mess, Chris?
Chris: Great question. I want to be really clear. I know I've hammered on this a couple times. I'm not saying all the new stuff is bad, never use it. But what I do want to encourage is a little bit more thoughtfulness about how we build for the web.
Chris: I think the overlying theme here is that old doesn't mean obsolete. It doesn't mean never embrace new stuff, but don't be so quick to just jump on all the shiny new stuff just because it's there. I know it's one of the things that keeps this industry really exciting and makes it fun to work in, there's always something new to learn. But when you pick these new things, do it because it's the right tool for the job and not just because it's the shiny new thing.
Chris : L'une des autres choses que nous n'avons pas abordées autant que je l'aurais souhaité, mais je pense que c'est vraiment important, c'est que la plate-forme a beaucoup rattrapé ces dernières années. Adopter cela autant que possible se traduira par une expérience Web pour les gens plus rapide, moins fragile, plus facile à construire et à entretenir car cela nécessite moins de dépendances telles que l'utilisation de ce que le navigateur vous donne hors de -la boîte. Nous avions besoin de jQuery pour sélectionner des choses comme des classes. Maintenant, les navigateurs ont des moyens natifs de le faire. Les gens aiment JSX parce qu'il vous permet d'écrire du HTML en JavaScript de manière plus transparente. Mais nous avons également des littéraux de modèle dans Vanilla JavaScript qui vous offrent le même niveau de facilité sans la dépendance supplémentaire. HTML lui-même peut maintenant remplacer beaucoup de choses qui nécessitaient auparavant JavaScript, ce qui est absolument incroyable.
Chris : Nous avons parlé un peu de… c'est un truc CSS, mais il survole les liens et comment cela nécessitait auparavant 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 en accordéon de manière native, sans aucun script nécessaire. Vous pouvez faire des saisies automatiques en utilisant juste un… Je ne devrais pas dire juste, je déteste ce mot. Mais en utilisant un humble élément d'entrée, puis un élément de liste de données qui lui est associé, avec quelques options. Si vous êtes curieux de savoir comment tout cela fonctionne sur vanillajstoolkit.com, j'ai un tas de trucs JavaScript que la plate-forme vous donne. Mais j'ai aussi l'habitude d'exiger JavaScript et maintenant je n'ai pas le genre de choses qui pourraient être intéressantes aussi si vous voulez que des exemples de code accompagnent cela.
Chris: Du côté CSS, mon plugin Vanilla JS le plus populaire est cette bibliothèque qui vous permet d'animer le défilement vers les liens d'ancrage. 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, un comportement de défilement fluide. C'est plus performant. C'est plus facile d'écrire. Il est plus facile de modifier son comportement. C'est juste une meilleure solution globale.
Chris : L'une des autres choses que j'aurais aimé que nous fassions davantage, c'est de nous appuyer sur des applications multipages. Je me sens un peu justifié ici, car j'ai récemment vu un article de quelqu'un chez Google qui pousse en fait pour cette approche maintenant aussi. J'ai pensé que c'était assez intéressant, compte tenu de cet énorme cadre anguleux puis… toutes les choses, boum, que Google a lancées il y a quelques années. C'est 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ù ce 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 examinant d'abord les approches plus petites et plus modulaires au lieu de simplement opter pour les mastodontes de l'industrie. Au lieu de React, Preact fonctionnerait-il ? Au lieu d'angulaire… Je veux dire, au lieu de Vue plutôt, est-ce que Alpine JS fonctionnerait ? Il existe également ce pré-compilateur vraiment intéressant appelé Svelt, qui vous offre une expérience de type framework, puis compile tout votre code dans Vanilla JavaScript. Vous obtenez donc ces très petits lots qui contiennent exactement ce dont vous avez besoin et rien d'autre. Au lieu de CSS et de JavaScript, pourriez-vous intégrer un linter CSS tiers qui comparera votre HTML à votre CSS et retirera les éléments qui y sont restés par accident ? Une autre façon 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 peut-être le troisième et le plus important élément ici, même s'il s'agit moins d'une approche spécifique et plus simplement d'une chose que je souhaite que plus de gens gardent à l'esprit, c'est que le Web est pour tout le monde. De nombreux outils que nous utilisons aujourd'hui fonctionnent pour les personnes qui disposent de bonnes connexions Internet et d'appareils puissants. Mais ils ne fonctionnent pas pour les personnes qui utilisent des appareils plus anciens et qui ont des connexions Internet inégales. Il ne s'agit pas seulement des habitants des régions en développement. C'est aussi des gens au Royaume-Uni, dans certaines parties des États-Unis où nous avons des connexions Internet absolument catastrophiques. Le centre de notre pays a une connexion Internet très lente. 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, donc il vous reste 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. Internet y était horrible. Je ne sais pas si ça 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.
Drew : Si les auditeurs veulent en savoir plus sur cette approche, vous en avez parlé en détail 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 tout lire gratuitement en ligne. Vous pouvez aussi si vous le souhaitez, il y a des versions EPUB et PDF disponibles pour une très petite somme d'argent, 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'entre dans plus de détails si vous le souhaitez.
Chris : Mais j'ai également créé une page spéciale réservée aux auditeurs de Smashing Podcast sur gomakethings.com/smashingpodcast, car je suis très créatif pour nommer les choses. Cela inclut un tas de ressources en plus du livre, autour de choses dont nous avons parlé aujourd'hui. Il est lié à de nombreuses techniques différentes 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 endroit pour commencer.
Drew : C'est formidable. Merci. J'ai tout appris sur le Lean Web. Qu'as-tu appris dernièrement, Chris ?
Chris : Oui, deux ou trois choses. J'y ai fait allusion un peu plus tôt en regardant la vidéo de Jeremy sur les applications Web progressives. J'ai retardé d'apprendre à écrire ma propre application Web progressive pendant quelques années parce que je n'avais pas de besoin spécifique sur quoi que ce soit avec lequel 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 à 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 réalisons régulièrement ensemble, car le courant est coupé et elle ne peut pas accéder au portail d'apprentissage et suivre.
Chris : Pour moi, créer une expérience qui 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 commencé à creuser là-dedans et j'espère que cela sera mis en place dans les prochaines semaines. On verra. 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é l'une des raisons pour lesquelles vous aimez poser cette question, c'est pour montrer que les gens, aussi expérimentés soient-ils, apprennent toujours. Juste une petite anecdote connexe. Je suis développeur web depuis je pense, environ huit ans maintenant. Je dois encore rechercher 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. Je vais essayer quelques combinaisons de choses différentes, et j'ai toujours un mot faux à chaque fois. J'écris aussi parfois en italique au lieu d'italique. Ouais. Si jamais quelqu'un là-bas se sent comme, oh, je n'apprendrai jamais ce genre de choses… sachez simplement que peu importe à quel point vous êtes chevronné, il y a toujours quelque chose de vraiment basique que vous recherchez encore et encore sur Google.
Drew : Je suis développeur Web depuis 22 ou 23 ans, et je dois encore rechercher sur Google les différentes propriétés de Flexbox, à chaque fois. Bien que je l'utilise depuis 23 ans. Mais oui, certaines choses juste… il y en aura probablement plus à mesure que je vieillis.
Cris : Ouais. Honnêtement, j'ai fini par créer tout un site Web de choses que je recherchais encore et encore, juste pour avoir une référence copier-coller plus facile parce que c'était plus facile que de googler.
Drew : 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 m'épargner trois secondes de recherche sur Google.
Drew : Si vous, l'auditeur, souhaitez en savoir plus sur Chris, vous pouvez trouver son livre sur le Web à l'adresse leanweb.dev, ainsi que sa newsletter Developer Tips et plus encore sur gomakethings.com. Chris est sur Twitter à 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 : Non. Merci beaucoup de m'avoir invité, Drew. J'ai passé un moment absolument fracassant. C'était très amusant. J'apprécie vraiment l'opportunité de venir discuter.