Les meilleures pratiques modernes sontelles mauvaises pour le Web?

Aujourd'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 du 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 développé un bulletin d’informations sur les conseils, 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 vas-tu?

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

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

Drew: Pourquoi ne nous plantez-vous pas le décor? Quand nous parlons d'un Lean Web, quel est le problème que nous essayons de résoudre?

Chris: Ouais, excellente question. Juste 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 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 axée sur la simplicité, sur les performances, et l'expérience des développeurs … Je suis désolé, pas l'expérience des développeurs. L'expérience utilisateur plutôt, par rapport à 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 le verrons probablement dans notre conversation.

Chris : En fait, j'ai 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 cela aussi, que nous pouvons approfondir. Mais en réalité, le Lean Web consiste à se concentrer sur la simplicité et les performances 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: ] Au fur et à mesure que le Web évolue en tant que plate-forme de développement, il semble y avoir cette tendance toujours plus grande à la spécialisation.

Chris: Oui.

Drew: Les gens qui couvraient Full Stack, puis nous divisé 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 se spécialise. Quelqu'un peut se considérer et se vendre 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 des cadres et des 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 pas nécessairement le meilleur choix pour vous ou pour le projet.

Chris: Quand je pense à beaucoup de problèmes que nous ont 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 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 étrange.

Drew: À l'époque précédant l'apparition des grands frameworks, nous construisions 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.

Drew: Maintenant, c'est une partie d'ingénierie assez complexe que vous ' sont nécessaires pour se 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 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 frontière 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 éléments d’ingénierie absolument incroyables. Je ne veux pas enlever aux gens qui y travaillent. J'ai fini par être 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 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 beaucoup des outils que nous utilisons sont potentiellement surpuissants pour le 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 qu'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, c'est d'une paire de ciseaux. Vous n’avez pas besoin de tout le reste, mais nous l’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 en choisissant 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.

Drew: 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, bien sûr.

Drew: Mais atteindre 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. De nos jours, 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 le sont pas. familier, quand vous dites quelque chose comme Preact laisse tomber 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 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 une nouvelle peinture.

Chris: Mais je pense que, plus important encore, l'un des problèmes avec cela est que vous avez une sorte d'élément interactif là-dedans, 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 petites choses comme Preact ou Alpine, elles le font en fait directement. Ils convertissent la chaîne que vous leur fournissez de ce à quoi devrait ressembler l'interface utilisateur 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, faites un clic droit 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 seul tweet.

Chris: Lorsque vous commencez à descendre autant de niveaux, cela commence à avoir un impact réel sur les performances. Ce que fait le DOM virtuel, c'est 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 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 est que… la différence entre Preact et React est de 27 kilo-octets avant de déballer le tout dans sa véritable onde codée. 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 multifonction, ou si vous avez des gens dans des pays en développement, c'est vraiment… le temps de démarrer 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 ils sont comparables en 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. 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.

Drew: Certains pourraient dire qu'ils pourraient faire valoir que ces frameworks, des choses comme Vue, React sont tellement optimisés pour performances que vous en tirez tellement d'avantages qu'il suffit de l'associer à un gestionnaire de packages dans un bundler pour vous assurer que vous n'envoyez que le code que vous souhaitez. Sûrement, vous avez 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 bundling, cela va encore être plus gros que d’utiliser quelque chose comme Preact.

Chris: Drew, j’apprécie vraiment que vous posiez la question à ce sujet. Parce qu'une des autres choses dont je parle dans mon livre, The Lean Web, et dans 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 paquets et les bundleurs de modules sont l'un des moyens de le faire.

Chris: Comme vous l'avez mentionné… pour ceux d'entre vous qui ne le savent pas, ce sont des outils qui… ils compileront tout votre petit bits 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 en supprimeront certaines 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 très délicat château de cartes de dépendances au-dessus des dépendances au-dessus des dépendances.

Chris: 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 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 les 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 parcourue dans le JS moderne aurait pu vous prendre 10 minutes dans jQuery. Je ne suis pas vraiment 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 de nombreuses 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 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 nécessaires au démarrage d'un projet.

Drew: Il semble qu'il y ait énormément de travail pour obtenir quelque chose à Hello World, et il y a encore plus à 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. Ça va être une vraie barrière à l’entrée, non?

Chris: Absolument. L'autre élément ici est que les développeurs JavaScript ne sont pas toujours les seuls à 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 stack 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, le principal consultant en accessibilité de WordPress, Rian Rietveld, dont j'ai presque certainement massacré le nom… elle a démissionné très publiquement d'elle et a expliqué pourquoi dans un article 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 serait accessible. WordPress représente désormais 30% du Web. Leur objectif est de démocratiser l'édition, donc l'accessibilité en est un élément très important. 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 l'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 a été très 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 à 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 se sont soudainement retrouvés exclus du processus à cause 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 à le 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, quand ce n'est plus le cas.

