Fermer

novembre 30, 2021

Le Web estil mort ? — fracassant47 minutes de lecture



Résumé rapide ↬

Dans cet épisode, nous demandons si les changements apportés aux bonnes pratiques au cours de la dernière année ont eu un impact négatif sur le Web. Tout est-il en descente à partir d'ici ? Drew McLellan s'entretient avec l'expert Chris Ferdinandi pour le savoir.

Dans cet épisode, nous demandons si les changements apportés aux bonnes pratiques au cours de la dernière année ont eu un impact négatif sur le Web. Tout est-il en descente à partir d'ici ? Drew McLellan s'entretient avec l'expert Chris Ferdinandi pour le savoir.

Afficher les notes

Mise à jour hebdomadaire

Transcription

Photo de Chris FerdinandiDrew McLellan : Il est l'auteur du Vanilla JavaScript Pocket Guide série, créateur du programme de formation Vanilla JavaScript Academy et hôte du podcast Vanilla JavaScript. Nous lui avons parlé pour la dernière fois en juillet 2020où nous lui avons demandé si les meilleures pratiques modernes concernaient le Web. Nous savons donc qu'il est toujours un expert de Vanilla JS, mais saviez-vous qu'il est le seul responsable de l'absence de la Nouvelle-Zélande sur 50 % des cartes du monde ? Mes formidables amis, bienvenue à nouveau, Chris Ferdinandi. Salut Chris, comment vas-tu ?

Chris Ferdinandi : Oh, je défonce. Merci de m'avoir Drew. Chose intéressante. En fait, je m'assure que la Nouvelle-Zélande n'est pas sur les cartes car c'est probablement mon pays préféré dans le monde entier et je ne veux pas que trop de gens le sachent.

Drew : Vous voulez qu'il reste intact.[19659008]Chris : En effet.

Drew : Alors bienvenue dans le podcast. La dernière fois que nous avons parlé, nous avons posé cette question de savoir si les meilleures pratiques modernes, l'utilisation de frameworks réactifs et ce genre de choses étaient réellement mauvaises pour le progrès du Web. Et je ne sais pas s'il s'agissait d'un épisode controversé ou s'il a simplement touché une corde sensible chez de nombreux auditeurs, mais cette conversation a été l'un des épisodes les plus partagés et les plus écoutés que nous ayons diffusés.

Chris : Oh, c'est génial.

Drew : Cela fait en fait plus d'un an maintenant, 15 mois depuis que nous avons enregistré cela, ce qui, au rythme où se déplace le Web, est littéralement une éternité. Alors je voulais demander, est-ce que quelque chose a changé ? Le web est-il toujours en déclin terminal ? L'aiguille s'est-elle déplacée du tout ?

Chris : Oui, pas mal de choses ont changé, pas mal de choses. Donc je pense que c'est tellement bizarre. La technologie Web évolue si rapidement, mais le Web lui-même a tendance à évoluer un peu plus lentement en termes de tendances et d'habitudes des développeurs. Et donc vous voyez ces arcs légèrement plus longs où vous aurez un tas de technologies qui s'accumuleront autour d'une approche, puis cela commencera lentement à basculer dans l'autre sens, puis à changer d'un seul coup. Et donc la dernière fois que nous avons parlé, je pense que l'un des grands types de… Eh bien, j'avais deux grands points liés au Web moderne. Le premier était que nous utilisons de nombreux outils qui facilitent la tâche des développeurs, mais nous utilisons ces outils aux dépens de l'utilisateur. Nous lançons donc une tonne de JS côté client aux gens, et cela introduit une tonne de problèmes d'agilité et de performances. Cela n'améliore pas nécessairement l'expérience du développeur autant que je pense que les gens le pensent. Ils le font pour certaines personnes. Et je pense que pour un autre segment des professionnels du front-end, cela peut en fait aggraver les choses. Mais ce que je commence à voir se produire maintenant, et l'une des choses que j'aimerais approfondir un peu plus, c'est que je pense que nous voyons un nouveau, c'est presque comme une deuxième génération d'outils qui prend beaucoup de temps le développeur bénéficie de ces frameworks côté client et supprime les effets punitifs que nous imposons à nos utilisateurs en conséquence. Il s'agit donc de prendre ces mêmes concepts et outils et de les emballer un peu différemment d'une manière qui est en fait meilleure pour le front-end. l'idée que le développement moderne a brisé le Web, mais il commence aussi à le réparer. Et donc nous pouvons certainement creuser cela sous différents angles, selon l'endroit où vous souhaitez mener cette conversation.

Drew : Bien sûr. Quel genre de choses avez-vous vues au cours de la dernière année qui se démarquent vraiment de ce point de vue ?

Chris : Oui, donc les deux plus grandes tendances que j'ai remarquées sont la montée en puissance des microframeworks. Donc, là où nous avons vu beaucoup de très grandes bibliothèques globales pendant un certain temps, React, Vue avant cet angle, qui n'est qu'une bête énorme à ce stade, nous avons commencé à voir des bibliothèques plus petites qui font la même chose prendre tout leur sens. Ainsi, par exemple, je pense que le roi de cette colline est probablement Preact, qui est une alternative de trois kilo-octets à React qui utilise la même API, envoie beaucoup moins de code et exécute en fait des ordres de grandeur plus rapidement sur les mises à jour sûres que React. Donc, vous avez des choses comme ça.

