Portage de JustHTML de Python vers JavaScript : réalisé en 4,5 heures avec Codex CLI et GPT-5.2

 (simonwillison.net)
7 points par GN⁺ 2025-12-19 | 1 commentaires | Partager sur WhatsApp
  • Cas de portage complet du parseur HTML5 JustHTML de Python vers JavaScript, réalisé en environ 4,5 heures à l’aide de Codex CLI et GPT-5.2
  • La nouvelle bibliothèque JustJSHTML est un parseur HTML5 sans dépendances qui réussit 9 200 tests de html5lib-tests tout en reproduisant fidèlement la conception de l’API d’origine
  • L’ensemble du processus s’est déroulé avec 8 prompts et quelques commandes de suivi, GPT-5.2 générant automatiquement 9 000 lignes de code et 43 commits
  • Le projet a été finalisé sous la forme d’un véritable projet open source, incluant commits automatiques, tests, documentation et génération d’une page playground
  • Cette expérience met en lumière à la fois la productivité concrète des agents de codage basés sur des LLM et de nouvelles questions de droit d’auteur, d’éthique et de fiabilité

Aperçu du projet

  • JustHTML est un parseur HTML5 conforme au standard développé par Emil Stenström, écrit en Python, dont l’implémentation réussit l’ensemble des tests html5lib-tests
    • html5lib-tests constitue le standard des tests d’interopérabilité entre parseurs HTML5 et est utilisé par divers projets, dont html5ever de Servo
  • Simon Willison a décidé de porter lui-même ce projet en JavaScript, en s’appuyant sur Codex CLI et GPT-5.2 avec un minimum d’intervention manuelle
  • Le résultat, JustJSHTML, fonctionne à la fois dans le navigateur et sous Node.js et est écrit en JavaScript pur, sans dépendance externe

Processus de développement

  • En local, clonage des dépôts justhtml et html5lib-tests, puis création d’un nouveau répertoire justjshtml
  • Exécution de Codex CLI avec l’option --yolo (contournement des validations et du sandboxing) pour lancer le modèle GPT-5.2
  • Dans le premier prompt, instruction donnée d’analyser le code Python existant afin de rédiger une nouvelle spécification d’API JavaScript (spec.md)
    • À l’étape initiale (Milestone 0.5), mise en œuvre d’une version capable de réussir un test simple d’analyse d’un document HTML
  • Ensuite, progression automatique par étapes via des commandes telles que “Implement Milestone 0.5” et “commit and push often”
    • Configuration de GitHub Actions pour exécuter les tests à chaque commit
    • Au total, génération de 43 commits, 9 000 lignes de code et 9 200 tests réussis

Résultats et livrables

  • Codex CLI a consommé au total 2 089 858 tokens, le tout dans l’abonnement mensuel ChatGPT Plus sans coût supplémentaire
  • La bibliothèque finalisée inclut notamment
    • des extensions d’API comme stream(), query()/matches() et toMarkdown()
    • un script de tests unitaires sans dépendances et son intégration CI
    • la correction de bugs de détail, comme une erreur de traitement de la balise
  • Un fichier playground.html a été généré automatiquement pour permettre des tests directs dans le navigateur
  • Le README.md comprend des exemples d’utilisation, le processus de build et des exemples pour Node.js et HTML

Ce que cela indique sur l’usage des LLM

  • GPT-5.2 a mené à bien, avec une supervision minimale, des centaines d’appels d’outils et plusieurs heures de travail continu
  • Lorsqu’un problème peut être défini de manière pilotée par les tests, un agent de codage peut produire de façon autonome un code très abouti
  • Les tâches structurées comme le portage entre langages sont particulièrement bien adaptées aux LLM
  • Le coût de génération du code est tombé à un niveau pratiquement “quasi gratuit”, même si le coût de maintenance d’un code validé demeure

