พอร์ต JustHTML จาก Python ไปยัง JavaScript: เสร็จใน 4.5 ชั่วโมงด้วย Codex CLI และ GPT-5.2

 (simonwillison.net)
7 คะแนน โดย GN⁺ 2025-12-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • กรณีศึกษาการ พอร์ต HTML5 parser JustHTML จาก Python ไปเป็น JavaScript แบบสมบูรณ์ โดยใช้ Codex CLI และ GPT-5.2 จนทำเสร็จได้ภายในราว 4.5 ชั่วโมง
  • ไลบรารีใหม่ JustJSHTML เป็น HTML5 parser ที่ไม่มี dependency ผ่านการทดสอบของ html5lib-tests 9,200 รายการ และถอดแบบการออกแบบ API ต้นฉบับไว้ครบถ้วน
  • กระบวนการทั้งหมดดำเนินผ่าน 8 prompt และคำสั่งติดตามผลอีกไม่กี่ครั้ง โดย GPT-5.2 สร้างโค้ด 9,000 บรรทัดและ 43 commit โดยอัตโนมัติ
  • โปรเจ็กต์นี้เสร็จสมบูรณ์ในรูปแบบโอเพนซอร์สครบถ้วน รวมถึง การ commit อัตโนมัติ, การทดสอบ, เอกสาร, และการสร้างหน้า playground
  • การทดลองครั้งนี้ชี้ให้เห็นทั้ง ประสิทธิภาพการทำงานจริงของ coding agent ที่ขับเคลื่อนด้วย LLM และการตั้งคำถามใหม่เรื่อง ลิขสิทธิ์ จริยธรรม และความน่าเชื่อถือ

ภาพรวมโปรเจ็กต์

  • JustHTML คือ HTML5 parser ที่สอดคล้องตามมาตรฐาน พัฒนาโดย Emil Stenström เขียนด้วย Python และเป็น implementation ที่ผ่าน html5lib-tests ได้ครบทั้งหมด
    • html5lib-tests คือ มาตรฐานของการทดสอบ interoperability ระหว่าง HTML5 parser และถูกใช้ในหลายโปรเจ็กต์ เช่น html5ever ของ Servo
  • Simon Willison ตัดสินใจ พอร์ตโปรเจ็กต์นี้ไปยัง JavaScript ด้วยตัวเอง โดยใช้ Codex CLI และ GPT-5.2 เพื่อลดงานที่ต้องทำด้วยมือให้น้อยที่สุด
  • ผลลัพธ์คือ JustJSHTML ซึ่ง ทำงานได้ทั้งบนเบราว์เซอร์และ Node.js และ เขียนด้วย JavaScript ล้วนโดยไม่มี dependency ภายนอก

กระบวนการพัฒนา

  • โคลนรีโพสิทอรี justhtml และ html5lib-tests ในเครื่อง แล้วสร้างไดเรกทอรีใหม่ justjshtml
  • รัน Codex CLI ด้วยออปชัน --yolo (ข้ามการอนุมัติและ sandbox) เพื่อใช้งานโมเดล GPT-5.2
  • ใน prompt แรก สั่งให้วิเคราะห์โค้ด Python เดิมแล้วเขียน สเปก JavaScript API ใหม่ (spec.md)
    • เริ่มจากระยะต้น (Milestone 0.5) ด้วยการทำเวอร์ชันที่ผ่านการทดสอบการ parse เอกสาร HTML แบบง่าย
  • หลังจากนั้นจึงให้พัฒนาอัตโนมัติเป็นลำดับผ่านคำสั่งอย่าง “Implement Milestone 0.5”, “** commit and push often**”
    • ตั้งค่า GitHub Actions เพื่อ รันทดสอบทุกครั้งที่มี commit
    • สุดท้ายได้ผลลัพธ์เป็น 43 commit, โค้ด 9,000 บรรทัด, และ ผ่านการทดสอบ 9,200 รายการ

