Smashing Podcast Episode 45 Avec Jeremy Wagner : Qu'est-ce que le JavaScript responsable ?

Cet épisode a été aimablement soutenu par nos chers amis de Wix, la plateforme permettant aux professionnels de créer des sites clients, de gérer des projets complexes et de développer des entreprises en ligne. Merci!

Dans cet épisode, nous parlons de JavaScript responsable. Qu'est-ce que cela signifie pour le code d'être responsable, et comment devrions-nous aborder les projets différemment ? J'ai parlé à l'expert Jeremy Wagner pour le savoir.

Afficher les remarques

• Site Web JavaScript responsable
• Acheter le livre de A Book Apart
• Site personnel de Jeremy
• Jérémy sur Twitter

Mise à jour hebdomadaire

• La loi de Fitts à l'ère du toucher écrit par Steven Hoober
• Conception Web bien faite : parfaitement inutile écrit par Frederick O'Brien
• Tout ce que vous voulez savoir sur la création d'interfaces utilisateur vocales écrit par Nick Babich & Gleb Kuznetsov
• Implications de l'adhésion de WordPress au protocole Block écrit par Leonardo Losoviz
• Réflexions sur Markdown écrit par Knut Melvar

Transcription

Drew McLellan : C'est un rédacteur technique, un nerd de la performance Web, un développeur et un conférencier, qui travaille actuellement chez Google. Il a écrit pour A List Apart, CSS-Tricks et Smashing Magazine, et est l'auteur d'un nouveau titre, Responsible JavaScript for A Book Apart. Nous savons donc qu'il est un technicien et un communicateur qualifié, mais saviez-vous qu'il veut faire le tour du monde sur une planche à pagaie debout ? Mes amis fracassants, veuillez accueillir Jeremy Wagner. Salut Jérémie, comment vas-tu ?

Jeremy Wagner : Je suis fracassant. Comment vas-tu?

Drew : Je vais très bien. Merci. Je voulais vous parler aujourd'hui de cette idée de JavaScript responsable. S'agit-il d'une nouvelle approche ou technique, ou parlez-vous littéralement d'une utilisation responsable de JavaScript ?

Jeremy : Je parle littéralement d'utiliser JavaScript de manière responsable. Ainsi, selon l'archive HTTP, nous avons constaté une augmentation médiane de près de 58 % de la quantité de JavaScript téléchargée par les appareils mobiles, passant d'environ 290 kilo-octets à près de 500 kilo-octets au cours de la dernière année.

Drew : Waouh.

Jeremy : Donc, quand je parle d'utiliser JavaScript de manière responsable, c'est une première sorte d'approche de l'utilisateur à dire… pour évaluer de manière critique ce que nous construisons et est l'objectif de ce que nous construisons servi par les pratiques de développement Web modernes, donc parler. Et je suppose que c'est un peu… peut-être pas ironique, mais je ne m'intéressais pas au développement Web moderne, mais un sous-produit du développement Web moderne est qu'il est très facile d'ajouter des dépendances aux projets. Tout est une installation MPM et chaque installation MPM a un coût, ce coût varie. Mais ce que nous voyons, c'est que dans ces données d'archive HTTP, le 95e centile... c'est-à-dire les 5 % d'expériences qui sont les plus lentes... ou pas les plus lentes, mais qui expédient le plus de JavaScript, qui a augmenté d'environ 875 l'année dernière. kilooctets à environ 1,4 mégaoctets.

Drew : Waouh.

Jeremy : C'est donc une énorme quantité de JavaScript qui est transférée et cela a à la fois des implications sur les performances de chargement et sur les performances d'exécution.

Drew : Vous avez donc mentionné la performance ici. Il semble que l'expérience Web moderne, de mon point de vue, soit comme 10% HTML et CSS et 90% JavaScript. Et il doit y avoir une sorte de considérations de performance à cela. Je veux dire, vous avez parlé de la quantité de données que nous transférons, mais il y a d'autres considérations de performances là-dessus avec beaucoup de JavaScript.

Jérémy : Exact. Donc, avoir une connexion Internet lente et vous savez… où je vis aux États-Unis, si vous allez assez loin en dehors d'une grande ville, cela devient un peu difficile selon l'endroit où aller… pour faire face à la lenteur d'Internet peut être dans sorte de ces zones rurales et il y a beaucoup de gens qui vivent dans des zones comme celle-ci. Et donc l'aspect performances de chargement est déjà assez difficile lorsque vous commencez à expédier des mégaoctets de JavaScript, mais vous pourriez aussi avoir affaire à quelqu'un qui n'a pas d'iPhone… comme un iPhone X ou un iPhone 13.

Jeremy: Ils pourraient simplement être sur un téléphone polyvalent ou simplement comme un téléphone Android à petit budget, essayant simplement de naviguer dans la vie. Je veux dire, pensez à des choses comme les services bancaires en ligne, l'aide au chômage ou d'autres aides gouvernementales, des portails comme celui-ci pour les applications. Apprentissage en ligne, il y a juste beaucoup d'endroits où un excès de JavaScript peut vraiment avoir un effet néfaste pour les personnes qui pourraient ne pas avoir la chance de vivre dans de grandes zones métropolitaines ou même dans des zones métropolitaines qui ne sont pas bien desservies par Internet haut débit et celles sur des appareils plus lents . Je pense qu'en tant que développeurs, nous avons tendance à regarder… nous achetons des MacBook ou ces appareils haut de gamme, et nous ne voyons parfois pas vraiment où ces problèmes peuvent survenir lorsque nous abusons de JavaScript.

Drew : Et un peu comme vous l'avez mentionné ici, ce sont parfois les personnes qui ont le plus à perdre en ne pouvant accéder à un service qui sont pénalisées par ce genre de choses. Ces personnes sans connexions de données rapides ou sans appareils très performants accèdent parfois à des services qui signifient tout pour… cela signifie tout pour eux auxquels ils peuvent accéder. Cela devient donc presque une question de droits de la personne à certains égards.