Questions éthiques et juridiques soulevées

  • La question d’une éventuelle violation du droit d’auteur du code source original en Rust et en Python
  • Le problème de l’attribution du droit d’auteur sur le code généré par LLM
  • L’impact de cette méthode de développement sur l’écosystème open source
  • La fiabilité du code généré automatiquement et la responsabilité de son usage en production
  • La possibilité de comparer sa qualité à celle d’un code développé pendant plusieurs mois par des experts humains

Conclusion

  • Ce cas illustre une nouvelle étape dans l’automatisation de la programmation et démontre le potentiel pratique des agents de codage IA
  • Il souligne aussi la nécessité de définir des cadres juridiques et éthiques et de redéfinir les modes de collaboration open source

À lire aussi

1 commentaires

 
GN⁺ 2025-12-19
Avis Hacker News

  • Ce qu’il y a de plus intéressant dans ce cas, c’est qu’un projet de portage de bibliothèque fondé sur des tests indépendants du langage est devenu bien plus réaliste
    La clé, c’est html5lib-tests, une collection de plus de 9 000 tests de parseur HTML5. html5ever de Servo (Rust), JustHTML d’Emil (Python) et ma version JavaScript utilisent tous ces tests
    J’ai pu utiliser un agent de codage pour porter le code Python vers JavaScript et le faire tourner automatiquement en boucle jusqu’à ce que tous les tests passent
    Ce type de suite de tests standardisée est rare, mais là où elle existe, elle montre un énorme potentiel

    • En combinant la spec WHATWG et les tests html5lib, cela devient encore plus puissant
      J’ai créé hier en quelques heures une version typée en OCaml, et j’ai laissé un agent construire automatiquement un validator HTML5 pur OCaml
      Je combine les tests html5lib et les tests du validator pour créer un validator HTML5 OCaml avec peu de dépendances
      Cela ressemble à une sorte de vérification formelle inversée — on converge vers une spécification structurée à partir de faits dispersés, les tests
    • Hier, en portant du Python vers Rust, le LLM n’arrivait absolument pas à trouver le problème. Au final, dès que j’ai copié l’original Python dans le projet Rust pour les comparer, le problème a été résolu immédiatement
      Il semble assez fort pour le pattern matching entre langages. Vu sous l’angle de l’espace latent, cela se tient
    • La prochaine étape sera sans doute de convertir les tests dépendants d’un projet vers un format indépendant, puis de les valider avec l’original avant de porter
    • Les LLM sont très forts pour le portage entre langages. Sur des benchmarks comme MLE-Bench, les agents atteignent déjà un niveau où ils résolvent des compétitions Kaggle avec une médaille en moins de 24 heures
      On a déjà l’impression d’être entrés dans une époque où l’IA construit de l’IA, comme dans l’article AI4AI
    • C’est pour cette raison que, pour l’instant, j’ai décidé de ne pas publier les tests du projet. D’habitude je publie en open source, mais cette fois je réfléchis encore

  • En réalité, le parseur HTML5 de Firefox a d’abord été écrit en Java, puis converti de façon semi-automatique en C++ pour Gecko
    Le portage de JustHTML est en soi une bonne expérience, mais personnellement j’ai l’impression qu’il aurait été plus productif de porter le code Java vers TypeScript

    • Fait étonnant, le parseur Java de Firefox est toujours maintenu
      Quand on regarde le dossier correspondant et les commits récents, il y a encore eu des mises à jour en novembre
    • Il y avait sans doute de meilleures méthodes, mais j’aimais le design d’API d’Emil, donc j’ai choisi de partir de JustHTML
      Je trouvais intéressant de voir si l’on pouvait porter en une soirée vers Python une bibliothèque qu’il a construite à travers plus de 1 000 commits
    • D’un point de vue juridique, du code porté dans un autre langage reste malgré tout une œuvre dérivée
      Avec une licence MIT, il faut toujours inclure tel quel l’avis de copyright d’origine et le texte de licence
      Autrement dit, la bonne pratique consiste à ajouter ses propres informations de copyright sous la ligne de copyright originale
    • Du point de vue du débogage et de l’audit, je pense qu’écrire en JavaScript est préférable
      L’avantage de TypeScript est surtout d’améliorer l’expérience développeur, et ce besoin diminue avec du code généré par machine

  • À propos de l’idée que « le code est presque gratuit », le vrai coût dépend en réalité de la capacité des humains à comprendre et modifier ce code
    Même pour du code produit par un LLM, l’intervention humaine reste nécessaire dès qu’il s’agit de bugs complexes ou de problèmes de contexte

    • Mais il se peut qu’un jour on vive dans un monde où refaire quelque chose de zéro coûtera moins cher et ira plus vite que le maintenir

  • Les résultats de tests du dépôt d’origine montrent que les 9 000 tests de html5lib-tests passent tous
    Mais chaque navigateur a un comportement différent. Par exemple, selectolax n’est qu’à 68 % selon html5lib, mais dépasse les 90 % de correspondance par rapport à Chrome

    • C’est un problème de gestion des espaces de noms. <svg title> est une balise propre à SVG, et le parseur doit le reconnaître comme tel
      Ce serait intéressant d’exécuter aussi les tests dans Chrome

  • Cela fait aussi écho au billet récemment publié sur HN, "Le coût du logiciel a-t-il baissé de 90 % ?"

    • Cela dit, ce billet simplifie trop les choses. Si l’expérience de Simon a été possible, c’est parce qu’il disposait de 9 000 tests indépendants du langage et d’un design d’API existant
      La plupart des projets ne réunissent pas ces conditions, donc il est difficile de généraliser

  • Sur les questions de droit d’auteur et d’éthique, je suis en train de porter des projets sous licence MIT vers Rust/Python avec Claude Code
    Je pense que l’esprit de l’open source consiste à améliorer le code existant pour faire progresser l’écosystème
    En revanche, je ne porte jamais de projets sous GPL

    • Quelle que soit la licence, le copyright doit être respecté, et un portage produit par LLM est lui aussi considéré comme une œuvre dérivée
    • Les développeurs qui choisissent la GPL le font avec une intention claire, donc tenter de contourner la licence via un LLM revient à en trahir l’esprit

  • Il y a aussi eu des critiques du type : « créer cela d’abord, puis seulement poser la question des problèmes juridiques et éthiques, c’est irresponsable »

    • Mais j’ai volontairement pris ce risque pour provoquer cette discussion
      À ce stade, je pense qu’il est important de montrer que ce genre de chose est non seulement possible, mais aussi étonnamment facile

  • L’approche par oracle est pratique même sans test standard
    On peut capturer les entrées/sorties du programme original pour en faire des tests, puis générer automatiquement des milliers de cas avec un outil comme Hypothesis
    Nous entrons désormais dans une époque où l’actif principal n’est plus la base de code, mais la suite de tests elle-même

    • Cela fait même se demander s’il serait possible de créer une application entière uniquement à partir des tests

  • GPT-5.2 a coûté 28,31 $ pour générer 9 000 lignes complètes de code JavaScript
    Avec une telle efficacité, on a l’impression que le rôle des développeurs juniors et intermédiaires pourrait fortement diminuer dans les 5 à 10 prochaines années
    Voir le lien de calcul des coûts

    • Mais il s’agit ici d’un cas idéal de portage d’un projet existant. Créer une nouvelle bibliothèque à partir de zéro reste une tout autre affaire
      Malgré tout, cela entraînera probablement de grands changements économiques pour les langages dotés d’un petit écosystème
    • La notion d’« ingénieur logiciel » ne va pas disparaître, ce sont plutôt le rôle et les attentes qui vont évoluer
    • Certains ont aussi rétorqué : « comme si on passait nos journées à ne faire que du portage entre langages ». La réalité est évidemment bien plus complexe

  • Tous les portages par IA ne réussissent pas. Il existe aussi des échecs → The port I couldn’t ship

    • La réussite dépend fortement du rapport entre le code source et la quantité de tests
      Ce serait une analyse intéressante si l’on accumulait des données sur les projets faciles, ceux qui ne le sont pas, et les approches les plus rapides
      Ce serait vraiment passionnant si Simon faisait ce type d’expérience comparative