Portando o JustHTML de Python para JavaScript: concluído em 4,5 horas com Codex CLI e GPT-5.2

 (simonwillison.net)
7 pontos por GN⁺ 2025-12-19 | 1 comentários | Compartilhar no WhatsApp
  • O parser HTML5 JustHTML foi totalmente portado de Python para JavaScript, em um caso concluído em cerca de 4,5 horas usando Codex CLI e GPT-5.2
  • A nova biblioteca JustJSHTML é um parser HTML5 sem dependências, passa em 9.200 testes do html5lib-tests e reproduz fielmente o design da API original
  • Todo o processo foi conduzido com 8 prompts e alguns comandos de acompanhamento, com o GPT-5.2 gerando automaticamente 9.000 linhas de código e 43 commits
  • O projeto foi finalizado como um pacote open source completo, incluindo commits automáticos, testes, documentação e geração de uma página playground
  • Este experimento levanta novas questões sobre a produtividade prática de agentes de programação baseados em LLM, além de direitos autorais, ética e confiabilidade

Visão geral do projeto

  • JustHTML é um parser HTML5 compatível com os padrões desenvolvido por Emil Stenström, escrito em Python e com uma implementação que passa em toda a suíte html5lib-tests
    • O html5lib-tests é o padrão de testes de interoperabilidade entre parsers HTML5 e é usado em vários projetos, como o html5ever do Servo
  • Simon Willison decidiu portar diretamente este projeto para JavaScript, usando Codex CLI e GPT-5.2 com o mínimo possível de trabalho manual
  • O resultado, JustJSHTML, funciona tanto em navegadores quanto em ambientes Node.js e foi escrito em JavaScript puro, sem dependências externas

Processo de desenvolvimento

  • No ambiente local, ele clonou os repositórios justhtml e html5lib-tests e criou um novo diretório, justjshtml
  • O Codex CLI foi executado com a opção --yolo (ignorando aprovações e sandbox) para rodar o modelo GPT-5.2
  • No primeiro prompt, foi instruído a analisar o código Python existente e escrever uma nova especificação de API em JavaScript (spec.md)
    • Como etapa inicial (Milestone 0.5), foi implementada uma versão que passasse em testes simples de parsing de documentos HTML
  • Depois disso, o desenvolvimento prosseguiu automaticamente em etapas com comandos como “Implement Milestone 0.5” e “** commit and push often**”
    • O GitHub Actions foi configurado para executar os testes a cada commit
    • O resultado final teve 43 commits, 9.000 linhas de código e 9.200 testes aprovados

Resultados e entregáveis

  • O Codex CLI usou ao todo 2.089.858 tokens e a tarefa foi realizada sem custo adicional dentro da assinatura mensal do ChatGPT Plus
  • A biblioteca final inclui os seguintes recursos
    • Expansões de API como stream(), query()/matches() e toMarkdown()
    • Script de testes unitários sem dependências e integração com CI
    • Correções de bugs específicos, como um erro no tratamento da tag <br>
  • Um playground.html foi gerado automaticamente, permitindo testar diretamente no navegador
  • O README.md inclui modo de uso, processo de build e exemplos para ambientes Node.js e HTML

Implicações do uso de LLM

  • O GPT-5.2 concluiu centenas de chamadas de ferramentas e várias horas de trabalho contínuo com supervisão mínima
  • Quando é possível definir o problema com base em testes, agentes de programação conseguem gerar código de alta qualidade de forma autônoma
  • Trabalhos estruturados, como portar código entre linguagens, são executados com grande eficiência por LLMs
  • O custo de gerar código caiu na prática para um nível “quase gratuito”, embora o custo de manter código validado continue existindo

Questões éticas e legais levantadas

  • A possibilidade de violação de direitos autorais do código original em Rust e Python
  • A questão de a quem pertencem os direitos autorais sobre o código gerado por LLM
  • O impacto que esse tipo de desenvolvimento pode ter no ecossistema open source
  • A confiabilidade do código gerado automaticamente e a responsabilidade por seu uso em produção
  • A possibilidade de comparar sua qualidade com a de código desenvolvido por especialistas humanos ao longo de meses

Conclusão

  • Este caso mostra uma nova etapa da automação da programação e comprova o potencial prático de agentes de codificação com IA
  • Ao mesmo tempo, deixa como desafio a necessidade de definir padrões legais e éticos e de redefinir as formas de colaboração no open source

Leituras relacionadas