Jérémy : Ouais. Je veux dire, nous avons tendance à voir les performances Web être encadrées en termes de valeur commerciale. J'étais consultant en performance pour une e-com et comme une grande entreprise alimentaire, une grande e-com… comme un magasin, comme un point de vente d'électronique et c'est très tentant de faire ça, non ? Parce que lorsque vous travaillez pour une entreprise, je veux dire, évidemment, vous voulez que les finances soient saines et les performances Web jouent un rôle là-dedans, je pense. Je pense qu'il existe un certain nombre d'études de cas qui le prouvent. Cependant, il y a cet aspect humain et même pour les entreprises, comme les épiceries et ce genre de choses. Oui, ils sont axés sur les revenus. Ils veulent avoir des finances saines et les performances Web en font partie, mais ils répondent également à un besoin critique, n'est-ce pas ? Comme si vous deviez manger, n'est-ce pas ?

Jeremy : Et comme certaines personnes pourraient être confinées à la maison pour une raison ou une autre. Ils pourraient ne pas être en mesure de monter facilement dans une voiture. Ils n'ont peut-être pas de voiture. Ils comptent donc sur ces services pour subvenir à leurs besoins, mais plus que cela, de l'aide s'ils en ont besoin et surtout comme une intervention de crise et ce genre de choses. Je ne pense pas qu'il soit exagéré de dire qu'un partenaire qui a été maltraité et expulsé de chez lui pourrait se tourner vers son smartphone et frapper Google pour essayer de trouver un portail d'intervention et d'assistance en cas de crise. Et JavaScript peut en quelque sorte entraver ces types d'objectifs et répondre à ces besoins humains. Quand on a tendance à s'appuyer un peu trop dessus.

Drew: Je veux dire, nous avons, nous avons vu une sorte d'aperçu de cela au cours des 18 derniers mois environ avec COVID et les gens se sont isolés et, comme vous le dites, ont besoin de commander des courses à livrer. Le Web devient alors une bouée de sauvetage pour eux. Ils se sentent mal, ne peuvent pas quitter leur logement parce qu'ils s'isolent et qu'ils doivent se procurer de la nourriture et des fournitures essentielles. Alors oui, c'est une partie de plus en plus importante de la vie quotidienne pour nous tous, je pense.

Jérémy : Exactement. Et pour en revenir au genre d'histoire d'appareil, Tim Kadlec a écrit un article incroyable il y a quelques années, je pense que c'était il y a deux ans, peut-être trois ans, mais cela s'appelait Prioritizing the Long Tail of Performance. Et quand vous regardez cela… donc dans le langage des performances Web, nous parlons en quelque sorte de données de laboratoire par rapport à des données de terrain. Et les données de laboratoire, c'est comme lorsque vous utilisez Lighthouse ou que vous lancez un site Web sur un test de page Web pour voir comment il se comporte. Ce sont tous des outils vraiment utiles, mais lorsque vous regardez ces données de terrain, vous commencez vraiment à avoir une image plus large et une vue plus large de qui est vraiment votre public. Et dans cet article, Tim Kadlec explique ce que signifie donner la priorité à la longue traîne de la performance. C'est-à-dire tous ces appareils qui… ne sont peut-être pas aussi costauds et aussi puissants que les appareils que nous, en tant que développeurs, pouvons avoir.

Jeremy : Et l'idée derrière cet article est que si nous pouvons nous concentrer sur ce 90e ou 95e centile, nous sommes... et améliorons cette expérience pour ces personnes, nous construisons un Web plus rapide pour tout le monde, y compris ceux qui utilisent des appareils rapides. Et attaquer un point de données là-dessus aux États-Unis et cela vient juste de statcounter.com. Quelque chose comme 28 points… environ 28 % des personnes utilisent un appareil iOS que cet outil capture. Et environ 21% d'entre eux sont Android. Et Android a tendance à représenter une bonne partie de cette longue queue d'appareils, car Android n'est pas monolithique. Plusieurs fabricants d'appareils fabriquent des téléphones Android, mais pour contraster cela avec le monde, parce que le monde est plus que les États-Unis, c'est environ 16 % des personnes qui utilisent iOS et environ 41 % des personnes qui utilisent Android. Il est donc vraiment payant de donner la priorité à ces expériences plus lentes ou potentiellement plus lentes.

Drew : J'ai lu dans votre livre des informations sur l'étranglement thermique des appareils, ce que je n'avais jamais vraiment envisagé auparavant. Quelles sont les préoccupations là-bas?

Jeremy : Les préoccupations là-bas, et je ne suis en aucun cas un expert des microprocesseurs. Je suis juste le développeur Web qui écrit probablement un peu trop, mais… donc l'idée derrière la limitation thermique et cela existe dans tous les systèmes, pas seulement comme les téléphones et les tablettes, c'est qu'un microprocesseur va… quand il prend des charges de travail excessives ou vraiment juste des charges de travail en général, le produit résiduel de ce travail est la chaleur. Et donc les appareils ont des moyens d'atténuer cela. Comme votre ordinateur portable possède à la fois un dispositif de refroidissement passif et actif.

Jeremy : Donc, comme un dispositif de refroidissement passif, c'est comme un dissipateur de chaleur ou une sorte de dissipateur de chaleur. Et la partie active de cela est comme un ventilateur pour disperser plus efficacement la chaleur. Certaines versions de PC personnalisées peuvent utiliser comme le refroidissement liquide, ce qui est en quelque sorte un exemple relativement extrême, mais un téléphone mobile n'a pas cela, car où allez-vous vraiment installer un ventilateur dans tout cela, si la portabilité est un peu votre chose, non?