Chris: Pendant un moment, vous aviez… Eh bien, c'est toujours là, mais Alpine JS, qui a été inspiré par VJS et qui a ensuite inspiré Evan You qui a construit Vue pour sortir Petite Vue, qui est un sous-ensemble de 5,5 kilo-octets de Vue optimisé autour de l'amélioration progressive. Ce sont donc toujours des bibliothèques côté client, mais l'intention derrière elles est qu'elles livrent moins de code, incluent moins d'abstractions et fonctionnent finalement plus rapidement et mettent moins de ce coût sur l'utilisateur frontal. C'est donc un angle. Et donc celui qui a lancé toute cette tendance a été ressenti par Rich Harris, qui reprend l'idée de la réactivité basée sur l'état. Mais au lieu que ce soit quelque chose qui s'exécute en temps réel dans le client, vous créez votre code avec le même modèle général que vous pourriez avec React ou Vue, puis vous exécutez un outil de construction qui compile tout cela en HTML simple et vanille JavaScript, et c'est ce qui est envoyé au navigateur. Et donc vous avez supprimé presque toutes les abstractions dans le client et vous fournissez quelque chose qui est bien plus proche de ce que vous pourriez écrire à la main avec la manipulation DOM à l'ancienne, mais avec la commodité pour les développeurs de l'IE basée sur l'état. C'était donc vraiment intéressant.

Chris : Plus récemment, il y a un nouvel outil appelé ASTRO qui s'appuie sur ce que Rich a fait avec Svelt, et vous permet également d'extraire des composants de vos bibliothèques préférées afin que vous puissiez mélanger et assortir Vue , React, FELT, Vanilla, JavaScript, le tout dans un seul package, compilez le tout dans Vanilla JavaScript et expédiez des ordres de grandeur, moins de code sans les abstractions. Et ainsi, il fonctionnerait également beaucoup plus rapidement dans le navigateur. Et ce sont, je pense pour moi, vraiment les deux grandes choses qui sont comme se tenir sur les épaules de géants et produire un front-end qui, espérons-le, commencera à être un peu plus rapide. Les compilateurs en particulier sont intéressants car ils nous éloignent autant que possible du rendu HTML dans le navigateur. Vous restituez toujours votre code HTML ou vous le créez toujours avec JavaScript si vous le souhaitez, mais le résultat obtenu est plus de HTML statique et moins de JavaScript, ce qui est toujours une bonne chose.

Drew : Pensez-vous que c'est celui de l'écosystème réponse à cette insatisfaction discrète des développeurs sur le poids des frameworks modernes ? Est-ce juste un soulèvement naturel ?

Chris : Oui, c'est vrai. Bien que pour être honnête, je ne sais pas exactement à quel point cela a été motivé par… Eh bien, il y a certainement des développeurs soucieux de la performance qui ont exprimé très clairement à quel point ces outils sont mauvais pour l'utilisateur. Je ne sais pas si c'est nécessairement représentatif de la population générale. Je veux dire, certainement un sous-ensemble étant donné la dernière fois que nous avons parlé de cet épisode, mais je pense que l'une des choses qu'aucun de ces outils pour moi n'arrive à atteindre est… Ou la chose qui me dérange le plus par le moderne Web que je ne pense pas que ces outils abordent, c'est que j'ai personnellement l'impression que le processus de développement en général est trop compliqué. L'expérience des développeurs est en fait meilleure avec ces outils, mais je pense que pour beaucoup de développeurs dans un environnement d'équipe, cela peut l'être. Pour moi, en tant que développeur en grande partie solo, je trouve que ces outils posent plus de problèmes qu'ils n'en valent la peine, mais je sais que beaucoup de gens ne sont pas d'accord avec moi là-bas, donc je ne veux pas rejeter cela comme invalide. Si vous trouvez ces outils très utiles, mais oui, je pense que c'est peut-être un retour de pendule naturel dans l'autre sens. pensez cependant qu'il existe presque un cycle naturel dans le Web où vous commencez à utiliser beaucoup de JavaScript pour résoudre des problèmes à mesure que le Web et ses capacités se développent. Et finalement, ces bibliothèques JavaScript sont absorbées par la plate-forme elle-même, mais c'est un processus beaucoup plus lent que la création d'une nouvelle bibliothèque JavaScript, car ce sont des processus standard et leur importance. Nous avons donc vu la même chose se produire avec jQuery, à droite, où la quantité de JavaScript utilisée sur le Web a augmenté avec les plugins jQuery et jQuery. sont vraiment intelligents et nous avons commencé à avoir des façons natives de le faire. Et puis il y a eu ce très long et lent ralentissement de l'abandon de jQuery. Donc, je pense que ces bibliothèques, autant qu'elles ont fait beaucoup de… Ce sera un peu controversé ici et disons qu'elles ont fait beaucoup de dégâts au Web. Ils ont également joué un rôle important en ouvrant le chemin des vaches pour ce à quoi les API natives pourraient ressembler. Je ne veux donc pas les rejeter complètement comme terribles.

Drew : Il est intéressant que vous ayez mentionné ASTRO juste un peu plus tôt. J'ai en fait enregistré une interview avec Matthew Phillips. Je ne sais pas s'il sort avant ou après celui-ci. Il est l'un des principaux développeurs d'ASTRO. Et c'est certainement une approche très créative et intéressante du problème. Je me demande quand vous dites combien c'est. Nous avons créé un ensemble de problèmes pour nous-mêmes et maintenant nous avons créé une nouvelle solution, qui corrige ces problèmes et nous donne quelque chose d'encore mieux. Mais empilons-nous simplement les briques les unes sur les autres et nous retrouvons-nous toujours avec une tour très bancale à cause de cela ? Sommes-nous simplement sur la mauvaise voie ?

