L’IA est-elle en train de faire revivre à la frontend sa décennie perdue ?

• Le deskilling remplace le travail qualifié par des techniques utilisables avec moins de compétences, ce qui réduit les coûts et les barrières à l’entrée, mais affaiblit aussi le pouvoir de négociation des travailleurs
• Côté frontend, durant les dix dernières années, les frameworks et les outils ont masqué les connaissances sur le navigateur, l’accessibilité et la performance, reléguant l’expertise du front of the frontend
• L’IA agentique pousse le code vers un niveau d’abstraction plus élevé, mais il s’agit d’une abstraction non déterministe et fuyante (leaky), dont les résultats peuvent fortement varier au moindre changement d’entrée ou de modèle
• Les LLM prolongent la logique du copier-coller depuis Stack Overflow : ils rendent les experts plus rapides et permettent aussi aux débutants d’obtenir quelque chose qui fonctionne, mais quelqu’un doit malgré tout comprendre et corriger le résultat
• L’IA peut produire davantage d’AI slop et servir à réduire les coûts, sans pour autant faire disparaître le besoin de personnes qui comprennent la qualité, les utilisateurs et les compromis

---

Le frontend et le code avec IA à travers le prisme du deskilling

• Le deskilling est le processus par lequel un travail qualifié est remplacé par des techniques manipulables par des travailleurs semi-qualifiés ou non qualifiés ; cela réduit les coûts et abaisse les barrières à l’entrée, mais affaiblit le pouvoir de négociation des travailleurs
• Le développement frontend a connu ce phénomène au cours des dix dernières années via les frameworks JavaScript et les outils, et l’IA agentique provoque aujourd’hui une évolution similaire dans l’ensemble de la programmation
• Comme le suggère l’expression Frontend’s Lost Decade, l’expertise frontend fondée sur une compréhension approfondie du navigateur et de l’expérience utilisateur a été éclipsée par un développement centré sur les frameworks

L’expertise disparue du frontend

• Autrefois, le développement frontend exigeait des connaissances spécialisées en HTML sémantique, CSS, différences entre navigateurs, accessibilité, amélioration progressive, performance réseau, conception d’interface et tests utilisateur
• Certains praticiens distinguent ces domaines du “frontend” actuel et les appellent le front of the frontend
• Le deskilling du frontend a progressé avec l’arrivée de frameworks et d’outils qui traitent le navigateur comme une simple cible de compilation, à l’image de la JVM ou d’iOS
• En important un composant comme Shadcn radio button, on peut créer une fonctionnalité sans comprendre en profondeur le HTML sous-jacent, les subtilités propres à chaque navigateur, les performances de chargement de page ou l’accessibilité
• Les entreprises peuvent ainsi affecter plus facilement des développeurs généralistes à des tâches frontend et réduire leurs coûts
• Le “développeur full stack” désigne de plus en plus souvent non pas quelqu’un qui maîtrise en profondeur le frontend et le backend, mais un développeur polyvalent capable de traiter les deux côtés avec un framework JavaScript
• Le même développeur peut être plus facilement réaffecté d’un projet à l’autre, et on peut même lui confier des applications natives via React Native et Electron
• Si l’abaissement des barrières à l’entrée a des avantages, le pouvoir de négociation des travailleurs s’en trouve affaibli

Le code avec IA : une abstraction plus haute, mais aussi une abstraction fuyante

• Ce qui se passe aujourd’hui dans la programmation en général ressemble fortement à ce que les développeurs web ont déjà vécu
• On se dirige vers un remplacement du travail qualifié, consistant à écrire le code soi-même, par des techniques manipulables par des travailleurs semi-qualifiés ou non qualifiés
• On ne sait pas encore clairement quelles compétences seront finalement requises pour les travailleurs qui pilotent une IA agentique, ni à quels niveaux se stabiliseront le coût du travail et celui des LLM locaux ou distants
• En revanche, il semble clair que les entreprises pourront s’appuyer sur cette technologie pour réduire les coûts et affaiblir le pouvoir de négociation des travailleurs
• La baisse de la valeur marchande de compétences longuement acquises rappelle la manière dont les artisans et ouvriers spécialisés ont été remplacés par des travailleurs à la chaîne
• Le deskilling peut aussi se voir comme un gain d’efficacité par l’automatisation, autrement dit comme un passage à un niveau d’abstraction plus élevé
• Les nouvelles technologies masquent les détails et permettent aux opérateurs de se concentrer sur une vue d’ensemble, mais décider quels détails peuvent être jugés “sans importance” est un choix majeur
• Et les détails d’une abstraction finissent toujours par fuiter