Drew: J'ai trouvé récemment dans un projet de recherche des moyens de résoudre certains des problèmes de CSS, 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é certains de ces CSS dans des approches 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 faire cela.

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 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 allez avec 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 et correcte 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 où vous avez vos propriétés directement dans le HTML et Vue les remplace, mais vous pouvez également utiliser une sorte de syntaxe de modèle plus JSX si vous préférez.

Chris: J'ai entendu plusieurs personnes se plaindre quand ils 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 disant 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à, là où vous étiez mentionnant 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 s'en va avec. 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 le sont pas. t utilisé 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 juste ces mots absurdes qui sont crachés.

Chris: C'est là que je commence à vraiment me plonger dans le vieil homme qui 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 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 véritable 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 gère des problèmes que vous n’avez pas, et vice-versa. La taille et l’échelle de ce sur quoi ils travaillent sont simplement différentes, et c’est bien.

Drew: 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 pouvez 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 choses comme 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, les ouvre 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 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, cela ne nécessite pas une énorme réécriture pour les retirer.

Chris: Donc, pour y arriver, nous avons tout un tas de styles que nous n'utilisons plus thing, that's why I would personally favor a build tool technology that audits your CSS against the rendered markup and pulls out the things you don't need. Because down the road if a platform catches up, you can pull that piece of the build tool out without having to change everything. It’s just augmenting what you already have, whereas CSS and JS doesn’t give you that same kind of benefit. I’m just picking on that one, but I think about a lot of these technologies more broadly.

Chris: I do feel things like React or Vue are probably paving some cow paths that browsers will eventually catch up with and probably use similar approaches if not the same, so there may be less rewriting involved there. A lot of the ecosystem stuff that gets plugged in around that may be less so.

Drew: I think it’s right, isn’t it, that the web platform moves slowly and carefully. You think if five years ago, we were all putting JavaScript Carousels on our pages. They were everywhere. Everyone was implementing JavaScript Carousels. If the web platform had jumped and implemented a Carousel solution to satisfy that need, it would not be sat there with nobody using it because people aren’t doing that with Carousels anymore. Because it was just a fad, a design trend. To counteract that and stop the platform itself becoming bloated and becoming a problem that needs solving, it does have to move at a lot steadier pace. 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. Would you agree with that?

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. Absolutely. Absolutely. 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: One of the other things we didn’t get into as much as I would have liked, but I think is really important, is that the platform has caught up in a really big way in the last few years. Embracing that as much as possible is going to result in a web experience for people that is faster, that is less fragile, that is easier for you to build and maintain because it requires fewer dependencies such as using what the browser gives you out-of-the-box. We used to need jQuery to select things like classes. Now browsers have native ways to do that. People like JSX because it allows you to write HTML in JavaScript in a more seamless way. But we also have template literals in Vanilla JavaScript that give you that same level of ease without the additional dependency. HTML itself can now replace a lot of things that used to require JavaScript, which is absolutely amazing.

Chris: We talked a little bit about… this is a CSS thing, but hovers over links and how that used to require JavaScript. But using things like the details and summary elements, you can create disclosure, like expand and collapse or accordion elements natively with no scripting needed. You can do auto complete inputs using just a… I shouldn’t say just, I hate that word. But using a humble input element and then a data list element that gets associated with it, with some options. If you’re curious about how any of this stuff works over at vanillajstoolkit.com, I have a bunch of JavaScript stuff that the platform gives you. But I also have some used to require JavaScript and now doesn’t kind of things that might be interesting too if you want some code samples to go along with this.

Chris: On the CSS side of things, my most popular Vanilla JS plugin ever is this library that lets you animate scrolling down to anchor links. It is very big. It’s the hardest piece of code I’ve ever had to write. And it now is completely replaced with a single line of CSS, scroll behavior smooth. It’s more performant. It’s easier to write. It’s easier to modify its behavior. It’s just a better overall solution.

Chris: One of the other things that I wish we did more is leaning on multi-page apps. I feel a little bit vindicated here, because I recently saw an article from someone at Google that actually pushes for this approach now too. I thought that was pretty interesting, given this huge angular and then framework… all the things, boom, that Google started a few years back. Kind of cool to see them come back around to this. Using things like static site generators and awesome services like Netlify and CDN caching, you can create incredibly fast web experiences for people using individual HTML files for all of your different views. So kind of leaning on some of this out-of-the-box stuff.