Jeremy : Donc, pour que ces appareils puissent faire face à ces lourdes charges de travail, ils peuvent réduire artificiellement la vitesse du processeur, comme réduire la fréquence d'horloge jusqu'à ce que cet appareil entre dans un état dans lequel cette fréquence d'horloge peut être augmentée. Et cela a des implications parce que si vous mâchez des tonnes et des tonnes et des tonnes et des tonnes de JavaScript, vous avez comme ces gros morceaux qui arrivent sur le fil, eh bien, cela lance le traitement, n'est-ce pas ? Il y a donc beaucoup de traitement à travers l'évaluation et l'analyse lors de la compilation puis de l'exécution. Et si vous faites cela avec un ou deux mégaoctets de JavaScript, et que vous avez beaucoup d'autres processus en cours en arrière-plan, comme différents onglets, ce genre de chose qui, qui peut mettre votre état... cela augmente la probabilité que l'appareil peut entrer dans un état d'étranglement thermique, ce qui signifie qu'il sera moins capable d'assumer ce travail supplémentaire.

Drew : C'est donc une sorte de boucle de rétroaction négative. N'est-ce pas? Vous donnez beaucoup de travail à l'appareil. Il devient très chaud et est alors moins capable d'exécuter réellement ce travail car il doit ralentir.

Jérémy : Exact. Et encore une fois, je ne suis pas un expert en microprocesseur. Je suis sûr que si, si, si un ingénieur qui connaissait très bien cela pouvait probablement me corriger sur certains détails, mais l'idée générale est que oui, à mesure que la pression environnementale augmente, l'appareil est moins capable de faire face à ces lourdes charges de travail jusqu'à ce que cette pression diminue.

Drew : nous écrivons donc du JavaScript pour tout le spectre d'appareils du dernier Apple M1 Max est le nouveau processeur, n'est-ce pas ? Des ordinateurs portables jusqu'aux appareils qui ont à peine assez de RAM de travail pour afficher une page Web. Mais le Web n'a pas commencé comme ça, les jeunes auditeurs pourraient être intéressés de savoir que nous avions l'habitude de créer des expériences Web interactives sans aucun JavaScript. Notre gros et lourd cadre va être notre perte.

Jeremy: Je dirais que les frameworks ont un temps et un lieu et ceux qui lisent des extraits de ce livre peuvent avoir l'idée que je suis anti-framework. Et je suis définitivement critique à l'égard de plusieurs frameworks, mais ils ont un but et il est possible de les utiliser d'une manière qui préserve une bonne expérience utilisateur ou peut aboutir à une bonne expérience utilisateur. Mais ce que je ne pense pas que nous fassions assez, c'est une sorte d'évaluation critique de ces frameworks en termes de la façon dont ils nuisent… aux performances d'exécution, n'est-ce pas ? Donc, le type de choses dont je parle, où si vous cliquez sur un bouton, et il faut à l'appareil une seconde peut-être deux pour répondre à cette entrée, car il se passe tellement de choses en arrière-plan. Vous avez des trucs JavaScript tiers comme la collecte d'analyses, puis vous avez d'autres choses qui s'exécutent sur des threads.

Jeremy : Et que si vous n'évaluez pas de manière critique les performances d'exécution d'un framework, vous pourriez laisser quelques opportunités sur la table pour mieux servir vos utilisateurs. Donc, un bon exemple, que j'aime toujours utiliser, c'est réagir contre pré-agir. Je tape sur ce tambour depuis un moment. J'ai fait un article pour CSS-Tricks il y a quelque temps qui décrivait une interaction de clic de base comme un menu de navigation mobile. Et cela semble trivial, mais ce que vous constatez, c'est que sur tous les appareils, React offre de meilleures performances d'exécution, mais il a fondamentalement la même API. Il y a des différences, il y a quelques petites différences et des choses qui peuvent être dissimulées avec la compatibilité pré-acte, mais c'est simple… et je ne devrais pas dire un choix simple, mais ce choix, ce choix fondamental peut être la différence entre une expérience qui fonctionne vraiment bien pour tous les utilisateurs ou au moins la plupart des utilisateurs, ou une expérience qui ne fonctionne bien que pour certains. Espérons que cela avait du sens.]

Drew : Je veux dire, avec tous les frameworks et les outils de construction, ils semblent s'améliorer tout le temps pour faire des choses comme secouer les arbres et optimiser les bundles qu'ils fournissent et comment ils sont ensuite livrés au navigateur. Lorsque vous utilisez de gros frameworks, pensez-vous qu'il y a un point de basculement où vous écrivez une si grosse application, tellement de code, que le framework vous permet d'envoyer moins de code en raison de toute son abstraction ?

Jeremy : C'est une question à laquelle il est difficile de répondre. Un aspect de cela est que le framework lui-même représente une quantité de code que vous ne pourrez jamais optimiser. Donc, avoir comme un cadre mince, comme un pré-acte ou n'importe quel nombre de semblables… Ou comme un sort par exemple, ça aide beaucoup. Mais le problème que j'ai vu et je pense que les données de l'archive HTTP soutiennent ce point est qu'il semble que chaque fois que nous avons ces progrès dans les microprocesseurs et les réseaux qui s'accélèrent, nous avons tendance à consommer ce gain, n'est-ce pas ?

Jeremy: Nous avons tendance à être sur ce tapis roulant où nous n'avançons jamais vraiment. Et je ne sais pas, comme je ne suis pas clairvoyant sur l'histoire de… ou désolé, à quoi ressemble l'avenir des frameworks. Je suis sûr qu'il y a des gains d'efficacité qui peuvent être réalisés. Mais ce que nous voyons sur le terrain en termes de quantité de JavaScript brut… seule la quantité brute de JavaScript est utilisée. Cela ne me dit pas que c'est un problème dont nous pouvons en quelque sorte automatiser la sortie. Je pense que nous devons… nous devons être des êtres humains et intervenir et prendre des décisions qui sont dans le meilleur intérêt des utilisateurs. Sinon, je ne nous vois pas sortir de ce tapis roulant, pas dans ma carrière peut-être, mais je ne sais pas.