Chris : Cela dépend. Alors moi, alors que les cheveux sur ma tête ont commencé à disparaître et que ma barbe est devenue plus blanche, j'ai commencé à parler dans moins d'absolus que je ne le faisais. Et donc il y a cinq ans, j'aurais dit : « Absolument oui. Je ne veux pas diminuer la valeur de ces outils dans un environnement d'équipe. Et l'autre chose, je pense honnêtement que beaucoup de bibliothèques ont vraiment le potentiel pour au moins corriger les problèmes dans l'intervalle, ce sont les problèmes d'accessibilité avec le Web autour des composants complexes de l'interface utilisateur. Donc, en bref, si je devais donner une seule phrase, oui, je pense qu'à bien des égards, nous créons un château de cartes vraiment délicat qui s'effondre très facilement. Et je pense que l'une des choses les plus intéressantes à propos de l'utilisation principalement ou presque entièrement d'une plate-forme native pour créer pour le Web, donc il suffit de créer un code HTML, CSS et JavaScript, vous ne pouvez pas toucher à ce code pendant cinq ans et y revenir et vous ne le faites pas. Vous n'avez aucune dépendance à mettre à jour. Vous n'avez aucun outil de construction à exécuter pour recommencer à travailler avec. Cela fonctionne. Et c'est vraiment génial.

Chris: Mais je pense que ce que je vois avec les bibliothèques, c'est que beaucoup d'entre elles entrent en création pour combler les lacunes dans ce que la plate-forme peut faire. Et ce que j'ai remarqué, c'est qu'après le rattrapage de la plate-forme, les bibliothèques restent très longtemps. Et donc la chose que j'essaie toujours de faire est d'être un peu réfléchi sur ce que j'ajoute aux choses que je construis, car c'est vraiment facile d'ajouter des choses et vraiment difficile de les enlever une fois qu'elles sont là. Et juste, je pense que pour fonder ces concepts abstraits enivrants, je parle pendant une seconde, chaque année, l'objectif du Web, le cabinet de conseil en accessibilité Web effectue une enquête sur le million de sites les plus importants sur le Web. Et ils exécutent un audit, juste des audits automatisés. Ils ne font pas une inspection détaillée de tous ces sites. Alors remplissez simplement cela, comme des tâches de robot et un ramassage. Et historiquement, l'une des choses qu'ils ont toujours trouvées est que les sites qui utilisent des bibliothèques de rendu d'interface utilisateur ont plus de problèmes d'accessibilité que les sites qui n'en ont pas.

Chris : Cette année, ils ont trouvé la même tendance à une exception près. Les sites qui utilisent React ont en fait moins de problèmes d'accessibilité que les sites qui ne le font pas. Et c'est une tendance notable ou un écart notable, plutôt par rapport à l'année précédente, lorsque les sites React avaient plus de problèmes d'accessibilité. composants accessibles, routage accessible, des choses de cette nature. Et pour les composants complexes, des choses comme les onglets et les widgets de divulgation, et les curseurs et des choses comme ça, il est vraiment difficile de les rendre accessibles avec seulement HTML et Vanilla JavaScript. Essayer de garder une trace des attributs ARIA que vous devez ajouter, quels éléments et comment les modifier en fonction de différents comportements et comment déplacer le focus et annoncer différentes choses est vraiment complexe. Et je pense que ces bibliothèques autant qu'elles peuvent être un château de cartes très délicat, j'y vois un énorme potentiel pour combler ces lacunes. Là où j'aimerais finalement finir, c'est dans un endroit où la plate-forme, le Web, les navigateurs offrent des composants natifs qui font ces choses pour que vous n'ayez pas besoin des bibliothèques. Et je pense que les détails et les éléments de résumé fournissent un très bon modèle de ce à quoi cela pourrait ressembler. un élément HTML que vous enveloppez autour d'un contenu, puis à l'intérieur de celui-ci vous imbriquez un élément de résumé avec comme une petite description de ce qu'il y a dans ce contenu. Et par défaut, cet élément sera un morceau de contenu réduit. Et lorsque vous cliquez sur le contenu du résumé, il se développe, puis lorsque vous cliquez à nouveau dessus, il se réduit et affiche une petite flèche lorsqu'il est ouvert ou fermé pour indiquer ce qui se passe ici. Il est accessible hors de la boîte. Si le navigateur ne le prend pas en charge, il affiche tout le contenu par défaut. Donc, il est juste automatiquement amélioré progressivement. Vous n'avez pas besoin de faire quoi que ce soit de spécial là-bas.

Chris: Il peut être stylisé avec CSS. Vous pouvez même modifier les icônes qui s'affichent lorsqu'elles sont développées et réduites, simplement avec CSS. Vous n'avez pas besoin d'écrire de JS pour cela, mais si vous souhaitez étendre le comportement d'une manière ou d'une autre, vous le pouvez, car il expose également un événement JavaScript qui se déclenche chaque fois qu'il est ouvert ou fermé. Et j'aimerais voir plus de choses comme ça pour les onglets, pour les curseurs d'images, les carrousels ou les galeries de photos, qui… Nous avons tellement de composants interactifs différents maintenant sur le Web qui peuvent ou non toujours être appropriés, mais ils sont dans les conceptions et les gens les construisent et avoir un moyen de faire ces choses sans avoir à chercher comment les rendre accessibles ou s'appuyer sur une bibliothèque de 30 kilo-octets serait génial.

Chris: Et donc pour moi, c'est, je pense, la prochaine évolution du web. C'est là que je veux vraiment voir les choses commencer. Et je pense que c'est le grand besoin auquel ces bibliothèques répondent aujourd'hui en plus d'autres choses comme la modification de l'interface utilisateur en fonction des changements d'état et des cas d'utilisation intéressants comme celui-ci.

Drew : Ouais. Les navigateurs modernes sont tellement capables maintenant et ils se mettent automatiquement à jour et ils incluent de nombreuses fonctionnalités nativement sur lesquelles nous comptions auparavant, sur de gros frameworks et des outils de construction pour. L'exigence d'un processus de build pour déployer un projet est-elle un drapeau rouge en 2021 ? HTML, CSS et JS devraient-ils simplement être déployables tels quels ?

