JustHTML का Python से JavaScript में पोर्ट: Codex CLI और GPT-5.2 के साथ 4.5 घंटे में पूरा

• HTML5 parser JustHTML को Python से पूरी तरह JavaScript में port करने का एक उदाहरण, जिसे Codex CLI और GPT-5.2 की मदद से लगभग 4.5 घंटे में लागू किया गया
• नई लाइब्रेरी JustJSHTML एक dependency-free HTML5 parser है, जो html5lib-tests के 9,200 tests पास करती है और मूल API डिज़ाइन को ज्यों का त्यों दोहराती है
• पूरी प्रक्रिया 8 prompts और कुछ follow-up commands के साथ पूरी हुई, और GPT-5.2 ने 9,000 lines of code और 43 commits अपने-आप तैयार किए
• प्रोजेक्ट auto-commit, test, documentation, और playground page generation सहित एक पूर्ण open source रूप में पूरा हुआ
• यह प्रयोग LLM-आधारित coding agent की वास्तविक productivity के साथ-साथ copyright, ethics, और reliability से जुड़े सवाल भी सामने लाता है

---

प्रोजेक्ट अवलोकन

• JustHTML Emil Stenström द्वारा विकसित एक standards-compliant HTML5 parser है, जो Python में लिखा गया है और html5lib-tests का पूरा suite पास करता है
  • html5lib-tests, HTML5 parsers के बीच interoperability testing का standard है, और Servo के html5ever सहित कई प्रोजेक्ट्स में इस्तेमाल होता है
• Simon Willison ने इस प्रोजेक्ट को सीधे JavaScript में port करने का फैसला किया, और Codex CLI व GPT-5.2 का उपयोग करके इसे न्यूनतम manual work के साथ आगे बढ़ाया
• तैयार परिणाम JustJSHTML browser और Node.js दोनों environments में चलता है, और बिना external dependencies के pure JavaScript में लिखा गया है

विकास प्रक्रिया

• लोकल environment में justhtml और html5lib-tests repositories को clone किया गया, और नई directory justjshtml बनाई गई
• Codex CLI को --yolo option (approval और sandbox bypass) के साथ चलाकर GPT-5.2 model इस्तेमाल किया गया
• पहले prompt में मौजूदा Python code का विश्लेषण करके नई JavaScript API specification (spec.md) लिखने का निर्देश दिया गया
  • शुरुआती चरण (Milestone 0.5) में सरल HTML document parsing test पास करने वाला संस्करण लागू किया गया
• इसके बाद चरण-दर-चरण “Implement Milestone 0.5”, “** commit and push often**” जैसे commands के जरिए automated development चलाया गया
  • GitHub Actions सेट करके हर commit पर tests चलाए गए
  • कुल 43 commits, 9,000 lines of code, और 9,200 tests पास करने वाला परिणाम तैयार हुआ

परिणाम और आउटपुट

• Codex CLI ने कुल 2,089,858 tokens इस्तेमाल किए, और यह ChatGPT Plus की मासिक subscription के भीतर बिना अतिरिक्त लागत के किया गया
• तैयार लाइब्रेरी में ये features शामिल हैं
  • stream(), query()/matches(), toMarkdown() जैसी API extensions
  • no-deps unit test script और CI integration
  • tag handling error जैसे सूक्ष्म bugs का समाधान
• playground.html अपने-आप बनाया गया, जिससे browser में सीधे test किया जा सकता है
  • GitHub Pages के जरिए https://simonw.github.io/justjshtml/playground.html पर चलाया जा सकता है
• README.md में usage, build process, और Node.js व HTML environments के examples शामिल हैं

LLM उपयोग के संकेत

• GPT-5.2 ने सैकड़ों tool calls और कई घंटों के लगातार काम को न्यूनतम supervision में पूरा किया
• जहाँ test-driven problem definition संभव हो, वहाँ coding agents काफी परिपक्व code को स्वायत्त रूप से तैयार कर सकते हैं
• भाषाओं के बीच porting जैसे संरचित काम LLM बहुत प्रभावी ढंग से कर सकता है
• code generation की लागत व्यावहारिक रूप से ‘लगभग मुफ्त’ स्तर तक गिर गई है, लेकिन verified code को बनाए रखने की लागत अब भी बनी हुई है

उठे नैतिक और कानूनी प्रश्न

• Rust और Python मूल code के copyright infringement की संभावना
• LLM द्वारा बनाए गए code के copyright ownership का सवाल
• इस तरह की development शैली का open source ecosystem पर प्रभाव
• auto-generated code की reliability और production use की accountability
• मानव विशेषज्ञों द्वारा महीनों में विकसित code के साथ quality comparison की संभावना

