Le tapis roulant du frontend
(polotek.net)- Plus un produit dure longtemps, plus le temps et l’énergie consacrés au débat sur la réécriture coûtent cher, davantage encore que le choix du framework frontend
- Si un produit existe toujours dans 5 ans, c’est un succès, mais d’ici là le framework choisi aura de fortes chances d’être dépassé ou d’avoir profondément changé dans une nouvelle version portant le même nom
- Les meilleures équipes produit, plutôt que de passer à de nouveaux outils, cherchent à comprendre en profondeur leur framework actuel et à atteindre un niveau de maîtrise suffisant pour que l’outil ne freine pas l’avancement du travail
- Pour réduire les coûts à long terme, un choix plus proche de la plateforme web et des technologies web fondamentales, plutôt que d’abstractions complexes, peut constituer un compromis business réaliste
- La complexité de l’écosystème frontend complique la vie des développeurs débutants comme des équipes de recrutement, et les développeurs qui maîtrisent mal les fondamentaux du web sont plus vulnérables au prochain changement de stack
Il est difficile de descendre du tapis roulant par une réécriture
- Beaucoup d’équipes frontend pensent qu’une réécriture mènera à une meilleure situation, mais pour des produits faits pour durer, le choix du framework n’est pas en soi la décision technique la plus importante
- Si un produit dure plus de 5 ans, on peut considérer cela comme un succès, mais pendant ce temps le framework choisi peut devenir obsolète
- La communauté frontend a toujours évolué en mettant le changement au centre, et il y a peu de chances que cela change bientôt
- Même les frameworks populaires qui survivent peuvent être totalement différents à l’intérieur, et être en pratique réécrits sous un nouveau numéro de version
- Ce sur quoi une équipe doit se concentrer n’est pas la poursuite d’outils nouveaux et brillants, mais une connaissance suffisante du framework qu’elle utilise déjà
- Il faut un niveau de compréhension et de maîtrise tel que l’outil ne devienne pas un obstacle à l’avancement du travail
- Espérer qu’un passage à un autre outil résoudra les problèmes relève presque du piège
Plus on est proche de la plateforme web, plus les coûts à long terme diminuent
- Pour une entreprise qui cherche à réduire le coût du vieillissement rapide des technologies frontend, il peut être pertinent d’envisager une approche plus proche de la plateforme web
- Cela implique de réduire les abstractions complexes et de réapprendre ce que le web peut réellement faire
- Cela ne veut pas dire que c’est la réponse à tous les problèmes ni que c’est toujours mieux
- Cela peut constituer un compromis business offrant plus de valeur à long terme et réduisant les coûts
- En restant proche des technologies web fondamentales, on est moins dépendant, lors du recrutement futur d’ingénieurs compétents, de l’idée qu’il faudrait réécrire des millions de lignes de code avant de pouvoir travailler
- Pour les ingénieurs eux-mêmes, comprendre en profondeur les technologies web fondamentales aide davantage leur valeur de marché à long terme que de continuer à suivre un framework particulier
- Cela peut impliquer de renoncer à une partie de l’employabilité à court terme
- C’est plus favorable à la durabilité d’une carrière qu’une stratégie consistant à apprendre toutes les technologies populaires
- Connaître une technologie précise ne protège pas des réalités comme une dégradation du marché
Préférences de framework et coût pour l’équipe
- Les ingénieurs ayant une forte préférence pour un framework devraient refléter ce critère dans leurs conditions de recherche d’emploi
- Entrer dans une équipe qui utilise déjà un framework donné puis essayer de la faire basculer vers celui que l’on préfère déstabilise l’équipe et augmente fortement les coûts
- La complexité actuelle de l’écosystème frontend pèse à la fois sur les développeurs débutants et sur les entreprises
- Les débutants ont du mal à acquérir suffisamment de compétences pour trouver un emploi et se sentent dépassés par des outils complexes
- Les entreprises trouvent même plus difficile de recruter des développeurs généralistes, et le seuil d’entrée des postes de développeur permanents augmente aussi
- Si les personnes qui apprennent l’écosystème technique actuel n’acquièrent pas les fondamentaux du web, elles risquent un sérieux désavantage lorsque la stack changera à nouveau
- Le web est une plateforme puissante et unique pour livrer du logiciel ; il s’est amélioré avec le temps tout en conservant un haut niveau de rétrocompatibilité
- Les outils de base actuels sont déjà suffisamment bons, mais la couche des frameworks agit aujourd’hui davantage contre la plateforme qu’en l’adoptant
1 commentaires
Avis sur Hacker News
J’ai récemment travaillé à remplacer, dans le système de build du code frontend, yarn par pnpm. Je suis normalement ingénieur backend, mais j’ai aussi pas mal d’expérience côté JS.
Ce qui m’agace le plus quand je mets les pieds dans le frontend, c’est que vraiment tout semble deprecated. Si on utilisait apollo CLI en 2022, il est aussitôt devenu deprecated et il faut apprendre un outil totalement différent, comme graphql-client, avec une configuration et des options sans rapport. Au final, j’ai gardé l’ancien et j’ai simplement désactivé la vérification du moteur Node par pnpm pour qu’il arrête de se plaindre. Quand on essaie de faire une mise à jour patch d’une dépendance, les signatures de types peuvent casser, donc on la fige aussi, et on laisse dans la codebase un TODO en espérant que quelqu’un le corrigera un jour.
Une fois qu’on arrive enfin à le faire tourner, des centaines d’avertissements deprecated défilent pendant l’installation, et dès que le build se termine, on n’a qu’une envie : s’enfuir.
Je trouve vraiment étrange à quel point tout le développement frontend accepte ainsi les breaking changes et les éléments deprecated. Je travaille depuis presque 4 ans sur un gros projet Rust ; pendant ce temps, il y a bien eu quelques petits breaking changes dans des bibliothèques tierces, mais une seule modification majeure qui a vraiment exigé de gros changements dans l’application. À l’inverse, en JS, on dirait qu’il faut réécrire quelque chose tous les 6 mois.
Le monde du frontend a adopté les réseaux sociaux, YouTube, et même Twitch bien plus activement que d’autres domaines. Pour rester pertinents, ces influenceurs ont constamment besoin de nouveaux sujets, donc ils poussent sans cesse des nouveautés dont ils peuvent faire du contenu.
À cela s’ajoute une culture de conférences très active. Les conférences frontend et JS donnent l’impression d’être une grande compétition pour présenter le prochain sujet à la mode.
Le marché des formations frontend est aussi énorme. Les créateurs de cours doivent convaincre votre patron d’approuver une formation vidéo à 700 $ en offre limitée pour apprendre la nouvelle tendance ; pour cela, il faut éloigner l’industrie de ce que tout le monde connaît déjà. Ils poussent donc fortement le nouveau et rendent l’ancien deprecated.
Une petite webapp en pur JS de 5 KLOC que j’ai écrite il y a 15 ans est encore utilisée quotidiennement par une dizaine de personnes, sans qu’une seule ligne ait été modifiée. Elle tient même mieux qu’une application Win32.
À mon avis, la majeure partie du churn du frontend relève simplement d’un échec politique et organisationnel.
Quand j’ai commencé, à l’époque du JS pur/jQuery, la gestion des dépendances consistait en pratique à copier des fichiers
.jsdans un répertoirevendor/. Ensuite sont arrivés nodejs/npm, et côté frontend on utilisait aussi bower avant npm ; soudain, le conseil standard est devenu de ne plus rien écrire soi-même et de télécharger des modules.Mais déjà à l’époque, beaucoup de gens se demandaient s’il était vraiment judicieux de ne pas posséder directement des milliers de lignes de code caché, et de les confier à des bénévoles qui font de l’open source pour le plaisir.
Aujourd’hui encore, si l’on veut maintenir un projet longtemps, on peut éviter de faire grossir démesurément les parties invisibles. On peut traiter les petits problèmes ainsi : « je n’ai besoin que d’une fonction de cette bibliothèque, donc ne dépendons pas de toute la bibliothèque ; copions seulement cette fonction dans la codebase et ajoutons des tests ».
C’est pourquoi je pense que ce n’est pas un problème propre à JavaScript, mais un problème de personnes et de processus. Beaucoup de développeurs JS ne rencontrent pas ce genre de problème, mais une grande partie de l’écosystème, si.
Des milliers d’heures-personnes sont dépensées chaque jour à corriger les conséquences de breaking changes « très importants »™, du genre : « Et si on renommait MultiselectDropdown en MultiSelectButtonDropdown ? Et changeons aussi complètement l’API ! »
Il n’existe presque pas de culture qui comprenne le coût énorme des API cassantes. Après 10 ans de Go, c’est particulièrement frustrant. Go a une promesse de rétrocompatibilité, et cela semble aussi influencer l’attitude des développeurs de bibliothèques Go vis-à-vis de la compatibilité et des breaking changes. C’est une expérience vraiment agréable de voir du code écrit il y a 10 ans compiler et fonctionner tel quel avec le Go actuel.
J’ai aussi migré vers Flutter pour échapper à cet enfer JS/web, et cela m’a plutôt bien convenu ; j’ai pu oublier une grande partie de la complexité accidentelle de la stack web. Mais la culture du « ce n’est pas grave de casser les packages » s’infiltre aussi dans l’écosystème Dart, ce qui est très agaçant.
Honnêtement, je trouve ça bien pire que le frontend. Côté frontend, TypeScript et les caractéristiques du langage limitent tout de même l’étendue des dégâts à un niveau relativement sain. En Python, on peut vraiment faire littéralement n’importe quoi, et donc les auteurs de bibliothèques font littéralement n’importe quoi. S’ils veulent changer la façon d’importer les modules, ils le font ; s’ils veulent casser avec des métaclasses toutes les hypothèses sur le comportement des classes, ils le peuvent. On pourrait penser que le typage statique aidera, mais même une chose aussi basique que
Partialn’existe pas, et il n’est pas non plus possible d’affirmer statiquement que deux objets ont le même type.Ça me fait rire quand je vois des gens se plaindre qu’une bibliothèque change. La transition de Python 2 à 3 a été tellement horrible que, dans une entreprise précédente, il existait un monolithe Python de 100 millions de lignes sans aucun plan de migration vers Python 3. Passer de SqlAlchemy 1 à 2, c’est une migration en 8 étapes, pratiquement une réécriture complète, et si une seule chose casse, le site tombe. Et pourtant on se plaint que React ait ajouté les hooks de manière optionnelle.
Ce qui est étrange, c’est qu’Internet déborde d’articles sur le « tapis roulant du frontend », mais qu’on voit rarement des textes qui râlent sur l’autre versant.
À propos de l’idée selon laquelle « en tant qu’ingénieur, plus on comprend en profondeur les technologies web fondamentales, plus on conserve une valeur bien plus élevée sur le marché avec le temps », je pense être légitime pour donner mon avis, ayant fait du front-end pendant près de 20 ans et traversé plusieurs grands changements de paradigme.
Il est clairement vrai que connaître toutes les technologies web fondamentales fait de vous un ingénieur plus équilibré. Mais je suis sceptique sur le fait que cela vous rende plus attractif sur le marché de l’emploi. Non pas parce que ces connaissances ne sont pas importantes, mais parce que les décideurs en matière de recrutement font généralement du pattern matching.
Si vous voulez maximiser votre « valeur de marché », il faut toujours être très bon en React. C’est presque le ticket d’entrée de base ; le reste est excellent, mais sans cette base, vos options se réduisent. Peut-être que c’est ce que l’auteur voulait dire et que je l’ai mal lu.
En revanche, pour des rôles de conseil ou de contractuel, je suis d’accord avec le commentaire d’origine. Quand on travaille avec des personnes qui recrutent dans de grands cabinets de conseil ou décident qui mérite un entretien, elles écartent presque automatiquement ceux qui ne connaissent pas déjà la stack qu’elles préfèrent ou celle que leur client utilise actuellement. Même les architectes techniques font cela, ce n’est donc pas seulement un problème de recruteurs non techniques. Ils ne veulent pas de temps d’adaptation à la technologie elle-même, quel que soit le niveau d’expertise.
Dans ces rôles, rester constamment à jour est très important. Sinon, le responsable du recrutement jette le CV parce qu’il manque un buzzword, avant même qu’un ingénieur ait pu évaluer les compétences.
C’est peut-être un cas atypique, mais ne pas connaître React n’a jamais été un problème. L’expression « ticket d’entrée de base » est trop forte.
Le front-end a un plafond de rémunération assez net. Une fois qu’on dépasse un certain niveau, on n’a plus jamais besoin de créer d’UI.
La plupart des entreprises, même les grandes, ne se soucient pas vraiment des fondamentaux, ne les vérifient pas et ne recrutent pas sur cette base. Elles recrutent sur des critères comme « bon en React » ou « beaucoup d’expérience avec Next.js ».
Les fondamentaux sont excellents quand on construit quelque chose à partir de zéro, mais les entreprises réelles font rarement ce genre de choses. La plupart du temps, elles prennent des solutions existantes avec un gros écosystème et une bonne documentation. Si vous les maîtrisez, vous serez embauché bien plus facilement, et vous pourrez apprendre les fondamentaux en chemin.
Dire que « quel que soit le framework choisi, il sera obsolète dans 5 ans » ressemble à un argument un peu daté.
Je ne suis pas principalement développeur front-end, mais je ne l’évite pas quand il faut en faire, et j’utilise React depuis une dizaine d’années. Une partie de l’attention se déplace vers Svelte, mais lorsque Svelte dépassera React, Svelte aura probablement déjà été utilisé en production depuis tout aussi longtemps. Angular finira peut-être aussi par perdre de la vitesse, mais si l’on considère ensemble les époques Angular1 et Angular2+, il est plus ancien que React.
Le développement front-end évolue vite, c’est vrai, mais ce n’est pas à ce point catastrophique. Si vous faites des choix ennuyeux, vous obtenez des résultats ennuyeux.
Angular1 et 2 étaient quasiment incomparables, à part le nom, et beaucoup de développeurs s’y sont brûlé les ailes. Angular lui-même change aussi assez fortement. Ce n’est pas aussi extrême que le passage de v1 à Angular2, mais cela demande tout de même une réadaptation importante. Tout migre vers les standalone components, la nouvelle syntaxe de templates, les signals, etc.
React, c’est similaire. L’arrivée des composants fonctionnels et des hooks a constitué un grand changement de paradigme. C’était compatible, mais très différent.
C’est pareil pour les paradigmes plus généraux. Au début, tout était rendu côté serveur, puis on a foncé à toute vitesse vers les applications monopage, avant de revenir au rendu côté serveur, mais cette fois sous forme de rendu serveur partiel avec hydration.
Il est suffisamment différent pour qu’on puisse presque parler d’un autre framework ; donc, même s’il y a de la nuance, cet argument n’est pas complètement mort.
C’est vraiment simple à travailler. J’ai créé une petite appli de répartition d’actions, et ce qui m’a le plus surpris, c’est la taille du bundle. Elle était de 9 Ko en gzip, plus petite que n’importe quel framework que je connais. Même plus petite que htmx, qui est dans une certaine mesure presque « anti-JS ».
De vieux frameworks peuvent tourner pendant très longtemps. Tant qu’il existe des personnes qui connaissent cette stack et qu’on peut les embaucher pour travailler dessus quand c’est nécessaire, cette stack n’est pas obsolète. « Ancienne » ou « legacy » peut convenir. Mais tant qu’il n’arrive pas un jour où il ne reste absolument plus personne pour s’en occuper, elle n’est pas obsolète.
C’est intéressant d’appeler ça un problème de frontend. Ce n’est pas un problème de frontend, c’est le problème d’un immense écosystème dans lequel de nouveaux participants arrivent sans cesse.
On voyait exactement la même chose il y a 15 ans, quand Java était à la pointe de l’innovation. En quelques années, des dizaines de frameworks et plusieurs systèmes de build sont apparus. Le passage de React 17 à 18 est un changement bien plus faible que celui de Perl 5 à 6, ou de Python 2 à 3.
Côté backend, au lieu de « utilisons un nouveau framework », on a « utilisons un nouveau langage ». La mode du moment est de réécrire des choses en Rust ; avant ça, il y a eu Go, Haskell, Scala et F#.
Si vous trouvez pénible de migrer du code frontend de React vers quelque chose comme Svelte, essayez donc de réécrire une appli VB 6. Sans même parler des trucs façon RPC avec les données dans le code.
Ça ne veut pas dire que l’instabilité des pratiques d’ingénierie n’est pas un problème. C’en est un gros. Simplement, ce n’est pas un problème propre au frontend.
webpack a aussi 13 ans, mais sa manière de se configurer a changé de façon spectaculaire même ces dernières années.
Si la configuration d’Apache changeait aussi souvent que celle de ces systèmes, personne n’utiliserait Apache.
Dans mon poste précédent, il y a eu deux migrations de base de données en deux ans, qui ont consommé au total un an de temps d’ingénierie. Cela ne concernait pas quelques tables non critiques, mais toutes les tables. Quand quelque chose cassait, ou que la direction demandait pourquoi c’était si lent, on accusait les ingénieurs qui apprenaient le frontend, au motif qu’ils manquaient d’expérience.
Je travaille comme développeur Java depuis plus de 25 ans ; pendant un peu plus de mes 10 premières années, j’ai fait du full-stack, ce qui était alors la forme habituelle dans les entreprises. Aujourd’hui, il est courant d’avoir une équipe frontend séparée, et souvent même trois équipes : web, iOS et Android. Pour moi, ce changement s’est produit à peu près au moment du passage d’AngularJS à Angular.
Java aussi a changé rapidement pendant ses dix premières années environ, surtout pendant les trois premières. Mais cette période est terminée. Java 5 a été un gros changement, et Java 8 a aussi apporté des fonctionnalités majeures, mais Java 8 date de 2014. Notre équipe n’est passée que récemment à Java 11, alors que Java 24 est maintenant sorti. Je n’ai jamais utilisé les fonctionnalités de Java 11, et je ne sais même pas ce que c’est. En 10 ans, je n’ai appris aucune nouvelle fonctionnalité du langage.
Les outils de build sont les mêmes depuis 15 ans, et l’IDE est le même depuis 20 ans. Le framework principal que nous utilisons est aussi le même depuis 10 ans. Quand j’ai rejoint mon dernier poste, la structure de la base de code était exactement la même que dans mon équipe précédente.
Créer des services web en Java est un problème résolu. C’est complètement ennuyeux, dans le bon sens du terme, comme COBOL.
Le frontend changeait déjà vite à la fin des années 90 et au début des années 2000, mais il a continué à changer rapidement depuis. Un projet personnel d’UI que j’ai créé il y a quelques années est devenu totalement obsolète.
Pour les projets Java sur lesquels j’ai travaillé après l’ère EJB, on pourrait trouver aujourd’hui un développeur Java et le mettre dessus : il serait productif tout de suite. Même s’il était né après la création du projet. Il aurait seulement quelques vieilles bibliothèques à apprendre.
La façon de descendre du tapis roulant, c’est de ne pas utiliser du tout de framework frontend. Ce n’est pas de choisir un autre framework au hasard pour devoir tout réécrire plus tard.
Il faut du rendu côté serveur, du JavaScript uniquement quand c’est nécessaire, et ne pas séparer en interne les effectifs backend et frontend.
Si un ingénieur peut écrire le SQL qui ne récupère que les colonnes exactes nécessaires à une vue web en SSR, et être aussi responsable de cette vue web, il n’a pas besoin de passer une seule seconde à réfléchir à une API ou à un ORM. Il suffit de connaître SQL et du HTML/CSS/JS moderne et pur. La majeure partie du travail devient la transformation d’une vue métier (SQL) vers le DOM (HTML), et l’écosystème de programmation côté serveur passe au second plan.
À mon avis, l’aboutissement consiste à faire du SSR de contenu web à l’intérieur du SGBDR. Une approche à la Oracle APEX. Mais la plupart des ingénieurs ne sont pas encore prêts à avoir cette discussion. Moi non plus, je ne l’étais pas la première fois que je l’ai vue en pratique. Nous sommes trop attachés à notre façon de souffrir.
Elle a aggravé le problème de la complexification excessive du frontend. Comme il y a des gens dans l’équipe frontend, ils continuent à créer du travail et à ajouter de la complexité. Le fait qu’il y ait trop de personnes qui ne connaissent que le développement web et rien d’autre est aussi un problème.
Sur un side project, l’une de mes contraintes initiales était que tout le site puisse se dégrader élégamment même si JavaScript était désactivé. Du coup, chaque fois que je voulais ajouter une fonctionnalité qu’on ferait habituellement en JavaScript, je me demandais : « est-ce que je peux faire ça sans JavaScript ? » Et jusqu’ici, étonnamment, la réponse a toujours été oui.
Rien qu’avec des sélecteurs CSS sur des contrôles HTML natifs, on peut vraiment faire beaucoup de choses aujourd’hui. Cette base de code ne contient toujours pas une seule ligne de JS.
Les équipes produit/design peuvent pousser à ajouter autant de fioritures JavaScript que possible, sans aucune considération pour l’utilisabilité, les performances, l’accessibilité ou de bonnes pratiques d’ingénierie.
Je ne suis pas très bon en frontend, et nous n’avons pas de designer. Je suis bien meilleur en backend, mais d’autres personnes de l’équipe ont plus de talent que moi en design frontend.
Quand j’ai créé mon premier site web, je lisais des articles du genre « Svelte est meilleur que React » ou « solid-js sera la prochaine grande tendance », et je pensais que c’était une partie importante du développement web.
Les débutants feraient mieux de lire MDN et d’ignorer le reste.
Il faut des tutoriels et des walkthroughs, et construire une compréhension interne de la façon dont tout cela fonctionne.
Les frameworks aident à abstraire ces aspects.
Mais l’obsession récente pour Next.js et le SSR, peut-être pas. Personnellement, je pense même que cela pourrait contribuer au déclin côté React.
Vu les progrès du JS et du CSS purs ces dernières années, et le fait que des fonctionnalités intéressantes comme l’animation de
display: nonesoient presque au stade de l’adoption, générer du HTML à partir de templates côté serveur et n’utiliser JS que là où c’est nécessaire paraît plus pertinent que jamais.Je dis ça en tant que personne qui gagne principalement sa vie avec React.
Comme l’auteur, je fais du frontend d’une manière ou d’une autre depuis 20 ans. L’écosystème, le churn, les numéros d’équilibriste pour synchroniser l’état entre frontend et backend, tout cela est complètement fou.
J’ai récemment lancé une preuve de concept avec Go templates et HTMX, en essayant de retrouver à peu près la sensation de construire une UI avec des « composants » comme dans React. Il y a encore beaucoup d’aspérités, mais le potentiel est là. Honnêtement, je ne suis même pas encore sûr d’avoir besoin de HTMX. J’ai commencé à gérer directement les event listeners, et je crois que je préfère cette approche.
Fait intéressant, la gestion d’un état d’UI complexe basé sur les rôles et permissions utilisateur est beaucoup plus simple côté serveur. Il suffit d’envoyer uniquement le HTML que l’utilisateur est autorisé à voir.
Cela dit, React, Vue, etc. ont une inertie énorme. Je ne vois pas trop comment un basculement collectif de mentalité pourrait commencer. D’autant plus que beaucoup de développeurs ne connaissent rien d’autre que les frameworks frontend comme façon de construire une UI.
Je ne suis pas sûr de l’affirmation selon laquelle « quel que soit le framework choisi, il sera obsolete dans 5 ans ».
J’utilise React professionnellement depuis plus de 10 ans.
package.json? Quelle version de node/npm votre équipe utilise-t-elle ?Si vous utilisez une version suffisamment récente et des bibliothèques populaires, vous avez sûrement vu s’accumuler les avertissements de dépréciation sur les dépendances transitives pendant
npm install.Pour être juste, je trouve que le code React lui-même a plutôt bien maintenu la rétrocompatibilité. Ce n’est pas la faute de React. Mais tous les systèmes de build qu’on utilisait il y a 5 ans ont changé et cassé la rétrocompatibilité. J’avais même oublié les méthodes de cycle de vie des composants.
Même un projet aussi bien maintenu que React ne peut pas échapper au désordre de son écosystème.
Ce n’est pas toujours un choix possible, mais aujourd’hui je préfère généralement importer du JS pur sans système de build, traiter autant que possible côté backend Python/Django, et sortir complètement de l’écosystème JavaScript. Je ne l’ai jamais regretté.
Vous laissez encore votre app en React 15 ?
Tous les éditeurs WYSIWYG qui fonctionnent avec React 16 ne sont plus maintenus. Si un problème de sécurité est découvert, on en est à « tenter sa chance ». Ou alors il ne faut pas les utiliser.
React 16 est encore supporté, mais il est clairement obsolete.
Le contre-argument, c’est que si l’on n’adopte pas de framework, on finit par créer un framework maison que les personnes extérieures à l’équipe ne comprennent pas, généralement mal documenté, et sur lequel il faut sans cesse travailler pour ajouter des fonctionnalités déjà présentes dans les frameworks existants.
Il y a des fonctionnalités dont tout le monde a besoin en frontend et des problèmes communs à résoudre. Ne vaut-il pas mieux au moins partir avec quelque chose plutôt que de commencer de zéro ?
Comme personne n’a jamais vu le framework interne, il est impossible de trouver quelqu’un qui soit productif immédiatement. Même avec une très bonne documentation, il faut du temps pour l’apprendre et l’intégrer. Pour un recrutement long terme, ce n’est pas forcément le pire, mais si vous avez temporairement besoin de développeurs supplémentaires, il n’y a pas de solution.
Comme je l’ai écrit ailleurs, presque tout le monde veut une web app, ou pense en avoir une, alors qu’en réalité il ne s’agit généralement que d’un site web dynamique. Il n’est pas nécessaire d’empiler des frameworks pour construire un site web dynamique.
Ce n’est pas un problème de frontend, c’est un problème de l’écosystème JS. Cela arrive aussi côté backend.
L’environnement JS est un foutoir complet de dépendances qui ont elles-mêmes des dizaines, voire des centaines, d’autres dépendances. Par exemple, le graphe de dépendances de Platformatic, un framework Node basé sur Fastify, ressemble à ceci :
https://npmgraph.js.org/?q=platformatic#zoom=h
Ces dépendances peuvent être abandonnées à tout moment. Même d’énormes dépendances comme Axios ou Express ont, à une époque, semblé délaissées.
Et chaque dépendance est gouvernée par ce que son mainteneur estime être la bonne approche. Il y a quelques jours, une dépendance utilisée en production, avec environ 25 millions de téléchargements par semaine — React étant autour de 26 millions — et présente dans 10 millions de dépôts GitHub, a décidé qu’il était acceptable d’abandonner la prise en charge d’une version de Safari vieille d’environ 3 ans. Quand on sait que Safari représente plus de 50 % du marché mobile aux États-Unis, c’est vraiment délirant.