Chris : Donc, techniquement, ils le sont. Je ne pense pas que pour la plupart des processus de construction réels ou pour la plupart des applications, des sites ou des entreprises, cela soit nécessairement réaliste aujourd'hui. Je ne sais pas si j'appellerais ça un drapeau rouge autant qu'un résigné, j'aimerais que ce ne soit pas comme ça, mais je comprends pourquoi c'est le cas, pour moi. Même pour moi, mon site compte maintenant plusieurs milliers de pages. Je pense que j'ai jusqu'à trois ou quatre mille pages et il n'y a aucun moyen que je code tout cela à la main. J'utilise un générateur de site statique et je pense que des outils comme celui-ci peuvent être vraiment géniaux. Et donc j'aime garder le mien aussi léger que possible, mais je pense que créer des outils qui mettent plus de temps d'exécution sur vous, le développeur, et vous permettent ainsi d'envoyer moins au navigateur est une bonne chose, d'autant plus que les choses que nous construire deviennent plus complexes. Donc, je ne sais pas si je dirais nécessairement que c'est juste par défaut un drapeau rouge. Je pense que cela dépend beaucoup de la façon dont vous l'utilisez. Si vous devez exécuter une version pour expédier un site marketing ou un site de brochures d'une ou deux pages, oui, c'est un drapeau rouge. Mais si vous créez des applications complexes et que celles-ci vous permettent de créer d'une manière plus sensée pour vous, puis d'envoyer moins de choses au navigateur, ce n'est pas une mauvaise chose. Et c'est pourquoi je trouve des outils comme ASTRO vraiment, vraiment intéressants car il y a toujours une étape de construction là-bas, mais c'est une étape de construction au service d'une meilleure expérience utilisateur final.

Drew : Oui. Il transfère tout ce calcul sur le serveur pour créer une heure ou une heure pré-différée et non l'heure de la demande de page.

Chris: Ouais. Et donc pour moi, je divise presque les étapes de construction en… Comme pour moi, l'étalon-or est que si je peux l'expédier sans aucune étape de construction, c'est génial. Mais même pour moi, le gars du jazz vanille, ce n'est pas comme ça que je fais les choses à cent pour cent aujourd'hui. Et donc, je pense que la prochaine étape est celle des compilateurs qui réduisent votre code à autant de HTML et de vieux JavaScript que possible, par rapport à ceux qui créent encore plus de JavaScript, comme ceux qui prennent un tas de petits fichiers et font un fichier encore plus gros. Donc plus du premier, moins du dernier si possible est toujours une bonne chose, mais pas toujours possible. à une approche Vanilla JavaScript, ne pas avoir un million de dépendances à mettre à jour tout le temps, mais je suppose que l'un des avantages de certains de ces plus gros frameworks est qu'ils dictent parfois et parfois facilitent une méthode de travail uniforme, ce qui est vraiment important avec des équipes plus grandes. Y a-t-il un risque qu'un projet déraille un peu sans ces normes et procédures en place qu'un cadre impose ?

Chris : Oui. Oui. Je pense que c'est juste. J'avais l'habitude de minimiser, je pense, l'importance de cela pendant un certain temps. Et je pense que c'est valable. C'est un avantage certain de ces outils. Je pense que le petit contre-argument ici est peut-être que si vous Google, "Comment faire X avec React", vous obtiendrez une demi-douzaine d'approches différentes pour faire cette chose. Donc, il y a des conventions, mais il n'y a pas forcément de dur et de rapide, comme si vous ne le faites pas de cette façon, tout enfreint des règles. L'un des attraits de ces outils est qu'ils ont beaucoup de flexibilité. Certes, ils appliquent des approches plus standard que de simples champs verts, ce que font les choses natives du navigateur. Et donc je pense qu'il y a peut-être un peu d'équilibre, même si vous n'avez pas un chef d'équipe solide qui pilote les normes de code internes. approche avant. Ce n'est donc pas comme si ces outils vous le donnaient automatiquement, mais ils vous donnent certainement des directives, peut-être des rails qui vous poussent dans la bonne direction. Et je sais que certaines personnes en ont besoin. Si c'est quelque chose dont vous avez besoin, c'est là que j'aime vraiment que nous voyions plus de ces petites bibliothèques qui utilisent les mêmes conventions, comme Petite Vue ou Preact et des compilateurs qui aussi… Comme FELT a des rails très rigides autour, certainement plus que ce que vous verriez avec ASTRO et donc si vous en avez vraiment besoin, je pense que vous avez des options qui ne punissent pas les utilisateurs pour ce besoin autant que ce que nous faisions il y a quelques années.

Drew : Dans le travail que je fais, nous utilisons Vue et les composants de fichier unique de Vue sont un cas vraiment convaincant en ce sens que nous avons des ingénieurs qui écrivent du code front-end, qui ne sont pas nécessairement des spécialistes front-end qui disent voici un moyen pour créer un squelette de composant à fichier unique. Votre modèle va ici, votre script Java va ici, votre CSS va ici. Et tout naturellement à la suite de cela, nous nous retrouvons avec une base de code très cohérente, même si elle a été créée par un ensemble de personnes très diverses. Et donc, les conventions comme celle-là peuvent vraiment avoir un grand avantage pour les équipes qui ne vont pas nécessairement toutes dans la même direction parce que le département d'ingénierie est si énorme ou autre.