Drew : Dans le livre, vous parlez de sites Web et d'applications Web et comment comprendre la différence et avec lequel vous travaillez vous aide à choisir votre stratégie de développement et d'optimisation. Parlez-nous un peu de cela.

Jeremy : C'est une très bonne question. Et j'écris à ce sujet dans l'article éponyme que j'ai écrit pour A List Apart intitulé Responsible JavaScript Part One, qui est en quelque sorte le prélude à ce livre. Est-ce que nous chargeons beaucoup dans cette terminologie. Comme en tant que rédacteur technique, je vois les deux s'utiliser de manière interchangeable. Ce que je vois, c'est qu'avec les sites Web, l'implication est que c'est une sorte d'expérience multi-âge, n'est-ce pas ? C'est une collection de documents. Maintenant, un document… ces documents peuvent avoir des fonctionnalités intégrées comme ces petites îles, comme le terme a été en quelque sorte ces derniers temps, ces petites îles de fonctionnalités qui permettent aux gens de faire avancer les choses.

Jeremy : Mais il y a aussi les applications Web et les applications Web ont en quelque sorte cette connotation d'application native comme une fonctionnalité. Nous parlons donc d'applications d'une seule page, nous parlons de grandes quantités de JavaScript pour générer une interactivité complexe. Et il y a des moments où le modèle d'application Web a du sens. Comme par exemple, Spotify en est un bon exemple. Cela fonctionne mieux en tant qu'application Web. Vous ne voudriez pas vraiment essayer de l'utiliser ou de le concevoir comme une application multipage. Comme un site Web traditionnel, mais je pense que ce n'est pas une valeur par défaut durable, car lorsque votre valeur par défaut pour chaque projet est de dire : "Eh bien, tout ce dont nous avons besoin pour livrer une application d'une seule page, comme un routeur côté client et un framework lourd et décharger tout de ce traitement de rendu du serveur vers le client. » Je pense que c'est là que vous commencez à atteindre un point où vous excluez les utilisateurs, même involontairement, mais les excluez néanmoins.

Drew : Y a-t-il un grand gouffre, pensez-vous entre les gens qui adoptent l'approche selon laquelle nous allons publier un site Web et il peut avoir n'importe quelle fonctionnalité interactive et ceux qui disent : « Nous sommes une société de logiciels, nous sommes créer un produit, un produit logiciel et notre plate-forme via laquelle nous allons le livrer est le Web, plutôt que des applications natives pour plusieurs plates-formes. Est-il probable qu'ils abordent le problème de manière complètement différente ? Les considérations sont-elles différentes selon votre perspective à ce moment-là ?

Jeremy : C'est une question difficile. Alors-

Drew : C'était difficile pour moi de le dire.

Jeremy : Je dirais qu'une entreprise qui… donc un bon exemple serait comme une nouvelle, n'est-ce pas ? Ils sont bien servis par le type de modèle de site Web, car il s'agit littéralement d'une collection de documents, d'articles. Et les personnes qui développent ces expériences vont probablement avoir un ensemble de compétences différent de celui d'une entreprise comme Spotify ou d'une entreprise qui a comme une grande application Web comme Envision ou ce genre de chose. Et donc oui, je pense qu'ils vont aborder cela sous des angles différents. La façon dont j'ai en quelque sorte regardé les choses, c'est qu'il y a un segment… ou du moins c'est ainsi que j'ai perçu la communauté du développement Web dans son ensemble, c'est qu'il y a un segment de personnes, de développeurs Web qui viennent du développement de logiciels non traditionnels arrière-plans, non ? Et je suis l'une de ces personnes, je bricolais avec le web quand j'étais un peu comme un gamin, n'est-ce pas ?

Jeremy: Comme au collège et faire des pages de fans stupides pour tous comme les jeux vidéo à l'époque que j'aimais vraiment. Et je n'ai jamais eu ce genre de formation en informatique. Il y a des concepts informatiques que j'ai appris en cours de route. Ensuite, il y a aussi un segment de développeurs, en particulier je pense qui sont apparus au cours des cinq à 10 dernières années et qui abordent cela d'une manière plus orientée vers l'informatique. Et je pense que cela va… ces différences et ces expériences vont conduire chacun de ces groupes à tirer ses propres conclusions sur la meilleure façon de se développer pour le Web. Mais je pense que la seule façon de vraiment… développer durablement pour le Web est d'évaluer de manière critique ce que vous construisez et d'essayer de vous aligner sur une approche qui sert au mieux les utilisateurs de ces produits. Et c'est en quelque sorte là où le site Web et les modèles d'application Web me viennent à l'esprit lorsque j'évalue ces choses.

Drew : Ouais. C'est intéressant. Je veux dire, dans le livre, vous citez en fait une partie de mon travail. Merci beaucoup. Et mon choix de technologies ennuyeuses sur PHP Apache et une pincée de JavaScript roulé à la main peuvent créer une expérience utilisateur très rapide par défaut, sans avoir besoin de faire une optimisation particulière. Je pense que cela offre une excellente expérience utilisateur aux visiteurs qui viennent consulter le contenu du site.

Drew : Mais en fait, j'ai l'impression que cet environnement de création de contenu est en quelque sorte le revers de la médaille, une fois que vous êtes connecté et que vous publiez sur le site. Je pense qu'il souffre un peu d'être construit avec une approche de site Web, plutôt qu'une sorte d'approche d'application Web lourde en JavaScript, à tel point que je pense… ou peut-être qu'il faut les deux. Je dois continuer à publier le front-end dans de jolis HTML et CSS statiques et de minuscules morceaux de JavaScript. Mais le backend où je veux fournir une expérience de création de contenu peut-être qu'un choix technologique différent serait préférable. C'est assez intéressant parce qu'il n'est pas toujours nécessaire que ce soit l'une ou l'autre, n'est-ce pas ? Ce n'est pas un choix binaire. C'est plus un spectre, diriez-vous ?

