JustHTML von Python nach JavaScript portiert: Mit Codex CLI und GPT-5.2 in 4,5 Stunden fertig

 (simonwillison.net)
7 Punkte von GN⁺ 2025-12-19 | 1 Kommentare | Auf WhatsApp teilen
  • Fallbeispiel einer vollständigen Portierung des HTML5-Parsers JustHTML von Python nach JavaScript, umgesetzt mit Codex CLI und GPT-5.2 in rund 4,5 Stunden
  • Die neue Bibliothek JustJSHTML ist ein HTML5-Parser ohne Abhängigkeiten, besteht 9.200 Tests aus den html5lib-tests und bildet das ursprüngliche API-Design originalgetreu nach
  • Der gesamte Prozess lief mit 8 Prompts und einigen Folgekommandos ab, wobei GPT-5.2 9.000 Zeilen Code und 43 Commits automatisch erzeugte
  • Das Projekt wurde als vollständiges Open-Source-Paket fertiggestellt, einschließlich automatischer Commits, Tests, Dokumentation und Generierung einer Playground-Seite
  • Dieses Experiment zeigt nicht nur die praktische Produktivität LLM-basierter Coding-Agenten, sondern wirft auch neue Fragen zu Urheberrecht, Ethik und Zuverlässigkeit auf

Projektüberblick

  • JustHTML ist ein von Emil Stenström entwickelter standardkonformer HTML5-Parser, geschrieben in Python und eine Implementierung, die die gesamten html5lib-tests besteht
    • Die html5lib-tests gelten als Standard für Interoperabilitätstests zwischen HTML5-Parsern und werden in verschiedenen Projekten wie Servos html5ever verwendet
  • Simon Willison entschied sich, dieses Projekt direkt nach JavaScript zu portieren, und setzte dafür Codex CLI und GPT-5.2 ein, mit minimaler manueller Arbeit
  • Das Ergebnis JustJSHTML läuft sowohl im Browser als auch in Node.js und ist in reinem JavaScript ohne externe Abhängigkeiten geschrieben

Entwicklungsprozess

  • Im lokalen Umfeld wurden die Repositories justhtml und html5lib-tests geklont und ein neues Verzeichnis justjshtml angelegt
  • Codex CLI wurde mit der Option --yolo gestartet, um das Modell GPT-5.2 auszuführen und Freigaben sowie Sandbox-Beschränkungen zu umgehen
  • Im ersten Prompt wurde angewiesen, den bestehenden Python-Code zu analysieren und daraus eine neue JavaScript-API-Spezifikation (spec.md) zu erstellen
    • Als erste Etappe (Milestone 0.5) sollte eine Version implementiert werden, die einfache Tests zum Parsen von HTML-Dokumenten besteht
    Anzeige
  • Anschließend lief die Entwicklung schrittweise automatisiert über Kommandos wie „Implement Milestone 0.5“ und „commit and push often“
    • GitHub Actions wurde eingerichtet, damit bei jedem Commit Tests ausgeführt werden
    • Insgesamt entstanden 43 Commits, 9.000 Zeilen Code und ein Ergebnis mit 9.200 bestandenen Tests

Ergebnisse und Artefakte

  • Codex CLI verbrauchte insgesamt 2.089.858 Tokens und das Ganze wurde im Rahmen eines monatlichen ChatGPT-Plus-Abos ohne zusätzliche Kosten durchgeführt
  • Die fertige Bibliothek enthält unter anderem folgende Funktionen
    • API-Erweiterungen wie stream(), query()/matches() und toMarkdown()
    • ein no-deps-Unit-Test-Skript sowie CI-Integration
    • Detailkorrekturen wie die Behebung eines Fehlers bei der Verarbeitung des Tags
  • playground.html wurde automatisch erzeugt, sodass direkt im Browser getestet werden kann
    Anzeige
  • README.md enthält Nutzungsanleitung, Build-Prozess sowie Beispiele für Node.js- und HTML-Umgebungen

Erkenntnisse zum LLM-Einsatz

  • GPT-5.2 erledigte mit minimaler Aufsicht hunderte Tool-Aufrufe und mehrere Stunden kontinuierlicher Arbeit
  • Wenn sich Probleme testgetrieben definieren lassen, können Coding-Agenten eigenständig hochgradig ausgereiften Code erzeugen
  • Sprachübergreifende Portierungen sind eine Art struktureller Aufgabe, die LLMs besonders effizient ausführen können
  • Die Kosten für Codegenerierung sind faktisch auf ein Niveau von „fast kostenlos“ gesunken, auch wenn die Pflege verifizierten Codes weiterhin Aufwand verursacht