1 comentários

 
GN⁺ 2025-12-19
Opiniões do Hacker News

  • O ponto mais interessante deste caso é que projetos de portar bibliotecas com base em testes independentes de linguagem ficaram muito mais realisticamente viáveis
    O núcleo disso é o html5lib-tests, um conjunto com mais de 9.000 testes de parser HTML5. O html5ever do Servo (Rust), o JustHTML do Emil (Python) e a minha versão em JavaScript usam esses testes
    Foi possível usar um agente de programação para portar o código Python para JavaScript e repetir automaticamente até passar em todos os testes
    Esse tipo de suite de testes padronizada é raro, mas onde existe mostra um grande potencial

    • Combinar a especificação WHATWG com os testes do html5lib torna isso muito mais poderoso
      Ontem, em poucas horas, criei uma versão com tipos explícitos em OCaml e deixei um agente rodando para construir automaticamente um validador HTML5 puro em OCaml
      Estou combinando os testes do html5lib com os testes do validator para criar um validador HTML5 em OCaml com poucas dependências
      Isso parece uma espécie de verificação de tipo reversa — um processo de convergir de fatos dispersos (testes) para uma especificação estruturada
    • Ontem eu estava portando de Python para Rust e o LLM simplesmente não conseguia encontrar o problema. No fim, copiei o original em Python para dentro do projeto Rust para comparar e aí resolveu na hora
      Parece ser bastante forte em casamento de padrões entre linguagens. Faz sentido quando se pensa no espaço latente
    • O próximo passo provavelmente será converter os testes dependentes do projeto para um formato independente, validá-los contra o original e então fazer o port
    • LLMs são muito fortes em portar entre linguagens. Em benchmarks como o MLE-Bench, os agentes já chegam ao nível de resolver competições do Kaggle em faixa de medalha dentro de 24 horas
      Parece que já começou a era em que IA cria IA, como no artigo AI4AI
    • Por isso, decidi não publicar os testes do projeto atual por enquanto. Normalmente eu liberaria como open source, mas desta vez estou repensando

  • Na verdade, o parser HTML5 do Firefox foi originalmente escrito em Java e depois convertido de forma semiautomática para C++ para o Gecko
    Portar o JustHTML em si é um bom experimento, mas pessoalmente acho que teria sido mais produtivo levar o código Java para TypeScript

    • Surpreendentemente, o parser em Java do Firefox ainda é mantido
      Pelas pastas relacionadas e pelos commits recentes, houve atualizações até em novembro
    • Havia muitos jeitos melhores, mas eu gostei do design de API do Emil e por isso usei o JustHTML como base
      Achei interessante tentar portar para Python, em uma noite, uma biblioteca que ele construiu ao longo de mais de 1.000 commits
    • Do ponto de vista legal, código portado mudando de linguagem continua sendo uma obra derivada
      Se for licença MIT, é preciso incluir integralmente o aviso de copyright original e o texto da licença
      Ou seja, o correto é adicionar a sua própria informação de copyright abaixo da linha de copyright original
    • Em termos de depuração e auditoria, acho melhor escrever em JavaScript
      A vantagem do TypeScript é melhorar a experiência do desenvolvedor, e essa necessidade diminui em código gerado por máquina

  • Sobre a frase “código é quase de graça”, o custo real depende de se humanos conseguem entender e modificar o código
    Mesmo código feito por LLM acaba exigindo intervenção humana em bugs complexos ou problemas de contexto

    • Mas talvez um dia chegue um mundo em que recriar seja mais barato e mais rápido do que manter

  • Pelos resultados de teste do repositório original, ele passa em todos os 9.000 testes do html5lib-tests
    Mas cada navegador trata isso de forma diferente. Por exemplo, o selectolax fica em 68% pelo critério do html5lib, mas comparado ao Chrome passa de 90% de correspondência

    • Isso é um problema de tratamento de namespaces. <svg title> é uma tag específica de SVG, então o parser precisa reconhecer isso
      Seria interessante rodar os testes também no Chrome

  • Isso também se conecta ao post recente no HN "O custo do software caiu 90%"

    • Só que esse texto simplifica demais. O experimento do Simon só foi possível porque já existiam 9.000 testes independentes de linguagem e um design de API existente
      A maioria dos projetos não tem essas condições, então é difícil generalizar

  • Sobre copyright e ética, eu estou portando projetos sob licença MIT para versões em Rust/Python com o Claude Code
    Acho que o espírito do open source é melhorar código existente e fazer o ecossistema evoluir
    Mas nunca porto projetos GPL

    • Independentemente da licença, o copyright precisa ser respeitado, e ports feitos por LLM também são considerados obras derivadas
    • Quem escolheu GPL fez isso com uma intenção clara, então tentar contornar a licença usando LLM fere esse espírito

  • Também houve a crítica de que “fazer isso primeiro e só depois perguntar sobre problemas legais e éticos é irresponsável”

    • Mas eu assumi esse risco de propósito para provocar essa discussão
      Neste momento, acho importante mostrar que isso “não é apenas possível, mas surpreendentemente fácil”

  • A abordagem de oráculo é prática mesmo sem testes padrão
    Dá para capturar a entrada e saída do programa original e usar isso como teste, além de gerar automaticamente milhares de casos com ferramentas como o Hypothesis
    Agora estamos entrando numa era em que, em vez da base de código, o principal ativo passa a ser a própria suite de testes

    • Chega até a fazer pensar se seria possível construir um app inteiro só a partir dos testes

  • O GPT-5.2 custou US$ 28,31 para gerar 9.000 linhas de JavaScript completo
    Com esse nível de eficiência, parece provável que, nos próximos 5 a 10 anos, o papel de desenvolvedores júnior e pleno diminua bastante
    Veja o link com o cálculo de custo

    • Mas este é um caso ideal de port de um projeto existente. Criar uma biblioteca nova do zero ainda é outra história
      Ainda assim, isso deve causar grandes mudanças econômicas em linguagens com ecossistemas pequenos
    • O conceito de “engenheiro de software” não vai desaparecer; só o papel e as expectativas vão mudar
    • Também houve quem retrucasse: “por acaso passamos o dia todo só portando linguagem?”. A realidade é muito mais complexa

  • Nem todo port com IA dá certo. Também há casos de fracasso → The port I couldn’t ship

    • O sucesso depende muito da proporção entre código-fonte e testes
      Se começarem a surgir dados sobre quais projetos são fáceis, ou qual abordagem é mais rápida, isso pode render uma análise bem interessante
      Seria muito interessante se o Simon fizesse esse tipo de experimento comparativo