Jérémy : Ouais tout à fait. Et je pense que nous commençons à voir plus de discussions dans la communauté sur le fait que le développement Web est un spectre comme celui-là. Pour être juste pour les personnes qui pourraient être intéressées par mon livre, cela vient définitivement du côté du site Web du spectre. Et encore, parce que j'ai l'impression que c'est toujours comme un bon défaut. Si vous ne savez pas comment vous voulez construire quelque chose, il est probablement préférable d'essayer de le construire d'une manière qui minimise l'utilisation de JavaScript et minimise le fait de pousser plus de travail sur le client. Cela dit, je pense que remarqué est une excellente expérience. Je pense que ces technologies bien usées et en quelque sorte vraiment «ennuyeuses» fonctionnent vraiment bien pour la tâche à accomplir. Et il le fait d'une manière qui est en quelque sorte ouverte et habilitante pour le développeur, n'est-ce pas ?

Jeremy: Vous n'avez pas besoin d'avoir une connaissance approfondie de comme… des magasins de gestion d'état ou des cadres de gestion d'état pour vraiment réussir ce genre de choses. Et je pense que remarqué est bien servi par cette approche particulière. Mais pour ce qui est de votre point de vue, je pense qu'il existe des opportunités dans n'importe quel site Web de se rapprocher du milieu du spectre sans se lancer dans tous les routages côté client comme des frameworks lourds qui gèrent tout sur le client et ce genre de choses. Je pense que l'approche de l'île commence à explorer à quoi cela ressemble. Et je l'admets, j'ai probablement involontairement fait des trucs de type îles. Je pense que nous l'avons fait pendant un certain temps, nous n'avons tout simplement pas vraiment mis de nom dessus. Mais je pense que maintenant que nous avons en quelque sorte identifié cela comme peut-être un point médian, nous pourrions commencer à voir des expériences Web qui offrent une bonne expérience utilisateur, mais qui sont toujours plus interactives. J'espère que ce n'était pas terriblement sinueux.

Drew : Cela rappelle un peu l'époque où nous intégrions une île de Flash ou...

Jérémy : Ouais.

Drew : Quelque chose dans une page où ceci est notre petite section interactive, et le reste circule en quelque sorte.

Jeremy: Ouais Comme Flash, oh mon Dieu, trois itérations de mon portfolio personnel à la sortie de l'université étaient vraiment merdiques avec des contrefaçons Flash avancées et comme des effets de survol. Et ce truc était vraiment, vraiment amusant. Et ça me manque parfois, comme s'il y avait toute une mine de contenu qui allait en quelque sorte disparaître parce que nous n'utilisons plus Flash. Et ça craint vraiment, mais d'une certaine manière, c'était en quelque sorte le précurseur de ce genre d'îles dont nous parlons. C'est-à-dire que vous pourriez simplement avoir une page Web statique et tout, mais vous auriez alors cette expérience interactive très riche, un peu comme si elle se trouvait en plein milieu de celle-ci.

Drew : Pendant longtemps, l'amélioration progressive a été considérée comme une bonne pratique pour créer des expériences Web. Est-ce toujours le cas, selon vous ?

Jeremy : J'accorderais que c'est probablement… pas probablement, j'accorderais que c'est plus de travail de faire une amélioration progressive parce que d'une certaine manière, vous bifurquez votre expérience de développement. Vous essayez de fournir une fonctionnalité minimale viable d'un site Web de manière à ce que le serveur puisse gérer un peu comme ces interactions clés. Mais en plus de cela, vous dites : "D'accord, eh bien maintenant, je veux faciliter cette interaction pour qu'elle soit un peu plus fluide avec JavaScript." Je pense toujours que c'est un moyen viable d'atteindre vos objectifs avec votre site Web, votre application ou votre produit.

Jeremy: Mais ce que je dirais, c'est que je ne recommanderais jamais que chaque interaction sur un site Web soit facilitée par ce type de modèle de navigation synchrone. Donc, comme un bon exemple, votre page de paiement pour votre site Web econ devrait certainement avoir une route de serveur. Vous devriez avoir une route de serveur pour ajouter des choses au panier, puis vous devriez pouvoir saupoudrer juste assez de JavaScript pour rendre cela un peu plus agréable afin que les choses puissent être un peu plus rapides et plus asynchrones.

Drew : Quand il s'agit de mesurer les performances. Nous entendons beaucoup parler des éléments vitaux du Web, principalement de Google. Sont-ils vraiment la référence à laquelle nous devrions nous mesurer? Ou est-ce simplement ce que Google veut que nous pensions ? Je comprends maintenant que cela pourrait être une question difficile que vous ayez commencé à travailler chez Google.

Jérémie : Ouais, ouais. Vous savez, donc je parle pour moi ici. Je pense que les éléments vitaux Web sont… les éléments vitaux Web de base initiaux sont une bonne tentative pour définir quelles parties de l'expérience utilisateur sont importantes. Je pense que des mesures telles que le changement de mise en page cumulatif et la plus grande peinture Contentful commencent à penser à l'expérience d'une manière que nous n'avions vraiment pas commencé à quantifier. Avant un changement de mise en page particulièrement cumulatif, car s'il y a déjà eu un moment où vous appuyez sur la rage, c'est parce qu'un bouton aime se déplacer sur la page ou quelque chose du genre. Je veux dire, je pense que c'est une chose utile pour le mesurer. C'est imparfait. Et je pense que quiconque travaille sur les éléments vitaux du Web serait d'accord pour dire qu'une amélioration est souhaitée dans certaines de ces mesures. Il y a d'autres mesures avec lesquelles je ne suis pas nécessairement entièrement d'accord. Par exemple, le premier délai d'entrée est une métrique difficile à cerner.

