Portan JustHTML de Python a JavaScript: terminado en 4.5 horas con Codex CLI y GPT-5.2

 (simonwillison.net)
7 puntos por GN⁺ 2025-12-19 | 1 comentarios | Compartir por WhatsApp
  • Caso de una portación completa del parser HTML5 JustHTML de Python a JavaScript, implementada en unas 4.5 horas con Codex CLI y GPT-5.2
  • La nueva librería JustJSHTML es un parser HTML5 sin dependencias que pasa 9,200 pruebas de html5lib-tests y reproduce intacto el diseño original de la API
  • Todo el proceso se realizó con 8 prompts y algunas órdenes de seguimiento, y GPT-5.2 generó automáticamente 9,000 líneas de código y 43 commits
  • El proyecto quedó terminado como un open source completo, incluyendo commits automáticos, pruebas, documentación y generación de una página playground
  • Este experimento vuelve a plantear preguntas sobre la productividad real de los agentes de programación basados en LLM junto con problemas de copyright, ética y confiabilidad

Resumen del proyecto

  • JustHTML es un parser HTML5 compatible con el estándar desarrollado por Emil Stenström, escrito en Python y una implementación que pasa toda la suite de html5lib-tests
    • html5lib-tests es el estándar de pruebas de interoperabilidad entre parsers HTML5, usado en distintos proyectos como html5ever de Servo
  • Simon Willison decidió portar directamente este proyecto a JavaScript, usando Codex CLI y GPT-5.2 para hacerlo con la menor intervención manual posible
  • El resultado, JustJSHTML, funciona tanto en navegador como en Node.js y está escrito en JavaScript puro sin dependencias externas

Proceso de desarrollo

  • En el entorno local clonó los repositorios justhtml y html5lib-tests, y creó un nuevo directorio llamado justjshtml
  • Ejecutó Codex CLI con la opción --yolo (omite aprobaciones y sandbox) para usar el modelo GPT-5.2
  • En el primer prompt le indicó que analizara el código existente en Python y redactara una nueva especificación de API en JavaScript (spec.md)
    • Como etapa inicial (Milestone 0.5), pidió implementar una versión que pasara una prueba simple de parseo de documento HTML
  • Después, el desarrollo continuó automáticamente con instrucciones por etapas como “Implement Milestone 0.5” y “** commit and push often**”
    • Configuró GitHub Actions para ejecutar pruebas en cada commit
    • El resultado final fue de 43 commits, 9,000 líneas de código y 9,200 pruebas superadas

Resultados y entregables

  • Codex CLI usó un total de 2,089,858 tokens, y se ejecutó sin costo adicional dentro de la suscripción mensual de ChatGPT Plus
  • La librería terminada incluye las siguientes funciones
    • Extensiones de API como stream(), query()/matches() y toMarkdown()
    • Script de pruebas unitarias sin dependencias e integración con CI
    • Corrección de bugs puntuales, como un error en el manejo de la etiqueta <br>
  • También generó automáticamente playground.html, que permite probarla directamente en el navegador
  • El archivo README.md incluye ejemplos de uso, proceso de build y ejemplos para entornos Node.js y HTML

Implicaciones del uso de LLM

  • GPT-5.2 completó con supervisión mínima cientos de llamadas a herramientas y varias horas de trabajo continuo
  • Cuando es posible definir el problema con un enfoque guiado por pruebas, un agente de programación puede generar código de alta calidad de forma autónoma
  • Las tareas estructuradas como la portación entre lenguajes son especialmente eficientes para un LLM
  • El costo de generar código ha bajado en la práctica a un nivel casi gratuito, aunque el costo de mantener código validado sigue existiendo

Preguntas éticas y legales planteadas

  • Si hubo o no infracción de copyright sobre el código fuente original en Rust y Python
  • El problema de a quién pertenece el copyright del código generado por un LLM
  • El impacto que este tipo de desarrollo puede tener en el ecosistema open source
  • La confiabilidad del código generado automáticamente y la responsabilidad de usarlo en producción
  • Si es posible compararlo en calidad con código desarrollado durante meses por expertos humanos