निष्कर्ष

• यह उदाहरण programming automation के एक नए चरण को दिखाता है और AI coding agents की व्यावहारिक क्षमता को साबित करता है
• साथ ही यह कानूनी और नैतिक मानकों को स्थापित करने की जरूरत और open source collaboration के तरीकों को फिर से परिभाषित करने की चुनौती भी छोड़ता है

[GN⁺]

Hacker News की राय

• इस मामले में सबसे दिलचस्प बात यह है कि language-independent tests पर आधारित लाइब्रेरी पोर्टिंग प्रोजेक्ट अब कहीं ज़्यादा व्यावहारिक हो गए हैं
  इसका केंद्र html5lib-tests नाम का 9,000 से अधिक HTML5 parser tests का संग्रह है। Servo का html5ever(Rust), Emil का JustHTML(Python), और मेरा JavaScript version — तीनों ही इन tests का उपयोग करते हैं
  coding agent का इस्तेमाल करके Python code को JavaScript में port किया गया और सभी tests पास होने तक उसे अपने-आप बार-बार चलाया जा सका
  ऐसे standardized test suites बहुत कम मिलते हैं, लेकिन जहाँ वे मौजूद हैं, वहाँ ये बड़ी संभावना दिखाते हैं

  • WHATWG spec और html5lib tests को साथ जोड़ने पर यह और भी शक्तिशाली हो जाता है
    मैंने कल ही कुछ घंटों में OCaml में type-annotated version बनाया, और pure OCaml HTML5 validator को अपने-आप build करने के लिए agent चला रखा है
    html5lib tests और validator tests को मिलाकर कम dependencies वाला OCaml HTML5 validator बनाया जा रहा है
    यह कुछ-कुछ reverse formal verification जैसा लगता है — बिखरे हुए तथ्यों (tests) से structured specification की ओर अभिसरण करने की प्रक्रिया
  • कल Python से Rust में port करते समय LLM समस्या को बिल्कुल पकड़ नहीं पाया। आखिर में Python original को Rust project में copy करके तुलना की, तब तुरंत समाधान मिला
    लगता है यह भाषाओं के बीच pattern matching में काफ़ी मज़बूत है। latent space के नज़रिये से देखें तो बात समझ आती है
  • अगला कदम शायद project-specific tests को independent format में बदलना, उन्हें original के साथ verify करना, और फिर port करना होगा
  • LLM भाषाओं के बीच porting में बहुत मज़बूत है। MLE-Bench जैसे benchmarks में agents 24 घंटे के भीतर Kaggle competitions में medal-level solutions तक पहुँच रहे हैं
    AI4AI paper की तरह, AI द्वारा AI बनाने का दौर मानो पहले ही शुरू हो चुका है
  • इसी वजह से मैंने फिलहाल मौजूदा project के tests को सार्वजनिक न करने का निर्णय लिया है। सामान्यतः मैं उन्हें open source के रूप में जारी करता हूँ, लेकिन इस बार फिर से सोच रहा हूँ

• दरअसल Firefox का HTML5 parser मूल रूप से Java में लिखा गया था, और बाद में semi-automatically Gecko के लिए C++ में बदला गया
  JustHTML port अपने-आप में एक अच्छा प्रयोग है, लेकिन व्यक्तिगत रूप से मुझे लगता है कि Java code को TypeScript में ले जाना ज़्यादा उत्पादक होता

  • हैरानी की बात है कि Firefox का Java parser अभी भी maintain किया जा रहा है
    संबंधित folder और हाल का commit देखें तो नवंबर में भी updates हुए थे
  • बेहतर तरीके कई थे, लेकिन मुझे Emil का API design पसंद आया, इसलिए JustHTML को आधार बनाया
    उसने 1,000 से अधिक commits से जो library बनाई, उसे एक शाम में Python में port करके देखना दिलचस्प था
  • कानूनी दृष्टि से देखें तो भाषा बदलकर port किया गया code भी अब भी derivative work ही है
    यदि license MIT है, तो original का copyright notice और license text ज्यों का त्यों शामिल होना चाहिए
    यानी original copyright line के नीचे अपना copyright information जोड़ना सही है
  • debugging और auditing के लिहाज़ से मुझे JavaScript में लिखना बेहतर लगता है
    TypeScript का फायदा developer experience सुधारना है, लेकिन machine-generated code में इसकी ज़रूरत कुछ कम हो जाती है