Jeremy : Je pense que c'est vraiment utile, n'est-ce pas ? Parce que ce que vous dites littéralement, c'est que nous voulons mesurer le délai et l'interactivité sur cette première interaction que l'utilisateur fait, mais cela manque un peu de contexte, n'est-ce pas ? Parce que certaines… beaucoup de choses peuvent l'affecter parce que cela n'est pas nécessairement toujours lié à JavaScript. Le premier délai d'entrée pourrait représenter le délai encouru par la focalisation du champ de formulaire, n'est-ce pas ? Ce genre de choses, des choses en HTML. Je pense que ces métriques… des métriques telles que le premier délai d'entrée peuvent être… elles peuvent être bénéfiques si vous pouvez les contextualiser avec des choses comme les entrées de l'API de tâche longue, la synchronisation des éléments et ce genre de choses. En fin de compte, je pense que l'avenir des éléments vitaux Web de base prouvera qu'il sera utile et déterminant pour mesurer ce qui fait une bonne expérience utilisateur. C'est mon avis personnel.

Drew : Je suppose que c'est, c'est une de ces choses que vous pouvez toujours mesurer par rapport à vous-même, mesurer vos propres améliorations ou si votre expérience s'est détériorée si votre score change, ne vous souciez pas tellement des feux de circulation, mais vous souciez de ce que vous savez. sur le contexte de votre site et comment un changement a apporté une amélioration.

Jeremy : Je pense que les métriques telles que le changement de mise en page cumulé sont excellentes, mais elles aussi pourraient bénéficier d'un peu d'amélioration. Dans l'état actuel des choses, le changement de disposition cumulatif mesure principalement les changements de disposition qui se produisent pendant le chargement. Et comme nous le savons, lorsqu'un utilisateur visite une page et atterrit sur une page, des changements de mise en page peuvent se produire à tout moment, n'est-ce pas ? Il y a donc certainement du travail que je pense que cela peut être fait pour améliorer la façon dont nous observons ce genre de phénomène, c'est certain.

Drew : Je pense que la stabilité de la mise en page est l'une des choses qui est en fait un peu plus difficile à réaliser lorsque vous travaillez avec une amélioration progressive. Parfois, lorsque vous chargez une page rendue par le serveur et que vous commencez ensuite à l'améliorer dans le client, il peut y avoir un risque de créer ce type de changement de mise en page, n'est-ce pas ?

Jérémy : Absolument. Et c'est en quelque sorte là que l'hydratation des composants devient un peu délicate car les dimensions de ce composant peuvent changer pour un certain nombre de raisons. Comme il pourrait y avoir du contenu présent dans le composant côté client qui ne s'affiche tout simplement pas sur le serveur en raison d'un état qui n'est pas évalué tant qu'il n'est pas exécuté sur le client. C'est un problème extrêmement difficile. Je ne vais pas m'asseoir ici et prétendre que j'ai la solution miracle.

Drew : Je voulais parler un peu de la dynamique des importations et du fractionnement du code, les deux étant des techniques différentes pour le problème du téléchargement et de l'exécution d'un énorme paquet de JavaScript dès le début de l'expérience. Y a-t-il un risque d'optimisation excessive en faisant beaucoup de petites demandes, en particulier sur les petits projets les plus simples, ou est-ce quelque chose qu'ils ne font absolument aucun mal à mettre en œuvre dès le départ en prévenant que vous allez avoir ces problèmes ? Ou devriez-vous attendre de voir réellement des problèmes de performances avant de penser à ce genre de choses ?

Jeremy : Je recommanderais donc que la fin de ce que vous venez de dire soit un bon moyen d'aborder cela. Nous ne devrions pas essayer d'optimiser prématurément à moins bien sûr que ces optimisations puissent être réalisées très rapidement et facilement, mais s'il faut beaucoup d'efforts pour optimiser dès le début, lorsqu'il n'y a pas vraiment beaucoup de problèmes de performances, je dirais que le fractionnement de code est probablement quelque chose qui n'a pas à se produire. Vous pouvez probablement simplement charger cette fonctionnalité à l'avance.

Jeremy : Mais par exemple, j'en parle dans le livre. Si vous avez une interaction de grande valeur qui est pilotée par un gros morceau de JavaScript, et pour moi, un gros morceau de JavaScript pourrait signifier 20 kilo-octets car sur le fil qui est compressé et cela pourrait finir par être un morceau de 60 kilo-octets de JavaScript. Ensuite, si vous pouvez l'extraire du bundle principal ou de l'un de vos myriades de bundles, votre site est peut-être en cours d'expédition, vous allez aider les performances de démarrage.

Jeremy : Mais dans le livre, je discute d'une technique pour percevoir quand… ou du moins essayer de percevoir quand l'utilisateur pourrait faire une interaction de grande valeur. Donc, l'exemple que j'utilise est un morceau de JavaScript. C'est utilisé pour valider le contenu d'un formulaire car la validation de formulaire HTML est excellente, mais elle n'est pas non plus stylisable et c'est assez simple. Il n'y a pas des tonnes de flexibilité pour des choses comme, type égal e-mail, n'est-ce pas ? Il l'évalue d'une certaine manière. Cependant, cette validation du formulaire sur le client est vraiment utile car nous pouvons également le styliser. Et nous pouvons aligner l'apparence de cette validation pour qu'elle soit plus proche de l'esthétique de la marque ou de l'esthétique du site Web. Et donc dans cet exemple, ce que j'ai fait, c'est que j'ai dit, si un utilisateur se concentre… même se concentre simplement sur l'un des champs du formulaire, c'est le moment où nous préchargeons ce morceau de JavaScript.