Chris : Oui, bien sûr. Où je pense que vous avez parfois des ennuis avec ça… Et je suis d'accord. J'aime absolument la possibilité de rendre une base de code cohérente avec un groupe de personnes différentes qui y travaillent est vraiment, vraiment importante parce que les personnes qui écrivent le code aujourd'hui ne seront pas nécessairement celles qui le maintiendront plus tard. Et cela peut vite devenir salissant. Le revers de la médaille est que si vous êtes quelqu'un qui n'est pas à l'aise ou qui n'est pas très à l'aise avec JavaScript, une grande partie de l'ensemble d'outils modernes est vraiment orienté vers JavaScript. Et il y a beaucoup de personnes dans les équipes qui se spécialisent principalement en HTML ou CSS ou en accessibilité. Et pour eux, JavaScript n'est pas une compétence de base et je ne pense pas qu'il soit juste de s'attendre à ce qu'il le soit. Et tout comme vous ne vous attendez pas à ce que tous vos développeurs JavaScript soient des experts en CSS.

Chris: Et cela peut donc rendre leur travail beaucoup plus difficile. Et c'est pour moi, toujours ce genre d'échange avec ces outils, c'est qu'ils peuvent faire des choses vraiment géniales, mais ils peuvent aussi garder beaucoup de gens hors du processus. Et j'ai l'impression que cet équilibre est différent d'une équipe à l'autre, mais pour moi, l'un des grands arguments pour s'appuyer davantage sur des éléments natifs du navigateur ou pour abandonner autant de ces dépendances que possible est que vous ouvrez beaucoup votre processus de développement des personnes qui ne sont pas aussi lourdes en JavaScript.

Drew : Il y a toujours ce courant sous-jacent au sein de l'industrie qui suggère qu'il existe la façon actuelle de faire les choses, la plus récente et la façon obsolète. Et si vous n'êtes pas à jour avec les dernières nouveautés, vous n'êtes en quelque sorte pas un aussi bon ingénieur ou quoi que ce soit. tout cela est Vanilla JS comme une approche à feuilles persistantes qui se démarque de ces techniques.

Chris: Ouais. Oui. Il y a quelques fils dans ce que vous venez de mentionner, Drew. Donc, l'un d'eux est, si vous comprenez les principes fondamentaux du Web, j'ai trouvé qu'il est beaucoup plus facile d'aimer une abeille, il suffit de passer d'une technologie différente à une technologie différente et de la comprendre suffisamment pour aimer… Même si vous n'utilisez pas le, regardez-le et dites : « D'accord, je peux voir certains avantages à cela ou non, et évaluer si c'est le bon choix. » Si vous avez besoin de vous plonger dans une nouvelle technologie en fonction des besoins des clients ou de l'évolution de la direction de l'entreprise, vous le pouvez. Je pense que c'est beaucoup plus difficile à faire si vous ne connaissez qu'une bibliothèque et que vous n'avez appris le Web que dans le contexte de cette bibliothèque. de jQuery, puis j'ai soutenu mon chemin dans Vanilla JavaScript, puis je suis passé à un tas d'autres choses également. Plus je pense à la façon dont ce processus s'est déroulé pour moi, je pense que j'ai pu le faire aussi facilement que je l'ai fait en grande partie parce qu'au moment où j'ai fait ce saut, ES5 était sorti et avait pris un tas de ses conventions de jQuery. Et donc il y avait beaucoup de ces vrais un pour une carte. Carte mentale des choses que je pouvais faire. Je ne sais pas si nous en sommes encore là avec certaines des bibliothèques d'interface utilisateur basées sur l'état, mais nous nous dirigeons définitivement dans cette direction et je pense que c'est formidable. Mais l'autre chose ici, il y a cette vraie pression, comme vous l'avez mentionné dans l'industrie pour toujours se tenir au courant de toutes ces nouvelles technologies, en grande partie parce que les personnes qui développent ces technologies et les personnes qui travaillent dans les grandes entreprises sont celles qui qui sont invités à prendre la parole lors de conférences et à parler de toutes les choses intéressantes qu'ils ont construites.

Chris: Mais la réalité est qu'une grande partie de notre site Web, comme je dirais la majorité de notre sur une vieille technologie ennuyeuse qui n'a pas été mise à jour depuis un certain temps, ou qui a été mise à jour, mais dans un simple processus de correctif. De nombreuses applications très importantes s'exécutent sur Python ou PHP, ou en tant que backend avec juste une pincée de HTML, CSS et JavaScript légers. jQuery est toujours utilisé sur beaucoup de choses importantes à l'exclusion d'autres bibliothèques. Et je n'en ai pas toujours l'impression parce que j'ai l'impression que la plupart des descriptions de poste que vous voyez parlent de vouloir de l'expérience dans React ou Vue ou quelque chose du genre de nos jours. Mais mon expérience de travail dans de plus grandes entreprises technologiques ou des entreprises de produits plus anciennes, est qu'il y a beaucoup d'emplois à trouver en travaillant sur une ancienne technologie stable. Et souvent, ce n'est pas toujours le travail le plus excitant, mais souvent ce sont des emplois qui paient bien et qui ont de très bonnes heures et beaucoup d'équilibre travail-vie personnelle d'une manière que vous n'obtiendrez pas de manière vraiment excitante. entreprise de technologie travaillant sur les dernières nouveautés.

Chris : Et il y a donc ces compromis là-bas. Ce n'est pas toujours une mauvaise chose. Oui, je pense que c'est l'un de ceux-là, comme le nouveau, le nouveau, le nouveau est potentiellement une minorité très bruyante du Web qui n'est pas représentative du Web dans son ensemble.

