Un mémo de décision pour tous ceux qui regardent leur
package.jsonet je me demandais.
La plupart des arguments en faveur du maintien de votre infrastructure SPA sur le tapis roulant de mise à niveau : le cycle sans fin de migrations de versions majeures, de désabonnement aux dépendances et de rotation des outils de construction. Cet argument est réel mais incomplet et, à lui seul, il n'a jamais été décisif : chaque atelier de charpenterie a appris à vivre avec le tapis roulant. Il existe un dossier plus solide, construit sur quatre piliers qui s’articulent les uns avec les autres.
Premièrement, le coût total de possession : le JavaScript Vanilla sur la plate-forme Web présente des propriétés TCO inhabituelles, dominées par une courbe de dépréciation presque plate. Le code écrit sur la plateforme ne pourrit pas, car son substrat ne change pas. À long terme, cette propriété unique l'emporte sur presque tous les arguments de productivité par fonctionnalité en faveur d'un framework.
Deuxièmement, le marché du travail : le bassin de personnes capables de travailler sur JavaScript Vanilla n’est pas une niche au sein du marché front-end – il s’agit de l’ensemble du marché front-end, plus la majeure partie du marché back-end. Chaque développeur de framework est, en soi, un développeur JavaScript. L’inverse n’est pas vrai. Si vous embauchez pour un cadre spécifique, vous embauchez dans un sous-ensemble tout en vous disant que vous embauchez dans le courant dominant.
Troisièmement, l’effet de levier de l’IA : les ingénieurs produisent désormais une part croissante de code avec l’aide de l’IA, et les aspects économiques de cette assistance diffèrent considérablement selon la cible. La plateforme Web est un petit corpus de connaissances stable et exhaustivement documenté ; un écosystème de framework est un vaste écosystème en mutation rapide dont les données de formation sont perpétuellement obsolètes. Les outils de codage de l’IA sont nettement plus fiables sur les premiers. À mesure que le développement assisté par l’IA devient le mode de production dominant, le substrat que l’IA gère le mieux devient le substrat le moins cher – et l’écart se creuse chaque année, la plate-forme reste immobile tandis que les frameworks évoluent.
Quatrièmement, l'architecture : le portage vers des composants Web n'est pas une translittération de la même conception dans une syntaxe différente. La plate-forme s'oriente vers une architecture véritablement différente - des composants autonomes transmettant des messages plutôt qu'un arbre réconcilié de manière centralisée - et cette architecture a ses propres conséquences économiques, principalement favorables à une large classe d'applications, que vous devriez adopter délibérément plutôt que de découvrir par accident.
La recommandation, énoncée d'emblée : si votre application se situe dans le quadrant droit – longue durée de vie, stabilisante, formes et vues plutôt que toile collaborative – migrez progressivement via le modèle étrangleur et rejetez toute réécriture big-bang. Le reste de cet article développe chaque pilier, le raisonnement qui les sous-tend et les conditions dans lesquelles tout l’argument s’inverse.
Avant les piliers, les principes sur lesquels ils reposent. Si vous n’êtes pas d’accord avec une conclusion ci-dessous, le désaccord concerne probablement l’une d’entre elles – et c’est l’endroit productif pour l’avoir.