Aufgeworfene ethische und rechtliche Fragen

  • Ob eine Urheberrechtsverletzung gegenüber dem ursprünglichen Rust- und Python-Code vorliegt
  • Wem das Urheberrecht an von LLMs erzeugtem Code zusteht
  • Welche Auswirkungen diese Art der Entwicklung auf das Open-Source-Ökosystem hat
  • Wie es um die Zuverlässigkeit automatisch erzeugten Codes und die Verantwortung bei Produktionseinsatz steht
  • Ob sich die Qualität mit Code vergleichen lässt, den menschliche Experten über Monate entwickelt haben

Fazit

  • Dieses Beispiel zeigt eine neue Phase der Programmierautomatisierung und belegt das praktische Potenzial von AI-Coding-Agenten
  • Gleichzeitig bleibt die Aufgabe, rechtliche und ethische Maßstäbe zu definieren und die Formen der Open-Source-Zusammenarbeit neu zu denken

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-19
Hacker-News-Kommentare

  • Das Interessanteste an diesem Fall ist, dass ein Bibliotheks-Portierungsprojekt auf Basis sprachunabhängiger Tests deutlich realistischer geworden ist
    Der Schlüssel ist html5lib-tests, eine Sammlung von mehr als 9.000 HTML5-Parser-Tests. Sowohl Servos html5ever (Rust), Emils JustHTML (Python) als auch meine JavaScript-Version nutzen diese Tests
    Mit einem Coding-Agenten konnte ich den Python-Code nach JavaScript portieren und ihn automatisch so lange iterieren lassen, bis alle Tests bestanden waren
    Solche standardisierten Test-Suites sind selten, aber wo es sie gibt, zeigen sie großes Potenzial

    • In Kombination mit der WHATWG-Spezifikation und den html5lib-Tests wird es noch viel mächtiger
      Ich habe gestern in wenigen Stunden eine typannotierte Version in OCaml erstellt und einen Agenten laufen lassen, der automatisch einen reinen OCaml-HTML5-Validator baut
      Ich kombiniere die html5lib-Tests mit den Validator-Tests, um einen OCaml-HTML5-Validator mit wenigen Abhängigkeiten zu bauen
      Es fühlt sich ein wenig wie Reverse Formal Verification an — ein Prozess, bei dem man aus verstreuten Fakten (Tests) zu einer strukturierten Spezifikation konvergiert
    • Gestern habe ich von Python nach Rust portiert, und das LLM hat das Problem überhaupt nicht gefunden. Als ich schließlich den Python-Originalcode in das Rust-Projekt kopierte und verglich, war es sofort gelöst
      Für Pattern Matching zwischen Sprachen scheint es ziemlich stark zu sein. Aus Sicht des Latent Space ergibt das Sinn
    • Der nächste Schritt wird wohl sein, projektabhängige Tests in ein unabhängiges Format zu überführen, sie gegen das Original zu validieren und dann zu portieren
    • LLMs sind beim Portieren zwischen Sprachen sehr stark. In Benchmarks wie MLE-Bench lösen Agenten Kaggle-Wettbewerbe innerhalb von 24 Stunden auf Medaillenniveau
      Es fühlt sich so an, als hätte die Ära, in der KI KI baut, wie im AI4AI-Paper, bereits begonnen
    • Aus diesem Grund habe ich entschieden, die Tests des aktuellen Projekts vorerst nicht zu veröffentlichen. Normalerweise veröffentliche ich als Open Source, aber diesmal überdenke ich das

  • Tatsächlich wurde der HTML5-Parser von Firefox ursprünglich in Java geschrieben und später halbautomatisch in C++ für Gecko umgewandelt
    Die JustHTML-Portierung selbst ist ein gutes Experiment, aber persönlich denke ich, dass es produktiver gewesen wäre, den Java-Code nach TypeScript zu übertragen

    • Überraschenderweise wird der Java-Parser von Firefox immer noch gepflegt
      Wenn man sich den betreffenden Ordner und die jüngsten Commits ansieht, gab es auch im November Updates
    • Es gab viele bessere Wege, aber mir gefiel Emils API-Design, deshalb habe ich JustHTML als Grundlage genommen
      Es war spannend, eine Bibliothek, die er in über 1.000 Commits aufgebaut hat, an einem Abend nach Python zu portieren
    • Aus rechtlicher Sicht ist auch in eine andere Sprache portierter Code weiterhin ein abgeleitetes Werk
      Bei einer MIT-Lizenz müssen der ursprüngliche Copyright-Hinweis und der Lizenztext unverändert enthalten bleiben
      Das heißt, korrekt wäre es, die eigene Copyright-Information unter der Copyright-Zeile des Originals hinzuzufügen
    • Für Debugging und Audits halte ich JavaScript für die bessere Wahl
      Der Vorteil von TypeScript liegt in der verbesserten Developer Experience, aber bei maschinell erzeugtem Code ist das weniger notwendig

  • Zu der Aussage „Code ist fast kostenlos“: Die tatsächlichen Kosten hängen davon ab, ob Menschen den Code verstehen und ändern können
    Auch von LLMs erzeugter Code braucht bei komplexen Bugs oder Kontextproblemen letztlich menschliches Eingreifen

    • Aber vielleicht kommt irgendwann eine Welt, in der Neuerstellen billiger und schneller ist als Wartung

  • Laut den Testergebnissen des Original-Repositories besteht es alle 9.000 Tests aus html5lib-tests
    Allerdings verhalten sich Browser unterschiedlich. selectolax erreicht nach html5lib nur 68 %, stimmt im Vergleich zu Chrome aber zu über 90 % überein

    • Das ist ein Problem der Namespace-Behandlung. <svg title> ist ein SVG-spezifisches Tag, und der Parser muss das erkennen
      Es wäre interessant, die Tests auch in Chrome laufen zu lassen

  • Das passt auch zum Kontext des kürzlich auf HN erschienenen Beitrags "Die Kosten von Software sind um 90 % gesunken"

    • Allerdings ist dieser Beitrag eine vereinfachte Behauptung. Simons Experiment war nur möglich, weil es 9.000 sprachunabhängige Tests und ein bestehendes API-Design gab
      Die meisten Projekte haben diese Voraussetzungen nicht, daher ist eine Verallgemeinerung schwierig

  • Zum Thema Urheberrecht und Ethik: Ich portiere gerade ein MIT-lizenziertes Projekt mit Claude Code nach Rust/Python
    Ich denke, der Geist von Open Source besteht darin, bestehenden Code zu verbessern und so das Ökosystem weiterzuentwickeln
    GPL-Projekte portiere ich allerdings niemals

    • Unabhängig von der Lizenz muss das Urheberrecht respektiert werden, und auch von LLMs erzeugte Portierungen gelten als abgeleitete Werke
    • Entwickler, die sich für GPL entschieden haben, hatten eine klare Absicht, daher beschädigt es diesen Geist, mit LLMs eine Umgehung der Lizenz zu versuchen

  • Es gab auch Kritik, dass es verantwortungslos sei, erst auf diese Weise etwas zu bauen und erst danach nach rechtlichen und ethischen Problemen zu fragen

    • Aber ich bin dieses Risiko absichtlich eingegangen, um diese Diskussion auszulösen
      Ich halte es derzeit für wichtig zu zeigen, dass so etwas „nicht nur möglich ist, sondern überraschend einfach“

  • Auch ohne Standardtests ist der Oracle-Ansatz praktisch
    Man kann die Ein- und Ausgaben des Originalprogramms aufzeichnen und als Tests verwenden und mit Tools wie Hypothesis automatisch Tausende Fälle generieren
    Wir leben jetzt in einer Zeit, in der nicht mehr die Codebasis, sondern die Test-Suite selbst das zentrale Asset ist

    • Tatsächlich fragt man sich schon, ob man eine komplette App nur aus Tests bauen könnte

  • GPT-5.2 kostete $28.31, um 9.000 Zeilen vollständigen JavaScript-Code zu erzeugen
    Bei dieser Effizienz scheint es, als würde die Rolle von Junior- und Mid-Level-Entwicklern in 5 bis 10 Jahren stark schrumpfen
    Siehe Link zur Kostenberechnung

    • Allerdings ist dies ein idealer Fall der Portierung eines bestehenden Projekts. Eine neue Bibliothek von Grund auf zu erstellen, ist weiterhin etwas anderes
      Trotzdem wird es für Sprachen mit kleinem Ökosystem große wirtschaftliche Veränderungen geben
    • Das Konzept des „Software Engineers“ wird nicht verschwinden, sondern nur seine Rolle und die Erwartungen daran werden sich ändern
    • Es gab auch den Einwand: „Verbringen wir wirklich den ganzen Tag nur mit Sprachportierungen?“ Die Realität ist deutlich komplexer

  • Nicht jede KI-Portierung ist erfolgreich. Es gibt auch Gegenbeispiele → The port I couldn’t ship

    • Der Erfolg hängt stark vom Verhältnis von Quellcode zu Tests ab
      Wenn sich Daten dazu ansammeln, welche Projekte leicht sind und welcher Ansatz schneller ist, wäre das eine spannende Analyse
      Es wäre wirklich interessant, wenn Simon solche Vergleichsexperimente durchführen würde