Drew : Et il semble y avoir avec cette idée que vous devriez adopter tout ce qui est nouveau et immédiatement jeter tout ce que vous avez utilisé au cours des 12 derniers mois. Il y a aussi cette idée que vous devriez concevoir des choses qui sont de niveau d'ingénierie d'entreprise, mais vous devriez faire chaque petit projet de la même manière qu'une énorme entreprise avec 400 ingénieurs construit des choses. Et ces deux idées ne sont en fait pas compatibles du tout. Ce sont les grandes entreprises avec toutes ces centaines d'ingénieurs qui utilisent l'ancienne technologie croustillante, parce que c'est fiable et qu'elles ont beaucoup trop d'élan. Ils détestent le laisser tomber et ramasser quelque chose de nouveau. Donc, ces deux idées sont un conflit indirect, je pense.

Chris: Ouais. C'est marrant. Vous voyez toujours le tout comme « Eh bien, est-ce que ça va évoluer, est-ce que ça va évoluer », genre de chose tout le temps. Et en a-t-il besoin ? Construisez-vous des choses pour un public de la taille de Facebook ? Je suis sûr que vous y arriverez à… Eh bien, vous y arriverez, mais ce serait merveilleux si vous y arriviez à un moment donné, mais comme, si vous n'êtes pas là aujourd'hui, ce n'est peut-être pas nécessairement ce dont vous avez besoin pour commencer. Comme si ce ne sont pas vos besoins aujourd'hui. Vous effectuez une pré-ingénierie pour un problème que vous n'avez pas au détriment de certains problèmes que vous faites. faire des choses, c'est une bonne idée, ou c'est une bonne idée pour tout le monde. Et ce n'est pas forcément le cas. Ces entreprises font beaucoup de choses correctement. Mais ils font aussi beaucoup de choses mal et ils le font de cette façon à cause des compromis techniques qu'ils ont dû faire en raison de la façon dont leurs équipes sont structurées ou des problèmes internes très spécifiques qu'ils ont eus au moment où ils ont pris cette décision ou parce que quelque part, un cadre était très attaché à quelque chose et l'a fait faire par l'équipe interne, même si ce n'était pas nécessairement le mieux à l'époque. Et puis ces choses restent. Et donc, oui, je pense que l'une des choses les plus importantes que je vois se produire dans notre industrie à notre propre détriment est de regarder ces quelques très grandes entreprises technologiques visibles et de penser: "S'ils le font de cette façon, je dois le faire aussi", ou « C'est le bon choix pour tout le monde. »

Chris : C'est si vieux, comme si personne n'avait été licencié pour avoir embauché le genre de chose d'IBM, mais appliqué à si c'est assez bon pour Google ou si c'est assez bon pour Twitter ou peu importe, alors oui. Je suis d'accord. Je pense que nous faisons beaucoup de cela et peut-être que nous ne devrions pas.

Drew : J'ai demandé sur Twitter plus tôt à ce sujet ce qui frustrait les gens au sujet des meilleures pratiques de développement Web modernes et d'après les réponses que j'ai reçues, il y a certainement un beaucoup d'insatisfaction face à l'état actuel des choses. Une tendance qui a pris de l'ampleur ces dernières années est comme l'approche Jamstack des chantiers de construction. Et il semble en surface que cela ne revienne qu'aux applications côté client et à rien de complexe sur le serveur, on dirait que cela revient à l'essentiel, mais est-ce que c'est le cas ? Est-ce ou masque-t-il simplement la complexité de la pile d'une manière différente ?

Chris : Cela dépend. Je suis un peu partial ici parce que j'aime le Jamstack personnellement, mais j'ai aussi vu… Bon, je ne devrais pas dire que j'ai vu. Je pense que ce que j'essaie de dire ici, c'est que Jamstack est un terme qui peut s'appliquer à un large éventail d'approches jusqu'à et y compris une très grande application JavaScript à page unique de deux mégaoctets qui n'a pas de rendu côté serveur à une extrémité. Et puis à l'autre extrémité, des fichiers HTML plats qui n'utilisent absolument aucun JavaScript, chargent instantanément votre navigateur et arrivent simplement à être expédiés à partir d'un CDN ou quelque chose comme ça. Et techniquement parlant, les deux sont Jamstack et ne sont pas du HTML plat. Ainsi, Jamstack n'est pas intrinsèquement meilleur que le rendu du serveur, mais dans de nombreux cas, cela peut l'être. balisage, et ils ont depuis changé l'orthographe et changé un peu la définition. Et cela englobe vraiment une approche de la construction du Web qui ne repose pas sur le rendu côté serveur. Donc, tout ce que vous servez, vous l'avez déjà compilé et assemblé et c'est ce qui est livré dans le navigateur. Et s'il y a un autre traitement ou script qui se produit, cela se produit dans le client. Ce n'est pas obligatoire, mais c'est souvent le cas. Et donc ce que je pense est génial à propos de Jamstack s'il est fait d'une certaine manière, c'est qu'il peut considérablement améliorer les performances des choses que vous construisez. of JavaScript to the client and having all the stuff that you used to do on the server happen in the browser instead, because the browser will always be less efficient at all that scripting than the server would be, but where this really comes to shine, and so I'll use like WordPress as an example. I love WordPress. I built my career on WordPress. It’s the reason why I was able to become a developer, but every time someone visits a WordPress site out of the box, it has to make a call to a database, grabs some content, mash it into some templates, generate HTML and ship that back to the browser.

Chris: And there are some plugins you can use to do some of that ahead of time, but it is a very slow process, especially on a shared inexpensive web host. A Jamstack approach would be to have that HTML file already built, and you cut… You don’t cut the server out, but you cut all of that server processing completely out. So the HTML file already exists and gets shipped. And in an ideal world, you would even push that out to a bunch of CDNs so it sits as close to the person accessing it as possible. And what that can do is take a load time from a couple of seconds on an inexpensive host to less than half a second, because of how little computing time it takes to actually just request a file, get the file back and load it, if it’s mostly HTML.