ผลลัพธ์และสิ่งที่ได้

  • Codex CLI ใช้ไปทั้งหมด 2,089,858 token และทำงานได้ภายใต้แพ็กเกจรายเดือน ChatGPT Plus โดยไม่มีค่าใช้จ่ายเพิ่มเติม
  • ไลบรารีที่เสร็จสมบูรณ์มีความสามารถต่อไปนี้
    • การขยาย API เช่น stream() , query()/matches() , toMarkdown()
    • สคริปต์ unit test แบบ no-deps และการผสานกับ CI
    • แก้บั๊กย่อยต่าง ๆ เช่น ข้อผิดพลาดในการจัดการแท็ก <br>
  • มีการสร้าง playground.html อัตโนมัติ ทำให้ทดสอบบนเบราว์เซอร์ได้โดยตรง
  • ใน README.md มีทั้งวิธีใช้งาน ขั้นตอน build และตัวอย่างสำหรับ Node.js กับสภาพแวดล้อม HTML

นัยสำคัญของการใช้ LLM

  • GPT-5.2 ทำงานต่อเนื่องหลายชั่วโมงพร้อมการเรียกใช้เครื่องมือหลายร้อยครั้งได้โดย แทบไม่ต้องมีการกำกับดูแล
  • หากสามารถนิยามปัญหาแบบ test-driven ได้ coding agent ก็มีศักยภาพในการ สร้างโค้ดคุณภาพสูงได้อย่างอัตโนมัติ
  • งานเชิงโครงสร้างอย่าง การพอร์ตข้ามภาษา เป็นสิ่งที่ LLM ทำได้อย่างมีประสิทธิภาพมาก
  • ต้นทุนของการสร้างโค้ดลดลงจนแทบจะอยู่ในระดับ “เกือบฟรี” แต่ ต้นทุนในการดูแลโค้ดที่ผ่านการตรวจสอบแล้ว ยังคงมีอยู่

คำถามด้านจริยธรรมและกฎหมายที่ถูกหยิบยกขึ้นมา

  • ประเด็นว่าเข้าข่าย ละเมิดลิขสิทธิ์ ของโค้ดต้นฉบับ Rust และ Python หรือไม่
  • ปัญหาเรื่อง การถือครองลิขสิทธิ์ ของโค้ดที่ LLM สร้างขึ้น
  • ผลกระทบที่แนวทางพัฒนาแบบนี้จะมีต่อ ระบบนิเวศโอเพนซอร์ส
  • ความน่าเชื่อถือของโค้ดที่สร้างอัตโนมัติ และ ความรับผิดชอบเมื่อใช้งานในโปรดักชัน
  • ความเป็นไปได้ในการ เปรียบเทียบคุณภาพ กับโค้ดที่ผู้เชี่ยวชาญมนุษย์ใช้เวลาพัฒนาหลายเดือน

บทสรุป

  • กรณีศึกษานี้แสดงให้เห็นถึง อีกขั้นของระบบอัตโนมัติในการเขียนโปรแกรม และพิสูจน์ ศักยภาพเชิงปฏิบัติของ AI coding agent
  • ขณะเดียวกันก็ทิ้งโจทย์สำคัญไว้ทั้งเรื่อง ความจำเป็นในการกำหนดมาตรฐานทางกฎหมายและจริยธรรม และ การนิยามรูปแบบความร่วมมือในโอเพนซอร์สขึ้นใหม่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-12-19