Chris: In situations where that’s not realistic for you, where you do need more JavaScript, you do need some sort of library, maybe taking a look at the smaller and more modular approaches first instead of just going for the behemoths of the industry. Instead of React, would Preact work? Instead of angular… I mean, instead of Vue rather, would Alpine JS work? There’s also this really interesting pre-compiler out there now called Svelt, that gives you a framework-like experience and then compiles all your code into Vanilla JavaScript. So you get these really tiny bundles that have just what you need and nothing else. Instead of CSS and JavaScript, could you bolt in some third party CSS linter that will compare your HTML to your CSS and pull out the stuff that got left in there by accident? Would a different way of authoring your CSS, like object oriented CSS by Nicole Sullivan, work instead? We didn’t really get to talk about that, but it’s a really cool thing people should check out.

Chris: And then I think maybe the third and most important piece here, even though it’s less of a specific approach and more just a thing I wish more people kept in mind, is that the web is for everyone. A lot of the tools that we use today work for people who have good internet connections and powerful devices. But they don’t work for people who are on older devices, have spotty internet connections. This is not just people in developing areas. This is also people in the U.K., in certain parts of the U.S. where we have absolutely abysmal internet connections. The middle of our country has very slow internet. I know there’s places in part of London where they can’t wire a new broadband in for historical reasons, so you’re left with these old internet connections that are really bad. There’s places like that all over the world. Last time I was in Italy, same thing. The internet there was horrible. I don’t know if it’s changed since then.

Chris: The things we build today don’t always work for everyone, and that’s too bad. Because the vision of the web, the thing I love about it, is that it is a platform for absolutely everyone.

Drew: If listeners want to find out more about this approach, you’ve gone into loads of detail to it in your book, The Lean Web. And that’s available online. Is it a physical book or a digital book?

Chris: It’s a little bit of both. Well, no. It’s definitely not a physical book. You go to leanweb.dev. You can read the whole thing for free online. You can also if you want, there’s EPUB and PDF versions available for a really small amount of money, I forget how much now. I haven’t looked at it in a while. The whole thing is free online if you want it. You can also watch a talk on this topic where I go into more details if you want.

Chris: But I’ve also put together a special page just for listeners of Smashing Podcast at gomakethings.com/smashingpodcast, because I’m very creative with naming things. That includes a bunch of resources in addition to the book, around things that we talked about today. It links to a lot of the different techniques that we covered, other articles I’ve written that go deeper into some of these topics and expand on my thinking a little bit. If folks want to learn more, that would probably be the best place to start.

Drew: That’s terrific. Je vous remercie. I’ve been learning all about the Lean Web. What have you been learning about lately, Chris?

Chris: Yeah, a couple of things. I alluded to this a little bit earlier with watching Jeremy’s video on progressive web apps. I have been putting off learning how to actually write my own progressive web app for a couple of years because I didn’t have a specific need on anything I was working with. I recently learned from one of my students who is in South Africa, that they have been dealing with rolling blackouts because of some stuff they have going on down there. As a result, she is not able to work on some of the projects we’ve been doing together regularly, because the power goes out and she can’t access the learning portal and follow along.

Chris: For me, now building an experience where it works even if someone doesn’t have internet has become a higher priority than… I realized that maybe it was before, so I just started digging into that and hope to get that put together in the next few weeks. We’ll see. Jeremy Keith’s resources on this have been an absolute lifesaver though. I’m glad they exist.

Chris: I know, Drew, you mentioned one of the reasons you like to ask this question is to show that people no matter how seasoned they are, are always learning. Just a little related anecdote. I have been a web developer for I think, about eight years now. I still have to Google the CSS property to use for making things italic, literally every single time I use it. For some reason, my brain defaults to text decoration even though that’s not the right one. I’ll try a couple of combinations of different things, and I always have one word wrong every time. I also sometimes write italics instead of italic. Yeah. If anybody ever there is ever feeling like, oh, I’m never going to learn this stuff… just know that no matter how seasoned you are, there’s always some really basic thing that you Google over and over again.

Drew: I’ve been a web developer for 22, 23 years, and I have to Google the different properties for Flexbox still, every time. Although I’ve been using that for 23 years. But yeah, some things just… there’s probably going to more of those as I get older.

Chris: Yeah. Honestly, I ended up building a whole website of stuff I Google over and over again, just to have an easier copy-paste reference because that was easier than Googling.

Drew: That’s not a bad idea.

Chris: That’s the kind of lazy I am. I’ll build a whole website to save myself like three seconds of Googling.

Drew: If you the listener would like to hear more from Chris, you can find his book on the web at leanweb.dev, and his developer Tips newsletter and more at gomakethings.com. Chris is on Twitter at Chris Ferdinandi. And you can check out his podcast at vanillajspodcast.com or wherever you usually get your podcasts. Thanks for joining us today, Chris. Do you have any parting words?

Chris: No. Thank you so much for having me, Drew. I had an absolutely smashing time. This was heaps of fun. I really appreciate the opportunity to come chat.

(il)