Chris: And so, yeah, I really like rambling in long winded response to your question, Drew, but I think the answer is, if you’re using it with something like a static site generator, it can be amazingly more performant than some of the other things we’ve done in the past. And it allows you to get that same WordPress experience where I’m authoring content and I have some templates and I don’t have to hardcode HTML, but the performance is way better on one end.

Chris: And then on the other end, you could theoretically define a React app as Jamstack as well and it can be really slow and buggy and terrible. And so it depends. The other thing I’m seeing happen that’s really, really funny and interesting is we just keep reinventing PHP over and over and over again as an industry in various ways. So-

Drew: We still have PHP as well. It’s not gone.

Chris: Right? And yet PHP still exists and still works great. And so we’ve got… Like I remember when Next.js came out. There was all these kind of, “And here’s all the things you can do with it.” And I was like, “Oh, that’s like PHP,” but a decade later. And then my friend Zach Leatherman who built Eleventy which is an amazing static site generator has been experimenting with some compiling in real time on the server stuff with Eleventy.

Chris: So it’s like just in time Jamstack and he even jokes that he’s essentially recreated PHP in node and JavaScript, but it’s slightly different because there’s like a serverless build that happens that then instant deploys it to a CDN and it’s like a little weird. So it’s still a house of cards. You’re just shifting around where those cards live and who’s responsible for them, but yeah, yeah. Jamstack is cool. Jamstack is problematic. It’s also not. It’s awesome. It’s potentially overused both as a term and a technology. Oui. It’s a whole lot of things and I love it in the same way that I love PHP. It’s great and it has problems and every technology and approach is a series of trade-offs.

Drew: Do you think we’re going through some industrial revolution in web development? What used to be skilled painstaking work from individual arts and is now high volume, high production factory output. All the machines have been brought in and the frameworks and the build tools and have we lost that hand rolled touch?

Chris: Well, I mean, yes, to an extent, but we don’t have to. I mean, that analogy is appropriate in many ways, because a lot of the ways we do things today produce… I like to call them front end pollution in the over-reliance on JavaScript, but also in the very literal sense. We have so many heavy build processes now that they generate more actual literal pollution as well. But I think the counter argument here is with a… I will use farming, right? You could go out and hand mill your wheat with a scyther. I forget what you call those. The crescent shaped tool that you use to chop your wheat, or you could use an oxen drawn machine that will pull that off, or you can use a big tractor.

Chris: And I think there’s a clear argument that at some point, factory farming is this big industrial complex that has lost a little bit of that close to the Earth touch, but I don’t think I necessarily need my farmers to be hand chopping their wheat. That is wildly inefficient for very little benefit. And there’s probably a balance there. And I feel the same thing with what we’re doing here. Some of these tools allow us to do more artisan work faster and more efficiently. And sometimes they just turn it into generating a bunch of garbage and turn it out as fast as possible. And there’s not necessarily a clear cut delineation for where that crossover happens. I think it’s a little fuzzy and gray and like a you know it when you see it kind of thing. Sometimes not always. But yeah, I think it’s a little bit of both. The commercialization of the web is both a really terrible thing and also a really great thing that has allowed folks like myself to have a living working on the platform that I love full time.

Chris: That’s awesome. But it’s also produced a lot of problems and I think that’s true for any technology. There’s good and bad that comes with all of it.

Drew: And maybe sometimes we’re just producing really fat pigs.

Chris: Yeah. I’ve gotten a lot more like, it depends as I’ve gotten older. This stuff used to really, really upset me from a purist standpoint. And I still really hate the fact that we’ve forced our users to endorse such a fragile and easily broken web. The web in general has gotten four to five times faster in the last decade. And the average website has only gotten a hundred milliseconds faster in terms of load time, because we just keep throwing more and more stuff at our users. And we could have a really fast resilient web right now if we wanted one, but we don’t. And part of that is a natural trade off for pushing the capabilities of the web further and further and that’s awesome, but I feel like sometimes we do things just because it’s shiny and new and not because it adds real benefit to folks. So I’d love to see a little bit more balance there.

Drew: Is part of the problem that we’re expecting the web to do too much? I mean, for many years we didn’t really have any great alternatives. So we enhanced and maybe over-stretched the high tech document system to behave like a software application. And now we’ve all got really powerful phones in our pockets, running a range of network connected apps. Is that the appropriate outlook for this functionality that we’re trying to build into websites? Should we just all be building apps for that case and leaving the document based stuff to be on the web?

Chris: I would argue the other direction. I think the bigger problem is… So maybe there are certain things for which I even personally I prefer like a native app over something in the web. But I think having the web do more frees you from app ecosystems and allows you as a team to build a thing and be able to reach more people with it, not have to download an app before you can access the thing you want. That’s a really cool thing. And I would argue that potentially the bigger problem is that browsers can’t keep up with the pace of the thing that we want the web to do. And that’s not a knock on the people behind the standards processes. I would not want to go back to every browser just does their own thing and the hell with it. That was awful to develop for.

Drew: It was, yeah.

Chris: We do have some of those similar problems though, just based on how the standards process works. So sometimes you’ll see Google get frustrated because they have so much in-house development power, get frustrated with other browsers that are part of that process not wanting to go along with something or not moving fast enough. And so they just… Leeroy Jenkins it and just run off and go do whatever they want to do. On the flip side you sometimes see Apple moving very, very slow because they don’t put as much investment into the web as they do other parts of their business, which is hopefully, maybe starting to change a little bit with some of the more recent hires they’ve made. But I think one of the things you run into is just the web tends to move a little slowly sometimes.

Chris: Technology moves fast, but the browsers themselves and the technologies they implement don’t always keep up. And so I don’t believe we demand too much of our browsers. I just think you get this natural ebb and flow where we demand a lot. We build a bunch of libraries to polyfill the things that we want and then when the browser eventually catches up, there’s this really slow, petering off as library usage for that particular stuff drops off.