ความเห็นจาก Hacker News

  • สิ่งที่น่าสนใจที่สุดในกรณีนี้คือโปรเจ็กต์พอร์ตไลบรารีที่อิงกับ การทดสอบที่ไม่ขึ้นกับภาษา กลายเป็นสิ่งที่ทำได้จริงมากขึ้นอย่างมาก
    แกนสำคัญคือชุดทดสอบตัวแยกวิเคราะห์ HTML5 กว่า 9,000 รายการชื่อ html5lib-tests Servo มี html5ever (Rust), JustHTML ของ Emil (Python) และเวอร์ชัน JavaScript ของผมก็ใช้ชุดทดสอบนี้ทั้งหมด
    เราสามารถใช้ coding agent พอร์ตโค้ด Python ไปเป็น JavaScript แล้วให้มันรันซ้ำอัตโนมัติจนกว่าจะผ่านทุกเทสต์ได้
    ชุดทดสอบมาตรฐาน แบบนี้หาได้ไม่บ่อย แต่ที่ใดมี มันก็แสดงให้เห็นศักยภาพอย่างมาก

    • ถ้ารวม WHATWG spec เข้ากับ html5lib tests ก็จะยิ่งทรงพลังขึ้นมาก
      เมื่อวานผมใช้เวลาไม่กี่ชั่วโมงสร้างเวอร์ชันที่มี type ชัดเจนใน OCaml และปล่อย agent ให้สร้าง HTML5 validator แบบ pure OCaml โดยอัตโนมัติอยู่
      ตอนนี้กำลังรวม html5lib tests กับ validator tests เพื่อสร้าง OCaml HTML5 validator ที่มี dependency น้อย
      มันให้ความรู้สึกเหมือน การตรวจสอบรูปแบบแบบย้อนกลับ — เป็นกระบวนการค่อย ๆ รวมข้อเท็จจริงที่กระจัดกระจาย (เทสต์) ให้กลายเป็นสเปกที่มีโครงสร้าง
    • เมื่อวานผมพอร์ตจาก Python ไป Rust แล้ว LLM กลับจับปัญหาไม่ได้เลย สุดท้ายพอคัดลอกต้นฉบับ Python เข้าไปในโปรเจ็กต์ Rust เพื่อเทียบกัน ปัญหาก็แก้ได้ทันที
      ดูเหมือนมันจะเก่งพอสมควรกับ การจับคู่แพตเทิร์น ข้ามภาษา ซึ่งก็ดูสมเหตุสมผลถ้ามองจากมุม latent space
    • ขั้นต่อไปน่าจะเป็นการแปลงชุดทดสอบที่ผูกกับโปรเจ็กต์ให้เป็น ฟอร์แมตอิสระ แล้วค่อยใช้ตรวจสอบกับต้นฉบับก่อนพอร์ต
    • LLM เก่งมากกับการพอร์ตข้ามภาษา ใน benchmark อย่าง MLE-Bench agent สามารถแก้โจทย์แข่งขัน Kaggle ได้ถึงระดับมีลุ้นเหรียญภายใน 24 ชั่วโมง
      มันให้ความรู้สึกว่ายุคที่ AI สร้าง AI อย่างใน งานวิจัย AI4AI ได้เริ่มขึ้นแล้ว
    • ด้วยเหตุนี้ ตอนนี้ผมจึงตัดสินใจว่าจะยังไม่เปิดเผยเทสต์ของโปรเจ็กต์นี้ ปกติผมมักปล่อยเป็นโอเพนซอร์ส แต่ครั้งนี้กำลังทบทวนอยู่

  • จริง ๆ แล้ว HTML5 parser ของ Firefox เดิมเขียนด้วย Java และต่อมาถูกแปลงแบบกึ่งอัตโนมัติไปเป็น C++ สำหรับ Gecko
    การพอร์ต JustHTML เองก็เป็นการทดลองที่ดี แต่ส่วนตัวผมคิดว่าการย้ายโค้ด Java ไป TypeScript น่าจะมีประสิทธิผลมากกว่า

    • น่าแปลกที่ Java parser ของ Firefox ยังถูกดูแลอยู่จนถึงตอนนี้
      ดูจากโฟลเดอร์ที่เกี่ยวข้อง และคอมมิตล่าสุด จะเห็นว่ามีการอัปเดตในเดือนพฤศจิกายนด้วย
    • มีวิธีที่ดีกว่านี้อีกหลายแบบ แต่ผมชอบ การออกแบบ API ของ Emil เลยเลือกใช้ JustHTML เป็นฐาน
      การได้ลองพอร์ตไลบรารีที่เขาสร้างจากคอมมิตกว่า 1,000 ครั้งมาเป็น Python ในเวลาแค่เย็นวันเดียวเป็นเรื่องที่น่าสนใจมาก
    • ในมุมมองทางกฎหมาย โค้ดที่พอร์ตโดยเปลี่ยนภาษาแล้วก็ยังคงเป็น งานดัดแปลง อยู่ดี
      ถ้าเป็นไลเซนส์ MIT คุณต้องคงข้อความลิขสิทธิ์และข้อความไลเซนส์ของต้นฉบับไว้ตามเดิม
      กล่าวคือควรเพิ่มข้อมูลลิขสิทธิ์ของตัวเองไว้ใต้บรรทัดลิขสิทธิ์ของต้นฉบับ
    • ในแง่การดีบักและการตรวจสอบ ผมคิดว่าเขียนเป็น JavaScript จะดีกว่า
      ข้อดีของ TypeScript คือการปรับปรุงประสบการณ์นักพัฒนา แต่สำหรับ โค้ดที่สร้างโดยเครื่อง ความจำเป็นตรงนี้ลดลง

  • สำหรับคำพูดที่ว่า “โค้ดแทบจะฟรีแล้ว” ต้นทุนจริงอยู่ที่คนยัง เข้าใจและแก้ไข โค้ดนั้นได้หรือไม่
    แม้จะเป็นโค้ดที่ LLM สร้างขึ้น สุดท้ายเมื่อเจอบั๊กซับซ้อนหรือปัญหาเรื่องบริบท ก็ยังต้องมีมนุษย์เข้ามาแทรกแซง

    • แต่ก็เป็นไปได้ว่าสักวันหนึ่งโลกจะมาถึงจุดที่การสร้างใหม่ถูกและเร็วกว่าการบำรุงรักษา

  • ถ้าดูผลเทสต์ของ repository ต้นฉบับ จะเห็นว่าผ่านทั้ง 9,000 เทสต์ของ html5lib-tests
    แต่เบราว์เซอร์แต่ละตัวมีวิธีจัดการต่างกัน ตัวอย่างเช่น selectolax ได้ 68% ตามเกณฑ์ html5lib แต่ถ้าเทียบกับ Chrome จะตรงกันเกิน 90%

    • นี่เป็นปัญหาเรื่อง การจัดการ namespace <svg title> เป็นแท็กเฉพาะของ SVG ดังนั้น parser ต้องรู้จักมัน
      ถ้าลองรันเทสต์กับ Chrome เองก็น่าจะน่าสนใจ

  • มันยังเชื่อมโยงกับบทความ "ต้นทุนซอฟต์แวร์ลดลง 90% แล้วหรือยัง" ที่เพิ่งขึ้น HN ไม่นานนี้ด้วย

    • แต่บทความนั้นเป็นการอ้างที่เรียบง่ายเกินไป การที่การทดลองของ Simon ทำได้ เป็นเพราะมีทั้ง ชุดทดสอบอิสระจากภาษาจำนวน 9,000 รายการ และ การออกแบบ API ที่มีอยู่แล้ว
      โปรเจ็กต์ส่วนใหญ่ไม่มีเงื่อนไขแบบนี้ จึงยากจะสรุปเป็นภาพรวม

  • เรื่องลิขสิทธิ์และจริยธรรม ตอนนี้ผมกำลังใช้ Claude Code พอร์ตโปรเจ็กต์ MIT license ไปเป็นเวอร์ชัน Rust/Python
    ผมมองว่าจิตวิญญาณของโอเพนซอร์สคือการนำโค้ดเดิมมาปรับปรุงและช่วยให้ ecosystem พัฒนาต่อไป
    แต่ โปรเจ็กต์ GPL ผมจะไม่พอร์ตเด็ดขาด

    • ไม่ว่าไลเซนส์ไหนก็ต้องเคารพลิขสิทธิ์ และงานพอร์ตที่ LLM สร้างก็ถือเป็นงานดัดแปลง
    • นักพัฒนาที่เลือก GPL มีเจตนาชัดเจนอยู่แล้ว ดังนั้นการใช้ LLM เพื่อพยายาม เลี่ยงไลเซนส์ จึงเป็นการบั่นทอนเจตนานั้น

  • ยังมีเสียงวิจารณ์ว่า “มาถามเรื่องกฎหมายและจริยธรรมเอาหลังจากทำด้วยวิธีนี้แล้วเป็นเรื่องไม่รับผิดชอบ”

    • แต่ผมจงใจยอมรับความเสี่ยงบางส่วน เพื่อกระตุ้นให้เกิดการถกเถียงนี้
      ตอนนี้สิ่งสำคัญคือการแสดงให้เห็นว่าสิ่งนี้ “ไม่ใช่แค่ทำได้ แต่ยังง่ายอย่างน่าตกใจ”

  • ถ้าใช้แนวทางแบบ oracle approach ต่อให้ไม่มีเทสต์มาตรฐานก็ยังใช้ได้จริง
    คุณสามารถจับ input/output ของโปรแกรมต้นฉบับมาใช้เป็นเทสต์ แล้วใช้เครื่องมืออย่าง Hypothesis สร้างเคสหลายพันรายการได้อัตโนมัติ
    ตอนนี้เรากำลังเข้าสู่ยุคที่แทนที่ codebase จะเป็นทรัพย์สินหลัก กลับกลายเป็น ตัว test suite เอง ที่สำคัญที่สุด

    • ถึงขั้นทำให้คิดได้ว่า เป็นไปได้ไหมที่จะสร้างทั้งแอปจากแค่เทสต์

  • GPT-5.2 ใช้เงิน $28.31 ในการสร้างโค้ด JavaScript ที่สมบูรณ์จำนวน 9,000 บรรทัด
    ถ้าประสิทธิภาพได้ระดับนี้ ภายใน 5–10 ปีข้างหน้า บทบาทของ นักพัฒนาระดับ junior และ mid-level น่าจะลดลงอย่างมาก
    ดู ลิงก์คำนวณต้นทุน ประกอบ

    • แต่กรณีนี้เป็นตัวอย่างในอุดมคติของการ พอร์ต โปรเจ็กต์ที่มีอยู่แล้ว การสร้างไลบรารีใหม่ตั้งแต่ศูนย์ยังเป็นอีกเรื่องหนึ่ง
      ถึงอย่างนั้น สำหรับภาษาที่มี ecosystem ขนาดเล็ก มันก็น่าจะสร้างการเปลี่ยนแปลงทางเศรษฐกิจครั้งใหญ่ได้
    • แนวคิดเรื่อง “software engineer” จะไม่หายไป แต่บทบาทและความคาดหวังจะเปลี่ยน
    • ก็มีคนโต้แย้งเหมือนกันว่า “งานที่เราทำทั้งวันคือพอร์ตภาษากันอย่างเดียวหรือไง” เพราะความจริงมันซับซ้อนกว่านั้นมาก

  • ไม่ใช่ว่าการพอร์ตด้วย AI จะสำเร็จเสมอไป ยังมีกรณีล้มเหลวเช่นกัน → The port I couldn’t ship

    • ความสำเร็จหรือความล้มเหลวขึ้นอยู่มากกับ สัดส่วนระหว่างซอร์สโค้ดกับเทสต์
      ถ้ามีข้อมูลสะสมมากพอว่าโปรเจ็กต์แบบไหนง่าย วิธีไหนเร็ว ก็น่าจะเป็นการวิเคราะห์ที่น่าสนใจมาก
      ถ้า Simon ลองทำการทดลองเปรียบเทียบแบบนี้ คงน่าสนใจมากจริง ๆ