Conclusión

  • Este caso muestra una nueva etapa de la automatización de la programación y demuestra el potencial práctico de los agentes de programación con IA
  • Al mismo tiempo, deja como tarea pendiente la necesidad de establecer criterios legales y éticos y de redefinir la forma de colaboración en open source

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-12-19
Comentarios en Hacker News

  • Lo más interesante de este caso es que un proyecto de portabilidad de librerías basado en pruebas independientes del lenguaje ahora se volvió mucho más viable en la práctica
    La clave es html5lib-tests, una colección de más de 9,000 pruebas para parsers de HTML5. Tanto html5ever de Servo (Rust), JustHTML de Emil (Python) y también mi versión en JavaScript usan estas pruebas
    Pude usar un agente de código para portar el código Python a JavaScript y hacerlo iterar automáticamente hasta pasar todas las pruebas
    Este tipo de suite de pruebas estandarizada es poco común, pero donde existe muestra un potencial enorme

    • Al combinar la especificación de WHATWG con las pruebas de html5lib, se vuelve mucho más potente
      Ayer hice en unas horas una versión tipada en OCaml, y dejé corriendo un agente para que construya automáticamente un validador HTML5 puro en OCaml
      Estoy combinando las pruebas de html5lib con las pruebas del validador para crear un validador HTML5 en OCaml con pocas dependencias
      Se siente como una especie de validación de tipos al revés: converger desde hechos dispersos (las pruebas) hacia una especificación estructurada
    • Ayer, al portar de Python a Rust, el LLM no lograba detectar el problema para nada. Al final, copié el original en Python dentro del proyecto Rust para compararlo y ahí se resolvió enseguida
      Parece bastante fuerte para el emparejamiento de patrones entre lenguajes. Desde la perspectiva del espacio latente, tiene sentido
    • El siguiente paso probablemente sea convertir las pruebas dependientes del proyecto a un formato independiente, validarlas contra el original y luego hacer el port
    • Los LLM son muy fuertes para la portabilidad entre lenguajes. En benchmarks como MLE-Bench, los agentes ya están al nivel de resolver competencias de Kaggle con rendimiento de medalla en 24 horas
      Da la sensación de que la era en la que la IA crea IA, como en el paper AI4AI, ya empezó
    • Por eso decidí no publicar las pruebas del proyecto actual por ahora. Normalmente las libero como open source, pero esta vez lo estoy reconsiderando

  • De hecho, el parser HTML5 de Firefox originalmente fue escrito en Java, y después se convirtió de manera semiautomática a C++ para Gecko
    Portar JustHTML en sí fue un buen experimento, pero personalmente creo que habría sido más productivo mover el código Java a TypeScript

    • Sorprendentemente, el parser en Java de Firefox todavía se sigue manteniendo
      Si ves la carpeta correspondiente y los commits recientes, hubo actualizaciones incluso en noviembre
    • Había muchos métodos mejores, pero tomé JustHTML como base porque me gustó el diseño de la API de Emil
      Me pareció interesante portar en una tarde a Python una librería que él construyó con más de 1,000 commits
    • Desde el punto de vista legal, el código portado a otro lenguaje sigue siendo una obra derivada
      Si tiene licencia MIT, hay que incluir tal cual el aviso de copyright y el texto de licencia del original
      Es decir, lo correcto es agregar tu información de copyright debajo de la línea de copyright original
    • En términos de depuración y auditoría, me parece mejor escribirlo en JavaScript
      La ventaja de TypeScript está en mejorar la experiencia del desarrollador, pero en código generado por máquina esa necesidad disminuye

  • Sobre la frase “el código es casi gratis”, el costo real depende de si las personas pueden entender y modificar ese código
    Incluso el código hecho por LLM termina necesitando intervención humana cuando aparecen bugs complejos o problemas de contexto

    • Pero tal vez algún día lleguemos a un mundo donde rehacer algo desde cero sea más barato y más rápido que mantenerlo

  • Si miras los resultados de prueba del repositorio original, pasa las 9,000 pruebas de html5lib-tests
    Pero cada navegador procesa las cosas de manera distinta. Por ejemplo, selectolax marca 68% según html5lib, pero comparado con Chrome coincide en más del 90%

    • Esto es un problema de manejo de namespaces. <svg title> es una etiqueta propia de SVG, así que el parser tiene que reconocerlo como tal
      Sería interesante correr también las pruebas en Chrome

  • También conecta con el post reciente en HN "El costo del software cayó 90%"

    • Aun así, ese texto simplifica demasiado. El experimento de Simon fue posible porque ya existían 9,000 pruebas independientes del lenguaje y un diseño de API existente
      La mayoría de los proyectos no tienen esas condiciones, así que es difícil generalizar

  • Sobre derechos de autor y cuestiones éticas, yo estoy portando proyectos con licencia MIT a versiones en Rust/Python usando Claude Code
    Creo que el espíritu del open source está en mejorar código existente y hacer crecer el ecosistema
    Pero nunca porto proyectos GPL

    • Sea cual sea la licencia, hay que respetar el copyright, y los ports hechos por LLM también se consideran obras derivadas
    • Quien eligió GPL lo hizo con una intención clara, así que intentar eludir la licencia usando LLM va en contra de ese espíritu

  • También hubo críticas diciendo que “es irresponsable preguntar por los problemas legales y éticos recién después de hacerlo así”

    • Pero asumí ese riesgo a propósito para provocar esta discusión
      Ahora me parece importante mostrar que esto “no solo es posible, sino sorprendentemente fácil”

  • Usar un enfoque oráculo también es práctico aunque no existan pruebas estándar
    Puedes capturar las entradas y salidas del programa original y usarlas como pruebas, y con herramientas como Hypothesis generar automáticamente miles de casos
    Estamos entrando en una era donde, más que el codebase, el activo principal pasa a ser la suite de pruebas misma

    • Incluso da para pensar si se podría construir una app completa solo con pruebas

  • GPT-5.2 costó $28.31 para generar 9,000 líneas completas de código JavaScript
    Con esa eficiencia, parece que en 5 a 10 años el papel de los desarrolladores junior e intermedios se va a reducir mucho
    Ver este cálculo de costos

    • Pero este es un caso ideal de portar un proyecto existente. Crear una librería nueva desde cero sigue siendo otra cosa
      Aun así, para los lenguajes con ecosistemas pequeños sí va a haber un cambio económico grande
    • El concepto de “ingeniero de software” no va a desaparecer; lo que cambiarán son el rol y las expectativas
    • También hubo quien respondió: “¿Acaso lo que hacemos todo el día es solo portar lenguajes?”. La realidad es bastante más compleja

  • No todos los ports con IA son exitosos. También hay casos fallidos → The port I couldn’t ship

    • El éxito depende mucho de la proporción entre el código fuente y las pruebas
      Si se acumulan datos sobre qué proyectos son fáciles y qué enfoques son más rápidos, saldría un análisis muy interesante
      Sería realmente interesante que Simon hiciera ese tipo de experimentos comparativos