Chris: Yeah. But I don’t know that I would say we demand too much of the web. Yeah, I don’t know. I actually, I love all the things the web can do. I think it’s really, for me, it’s what’s so exciting about the web. I think my frustration is more just with how slow some of these technologies are to come out, particularly on iOS devices. And I say this as someone who, I love my iPhone, but progressive web apps continue to be a second… They just don’t get as much priority as native apps do on that platform, which is disappointing.

Drew: So looking to the future on that note, what should we, as a development community be working on to fix some of these issues? Where should we be placing our efforts?

Chris: Yeah. So I think there are a few different things. And I think some of the tools we’ve talked about, I don’t think they’ll ever necessarily go away. They might change in form a little bit, but so I already see some cool things on the horizon. One of the things people love about single page apps that we’ve never been able to do with, I call them multistage apps, but they’re really just plain old webpages is like the nice transitions that happen between views where you might like fade in, fade out, or something like that.

Chris: There’s a native API in the works that’s going to make that a lot easier. That’s awesome. There’s also a native API in the works for HTML sanitization. So one of the big things that libraries do for you is they, when you’re rendering HTML from third party data, they have some libraries baked in that will help reduce your risk of cross-site scripting attacks.

Chris: There’s not really a good, just native way to do that, but there’s one in the works that will make that a lot easier. And even if you continue to use state based libraries, that should allow them to strip a bunch of code out and that would be an awesome thing.

Chris: One thing that the native web can’t do yet that would be really cool, is a way to handle DOM dipping so that if you want to build some HTML based on a JavaScript object and then update it as the object changes, it would be really cool if you didn’t have to rely on a library for that. And that there was maybe a performant out of the box way to do that in the browser. I think that would solve a lot of problems. As well as more accessible interactive components. I absolutely love when HTML and CSS can replace something I used to need JavaScript for. Doesn’t need to be as rigorously tested, way more fault tolerant, less likely to break, more performant all around. It’s a net win. And so I’d love to see more of those come to the platform.

Chris: So from a browser native thing there’s that. And then the other big thing I think we’re going to start to see more of is a shift away from client-side libraries and a shift to more pre-compiled stuff. Whether that’s static side generators, something like ASTRO that still uses JavaScript libraries, but pre renders them instead of making the browser do it. But those are the, I think, the big things I’m seeing start to happen and I think we’re going to see more and more of.

Drew: So you saying maybe it’s not all doom and gloom and perhaps we can fix this? There’s a way out?

Chris: No, yeah, I see us emerging from the dark ages slowly. And what I think is going to happen is we’re going to hit a point where much like where today people are like, “Why does everybody still use React?” I can imagine in 7 to 10 years time, we’re going to be like, “Why does anybody…” I’m sorry. Not React. jQuery. “Why does everybody still use jQuery?” We’re going to see the same thing with React and Vue. Like, “Why does everybody still start a project with those?” And there’s going to be some new libraries that are starting to emerge to solve a whole new set of problems that we haven’t even dreamed of today.

Drew: One comment from Twitter that I really identified with was from Amy Pellegrini, who said, “Every time I update something, everything gets broken.” Yep. I just think we’ve all been there, haven’t we?

Chris: Yeah. I unfortunately don’t think that will ever fully go away because even in the non-build tool era of jQuery, we used to just load it with a script element. You would run into situations where different versions would be incompatible with each other. And so you’d drop a plug in into your site and it would be like, “Sorry, you’re running jQuery 1.83, and this requires 1.89 or higher because it added this new…” And so there’s always been some version of that. I think it’s a lot more pronounced now because so much of it happens in the command line and spits out all these terrible errors that don’t make sense. But yeah, that unfortunately I don’t think will ever go away. I feel the pain though. That one, it’s a big part of the reason why I try and use as few dependencies as possible.

Drew: Me too. Me too. So I’ve been learning all about the lean web or learning more about the lean web than our conversation. What have you been learning about lately, Chris?

Chris: Yeah. Great question. So I have been going deep on service workers in part because I love their ability to both make the web faster, or even if you’re not building a progressive web app, they’re just really, really cool. One of the things I’ve absolutely loved them for though is they allow me to build a single page app like experience in terms of performance, without all the complexity of having to handle JavaScript routing and stuff. So I can have a multipage app, cache my API calls for a short period of time without having to cache them in memory. And so I’ve been able to do some really cool things with them. And then the other thing I’ve been learning a lot about lately is serverless, which allows me to get the benefits of having some server-side code without having to actually manage a server, which is great.

Chris: And so I went really, really deep on those, put together a couple of courses on both of those topics as well, but they have benefited me immensely in my own work, in particular service workers, which has been amazing. I’m obsessed with them. Recommend them for everybody.

Drew: That’s amazing. And where can people find those courses that you put together on?

Chris: So if you go to vanillajsguides.com, you can dig into those and a whole bunch of other courses as well.

Drew: Amazing. If you dear listener would like to hear more from Chris, you can find his book on the web at leanweb.dev and his developer tips newsletter, which I believe now gets over 12,000 subscribers-

Chris: Yeah. Up a little bit from the last time we chatted.

Drew: Yeah. That’s at gomakethings.com. Chris is on twitter @chrisferdinandi. And you can check out his podcast at podcast.com or wherever you usually get your podcasts from. Thanks for joining us today, Chris. Do you have any parting words?

Chris: No, that was a really great summary, Drew. Thank you so much. You hit all the key links. So thanks so much for having me. This was great.

Smashing Editorial" width="35" height="46" loading="lazy" decoding="async(il)




Source link

0 Partages