• “code लगभग मुफ़्त है” इस बात पर असली लागत इस बात से तय होती है कि इंसान उस code को समझ और बदल सकते हैं या नहीं
  LLM द्वारा बनाया गया code भी आखिरकार जटिल bugs या context-related समस्याओं में इंसानी दख़ल माँगता है

  • लेकिन हो सकता है कि कभी ऐसा समय आए जब maintenance की तुलना में दोबारा नया बनाना ही ज़्यादा सस्ता और तेज़ हो

• original repository के test results देखें तो html5lib-tests के सभी 9,000 tests पास हो जाते हैं
  लेकिन हर browser का व्यवहार अलग होता है। उदाहरण के लिए selectolax, html5lib के हिसाब से 68% है, लेकिन Chrome से तुलना करें तो 90% से अधिक मेल खाता है

  • यह namespace handling की समस्या है। <svg title> एक SVG-specific tag है, इसलिए parser को इसे पहचानना चाहिए
    Chrome पर भी tests चलाकर देखना दिलचस्प होगा

• हाल में HN पर आया "software cost 90% कम हो गया" लेख भी इसी संदर्भ से जुड़ता है

  • लेकिन वह लेख एक सरल बना दिया गया दावा है। Simon का experiment संभव हो पाया क्योंकि उसके पास 9,000 language-independent tests और existing API design था
    ज़्यादातर projects में ऐसी शर्तें नहीं होतीं, इसलिए इसे सामान्य रूप से लागू करना मुश्किल है

• copyright और ethics के सवाल पर, मैं MIT license वाले project को Claude Code से Rust/Python versions में port कर रहा हूँ
  मेरा मानना है कि open source की भावना यही है कि मौजूदा code को बेहतर बनाकर ecosystem को आगे बढ़ाया जाए
  लेकिन GPL projects को मैं कभी port नहीं करता

  • किसी भी license में copyright का सम्मान होना चाहिए, और LLM द्वारा किया गया port भी derivative work माना जाना चाहिए
  • जिसने GPL चुना है, उसके पीछे स्पष्ट मंशा होती है, इसलिए LLM का इस्तेमाल करके license bypass करने की कोशिश उसकी भावना को नुकसान पहुँचाती है

• यह आलोचना भी थी कि “ऐसा करने के बाद ही कानूनी और नैतिक सवाल पूछना गैर-जिम्मेदाराना है”

  • लेकिन मैंने यह जोखिम जान-बूझकर बहस को उकसाने के लिए लिया
    मुझे लगता है कि इस समय यह दिखाना ज़रूरी है कि ऐसी चीज़ें “सिर्फ संभव ही नहीं, बल्कि हैरान करने वाली हद तक आसान” हैं

• oracle approach अपनाएँ तो standard tests न होने पर भी यह व्यावहारिक हो सकता है
  original program के input/output को capture करके उसे test बनाया जा सकता है, और Hypothesis जैसे tools से हज़ारों cases अपने-आप generate किए जा सकते हैं
  अब वह दौर आ रहा है जहाँ codebase की बजाय test suite itself ही मुख्य asset बन सकती है

  • सच में यह सवाल भी आता है कि क्या सिर्फ tests से पूरा app बनाया जा सकता है

• GPT-5.2 को 9,000 lines का पूरा JavaScript code generate करने में $28.31 लगे
  अगर दक्षता ऐसी ही रही, तो 5~10 साल में junior और mid-level developers की भूमिका काफ़ी घट सकती है
  cost calculation link देखें

  • लेकिन यह एक ideal case है, जहाँ मौजूदा project को port किया जा रहा है। एक नई library को शुरू से बनाना अभी भी अलग बात है
    फिर भी छोटे ecosystem वाली भाषाओं में बड़ा आर्थिक बदलाव आ सकता है
  • “software engineer” की अवधारणा खत्म नहीं होगी, बस उसकी भूमिका और अपेक्षाएँ बदलेंगी
  • यह आपत्ति भी थी कि “क्या हम दिन भर सिर्फ language porting ही करते रहते हैं?” वास्तविकता इससे कहीं अधिक जटिल है

• हर AI porting सफल नहीं होती। असफल उदाहरण भी हैं → The port I couldn’t ship

  • सफलता काफी हद तक source code के मुकाबले test ratio पर निर्भर करती है
    कौन-सा project आसान है, कौन-सा approach तेज़ है — इस पर अगर data जमा हो, तो बहुत दिलचस्प analysis बन सकता है
    Simon अगर ऐसे comparative experiments करे, तो वह सच में बहुत रोचक होगा