Comment éviter que la technologie front-end ne nous rende irrités

Beaucoup de choses ont été écrites sur la façon dont le frontend est devenu déroutant et écrasant (voir JavaScript Frameworks - Heading into 2025 pour un aperçu) et je pense que cela a beaucoup à voir avec les incitations pour différentes parties, et je discute de ce qu'il faut pour combler un trou qui existe et créer un écosystème plus sain.

La réalité pour un développeur

Lorsqu'un développeur front-end envisage différentes technologies, il a besoin d'un moyen de convaincre les parties prenantes (à la fois les gens d'affaires et leurs pairs développeurs), et la seule façon d'y parvenir est de construire des choses et de les mesurer, prouvant ainsi les avantages et gérer les attentes. (Le moteur peut être la nécessité de construire quelque chose de complètement nouveau, d'améliorer une chose déjà existante, ou peut-être même simplement de prouver qu'aucun changement n'est nécessaire et qu'il n'y a aucun avantage à tirer d'une alternative, dans le cas où, par exemple, des parties externes font pression sur l'entreprise pour qu'elle l'envisage.)

Un exemple pourrait être un développeur qui envisage d'utiliser davantage de composants React Server (l'accent n'est pas mis sur RSC lui-même, il peut tout aussi bien s'agir de quelque chose d'autre, d'un autre framework ou d'un autre élément technologique). Ils doivent adapter leur architecture pour inclure un serveur, adopter de nouveaux modèles de programmation, réfléchir à l'organisation des fichiers avec ces nouveaux routeurs et directives, raisonner sur les contraintes de tout cela, sensibiliser les gens à tout cela, s'aligner sur les meilleures pratiques et besoins internes, discuter avec les clients et mettre à jour les SLA et la documentation,... Tout cela est très coûteux et risqué, donc une décision ne doit pas être prise à la légère.

(Ce processus épuisant et très coûteux consistant à comparer différentes technologies et à effectuer des migrations architecturales est quelque chose que traversent une bonne partie des équipes à travers le monde. Pensez simplement au nombre d'articles de blog et de vidéos sur les promesses non tenues d'un morceau de technologie (Vous n'avez pas besoin de Next.js - Pourquoi nous avons migré de Next vers React comme l'un des plus récents).)

Cependant, très vite, après avoir commencé à créer des POC, le développeur se rend compte que de nombreuses offres technologiques sont annoncées via l'argument « faites-nous confiance, mon frère ».

Chaque nouvelle technologie qui sort de la cuisine-cadre raconte une histoire d'améliorations magnifiques, avec des démos assez plastiques les mettant en valeur. Mais la réalité est souvent bien plus compliquée, les bénéfices marginaux et pourtant l’expérimentation et la migration très coûteuses. Le défi est pour chaque entreprise et chaque équipe de réinventer la roue et de trouver des moyens de prouver qu'il existe effectivement une certaine utilité dans leur cas particulier. Une énorme quantité de ressources et d’expertise interne est nécessaire pour examiner et tester diverses options de manière holistique et exhaustive.

La dynamique saine de l'écosystème front-end est compromise lorsqu'une entreprise qui qualifie la fonctionnalité Yet Another™ de The Now Best Thing Ever™, comme en témoigne une affirmation de Trust Me Bro™, d'inciter le développeur à y adhérer et à y mettre le efforts pour migrer vers celui-ci, pour découvrir qu'en effet, les problèmes difficiles sont difficiles à résoudre et que le retour sur investissement n'est pas là. Au fil du temps, se brûler de cette façon trop souvent conduit au ressentiment, à l'épuisement professionnel et à une aversion globale pour les risques futurs.

Les entreprises qui développent ces nouvelles technologies cool (et elles peuvent vraiment être cool !) s'étonnent que les gens ressentent du ressentiment et peuvent sembler inconsidérées par la quantité de travail que ce genre d'efforts nécessitent et par l'inaccessibilité des moyens vérifiables de le dire. quelles pourraient être les attentes réalistes. Tout cela peut paraître malhonnête.

On se rend compte que les entreprises qui construisent ces nouvelles technologies ont la responsabilité de prouver que leur technologie fonctionne, non seulement via la publicité, mais aussi en fournissant aux développeurs des outils pour guider leurs décisions et confirmer les avantages pour eux-mêmes. .

Les outils

Alors, à quoi ressemblent réellement ces outils ?

Les outils rendraient compte en permanence des mesures qui intéressent les développeurs (qui peuvent être mesurées objectivement), combinées et corrélées de manière holistique avec les changements apportés par les développeurs pour les aider à comprendre les compromis :

• Tailles des bundles (rapports exhaustifs sur les bundles par page et partagés, informations sur les bundles supplémentaires qui seraient chargés paresseusement (sur les interactions) et/ou automatiquement (travailleurs de service, préchargement et autres échauffements))
• Mesures sur le réseau (avec plus de sérialisation, il est bon de savoir quelles sont les économies réelles pour le client et comment cela affecte la communication entre le serveur et le client)
• répartitions temporelles et performances (qui incluent à la fois le serveur et le client, par exemple le temps nécessaire pour restituer le contenu et la quantité qui se trouve sur le serveur par rapport au client, la latence et le transfert du réseau, etc.)
• Web Vitals (avons-nous besoin de répartitions plus granulaires pour les différentes parties des pages Web qui sont à la fois chargées et rendues progressivement ? Est-il plus suffisant d'avoir des métriques uniques uniquement pour le chargement initial ?)
• tendances (au fil du temps) et corrélations entre toutes ces différentes métriques au niveau de l'ensemble d'un projet (afin qu'une équipe puisse suivre l'évolution des choses et éviter d'être désagréablement surprise par une dégradation des performances avec le temps ou l'introduction d'un cas limite seulement à certains endroits et certaines pages)

Les éléments mentionnés ici sont les mêmes qui intéressent n'importe quelle équipe, mais les outils permettant d'obtenir ce genre d'informations semblent difficiles et alambiqués à mettre en place, et parfois pratiquement impossibles lorsqu'il s'agit de frameworks qui se comportent comme un noir. boîte.

Incitations

Ce type d'outillage ne doit pas nécessairement être fourni par les mêmes entreprises qui développent elles-mêmes ces nouvelles technologies, mais pourrait également être construit par une autre entreprise (il pourrait déjà y avoir des allusions à des considérations similaires ? Evan You - Vue, Vite, VoidZero et l'avenir des outils JavaScript, ou je pourrais mal interpréter ce que dit Evan). Cependant, je pense que la même entreprise qui construit une nouvelle technologie devrait être celle qui fournit également les outils nécessaires pour vérifier ses gains, car les incitations sont de son côté :

En créant un tel outil qui rend compte de manière transparente de diverses mesures et différences entre diverses implémentations, une entreprise qui construit une nouvelle technologie/un nouveau cadre peut d'abord vérifier en interne les progrès et les réclamations, et s'aider elle-même à comprendre les compromis, puis à optimiser le bonnes mesures. De cette façon, l’entreprise reste responsable et honnête. Ainsi, toute la boucle de retour d’information sur l’amélioration peut se produire en interne, bien avant même d’atteindre le public.

En fournissant ensuite également ces mêmes outils au public, l'entreprise peut éviter tout risque de fausses déclarations et de déception, et offrir à la place la possibilité à chacun de simplement vérifier les choses par lui-même, sur ses propres projets. Cela générerait, à son tour, encore plus de confiance et de gratitude.

L'entreprise qui construit la technologie est également la mieux placée pour créer les outils correspondants - elle comprend mieux ses API et ses capacités, et combien ou combien peu il est nécessaire d'ouvrir pour faire fonctionner l'outillage (c'est une autre façon pour garder l'entreprise honnête et juste).

À terme, si l'entreprise souhaite étendre son modèle économique en rendant cet outillage payant, elle pourrait le faire. (Actuellement, une approche similaire se manifeste généralement par la passation de contrats et l'implication directe avec les entreprises clientes. Cependant, l'outillage pourrait rendre le tout beaucoup plus égoïste, ce qui pourrait profiter à toutes les parties.)

Conclusion

Nous sommes dans une ère de technologies concurrentes dans laquelle il n'existe pas de solution unique, et les migrations architecturales sur des projets de plus en plus grands ne sont pas bon marché. Pour permettre de décider et d'agir intelligemment, un outil et un reporting plus complets sont nécessaires, ceux qui guident et évaluent les décisions, les changements et les compromis en permanence, et ne se contentent pas de rendre compte une fois que tout a été fait.

Les entreprises qui construisent ces nouvelles technologies et ces nouveaux cadres sont celles qui bénéficieraient le plus de ces outils et sont les mieux placées pour les construire.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!