• Les abstractions qui fuient du frontend “moderne”

  • Une abstraction s’accompagne souvent d’un coût en performance, et renoncer à une partie des performances à l’exécution pour gagner en productivité développeur peut être un choix raisonnable avec des serveurs puissants et une charge moyenne
  • Sur des téléphones mobiles connectés à un réseau lent, ce même compromis devient un problème tout différent
  • L’usage massif de frameworks JavaScript lourds côté client comme React et de paquets de leur écosystème abstrait des questions comme l’accessibilité et la performance sur téléphones peu puissants ou réseaux lents
  • Au final, cela conduit à faire des choix sans penser à ces problèmes, ni s’en soucier

• Le caractère non déterministe du code agentique

  • Quand on crée une fonctionnalité ou corrige un bug avec une IA agentique, on ne rédige plus tout le code soi-même ; on décrit des changements de plus haut niveau avec moins de mots
  • L’IA s’appuie sur ses données d’entraînement et le contexte environnant pour compléter les détails omis ; parfois elle devine juste, parfois elle échoue
  • L’utilité de cette approche dépend beaucoup de ce que l’on considère comme important dans l’acte de coder
  • Le code agentique n’est pas déterministe comme un compilateur ; de petites variations dans l’entrée ou le modèle peuvent produire des résultats très différents, si bien que cette abstraction fuit bien davantage que les abstractions classiques de la programmation
  • Si l’on compare souvent l’IA à un “ingénieur junior”, c’est aussi à cause de cette non-déterminisme, avec une différence importante : un humain peut apprendre sans qu’on doive ajuster sans fin des fichiers AGENTS.md ou SKILL.md

Les LLM, prolongement du copier-coller depuis Stack Overflow

• L’analogie la plus proche pour l’usage des LLM est la manière dont on utilisait autrefois la recherche Google
• Savoir choisir les bons mots-clés pour faire remonter sur la première page le bon billet de forum ou la bonne réponse Stack Overflow était déjà une compétence que les développeurs devaient apprendre
• Le prompt LLM relève du même processus : obtenir une combinaison pertinente issue des données d’entraînement, comme une forme de recherche web floue dans un espace de très haute dimension
• Les résultats de recherche étaient sensibles à de petits changements de formulation et aux évolutions de l’index Google ; les LLM sont eux aussi sensibles à la manière de formuler l’entrée et aux changements de modèle
• Récemment, Google a modifié son moteur pour normaliser plus fortement les termes d’entrée ; la recherche est devenue plus facile pour ceux qui ne maîtrisent pas le Google-fu, mais aussi moins puissante pour les utilisateurs expérimentés
• Google et Stack Overflow ont irréversiblement transformé la programmation : au lieu de lire le manuel, on pouvait copier-coller des réponses et obtenir étonnamment souvent quelque chose qui fonctionnait au moins en partie
• Les LLM prolongent cette même dynamique
  • Ils rendent un peu plus rapides ceux qui savent ce qu’ils font
  • Ils permettent aussi à ceux qui ne savent pas très bien ce qu’ils font de produire quelque chose qui marche à peu près
• Les abstractions finissent toujours par fuir, et quand cela arrive, quelqu’un doit comprendre en profondeur ce qui se passe réellement pour corriger le problème
• De la même manière qu’on apprenait aux développeurs juniors à lire et comprendre une réponse Stack Overflow avant de l’utiliser, il faut désormais leur apprendre à lire les sorties des LLM, à les comprendre et à voir comment elles s’intègrent dans la base de code existante

La distance entre qualité et business