Jeremy: Donc, j'espère que d'ici le temps, et j'espère que parce qu'il faut un peu de temps pour remplir un formulaire, le réseau a suffisamment de temps pour le retirer de sorte que lorsque l'importation dynamique est appelée, il peut simplement toucher l'argent pour obtenir ce qui a déjà été préchargé. C'est quelque chose avec lequel j'ai travaillé un peu ici et là, et c'est difficile à faire dans toutes les situations. Comme par exemple, vous ne pouvez pas le faire de manière fiable tout le temps en survol car certains appareils n'ont pas de pointeur fin. Ils ont… ils sont… ce sont des entrées de robinet, n'est-ce pas ? Ainsi, un survol se produit à un moment différent que si vous aviez un pointeur fin, par exemple.

Drew: One aspect of responsible JavaScript use is thinking about how we consume our users, available resources, be that sort of battery life or data allowance, if they're on a data plan. Are there techniques that we can lean on here to, to help us think about those things?

Jeremy: Yeah. So currently, or at least historically from the last… I don't know exactly when this feature shipped but Chrome for Android and there used to be a Chrome extension thing for this called Save Data. And what you would do is if in your settings, in Chrome for Android you would say, “Reduce data usage.” I forget exactly what the label is on the check box, but you check it, you turn it on and what that does is it sends this signal as a request header. And it's a request header that's called save data and it only has one token and it's just on. Because if it's off, the header just doesn't get sent. And you can… on the backend, at least, you can look at this header and you can decided, “Well, do I really need to send the styles and the JavaScript for this carousel or can I render this differently?

Jeremy: Or maybe you start thinking about stuff outside of JavaScript where maybe you send lower quality images. There's a lot of opportunities there to reduce data usage. This is evolving though, save data is still around. And I think it will be for the foreseeable future, but now we're converging on a media query called prefers reduced data. So we have stuff like prefers reduced motion, prefers color scheme, it's sort of in that vein where I anticipate that these will be operating system level settings that we can make to say, “I really want websites or apps to use less data with this signal.” And you can match it on the client side, with the prefers reduced data media query using match media in JavaScript.

Jeremy: So then you can use that in JavaScript to say, “maybe this functionality isn't the most important thing. Maybe we don't really need to load this associated video embed if the text serves the purpose.” That type of thing, but it also converges with the save data header, at least this is what I observed is when I turn on the save data feature in Chrome for Android, the prefers reduce dat: reduced media query matches, but it also sends save data so you can still act on this on the back end or the front end.

Drew: That's nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that's sent over the wire.

Jeremy: Right. Or you might say… you might pull APIs less frequently in JavaScript, that type of thing. It's kind of a hack need phrase, but it really is limited to your imagination. There's a huge space where I think that concept can be applied to deliver better user experiences. And I've used it with a client of mine in Wisconsin. In rural Wisconsin it's just like… it is an internet dead zone. Like it's so difficult to… I don't know how people cope with how slow it is. Maybe it's just because of my data plan and I might be roaming or whatever, but I've used this to some effect to say, “You know, maybe they don't need this carousel.” Somebody who's just kind of out there in the sticks who… there's a lot of farmland in Wisconsin, but there's also like a lot of forests and somebody might need some work done in logging, right? It's a logging company. And so maybe all of these images, aren't really crucial to that user experience. And they really just want to get to… the phone number or whatever it is, and they want to get to it as fast as possible.

Drew: One thing many of us do is write JavaScript in sort of new shiny versions of VS script and TypeScript sometimes, and then use build tools to transfer that down to older syntax for browsers that encounter out in the wild. In some ways that feels like an excellent practice because we're building a code base with nice more modern clean code. In the case of TypeScript, perhaps more reliable code, less bugs. But are there consequences of doing this transpilation process that we might need to be aware of?

Jeremy: Anytime you take a new syntax and you have to transform it so that it's more broadly compatible, that's going to generally… I have not done this comprehensive audit of all features, but generally I've observed that, that results in more JavaScript. And that makes sense because for things like default parameters on functions, which are well supported by the way, and probably you can ship… I think you could probably just ship that on transpile and be fine, but it's a good example. When that gets transformed, it has to inject a lot of helper code in the function to look… to evaluate those defaults, right? So you get that equivalent functionality.

Jeremy: Now, JavaScript is evolving all the time and I think for the time being, we're going to be coping with transpilation costs. And it definitely does have an impact. When I worked with an e-com company, we were able to reduce several of their bundles for their pages, anywhere between 10%, maybe even 5%, in some cases, to sometimes 30 or 40% when we used a technique to transpile two sets of bundles, right? I talked about this at smashing comp. The name that got kind of got tacked on it was differential serving where you say, “I'm going to generate these transformed bundles for older browsers and serve it to them.” And I'll generate a different bundle for users on modern browsers or evergreen browsers that will be smaller because there will be less of that transpilation overhead. And when we use that, there was a measurable improvement in the user experience. And there were signals that that engagement was better when we did this. That said, differential serving is an interesting thing because IE11 is kind of now like fading. It's taking time, but it's fading.

Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don't quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.

Jeremy: In the case of the NHS or literally any government service, I would say that it's virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don't know where they're going to be accessing the web off of, right? The constraints we develop for are incredible, it's really, really hard. It's thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.

Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.

Jeremy: Yeah, for sure. This is sort of the more technical part of how you set up tool chains to do this, but… evaluating what your user base looks like is very important, because if a browser kind of falls out of a certain threshold of usage from significant to relatively insignificant, that might be the point at which you decide to evaluate, “Hey, maybe we need to bump things up in our browser's list configuration, so that we're transpiling bundles to be smaller since we don't need to ship those transforms anymore.” But it is kind of like another added step. And one of the approaches I talk about in the book is that you can write your JavaScript one in a couple ways.

Jeremy: You could decide that your style for using JavaScript will be to rely on older language constructs that are natively well supported. Like I think constant let are supported back to IE11. So it doesn't preclude you from using those types of things, but it allows you to ship less JavaScript. Whereas you… or you could say like the alternate approach might be that you are going to write JavaScript for newer browsers only, and accept that a segment of your users may not have functionality. But again, that depends on the purpose that your website is serving and whether or not it's crucial, right? Or infrastructure.