• Certains programmeurs ne sont jamais allés jusqu’à réellement comprendre les réponses Stack Overflow et ont estimé qu’il suffisait que le résultat fonctionne
• Beaucoup d’entreprises, même sans l’admettre ouvertement, se sont contentées de cette approche
• Aujourd’hui, on en est arrivé à une situation où les entreprises mettent publiquement en avant l’ampleur de leur usage de l’IA sans même faire semblant d’examiner les résultats produits
• Il existe bien des cas d’usage valables pour les LLM, mais aussi de nouvelles façons d’abîmer le code ainsi que la communication et les processus au sein des organisations
• Comme pour la revue de code, il existe de fortes divergences de vues sur la manière d’utiliser et d’intégrer les LLM dans un workflow ; si cela ne correspond pas à ce que l’équipe valorise, le flux de travail peut être sérieusement perturbé
• Beaucoup d’entreprises continuent à très bien fonctionner tout en produisant des logiciels médiocres
• Contrairement à ce que les programmeurs aiment croire, le succès d’une entreprise et la qualité du logiciel ne sont que très rarement corrélés
• En général, d’autres facteurs comme la marque ou le prix pèsent davantage, et les projets logiciels sont traités comme des boîtes noires où réussite et échec semblent avoir des probabilités comparables
• Même en frontend, un site lent et de nombreuses bannières de cookies peuvent nuire à la conversion, mais leur impact reste souvent moindre que celui de facteurs comme la fidélité à la marque ou le prix, d’autant que les sites concurrents sont eux aussi souvent lents
• Dans une ambiance du type “personne n’a jamais été licencié pour avoir choisi React”, on privilégie des choix sûrs plutôt que la qualité
• Cela ne veut pas dire qu’il faut cesser de se soucier des utilisateurs et du travail bien fait, mais il est devenu plus difficile de trouver un emploi qui permette réellement de le faire
• Quand la surchauffe retombera et qu’on comprendra mieux les tâches pour lesquelles les LLM sont vraiment adaptés — et celles pour lesquelles ils ne le sont pas — un certain équilibre pourra revenir, mais le métier, lui, ne sera plus le même qu’avant

Les compétences qui restent après l’industrialisation

• Quand les produits du quotidien et les bâtiments ont pu être massivement fabriqués par des procédés industriels, une première réaction a consisté à sortir d’usine des objets et des bâtiments imitant les styles passés pour paraître artisanaux
• Face à cet historicisme, le Bauhaus du début du XXe siècle a développé une approche qui ne cherchait pas à opposer l’ouvrier d’usine et l’artisan, mais à les faire travailler ensemble en repensant l’art et l’artisanat à partir des procédés de fabrication industrielle
• Le Bauhaus demandait au designer de revenir à l’atelier et de manipuler lui-même les matériaux, tout en visant au final des designs reproductibles à grande échelle
• Le logiciel se rapproche de l’artisanat dans la mesure où le programme écrit est livré à l’utilisateur “tel quel”, sans passer par une étape de fabrication ; mais il se rapproche aussi du design industriel puisqu’un même produit est distribué à des milliers d’utilisateurs
• La capacité à écrire du code à la main reste nécessaire, tout comme un designer industriel doit connaître les matériaux, et un web designer doit être très à l’aise avec HTML et CSS
• Google, Stack Overflow, les bibliothèques prêtes à l’emploi et les LLM permettent aux débutants de démarrer plus facilement, tout en abaissant en permanence les barrières naturelles qui faisaient obstacle au simple fait de faire fonctionner quelque chose
• L’industrialisation a produit quantité d’objets en plastique bon marché conçus sans réelle réflexion sur les usages ni les utilisateurs, mais le bon design industriel existe toujours
• Les traitements de texte ont généré beaucoup de documents très mal mis en forme, mais la typographie et le graphisme existent toujours
• Wix et Next.js ont permis de produire beaucoup de sites lents et peu accessibles, mais les praticiens du front of the frontend existent toujours eux aussi
• L’IA permet de produire beaucoup d’AI slop, mais cela ne signifie pas qu’on n’a plus besoin de personnes qui savent ce qu’elles font et qui se soucient de leur travail

Les changements et compromis à venir

• Comme dans d’autres secteurs, la part du travail bien fait pourrait devenir plus faible dans l’ensemble
• En parallèle, le volume total continuera probablement de croître, puisqu’il devient plus facile et moins coûteux de produire
• Il est encore difficile de dire si le nombre absolu de personnes rémunérées pour bien faire ce travail augmentera ou diminuera
• Produire rapidement un prototype ou un MVP peut parfois être le bon choix
• Si l’on n’a pas encore trouvé le product-market fit, il est souvent plus important d’itérer vite et d’apprendre que de tout concevoir d’emblée pour le long terme
• Mais encore faut-il savoir ce qu’on cherche à apprendre et comment valider cet apprentissage
• Une fois le bon moment venu, il vaut généralement mieux prendre du recul et refaire correctement les choses depuis le début
• Par exemple, obtenir plus tard de bonnes performances sur un frontend à la mauvaise architecture est très difficile
• Il est plus facile de partir d’une stack simple puis d’ajouter des fonctionnalités ensuite que de procéder à l’inverse
• Mastro encourage explicitement ce point de départ fondé sur de bonnes performances et une stack simple
• Qu’il s’agisse d’acheter un service, d’utiliser une bibliothèque open source, de générer avec un LLM ou d’écrire soi-même, il faut comprendre quels compromis sont faits dans chaque partie du système
• Quand l’emballement retombera, l’industrie finira par réaliser que l’IA n’est qu’un outil de plus dans la boîte à outils
• D’ici là, on risque de continuer à voir apparaître du code hideux, une communication cassée et des licenciements terribles au nom de l’IA

[GN⁺]

Avis sur Hacker News

• Je pense que la profonde expertise que l’OP regrette était en réalité assez inconfortable pour beaucoup de gens
  Je comprends qu’on puisse vivre de la maîtrise des particularités propres à chaque navigateur, de l’implémentation manuelle de composants accessibles ou de la spécificité CSS, mais pour la plupart des gens cela relève surtout de la complexité accidentelle. Permettre à davantage de personnes de créer quelque chose est clairement une bonne chose, et si une partie du résultat est plus lente ou moins accessible, c’est un compromis que l’on peut choisir
  On peut aussi dire que l’abstraction impose aux utilisateurs des conséquences qu’ils n’ont pas choisies, mais il me semble aussi qu’un LLM peut mieux comprendre que moi les conventions d’accessibilité

  • Il a toujours été difficile de bien traiter les aspects moins visibles de l’UX et du développement logiciel, comme l’accessibilité, l’intuitivité, la compatibilité, la réactivité, l’extensibilité, l’architecture ou les performances
    Mais les frameworks de très haut niveau, et maintenant les LLM, facilitent la sortie rapide de MVP à moitié cuits tout en sabotant ces aspects, ce qui creuse encore l’écart entre le « acceptable » et le « bon ». Quand on vise le « bon », il devient de plus en plus difficile de rivaliser avec ceux qui poussent de l’« acceptable »
    Au final, cela conduit à davantage d’heures sup et à une baisse de la qualité logicielle, peut-être même à un recul global de la satisfaction au travail. Ces derniers temps, on en arrive à réparer des sites cassés ou à supprimer leurs nuisances avec les outils de développement et uBlock pour retrouver des fonctions de base, et j’ai vu ici d’autres personnes dire qu’elles faisaient la même chose (https://news.ycombinator.com/item?id=47042747). Même à l’époque de Flash ou des premiers navigateurs, on n’avait pas besoin de bricoler soi-même de cette façon
    Il existe aussi un exemple moins anecdotique : https://news.ycombinator.com/item?id=47390945
    Le pire, c’est que la majeure partie de l’argent économisé par ces coupes remonte uniquement tout en haut de l’organisation
  • L’IA répète l’erreur consistant à placer un objet animé derrière un objet flou, ce qui force le navigateur à se re-rendre en permanence
    Le AI mode de Google contient aussi ce genre de chose, et d’autres sites semblent manifestement avoir ajouté des trucs similaires via du vibe coding
    Au début, je ne comprenais pas pourquoi l’utilisation du GPU explosait et pourquoi les ventilateurs s’emballaient, mais je vois maintenant que c’est une erreur fréquente de l’IA et que personne ne teste vraiment correctement. Les humains peuvent faire cette erreur eux aussi, mais jusqu’à présent je l’avais quasiment jamais rencontrée de toute ma vie
    Comme j’utilise un écran 240 Hz, le navigateur essayait de se re-rendre 240 fois par seconde, et je n’avais pas d’autre choix que de le bloquer avec uBlock Origin. C’est absurde
  • Les textes du genre « nous sommes en train de perdre notre savoir-faire » suivent toujours la même structure déprimante
    Ce qui est encore pire, c’est qu’à mi-parcours ils finissent par réfuter leur propre thèse
    Par exemple : « décider quels détails peuvent être considérés comme sans importance est une décision très lourde de conséquences, parfois subjective, et au bout du compte les détails finissent toujours par refaire surface ». Si c’est vrai, alors cette nouvelle technologie finira elle aussi par récompenser une compréhension technique profonde. Puisqu’on ne peut pas l’éviter. Là-dessus, je suis d’accord. Alors pourquoi le ton général est-il « l’IA transforme mes compétences en produit bon marché » ?
    Les sites web sont, techniquement, globalement meilleurs qu’il y a dix ans. Ils offrent plus de fonctions, sont plus rapides, et le SSL, l’accessibilité et le responsive sont devenus des valeurs par défaut plus solides. Les problèmes des fermes à contenu, du SEO et des sites d’actualités sont une autre forme de fiasco, provoquée par la publicité et les incitations des entreprises, pas la faute de React
  • Dire que « les LLM comprendront mieux que moi les conventions d’accessibilité » n’est vrai qu’au sens où d’autres personnes les ont comprises et mises par écrit
    Les LLM peuvent parfois en tirer parti. Mais si les gens cessent d’écrire ce savoir, qu’arrive-t-il ensuite ?
    Je suis d’accord sur le fait que c’est une bonne chose de permettre à plus de gens de créer. Toutes choses égales par ailleurs, plus il y en a, mieux c’est. Si « l’IA » s’était diffusée partout à cause d’améliorations indéniables, la situation et le ressenti seraient très différents
    Cela dit, les gens n’ont pas un droit naturel sur le savoir « généré » par leur travail. Si l’attribution et la rémunération étaient traitées sérieusement, et si l’entraînement ne pouvait se faire que sur des données payées à ceux qui les ont produites, il serait peut-être simplement bien plus rapide et moins coûteux d’apprendre le CSS
  • La commodité qui ignore la « profonde expertise » et accumule bricolages et abstractions paresseuses me paraît être une régression qui mène aux frameworks modernes de plusieurs Mo et jusqu’à Electron
    Bien sûr, personne ne se soucie de l’ordinateur de l’utilisateur, de l’usage mémoire, de l’expérience dégradée, de la bande passante gaspillée, ni du coût énergétique supplémentaire et de l’impact environnemental ajoutés à 8 milliards de personnes
    Est-ce aussi « clairement une bonne chose » que davantage de gens construisent des infrastructures publiques ? Si le résultat, ce sont de plus mauvaises routes, de plus mauvais ponts, des systèmes qui échouent ? Pour le logiciel, c’est pareil, et en réalité pour la plupart des choses aussi

• Une grande partie de ce que cet article disait en train de perdre de sa pertinence au sujet des « technologies frontend » consistait à traverser un champ de mines d’exceptions contre-intuitives, d’incompatibilités entre navigateurs, de dette historique et d’exceptions aux exceptions des exceptions
  Le frontend moderne, c’est-à-dire cette « tour d’abstractions qui fuit », se rapproche enfin d’un modèle mental de bon sens pour le développement web. C’est une couche plaquée de force au-dessus d’un amas explosif d’étrangetés que sont les standards et conventions du web, mais le simple fait que cela fonctionne et ne fuie qu’un peu reste en soi un accomplissement

  • Parler d’un « modèle mental de bon sens pour le développement web » n’a pas de sens. Soit on est dans un monde d’exceptions façon champ de mines, soit on est dans un modèle cohérent ; on ne peut pas avoir les deux à la fois
    Nous sommes toujours dans un champ de mines d’exceptions, et il est difficile de dire que les technologies qui servent à construire le frontend sont devenues propres, prévisibles et débarrassées du poids de l’histoire
    Tout ce que nous avons fait, c’est passer un peu d’enduit sur des erreurs et des incompatibilités de base ; nous n’avons rien résolu. React ne résout pas le fait que HTML n’a pas été conçu comme une boîte à outils pour l’UI. Next.js ne résout pas le fait que JavaScript est rempli d’erreurs de conception qui l’empêchent d’être un langage sûr, sain et rationnel. Tailwind ne résout pas le fait que CSS a été bricolé pour habiller un balisage qui n’avait pas été conçu pour le stylisme
    Ce que font les LLM aujourd’hui, c’est simplement « connaître » dans leur modèle statistique les horreurs cachées sous l’enduit. Ce modèle a été entraîné sur des exemples d’une époque où 99 % des cas consistaient à reboucher les fissures de la couche d’enduit précédente
  • Je ne suis pas spécialiste, mais pour avoir déployé du frontend visible par le grand public, le frontend ressemble à la route de briques jaunes du Magicien d’Oz
    Tant qu’on ne sort pas d’un petit ensemble de bonnes pratiques raisonnables, quelques bibliothèques ennuyeuses mais éprouvées suffisent à offrir une expérience tout à fait correcte
    Mais dès qu’on se retrouve mêlé au framework frontend à la mode du jour — ou pire, à celui qui était à la mode hier —, qu’il faut s’aligner sur les préférences étranges d’un autre développeur obsédé par une seule façon de faire, ou qu’on commence à gérer des hacks « géniaux » tenus ensemble avec de l’espoir et du ruban adhésif, la complexité et les modes d’interaction augmentent exponentiellement
  • Le texte original regrette en fait la perte d’un âge d’or qui n’a jamais existé
    Je l’ai vécue, cette époque. Le JavaScript pur spécial IE6 a été remplacé par un jQuery buggé, puis par des applications monopage Angular impossibles à maintenir, puis par des bases de code React monstrueuses
  • Ça ressemble à une remarque qui trahit l’ignorance
    En réalité, c’est bien plus que ça
    J’ai vu beaucoup trop de candidats se présenter en entretien comme experts Next.js alors qu’ils ne savaient rien faire d’autre. Ce n’est pas une compétence, c’est juste de la connaissance, et aujourd’hui elle est disponible gratuitement partout
  • La capacité à comprendre dans quelle tour, à quel étage et dans quelle pièce se trouve cette abstraction qui fuit reste très précieuse, et il est possible que les LLM ne la voient pas
    Ce n’est pas parce qu’une chose n’a pas été parfaitement conçue dès le départ par un comité qu’il faut tout oublier, refermer le livre et laisser une machine faire les calculs
    Moi aussi, je fais la seconde option, donc je sais ce qu’on risque de rater, mais pas au point de me laisser berner au point de produire un chaos impossible à maintenir. Chaque fois que les agents déraillent, mes compétences frontend se révèlent vraiment utiles

• Dire que « le frontend était une compétence hautement spécialisée, qui exigeait de connaître le HTML sémantique, le CSS, les différences entre navigateurs, l’accessibilité, l’amélioration progressive, les performances réseau, la conception d’interfaces, les tests utilisateurs, etc. » fera sans doute bien rire la génération précédente de développeurs frontend, c’est-à-dire les développeurs C/C++
  Le web était perçu comme ayant fortement abaissé la barrière d’entrée et déspécialisé le métier. Les programmeurs assembleur pensaient probablement la même chose des développeurs C/C++

  • Chaque couche pense être la plus importante, la plus spécialisée et la plus qualifiée
    Mais toutes les couches ont tort. Chaque couche est construite sur les abstractions de la couche inférieure. Si on descend jusqu’à la physique et aux mathématiques, on découvre que même les théoriciens des ensembles partent d’axiomes supposés. Personne ne sait vraiment ce que font les logiciens
  • Cette citation ne vient pas de l’article et n’a rien à voir avec lui, donc je ne comprends pas ce qui se passe

• Le raisonnement du type « ce nouveau processus produit des résultats de moindre qualité, et c’est triste que beaucoup de gens semblent s’en moquer » semble reposer sur l’idée qu’avant l’IA, la majeure partie de ce travail était réalisée par des artisans qualifiés, dévoués à la qualité
  Quiconque a réellement travaillé dans l’industrie et reste honnête sait que ce n’était pas la réalité. Il y avait énormément de choses en dessous de la moyenne
  Et selon la manière dont on définit la « qualité », il est même difficile d’affirmer que les résultats de l’IA sont de moindre qualité. L’IA peut produire une uniformité gênante, mais en même temps les conventions apprises par les modèles « fonctionnent » souvent pour la majorité des utilisateurs finaux, qu’on les aime ou non, ce qui donne aussi pas mal de résultats tout à fait exploitables

  • C’est plutôt une logique du type « ajouter une brique de plus sur le mur »
    Il y avait déjà énormément de pression pour faire le strict minimum répondant aux exigences puis déclarer la mission accomplie. Maintenant, on a l’impression que cette pression est devenue ingérable
  • Quant à l’idée qu’avant l’IA, des artisans qualifiés étaient dévoués à la qualité, certaines personnes ont bien eu la chance de connaître quelques périodes comme celle-là dans leur carrière
    Cela dit, je suis d’accord pour dire que cela avait déjà disparu avant l’IA
  • Le seuil de qualité semble terriblement bas
  • Oui. Le web d’avant jQuery et Bootstrap était un désastre, et ce n’était pas agréable à coder non plus
    S’il faut parler de faible qualité, c’était plutôt la norme à l’époque

• J’ai récemment eu une réflexion similaire.
  Cela fait au moins 10 ans que je ne fais presque plus de développement frontend, mais je suis assez vieux pour me souvenir de l’époque, à la fin des années 2000, où soudain tout le monde a commencé à utiliser des frameworks au lieu de construire les GUI web à la main, et où ceux qui continuaient à écrire eux-mêmes HTML/CSS/JS et les requêtes de base de données se faisaient encore moquer. Les offres d’emploi se sont elles aussi mises d’un coup à demander Ruby on Rails, Django, Spring, GWT, puis plus tard Angular, au lieu de PHP/HTML/CSS/SQL/JS.
  La sensation est étrangement familière aujourd’hui. On pouvait créer une application web fonctionnelle en quelques minutes sans connaissance approfondie, et cela paraissait magique. Puis on se contentait de survoler la documentation et de chercher sur le web pour personnaliser le framework, jusqu’au moment où ça ne marchait plus, parce qu’on ne comprenait absolument pas comment l’intérieur fonctionnait. Comme pour les webapps en vibe coding, on reconnaissait de loin les applications web standards bricolées en un après-midi, mais elles impressionnaient beaucoup les managers.
  Ce qui est amusant, c’est que les développeurs parlent de leur modèle de pointe préféré un peu comme les développeurs GUI d’il y a 15 ou 20 ans parlaient de leur framework web favori. Ils personnifient l’outil, voire s’y identifient, se frustrent parce que ce qui marchait en version X s’est dégradé en X.1, et on retrouve les mêmes phrases du genre « maintenant je développe 10 fois plus vite » ou « je vais recommencer à écrire XYZ à la main ».

  • À l’inverse, l’usage ultérieur des frameworks a aussi été une bonne tentative de standardisation.
    Un GUI maison que personne ne sait maintenir n’est pas non plus un avantage.
    Personnellement, je rejette tout ce qui paraît trop « massif » comme Nuxt/Next, mais j’aime bien Vue. Cela dit, en ce moment j’ai surtout envie de supprimer la majeure partie du JavaScript et d’aller vers des solutions du style HTMX ou Alpine avec des templates côté serveur.
    À titre personnel, moins j’utilise de technologies, mieux c’est. Il fut un temps où les webapps embarquaient toutes sortes de choses inutiles avant même qu’on y ajoute une seule ligne de code personnalisé.
  • Déjà au début des années 2000, les développeurs web étaient fatigués de tout coder à la main et cherchaient de l’automatisation, sous forme de frameworks ou de CMS.
    En 2004 encore, j’ai créé un site avec une approche basique consistant à mettre des fichiers txt dans une arborescence de répertoires, puis à faire insérer leur contenu dans le HTML par PHP en ajoutant des balises à la place des retours à la ligne. À l’époque, l’alternative, c’était des systèmes de gestion de contenu lourds.
    Après être passé au travail par deux horribles frameworks PHP conçus par des lead devs, arriver sur Django a été une transition plus progressive et bien plus agréable.
    Bien sûr, si on pousse encore plus loin, par exemple en ajoutant du versioning aux objets, cela devient très délicat, rien ne garantit que ça fonctionne, et il n’y a plus de moyen de corriger les choses.
    Malgré tout, l’attitude elle-même paraît similaire à celle d’aujourd’hui.

• Nous sommes dans l’industrie du logiciel. Le cœur de cette industrie consiste à automatiser des tâches très répétitives.
  Les projets frontend sont très répétitifs, et maintenant l’IA s’en charge. C’est une excellente chose, et cela libère beaucoup de temps pour construire des choses plus intéressantes.
  La déqualification de techniques qui ne sont plus si pertinentes fait partie de l’industrie depuis l’invention de l’ordinateur. C’est simplement qu’on a résolu le problème, avec l’IA ou autrement.
  Il suffit de passer à autre chose et d’apprendre de nouvelles techniques. En pratique, utiliser efficacement l’IA est aussi une compétence que certains trouvent difficile. Les choses ne se fabriquent toujours pas toutes seules. On peut y arriver avec les bons prompts, mais est-ce qu’on prompte correctement ? Est-ce que l’outil fait bien ce qu’on lui demande ? Comment le sait-on ? A-t-on vérifié ? Moi aussi je passe énormément de temps à prompter des IA, et même si je m’améliore clairement, cela reste proche d’un travail à plein temps.
  Dans une dizaine d’années, on regardera probablement cette manière de faire comme une façon très inefficace de produire du logiciel. Les outils vont s’améliorer et l’IA va devenir plus autonome. Si vous passez vos journées à répéter les mêmes prompts, quelqu’un ou quelque chose devra aussi automatiser cela.

  • Le but du logiciel est d’encoder la volonté humaine dans un état communicable à la machine.
    Le reproche ici, c’est que cette automatisation risque d’encoder ce qu’on ne voulait pas.
  • Au lieu d’abandonner le frontend, cette nouvelle efficacité apportée par l’IA devrait libérer des ressources pour pousser plus loin le frontend comme le backend.
    Le monde a besoin de bien plus de logiciels qu’on n’est actuellement capables d’en produire.
  • Je ne vois absolument pas ce que veut dire « les projets frontend sont très répétitifs ».
    C’est un point de vue si mauvais que je ne sais même pas par où commencer à le contredire. Le caractère répétitif, ce serait que toutes les UI ont des boutons ?
    Si les gens croient vraiment cela, je comprends pourquoi l’UX est en ruine depuis les années 90 et n’a fait qu’empirer depuis.
  • Vous seriez peut-être surpris de constater qu’il n’y a pas tant de « choses intéressantes » à construire que ça.

• Le coding avec l’IA aide énormément à fabriquer des prototypes de produit, mais il produit aussi des produits qui ont de loin l’air d’avoir été faits par l’IA.
  Je viens justement de voir une startup faire une démo de son application, et elle avait exactement une allure d’UI de vibe coding.
  Les retours qu’ils ont reçus étaient froids, mais justes : « c’est plutôt pas mal, mais on voit trop que c’est fait avec l’IA, et dans ce cas d’autres personnes qui voudraient la même chose peuvent aussi la faire très vite avec l’IA, donc ce que vous essayez de vendre n’a pas beaucoup de valeur ».

  • J’aimerais que cela arrive plus souvent. Les UI générées par des LLM, et les gens qui les jugent suffisantes, sont difficiles à supporter.
  • Ce qui est drôle, c’est qu’il suffit de mettre en place un design system de base et un peu de CSS pour que le code frontend généré par l’IA s’intègre de manière assez naturelle.
    Mais la plupart des gens ne prennent même pas ce minimum de soin.
    Les coins arrondis restent une mode sans fin, et tout ce qui est déjà mal défini semble être contaminé par cette forme.
  • Cela sonne davantage comme un fantasme que comme quelque chose qui s’est réellement produit.
    Un investisseur en capital-risque compétent ne ferait pas ce genre de retour dénué de sens. Si c’est bien, c’est bien ; en quoi est-ce important que cela ait été fait avec l’IA ? Si le produit avait eu la même qualité sans donner une impression de vibe coding, alors ça aurait été acceptable ? C’est seulement un sujet qui préoccupe les personnes idéologiquement opposées à l’IA.

• J’ai parfois l’impression que les techniques du début des années 2000 permettant de créer des interfaces utilisateur complexes en HTML, sans AJAX ni manipulation du DOM, ont pratiquement disparu, comme les techniques de construction des pyramides
  Les jeunes développeurs full stack ont parfois un côté « déqualification », au point que beaucoup pensent par exemple qu’il faut du JavaScript pour faire de la validation de formulaire
  Dès qu’on commence à utiliser AJAX et à manipuler le DOM, la complexité des communications asynchrones mène presque inévitablement à quelque chose d’une ampleur comparable à React. Même si on peut écrire document.title="A new title" et qu’il n’est pas nécessaire d’importer quoi que ce soit, dès qu’on considère le frontend comme « mettre à jour l’UI quand les données arrivent du serveur », une application complexe doit mettre à jour plusieurs parties de l’UI, et à un moment on finit par créer quelque chose comme un mécanisme de communication ou un bus de gestion d’état. Aurait-on pu le concevoir autrement ? Bien sûr que oui
  S’il y a un problème dans l’écosystème React, ce n’est pas le fait de construire des abstractions sur d’autres abstractions, mais le fait que ces abstractions fuient. Si l’on crée quelque chose de très simple sans trop se soucier de l’apparence, on peut utiliser Bootstrap ou MUI sans comprendre le CSS. Mais pour produire un travail de niveau professionnel destiné à être présenté à des clients, il faut comprendre le HTML, le CSS, le JS, ainsi que tous les frameworks utilisés dans le projet

  • J’ai souvent l’impression que, surtout sur HN, React est utilisé comme une insulte en quatre lettres qui remplace un mécontentement plus large envers le web interactif dans son ensemble
    La plupart des gens qui critiquent React ne comprennent pas réellement quel problème React résout. Si vous leur montrez le code source d’une webapp suffisamment complexe qui ne dépend pas de React, ils y trouveront une imitation de React développée en interne

• Je ne suis pas d’accord avec l’idée qu’exploiter une application frontend avec le rendu côté serveur, le chargement différé, etc. de NextJS soit « plus facile » qu’à l’époque où l’on n’utilisait que du HTML, du JS et du CSS
  Le niveau de complexité et les attentes des utilisateurs n’ont plus rien à voir
  En plus, il y a environ 1000 fois plus d’ingénieurs qualifiés et il faut rivaliser avec le marché mondial. Au début des années 2000, il n’y avait presque pas de concurrence. Les compétences des travailleurs ont généralement une corrélation assez lâche avec le niveau exigé par le marché, mais aujourd’hui la concurrence est extrêmement forte