Drew: The web platform is moving on that at magnificent pace, it seems at the moment and there seem to be all sorts of things being added to CSS. For example, that offer capabilities that we previously have to lean on JavaScript for. It is one way to use JavaScript responsibly to just not use it and to lean on native browser features instead?

Jeremy: I think that also works for JavaScript itself where it makes sense to use an API directly rather than an abstraction of it. Definitely do that. But certainly in the case of HTML and CSS, there are things we can now do or will be able to do in CSS that we just don't need JavaScript for. So an example of this would be… what's the word for it? Truncation of content, right? That's something that we can do in CSS. Whereas I've been in situations or in projects where I've seen libraries or a library get downloaded that does that. And we don't necessarily need to really do that anymore because CSS can handle it.

Jeremy: Or we have access to these layout modes now where we don't really need. If we invest the time to learn these layout modes like grid, we don't really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what's great about that is with layout modes like CSS grid, if they're abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what's possible, I always like to point to Jen Simmons, her experimental layout lab homepage.

Jeremy: I don't know how you would achieve a layout like that if you abstracted it into its own sort of layout library. You almost have to use it… I would think more than almost, you would have to use CSS grid directly in order to accomplish something like that. And that is like zero JavaScript and it's incredible and it's really neat. And I think the web in general would benefit more if we leaned more heavily on CSS and other core web technologies, as much as we do on JavaScript, probably not possible, but one can dream.

Drew: So the book Responsible JavaScript is out now from a book apart. And I really like it, it's full of very practical information. It's very to the point, you know? There's not filler. It's not like reading a recipe online where you have to hear about a trip to Peru before you get to the nitty gritty. It's just like it's all straight in there and it's all very nicely written. Was it a challenge to put that set of information together?

Jeremy: I'll have to ask… if this is the case, but I Think Responsible JavaScript might be the longest book that A Book Apart has put out, but I would have to go and reach into the closet for my copy of a responsible responsive design to see if I beat out Scott Gel on that, because that was a bit of a book, an awesome book, by the way, it was challenging I'm… As your listeners can probably guess I'm sort of a naturally verbose person and, and, and recovering, trying to like be more succinct, but we really packed in as much as we could and kept it as straight to the point while still trying to retain some, some light lively pros. So it didn't like sound mechanical, but the result was that the manuscript is like 42,000 words. So it's a book, it's a chunk of words and we had a great time working on it. People at A Book Apart were fantastic and, and really setting up those guardrails so that we would be successful.

Drew: And it's very much a book that you can sort of dip into various parts. You don't need to read it cover to cover, to gain loads of helpful information. You can just sort of find the bit that's relevant to the problem that you're facing at the moment and dive in there. So I think that's really great about it. So I've been learning all about Responsible JavaScript. And what have you been learning about lately Jeremy?

Jeremy: Une sorte de chose que je fais depuis sa sortie est de jouer avec l'API de peinture CSS. J'aime beaucoup l'API de peinture. Je veux dire, ça a toujours existé en soi…. comme à sa manière, car comme le canevas, le contexte 2D a été une chose. Parce que c'est… pour ceux qui ne le savent pas, l'API CSS pain est un moyen d'intégrer un contexte de canevas 2D et de le paramétrer et de le contrôler avec CSS, ce qui ouvre de nombreuses possibilités vraiment intéressantes, comme vous pouvez animer des choses qui vous ne pouviez pas animer auparavant et ce genre de chose.

Jeremy : Et récemment, j'ai rafraîchi mon blog. C'est… Je suis un grand geek de Final Fantasy, comme Final Fantasy II que je viens de rejouer et donc, il y en a environ 15 et 16 sortent un jour, mais c'est une sorte de domaine rétro. J'ai donc utilisé l'API de peinture CSS pour générer un monde aléatoire en utilisant différentes tuiles. Il y a donc des rivières et des choses qui coulent à travers et des tuiles d'herbe et des arbres et ce genre de choses. Et en paramétrant cela comme si l'utilisateur visitait mon site Web en mode sombre… ce travail de peinture sera rendu comme s'il faisait nuit. Il y aura juste une sorte de superposition dessus et ce genre de chose.

Jeremy : Mais l'API de peinture est incroyable. Je dois remercier Tim Holman. Lui, je l'ai vu à la JSConf Australie et il a fait une conférence sur l'art génératif. C'était vraiment juste, ça m'a vraiment intéressé. Et puis Sam Richard, dans la CSSConf la veille, a parlé de l'API de peinture CSS, quand ces deux choses se sont réunies pour moi, c'était comme, "Wow, c'est tellement cool." Et donc j'ai fait une chose appelée Paintlets ! C'est un Paintlets.Herokuapp.com si vous visitez et Chrome et vous devez malheureusement le faire, car il n'est pas encore très bien pris en charge. Vous pouvez voir comme un tas d'œuvres d'art différentes, aléatoires, générées au hasard et… ouais, j'ai juste… c'est ce que j'ai fait, désolé. Longue histoire là-dessus.

Drew : Incroyable. Cela sonne bien.

Jérémy : Ouais. Ouais.

Drew : Si vous, cher auditeur, souhaitez en savoir plus sur Jeremy, vous pouvez le trouver sur Twitter où il est @malchata et trouver ses présentations d'écriture, ses vidéos et ses projets sur son site personnel, jeremy.codes, Responsible JavaScript est disponible dès maintenant sur A Réservez à part. Et vous pouvez trouver plus d'informations à ce sujet sur Responsiblejs.dev. Merci de m'avoir rejoint aujourd'hui Jeremy, avez-vous des mots d'adieu ?

Jeremy : Allez de l'avant et construisez pour le Web de la meilleure façon possible et essayez de garder l'utilisateur à l'esprit. C'est un peu mon mantra et j'espère que ce livre le fera un peu coller.